Konnektivität in VPC-Netzwerken testen

Ein häufiger Anwendungsfall für Konnektivitätstests ist das Testen zwischen zwei Compute Engine-VM-Instanzen (virtuelle Maschine) in denselben VPC-Netzwerken oder in Peering-VPC-Netzwerken (Virtual Private Cloud).

Bei dieser Art von Test bewerten Konnektivitätstests die Erreichbarkeit mithilfe von Konfigurationsanalysen und Analysen der Live-Datenebene. Zum Analysieren der Konfiguration bestimmen Konnektivitätstests einen Trace-Pfad und werten ihn aus.

Für Trace-Diagramme auf dieser Seite werden die in der folgenden Legende beschriebenen Symbole verwendet.
Symbole Name Bedeutung
Graue Raute
Grafik: Legende für das Paket-Trace-Diagramm: graue Raute.
Logo: Check Point Ein Entscheidungspunkt, an dem Konnektivitätstests eine Konfiguration prüfen und entscheiden, ob ein Trace-Paket weitergeleitet, zugestellt oder verworfen werden soll.
Blaues Rechteck
Legende für das Paket-Trace-Diagramm: blaues Rechteck.
Hop Ein Schritt im Weiterleitungspfad für ein Trace-Paket, der eine Google Cloud-Ressource darstellt, die ein Paket an den nächsten Hop in einem VPC-Netzwerk weiterleitet, z. B. an einen Cloud Load Balancing-Proxy oder einen Cloud VPN-Tunnel.
Orangefarbenes Sechseck
Legende für das Paket-Trace-Diagramm: orangefarbenes Sechseck.
Endpunkt Die Quelle oder das Ziel eines Trace-Pakets.

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 (zum Vergrößern klicken).

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 Testzustände und Meldungen finden Sie unter Konfigurationsanalysestatus.

  1. Konnektivitätstests prüfen, ob die Quell-VM ausgehende Pakete mit der angegebenen Quell-IP-Adresse senden kann oder auf andere Weise standardmäßig den Spoofing-Prüfprozess ausführt.

  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.

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 einem endgültigen Zustand von 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 Google Cloud Console für das VM-zu-VM-Trace.
Screenshot der Google Cloud Console für das VM-zu-VM-Trace (zum Vergrößern klicken)

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
Maximierte Karte für die Firewallregel für eingehenden Traffic (zum Vergrößern klicken)

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 (zum Vergrößern klicken)

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 Quellendpunkt verlässt oder einen Zielendpunkt erreicht, wird durch eine hierarchische Firewallrichtlinienregel oder eine VPC-Firewallregel blockiert.
  • Wenn die Verbindung durch eine hierarchische Firewallregel blockiert wird, enthält der Trace den Namen der Richtlinie. Die Person, die den Test ausführt, ist möglicherweise nicht berechtigt, die Richtliniendetails aufzurufen. Weitere Informationen zu dieser Situation finden Sie unter Fehlerbehebung bei der hierarchischen Firewallrichtlinie.
  • 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.

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

Google Cloud Console mit einem Trace, der durch eine hierarchische Firewallregel blockiert wird.
Screenshot der Google Cloud Console für einen Trace, der durch eine hierarchische Firewallrichtlinienregel blockiert wird (zum Vergrößern klicken)

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 ein Ergebnis von Configuration analysis conversioned (Konfigurationsanalyse abgebrochen). In der API-Antwort entspricht dieses Label einem endgültigen Zustand von Abort.
Berechtigungen nur für das Dienstprojekt

Sie können das Trace nicht ausführen oder das Hostprojektnetzwerk in der Google 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, kann das zu den in der folgenden Tabelle aufgeführten Testergebnissen führen.

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 deutet darauf hin, dass ein Paket das Netzwerk verlassen 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 Status dem endgültigen Status Forward.

Der folgende Trace-Pfad zeigt den Weiterleitungsstatus 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 nicht zugängliches Peering-VPC-Netzwerk in einem anderen Projekt (zum Vergrößern klicken)

Nächste Schritte