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 wird die Erreichbarkeit durch Konnektivitätstests bewertet indem Sie sowohl die Konfigurationsanalyse als auch die Analyse der Live-Datenebene verwenden. 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.
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.
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.
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.
-
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.
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.
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.
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.
Bei Bedarf führen Konnektivitätstests eine Spoof-Prüfung für das Paket aus, das an der zweiten VM eingeht.
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 dem endgültigen Status 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.
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.
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.
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. |
|
| Keine passende Route | Eine Route zum Zielendpunkt wurde nicht gefunden. |
|
| 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.
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 Status Abort in der API-Antwort. |
| 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
Mit VPC-Netzwerk-Peering ohne Berechtigung für den peered
des Google Cloud-Projekts des Netzwerks aus dem Netzwerk primary kann dazu führen,
dem Testergebnis aus der folgenden Tabelle.
| 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 Status dem endgültigen Status Forward. |
Der folgende Trace-Pfad zeigt den Vorwärtsstatus für Peering-VPC-Netzwerke.
Nächste Schritte
- Häufige Testszenarien
- Weitere Informationen zu Konnektivitätstests
- Fehlerbehebung bei Konnektivitätstests