Gängige Anwendungsfälle für Konnektivitätstests

Konnektivitätstests bewerten, ob der Traffic zwischen den Endpunkten innerhalb Ihres Netzwerks erfolgreich übertragen wird. Sie bewerten die Erreichbarkeit durch Analysen der Netzwerkkonfiguration und in bestimmten Anwendungsfällen durch das Senden von Prüfpaketen.

Auf dieser Seite werden häufige Anwendungsfälle für Konnektivitätstests beschrieben, die in sechs Kategorien unterteilt werden:

  • Testen in VPC-Netzwerken (Virtual Private Cloud), einschließlich Netzwerken, die freigegebene VPCs und VPC-Netzwerk-Peering verwenden
  • Testen der von Google verwalteten Dienste (Vorschau)
  • Testen von einem VPC-Netzwerk zu einem Nicht-VPC-Netzwerk, z. B. einem lokalen Rechenzentrum
  • Aus einem Nicht-Google Cloud-Netzwerk zu einem VPC-Netzwerk testen
  • Von einem Nicht-Google Cloud-Netzwerk zu einem anderen Nicht-Google Cloud-Netzwerk testen
  • Google Cloud-Load-Balancer testen

Unter Ungültige oder inkonsistente Konfigurationen erkennen wird erläutert, wie mit diesen Szenarien verfahren werden kann.

Der Anwendungsfall für das Testen von einer VM-Instanz zu einer anderen beschreibt ein vollständiges End-to-End-Testszenario, einschließlich der Testergebnisse bereitgestellt in der Google Cloud Console.

Anleitungen zum Ausführen von Tests finden Sie unter Konnektivitätstests ausführen.

Legende für Trace-Diagramme

Für Trace-Diagramme auf dieser Seite werden die in der folgenden Legende beschriebenen Symbole verwendet.

Symbol Name Bedeutung
Grafik: Legende für das Paket-Trace-Diagramm: graue Raute.
Graue Raute
Prüfpunkt Ein Entscheidungspunkt, an dem Konnektivitätstests eine Konfiguration prüfen und entscheiden, ob ein Trace-Paket weitergeleitet, zugestellt oder verworfen werden soll.
Legende für das Paket-Trace-Diagramm: blaues Rechteck.
Blaues Rechteck
Hop Ein Schritt im Weiterleitungspfad für ein Trace-Paket, das eine Google Cloud-Ressource darstellt, die ein Paket an den nächsten Hop in einem VPC-Netzwerk weiterleitet (z. B. zu einem Cloud Load Balancing-Proxy oder zu einem Cloud VPN-Tunnel).
Legende für das Paket-Trace-Diagramm: orangefarbenes Sechseck.
Orangefarbenes Sechseck
Endpunkt Die Quelle oder das Ziel eines Trace-Pakets.

In VPC-Netzwerken testen

Ein häufiger Anwendungsfall für Konnektivitätstests ist das Testen von zwei Compute Engine-VM-Instanzen in denselben VPC-Netzwerken oder in Peering-VPC-Netzwerken. Bei dieser Art des Tests bewerten Konnektivitätstests die Erreichbarkeit mithilfe von Konfigurationsanalysen und dynamischen Prüfungen.

Zum Analysieren der Konfiguration bestimmen Konnektivitätstests einen Trace-Pfad und werten ihn aus.

Das folgende Diagramm zeigt den typischen Trace-Pfad zwischen zwei VM-Instanzen. Das Match routes-Objekt kann Routen darstellen, die den Traffic in einem einzelnen VPC-Netzwerk oder zwischen zwei Peering-VPC-Netzwerken weiterleiten.

Quell-VM zum Ziel-VM-Trace
Quell-VM zum Ziel-VM-Trace

In den folgenden Schritten werden die Prüfpunkte erläutert, die den einzelnen Punkten im Trace-Diagramm entsprechen. Die Prüfung kann an jedem Prüfpunkt fehlschlagen. In den Abfrageergebnissen wird dann der Grund für den jeweiligen Fehler angezeigt. Eine vollständige Liste der Teststatus und der Testnachrichten finden Sie in der Referenz zu den Status der Konfigurationsanalyse.

  1. Konnektivitätstests prüfen, ob die Quell-VM Pakete mit ausgehendem Traffic mit der angegebenen Quell-IP-Adresse senden oder anderweitig automatisch die primäre interne IP-Adresse verwenden kann. Andernfalls muss für diese VM die IP-Weiterleitung aktiviert sein.
  2. Konnektivitätstests führen eine Spoof-Prüfung durch, wenn ein simuliertes Paket an oder von einer VM-Instanz eine IP-Adresse verwendet, die dieser Instanz nicht gehört. Zu den IP-Adressen einer VM gehören alle internen und sekundären IP-Adressen der VM.

    Wenn die Adresse scheinbar aus externem Traffic stammt (auch als fremde Adresse bezeichnet), besteht die IP-Adresse die Spoof-Prüfung nicht.

  3. Um zu ermitteln, ob Trace-Pakete von der Quelle gesendet werden können, prüfen die Konnektivitätstests die entsprechenden Regeln für ausgehenden Traffic. Im Rahmen dieses Vorgangs beginnt der Konnektivitätstest zuerst mit der Auswertung der vorhandenen hierarchischen Firewallregeln. Weitere Informationen dazu, wie hierarchische Firewallregeln und VPC-Firewallregeln die Konnektivität beeinflussen, finden Sie unter Beispiele für hierarchische Firewallrichtlinien.
  4. Konnektivitätstests ermitteln eine Route für die Ziel-IP-Adresse gemäß der Routingreihenfolge. Wenn für die Ziel-VM-Instanz keine anderen Routen verfügbar sind, verwenden Konnektivitätstests die standardmäßige statische Route mit dem nächsten Hop als Internetgateway. Alle VPC-Netzwerke verwenden diese Standardroute, sofern Sie sie nicht entfernt haben.
  5. Mit Konnektivitätstests wird geprüft, ob die eingehenden Firewallregeln des Netzwerks den Empfang der Ziel-VM zulassen. Die Konnektivitätstests beginnen wiederum mit der Auswertung aller hierarchischen Firewallregeln, die bereits vorhanden sind.
  6. Bei Bedarf führen Konnektivitätstests eine Spoof-Prüfung für das Paket aus, das an der zweiten VM eingeht.
  7. Konnektivitätstests prüfen, ob die Ziel-VM ein Paket mit der angegebenen Ziel-IP-Adresse empfangen kann. Wenn diese Adresse eine fremde IP-Adresse ist, muss die Ziel-VM IP-Weiterleitung aktiviert haben. Eine fremde IP-Adresse ist eine Adresse, die nicht zur VM gehört.

Console

Die folgende Abbildung der Google Cloud Console zeigt die Ergebnisse eines VM-zu-VM-Tests.

Die Konfigurationsanalyse zeigt das Ergebnis Paket konnte übertragen werden. In der API-Antwort entspricht dieses Label dem endgültigen Zustand Deliver.

Dieses Ergebnis gibt an, dass die Konfigurationsanalyse die Netzwerkverbindung für jede Google Cloud-Ressource im Pfad von der Quell-VM zur Ziel-VM validiert hat. In diesem Fall gehören zur Route zwei VPC-Firewallregeln: eine implizite VPC-Firewallregel mit dem Namen default und eine Firewallregel, die für dieses VPC-Netzwerk erstellt wurde.

Außerdem wurde mit den Konnektivitätstests dynamisch geprüft, ob die Ziel-VM erreichbar ist. Dazu wurde die aktive Prüfung verwendet. Im Feld Ergebnis der letzten Paketübertragung werden die Details dieses Ergebnisses angezeigt.

Screenshot der Cloud Console für das VM-zu-VM-Trace
Screenshot der Cloud Console für das VM-zu-VM-Trace

Sie können jede der Karten im Trace-Pfad erweitern, um weitere Details anzusehen.

Das folgende Beispiel zeigt eine erweiterte Karte für eine Firewallregel für eingehenden Traffic. Diese Karte enthält Informationen zum VPC-Netzwerk, zur konfigurierten Aktion für die Firewallregel (Zulassen) und zur Regelpriorität.

Erweiterte Karte für die Firewallregel für eingehenden Traffic
Erweiterte Karte für die Firewallregel für eingehenden Traffic

Wenn ein Trace eine VPC-Netzwerkroute mit dem nächsten Hop als Peering-VPC-Netzwerk enthält, ist der Start des Trace keine VM-Instanz, sondern ein VPC-Netzwerk. Diese Art von Trace prüft Firewallregeln und -routen auf Netzwerkebene, da die getestete IP-Adresse aus einem Netzwerkbereich statt einer VM-Instanz stammt.

Peering-Netzwerke können im selben oder in verschiedenen Projekten vorhanden sein. Das folgende Trace-Beispiel zeigt Peering-Netzwerke in verschiedenen Projekten.

VM-zu-VM-Trace über ein zugängliches Peering-VPC-Netzwerk in einem anderen Projekt
VM-zu-VM-Trace über ein zugängliches Peering-VPC-Netzwerk in einem anderen Projekt

Testfehler bei VPC-Netzwerken

In der folgenden Tabelle sind häufige Fehler bei Tests in VPC-Netzwerken aufgeführt.

Fehlertyp Beschreibung Trace-Ergebnisse
Durch eine Firewallregel blockiert Traffic, der einen Quell- oder Zielendpunkt verlässt, wird durch eine hierarchische Firewallregel oder eine VPC-Firewallregel blockiert.
  • Wenn die Verbindung durch eine hierarchische Firewallregel blockiert wird, enthält der Trace den Namen der Richtlinie. Beachten Sie, dass der Nutzer, der den Test ausführt, möglicherweise nicht berechtigt ist, die Richtliniendetails aufzurufen. Weitere Informationen dazu finden Sie unter Fehlerbehebung.
  • Wenn die Verbindung durch eine VPC-Firewallregel blockiert wird, ist im Trace der Name der entsprechenden Firewallregel für eingehenden oder ausgehenden Traffic aufgeführt.
Keine passende Route Eine Route zum Zielendpunkt wurde nicht gefunden.
  • Wenn sich die Quell- und Ziel-VM-Instanzen in verschiedenen VPC-Netzwerken befinden und diese Netzwerke nicht über Peering verbunden sind, gibt die Analyse das Ergebnis Paket konnte verworfen werden aus.
  • Wenn sich die VMs im selben Netzwerk befinden, aber keine passende Route gefunden wird, wird der Traffic über die statische Standardroute mit einem nächsten Hop an das Internetgateway gesendet. In diesem Fall erreicht der Traffic nie die Ziel-VM und die Analyse gibt das Ergebnis Paket konnte verworfen werden aus.
  • Wenn keine Route zu einem Internet-Gateway vorhanden ist, gibt die Analyse das Ergebnis Paket konnte verworfen werden aus.
Instanz wird nicht ausgeführt Die Ziel-VM-Instanz ist vorhanden, ist jedoch nicht im ausgeführten Zustand. Die Analyse gibt das Ergebnis Paket konnte verworfen werden aus.
Ungültiger nächster Hop Der konfigurierte nächste Hop für eine VM-Instanz ist nicht mehr vorhanden und die Route zu dieser Instanz ist ungültig. Die Analyse gibt das Ergebnis Paket konnte verworfen werden aus.

Console

Die folgende Abbildung stellt einen Trace dar, der fehlgeschlagen ist, da die Verbindung durch eine hierarchische Firewallregel für eingehenden Traffic blockiert wird.

Cloud Console mit einem Trace, der durch eine hierarchische Firewallregel blockiert wird
Cloud Console mit einem Trace, der durch eine hierarchische Firewallregel blockiert wird

Testfehler bei freigegebenen VPC-Netzwerken

In gemeinsam genutzten VPC-Netzwerken kann das Fehlen von Berechtigungen für das Hostprojekt oder das Serviceprojekt zu den in der folgenden Tabelle aufgeführten Testfehlern führen.

Fehlertyp Verhalten Trace-Ergebnisse
Berechtigungen nur für das Hostprojekt Sie können das Trace nicht ausführen, da Sie keine Berechtigungen für das Dienstprojekt haben, in dem sich die Ziel-IP-Adresse befindet. Die Konfigurationsanalyse zeigt das Ergebnis Konfigurationsanalyse abgebrochen an. Dieses Label entspricht dem endgültigen Zustand Abort in der API-Antwort.
Berechtigungen nur für das Dienstprojekt

Sie können das Trace nicht ausführen oder das Hostprojektnetzwerk in der Cloud Console nicht auswählen, da Sie keine Berechtigung haben.

Da das Hostprojekt Netzwerkkonfigurationen hat, kann kein Trace für Ressourcen im Dienstprojekt ohne Zugriff auf VPC-Firewallregeln, Netzwerkrouten oder IP-Adressen im Hostprojekt ausgeführt werden.

Das Gesamtergebnis zur Erreichbarkeit ist Undetermined, da Konnektivitätstests nicht feststellen können, ob das Paket an das Ziel zugestellt werden kann.

Testfehler bei VPC-Netzwerk-Peering-Netzwerken

Wenn Sie beim VPC-Netzwerk-Peering keine Berechtigung für das Google Cloud-Projekt des peered-Netzwerks aus dem primary-Netzwerk haben, können die in der folgenden Tabelle aufgeführten Testfehler auftreten.

Fehlertyp Verhalten Trace-Ergebnisse
Sie haben keine Berechtigungen für die Projektkonfiguration im Peering-VPC-Netzwerk. Konnektivitätstests können nur die Konfigurationen im Projekt des primären Netzwerks verfolgen. Die Konfigurationsanalyse gibt das Ergebnis Paket konnte weitergeleitet werden aus. Dieses Ergebnis gibt an, dass ein Paket das Netzwerk verlässt und an ein Netzwerk gesendet wird, auf das Sie keinen Zugriff haben. In diesem Fall wurde das Paket an ein Peering-Netzwerk-Gateway weitergeleitet. In der API-Antwort entspricht dieser Zustand einer Forward.

Der folgende Trace-Pfad zeigt diesen Fehler für Peering-VPC-Netzwerke.

VM-zu-VM-Trace über ein unzugängliches Peering-VPC-Netzwerk in einem anderen Projekt
VM-zu-VM-Trace über ein unzugängliches Peering-VPC-Netzwerk in einem anderen Projekt

Testen der von Google verwalteten Dienste

Sie können eine Konfigurationsanalyse der Konnektivitätstests zu Routen von und zu den von Google verwalteten Diensten wie Google Kubernetes Engine-Clustermastern (GKE) oder Cloud SQL-Instanzen abrufen. Auch wenn Sie keine Zugriffsberechtigung für das Google-Projekt haben, in dem sich diese Ressourcen befinden, können Sie mit Konnektivitätstests die Konfiguration des VPC-Netzwerks des Projekts analysieren und ein Gesamtergebnis zur Erreichbarkeit bereitstellen. Konnektivitätstests bieten keine Konfigurationsdetails für Analysen innerhalb des Google-Projekts.

Bei Konnektivitätstests wird standardmäßig versucht, einen Test mit der privaten IP-Adresse des Endpunkts eines von Google verwalteten Diensts und der VPC-Netzwerk-Peering-Verbindung zwischen Ihrem Netzwerk und dem Google-Netzwerk auszuführen. Wenn der Endpunkt keine private IP-Adresse hat, wird bei Konnektivitätstests die öffentliche IP-Adresse verwendet. Konnektivitätstests analysieren, ob das Paket den Endpunkt erreichen kann. Dazu gehört auch die Analyse der Konfiguration im Google-VPC-Netzwerk für den Endpunkt. Wenn Konnektivitätstests innerhalb Ihres Projekts Konfigurationsprobleme erkennen, wird die Analyse angehalten, bevor das Google-Netzwerk erreicht wird.

Das folgende Diagramm zeigt den Trace-Pfad, wenn Sie die Konnektivität zu von Google verwalteten Diensten testen. Dabei wird als Beispiel ein GKE-Knoten zum Master getestet:

Grafik: Trace vom GKE-Quellknoten zum GKE-Ziel-Master
Trace vom GKE-Quellknoten zum GKE-Ziel-Master

Cloud SQL zu einer VM

In diesem Abschnitt wird ein Beispieltest von einer Cloud SQL-Instanz zu einer VM beschrieben.

Beispieleingaben

Die folgende Tabelle enthält Beispieleingabewerte für einen Test von einer Cloud SQL-Instanz. Im nächsten Abschnitt können Sie sich die Ausgabe für einen erfolgreichen Test ansehen.

Eingabeparameter Eingabewert
Protokoll TCP
Cloud SQL-Quellinstanz instance-1
Quellprojekt my-project
Ziel-VM vm-1
Zielport 80

Erfolgreicher Test

Dieser Abschnitt enthält ein Beispielergebnis für einen erfolgreichen Test von einer Cloud SQL-Instanz.

Console

Der folgende Screenshot aus der Cloud Console zeigt einen Trace von einer Cloud SQL-Instanz, wobei ein Gesamtergebnis von Reachable angegeben wird.

Dieses Ergebnis zeigt, dass Konnektivitätstests die Netzwerkkonnektivität von der Cloud SQL-Quellinstanz der Ziel-VM geprüft haben. Dies schließt die Analyse der Konfiguration in dem Google-Projekt ein, in dem die Cloud SQL-Instanz ausgeführt wird. Der Trace enthält keine Details zu den Ressourcen im Google-Projekt, da Sie nicht berechtigt sind, diese anzusehen.

t Grafik: Screenshot der Cloud Console für Trace von Cloud SQL zur VM
Screenshot der Cloud Console für Trace von der Cloud SQL-Instanz zur VM

Vom GKE-Knoten zum GKE-Clustermaster

In diesem Abschnitt wird ein Beispieltest von einem GKE-Knoten zu einem GKE-Clustermaster beschrieben.

Beispieltesteingaben

Die folgende Tabelle zeigt Beispieleingabewerte für einen Test zu einem GKE-Master. Im nächsten Abschnitt können Sie sich die Ausgabe für einen erfolgreichen Test ansehen.

Eingabeparameter Eingabewert
Protokoll TCP
GKE-Quellknoten gke-cluster-1-node-1
Quellprojekt my-project
GKE-Zielclustermaster projects/myproject/locations/us-central1/clusters/cluster-1
Zielport 443

Erfolgreicher Test

Dieser Abschnitt enthält ein Beispiel für einen erfolgreichen Test zu einem GKE-Master.

Console

Der folgende Screenshot aus der Cloud Console zeigt einen Trace zu einem GKE-Zielmaster, wobei ein Gesamtergebnis von Reachable angegeben wird.

Dieses Ergebnis zeigt, dass Konnektivitätstests die Netzwerkkonnektivität vom GKE-Quellknoten zum GKE-Zielmaster geprüft haben. Dies schließt die Analyse der Konfiguration der Ressourcen innerhalb des Google-Projekts ein, in dem der Master ausgeführt wird. Der Trace enthält keine Details zu den Ressourcen im Google-Projekt, da Sie nicht berechtigt sind, diese anzusehen.

Grafik: Screenshot der Cloud Console für Trace vom GKE-Knoten zum Master
Cloud Console-Screenshot für Trace vom GKE-Knoten zum Master

Vom GKE-Knoten zum GKE-Master über eine öffentliche IP-Adresse

Die folgende Tabelle zeigt Beispieleingabewerte für einen Test zu einem GKE-Master über eine öffentliche IP-Adresse. Im nächsten Abschnitt können Sie sich die Ausgabe für einen erfolgreichen Test ansehen.

Beispieltesteingaben

Eingabeparameter Eingabewert
Protokoll TCP
GKE-Quellknoten gke-cluster-1-node-1
Quellprojekt my-project
IP-Adresse des Ziels 104.1.1.1
Zielport 443

Erfolgreicher Test

In diesem Abschnitt wird ein Beispiel für einen erfolgreichen Test zu einem GKE-Master über eine öffentliche IP-Adresse beschrieben.

Console

Der folgende Screenshot aus der Cloud Console zeigt einen Trace zur öffentlichen IP-Adresse eines GKE-Masters, wobei ein Gesamtergebnis von Reachable angegeben wird.

Dieses Ergebnis zeigt, dass Konnektivitätstests die Netzwerkkonnektivität vom GKE-Quellknoten zu dem Netzwerk, in dem der GKE-Master ausgeführt wird, geprüft haben, jedoch nicht zum GKE-Master. Beim Testen über eine öffentliche IP-Adresse analysieren Konnektivitätstests nicht die Konfiguration der Ressourcen in dem Google-Projekt, in dem der Master ausgeführt wird.

Grafik: Screenshot der Cloud Console für Trace vom GKE-Knoten zum Master über eine öffentliche IP-Adresse
Screenshot der Cloud Console für Trace vom GKE-Knoten zum Master über eine öffentliche IP-Adresse

Testfehler bei von Google verwalteten Diensten

Tests der von Google verwalteten Dienste können mit der Fehlermeldung fehlschlagen, dass das Paket innerhalb des Dienstes abgelegt wurde (z. B. DROPPED_INSIDE_GKE_SERVICE oder DROPPED_INSIDE_CLOUD_SQL_SERVICE). Diese Meldung kann auf ein Konfigurationsproblem im Google-Projekt hinweisen, das in den folgenden Fällen den Dienst hostet:

  • Sie haben die Konnektivität zwischen einem GKE-Master und einem GKE-Knoten im selben Cluster (in beide Richtungen) getestet.
  • Sie haben die Konnektivität von Ihrem VPC-Netzwerk zu einer Cloud SQL-Instanz getestet, die mit Ihrem Netzwerk verbunden ist, wobei sich die Quelle und das Ziel in derselben Region befinden.

Wenn Sie die zuvor erwähnte Fehlermeldung für einen der oben aufgeführten Fälle erhalten haben, kontaktieren Sie den Support. Andernfalls kann die Fehlermeldung auf eine ungültige Eingabe hindeuten. Bestätigen Sie, dass Sie einen oder mehrere Endpunkte testen, die tatsächlich vorhanden sind, und dass Sie die verwaltete Ressource im Google-Projekt erreichen. Wenn Sie beispielsweise von einem GKE-Knoten zu einem GKE-Master testen, müssen Sie prüfen, ob der Knoten vorhanden ist und voraussichtlich über Konnektivität zum Master verfügt.

Beispiele für Testeingaben: Von VM zu einer Cloud SQL-Instanz in einer anderen Region

Die folgende Tabelle enthält Beispieleingabewerte für einen Test von einer VM zu einer Cloud SQL-Instanz, wobei sich die VM in einer anderen Region als die Cloud SQL-Instanz befindet. Im nächsten Abschnitt können Sie sich die Ausgabe des fehlgeschlagenen Tests ansehen.

Eingabeparameter Eingabewert
Protokoll TCP
Quell-VM instance-1
Diese VM befindet sich in einer anderen Region als die Cloud SQL-Instanz.
Quellprojekt my-project
Cloud SQL-Zielinstanz vm-1
Zielport 5432

Fehlgeschlagener Test

In diesem Abschnitt wird ein Beispiel für einen fehlgeschlagenen Test zu einer Cloud SQL-Instanz beschrieben.

Console

Der folgende Screenshot aus der Cloud Console zeigt einen Trace zu einer Cloud SQL-Instanz, wobei ein Gesamtergebnis von Unreachable angegeben wird.

Grafik: Screenshot der Cloud Console für Trace von fehlgeschlagener VM zu Cloud SQL
Screenshot der Cloud Console für Trace von fehlgeschlagener VM zu Cloud SQL

Aus einem VPC-Netzwerk in ein Nicht-Google Cloud-Netzwerk testen

Sie können die Konfigurationsanalyse der Konnektivitätstests verwenden, um die Konnektivität von Ihrem VPC-Netzwerk zu einem Nicht-Google Cloud-Netzwerk über Cloud VPN oder Cloud Interconnect zu testen. In der Regel ist ein Nicht-Google Cloud-Netzwerk Ihr lokales Netzwerk oder das Netzwerk eines anderen Cloud-Anbieters.

Die Konfigurationsanalyse bewertet den Netzwerkpfad nur bis zur externen IP-Adresse des Routers oder VPN-Gateways in einem Peer-Netzwerk.

Das folgende Beispiel zeigt ein Trace von VM1 in einem VPC-Netzwerk über einen klassischen VPN-Tunnel mit statischem Routing zu VM2 in einem lokalen Netzwerk.

Paket-Trace durch einen Cloud-VPN-Tunnel unter Verwendung statischer Routes
Paket-Trace durch einen Cloud-VPN-Tunnel unter Verwendung statischer Routes

Wenn in einem Peering-Netzwerk eine übereinstimmende statische oder dynamische Route für die Ziel-IP-Adresse vorhanden ist, passt die Konfigurationsanalyse die Route an und prüft sie gemäß der Routenpriorität.

Es gibt eine standardmäßige statische Route für alle Ziele mit dem nächsten Hop als Internetgateway. Konnektivitätstests können dieser Standardroute entsprechen, sofern Sie sie nicht entfernt oder geändert haben.

Wenn die statische Standardroute nicht vorhanden ist und keine anderen gültigen Routen zum Ziel vorhanden sind, gibt das Trace den endgültigen Zustand Drop zurück.

Trace-Pfad zu einem Nicht-Google Cloud-Netzwerk mithilfe des statischen Routings
Trace-Pfad zu einem Nicht-Google Cloud-Netzwerk mithilfe des statischen Routings


Trace-Pfad zu einem Nicht-Google Cloud-Netzwerk mithilfe des statischen Routings
Trace-Pfad zu einem Nicht-Google Cloud-Netzwerk mithilfe des dynamischen Routings

Aus einem Nicht-Google Cloud-Netzwerk zu einem VPC-Netzwerk testen

Die Konfigurationsanalyse prüft, ob Ihr VPC-Netzwerk ein eingehendes Paket von Ihrem lokalen Netzwerk empfangen kann, nachdem dieses Paket in Ihrem VPC-Netzwerk eingegangen ist. Die Analyse prüft auch, ob die VPC-Netzwerkkonfiguration die Zustellung dieses Pakets an das vorgesehene Ziel zulassen wird. Die Konfigurationsanalyse zeigt das Ergebnis Paket konnte weitergeleitet werden an. In der API-Antwort lautet der endgültige Zustand Forward. Das Ziel gilt als erreichbar.

Wenn Ihr VPC-Netzwerk über Cloud Router mit Ihrem lokalen Netzwerk per Peering verbunden ist, empfängt das VPC-Netzwerk eine oder mehrere dynamische Routen von Ihrem lokalen Peering-Netzwerk. Gleichzeitig bewirbt Ihr VPC-Netzwerk seine eigenen Routen zu Ihrem lokalen Peering-Netzwerk.

Da Konnektivitätstests keinen Zugriff auf Ihre lokale Netzwerkkonfiguration haben, kann die Konfiguration der korrekten Routen und Firewallregeln auf Ihrem lokalen Router nicht geprüft werden. Daher betrachtet die Konfigurationsanalyse der Konnektivitätstests den Traffic von Ihrem lokalen Netzwerk zu Ihrem VPC-Netzwerk immer als gültig.

Konnektivitätstests können jedoch auswerten, ob die VPC-Konfiguration die Zustellung eines Pakets an ein Ziel in Google Cloud zulassen würde. Dabei werden die folgenden Google Cloud-Ressourcen ausgewertet, um die Erreichbarkeit zu bewerten:

  • Firewallregeln für eingehenden Traffic des VPC-Netzwerks.
  • Die beworbene Route für IP-Adressen in Ihrem VPC-Netzwerk, die Cloud Router für Ihr lokales (Peering-)Netzwerk bewirbt.

Beispieltesteingaben

Die folgende Tabelle zeigt Beispieleingabewerte für einen Test-Google Cloud-Load-Balancer, der im vorherigen Abschnitt beschrieben wurde. Fahren Sie mit dem nächsten Abschnitt fort, um sich die Ausgabe für einen erfolgreichen Test anzusehen.

Eingabeparameter Eingabewert
Protokoll TCP
Beispiel für eine lokale IP-Adresse 10.0.29.2
Kästchen für Dies ist eine IP-Adresse, die im Google Cloud verwendet wird Deaktivieren Sie dieses Kästchen, um eine lokale IP-Quelladresse anzugeben.

Erfolgreicher Test von einem lokalen Netzwerk

In diesem Abschnitt wird ein Beispiel für einen erfolgreichen Test von einem lokalen Netzwerk zu einem VPC-Netzwerk beschrieben.

Console

Das folgende Testergebnis prüft die Konnektivität über Cloud VPN von der lokalen IP-Adresse zu einer VM-Instanz sowie die BGP-Sitzung (Border Gateway Protocol), -Routen und -VPC-Firewallregeln.

Beispielausgabe für einen erfolgreichen Test vom lokalen Netzwerk zu Google Cloud
Beispielausgabe für einen erfolgreichen Test vom lokalen Netzwerk zu Google Cloud

Zwischen zwei Nicht-Google Cloud-Netzwerken testen

Mithilfe der Konfigurationsanalyse der Konnektivitätstests können Sie die Erreichbarkeit zwischen zwei Nicht-Google Cloud-Netzwerken prüfen, die über Network Connectivity Center verbunden sind. In diesem Zusammenhang ist ein Nicht-Google Cloud-Netzwerk in der Regel Ihr lokales Rechenzentrum oder eine Zweigstelle.

Da Konnektivitätstests keinen Zugriff auf Ihre lokale Netzwerkkonfiguration haben, kann sie die Konfiguration von Routen und Firewallregeln auf Ihrem lokalen Router nicht prüfen. Somit wird der Traffic von Ihrem lokalen Netzwerk zu Ihrem VPC-Netzwerk immer von der Konfigurations-Analyse der Konnektivitätstests als gültig erachtet und nur Konfigurationen innerhalb der Google Cloud werden verifiziert.

Die Konfigurationsanalyse lernt die lokalen Netzwerkbereiche von den Cloud Routern, die mit den Spokes des Network Connectivity Centers verknüpft sind. Sie können Konfigurationsprobleme in Ihrem VPC-Netzwerk identifizieren, die die Konnektivität zwischen den lokalen Netzwerken beeinträchtigen können.

Alle Spoke-Typen des Network Connectivity Center verwenden Cloud Router, um Routen über BGP-Sitzungen auszutauschen. Beispiel:

  • Router-Appliance-Spokes: Wenn Cloud Router- und Router-Appliance-Instanzen sich in derselben Region befinden, tauschen sie Routen aus.
  • Spokes von Cloud VPN und VLAN-Anhängen: Cloud Router tauschen BGP-Routen mit Routern im lokalen Netzwerk aus.

Weitere Informationen zum Network Connectivity Center finden Sie unter Network Connectivity Center – Übersicht.

Testen zwischen zwei Nicht-Google Cloud-Netzwerken über die Router-Appliance

Im folgenden Beispiel verfolgen Konnektivitätstests ein simuliertes Paket von einem lokalen Netzwerk zu einem anderen. Das Paket gelangt über die Router-Appliance-Spoke in das VPC-Netzwerk, die mit dem ersten lokalen Netzwerk verbunden ist. Von dort folgt es einer dynamische Route, die durch den Cloud Router beworben wird, der der Router-Appliance-Spoke zugeordnet ist, die mit dem zweiten lokalen Netzwerk verbunden ist. Das Paket erreicht das lokale Netzwerk über die zweite Router-Appliance-Instanz.

Beispieleingaben

Die folgende Tabelle zeigt Beispieleingabewerte für einen Test von einer IP-Adresse im lokalen Netzwerk. Im nächsten Abschnitt können Sie sich die Ausgabe für einen erfolgreichen Test ansehen.

Eingabeparameter Eingabewert
Protokoll TCP
IP-Adresse des Quellendpunkts 192.168.1.1
Kästchen für Dies ist eine IP-Adresse, die im Google Cloud verwendet wird Deaktivieren Sie dieses Kästchen, um eine lokale IP-Quelladresse anzugeben.
IP-Adresse des Zielendpunkts 172.16.1.1
Kästchen für Dies ist eine IP-Adresse, die im Google Cloud verwendet wird Deaktivieren Sie dieses Kästchen, um eine lokale IP-Zieladresse anzugeben.

Erfolgreicher Test von einem lokalen Netzwerk zu einem anderen lokalen Netzwerk

In diesem Abschnitt wird ein Beispiel für einen erfolgreichen Test von einem lokalen Netzwerk in ein anderes über Router-Appliance-Spokes beschrieben.

Console

Das folgende Testergebnis wertet die Konnektivität von einem lokalen Netzwerk über zwei Router-Appliance-Instanzen zu einem anderen lokalen Netzwerk aus. Außerdem werden die BGP-Sitzung, Routen und VPC-Firewallregeln ausgewertet.

Beispielausgabe für einen erfolgreichen Test von einer lokalen Umgebung zu einer lokalen Umgebung.
Beispielausgabe für einen erfolgreichen Test von einem lokalen zu einem lokalen

Testen zwischen zwei Nicht-Google Cloud-Netzwerke über Cloud VPN und Cloud Interconnect

Im folgenden Beispiel verfolgen Konnektivitätstests ein simuliertes Paket von einem lokalen Netzwerk zu einem anderen. Das Paket wird über das VPN-Gateway in das VPC-Netzwerk eingegeben. Das Paket erreicht das andere lokale Netzwerk über eine Interconnect-Verbindung.

Beispieleingaben

Die folgende Tabelle zeigt Beispieleingabewerte für einen Test von einer IP-Adresse im lokalen Netzwerk. Im nächsten Abschnitt können Sie sich die Ausgabe für einen erfolgreichen Test ansehen.

Eingabeparameter Eingabewert
Protokoll TCP
IP-Adresse des Quellendpunkts 10.0.0.1
Kästchen für Dies ist eine IP-Adresse, die im Google Cloud verwendet wird Deaktivieren Sie dieses Kästchen, um eine lokale IP-Quelladresse anzugeben.
IP-Adresse des Zielendpunkts 10.240.0.1
Kästchen für Dies ist eine IP-Adresse, die im Google Cloud verwendet wird Deaktivieren Sie dieses Kästchen, um eine lokale IP-Zieladresse anzugeben.
Zielport 80

Beispieltest von einem lokalen Netzwerk zu einem anderen lokalen Netzwerk

In diesem Abschnitt wird ein Beispiel für einen Test von einem lokalen Netzwerk zu einem anderen lokalen Netzwerk über VPN- und VLAN-Anhang-Spokes beschrieben.

Console

Das folgende Testergebnis bewertet die Konnektivität von einem lokalen Netzwerk über VPN und VLAN-Anhang-Spokes zu einem anderen lokalen Netzwerk.

Beispielausgabe für einen erfolgreichen Test von einer lokalen Umgebung zu einer lokalen Umgebung.
Beispielausgabe für einen erfolgreichen Test vom lokalen Netzwerk zum lokalen Netzwerk über VPN- und VLAN-Anhang-Spokes

Google Cloud-Load-Balancer testen

Die Konfigurationsanalyse der Konnektivitätstests unterstützt das Tracing simulierter Pakete für alle Arten von Google Cloud-Load-Balancern.

Der Trace-Pfad für einen externen HTTP(S)-Load-Balancer gilt auch für einen TCP-Proxy-Load-Balancer und einen SSL-Proxy-Load-Balancer. Weitere Informationen finden Sie in der Übersicht über Cloud Load Balancing.

Im folgenden Beispiel führen Konnektivitätstests ein Tracing eines simulierten Pakets von einem externen Host zu einem VIP für einen externen HTTP(S)-Load-Balancer durch. Die TCP-Verbindung vom externen Host wird beim Proxy für den externen HTTP(S)-Load-Balancer beendet. Der externe HTTP(S)-Load-Balancer initiiert dann eine neue TCP-Verbindung zu einer VM, die als Load-Balancer-Back-End dient.

Ein typischer Trace-Pfad zu einem externen HTTP(S)-Load-Balancer mit Diagrammlegende
Typischer Trace-Pfad zu einem externen HTTP(S)-Load-Balancer

Im folgenden Trace-Pfad stellt die Konfigurationsanalyse der Konnektivitätstests drei Traces bereit, einen für jeden möglichen Pfad zu den drei Load-Balancer-Back-Ends. Das liegt daran, dass sie nur Konfigurationen und nicht die Live-Datenebene prüft.

Paket-Trace zu einem externen HTTP(S)-Load-Balancer
Paket-Trace zu einem externen HTTP(S)-Load-Balancer (siehe Diagrammlegende)

Beispieltesteingaben

Die folgende Tabelle zeigt Beispieleingabewerte für einen Test zum externen HTTP(S)-Load-Balancer, der im vorherigen Abschnitt beschrieben wurde. Im nächsten Abschnitt können Sie sich die Ausgabe für einen erfolgreichen Test ansehen.

Eingabeparameter Eingabewert
Zielprotokoll TCP
Zielport 80
Beispiel für eine externe Quell-IP-Adresse (nicht gezeigt) 62.35.1.1
Externe IP-Adresse des Load-Balancers 203.0.113.99
Zielprojekt myproject

Ein erfolgreicher Test für einen Load-Balancer

Dieser Abschnitt beschreibt ein Beispiel für einen erfolgreichen Test des zuvor beschriebenen externen HTTP(S)-Load-Balancers.

In der eigentlichen Datenebene wählt der Load-Balancer-Algorithmus für jede Back-End-Verbindung eine VM-Instanz aus. Da es in diesem Beispiel drei Load-Balancer-Back-Ends gibt, können Sie im Menü Trace-Auswahl auf dem Bildschirm Ergebnisse das gewünschte Trace auswählen.

Console

Das folgende erfolgreiche Testergebnis bestätigt, dass alle folgenden Google Cloud-Ressourcen für den externen HTTP(S)-Load-Balancer korrekt konfiguriert sind.

  • Weiterleitungsregel
  • Die Load-Balancer-Back-Ends, einschließlich der Fähigkeit des Load-Balancers, Systemdiagnosen erfolgreich an diese Back-Ends zu senden
  • Proxyverbindung
  • VPC-Firewallregeln

Dieses Ergebnis bestätigt, dass ein simuliertes Paket von einer externen IP-Adresse die Back-End-VM-Instanzen erfolgreich erreichen kann:

Ein detailliertes Beispiel für ein Trace zu allen drei Back-Ends finden Sie unter Ungültige oder inkonsistente Konfigurationen erkennen.

Beispielausgabe für einen erfolgreichen Test an einen externen HTTP(S)-Load-Balancer
Beispielausgabe für einen erfolgreichen Test an einen externen HTTP(S)-Load-Balancer

Auch wenn Sie keine Berechtigung zum Prüfen der Google Cloud-Ressourcen im Netzwerkpfad für den externen HTTP(S)-Load-Balancer haben, werden in der Cloud Console dennoch weiterhin Ergebnisse angezeigt, einschließlich erfolgreicher Ergebnisse. Auf der Karte für jede getestete Ressource wird jedoch "Sie sind nicht berechtigt, die Ressource in PROJECT_NAME anzusehen" angezeigt.

Test, der eine fehlende Firewallregel für eine Systemdiagnose anzeigt

Ein Load-Balancer-Trace prüft viele derselben zuvor beschriebenen Google Cloud-Ressourcenkonfigurationen. Wenn die folgenden Load-Balancer-Ressourcen jedoch falsch konfiguriert sind, zeigt die Analyse das Ergebnis Paket konnte verworfen werden (der endgültige Zustand des Trace ist Drop).

Console

Das folgende Testergebnis zeigt, dass die Firewallregeln für eingehenden Traffic des VPC-Netzwerks keine Systemdiagnose für die Load-Balancer-Back-Ends zulassen. Dadurch sind die Back-Ends für den Load-Balancer nicht verfügbar.

Beispielausgabe für eine fehlende Firewallregel
Beispielausgabe für eine fehlende Firewallregel

Zusätzlich zu ungültigen VPC-Firewallregeln finden Sie nachfolgend häufige Konfigurationsprobleme, die von Konnektivitätstests für Google Cloud Load-Balancer erkannt werden.

Zur Behebung dieser Probleme verwenden Sie die in der folgenden Tabelle dargestellten Lösungen.

Konfigurationsproblem Lösung
Die Eingabeparameter stimmen nicht mit dem Protokoll oder Port überein, den Sie in der Weiterleitungsregel für den Load-Balancer definiert haben. Ändern Sie vor dem Testen den Eingabeparameter so, dass er mit dem Protokoll oder Port übereinstimmt, den Sie in der Weiterleitungsregel definiert haben.
Für die Weiterleitungsregel für den Load-Balancer sind keine Back-Ends konfiguriert. Konfigurieren Sie vor dem Testen die Back-Ends für den Load-Balancer.
Der Load-Balancer hat ungültige oder inkonsistente Konfigurationen. Korrigieren Sie vor dem Testen die ungültigen oder inkonsistenten Konfigurationen.
Der Traffic kann keinen internen TCP/UDP-Load-Balancer mit einer nicht übereinstimmenden Region erreichen, da der interne TCP/UDP-Load-Balancer ein regionaler Dienst ist. Vor dem Testen konfigurieren Sie die Komponenten des Load-Balancers, damit diese sich in derselben Region befinden.

Nächste Schritte