Auf dieser Seite finden Sie Beispiele für ungültige oder uneinheitliche Konfigurationen von Google Cloud-Ressourcen, die bei der Fehlerbehebung mit Konnektivitätstests in Ihrem Netzwerk auftreten können.
Anleitungen zum Ausführen von Tests finden Sie unter Konnektivitätstests erstellen und ausführen.
Eine Beschreibung der Tests von und zu allgemeinen Netzwerkquellen und Zieltypen finden Sie unter Gängige Anwendungsfälle.
Ungültige Konfiguration erkennen
Es gibt viele verschiedene Typen von ungültigen Konfigurationen, d. h. Konfigurationen, die nicht korrekt sind oder aktualisiert wurden und nicht mehr gültig sind.
Ein Beispiel dafür ist eine VM-Instanz, die als NAT-Gateway konfiguriert, aber gelöscht oder migriert wurde. In diesem Fall ist die Route zur VM-Instanz noch vorhanden.
Im folgenden Diagramm sollte VM1 in Network 1 über eine VM-Instanz mit dem Namen nat_vm_1 auf Daten in VM2, VM3 und VM4 in Network 2 zugreifen können.
nat_vm_1 ist jedoch nicht mehr vorhanden, da sie auf die neue VM nat_vm_2 migriert wurde.
Die konfigurierte Route von VM1 zu den anderen drei VM-Instanzen verweist noch auf nat_vm_1 als nächsten Hop. Da nat_vm_1 jedoch nicht mehr existiert und keine Route zu nat_vm_2 vorhanden ist, kann VM1 nicht mit den anderen VM-Instanzen kommunizieren.
Ein Konnektivitätstests-Lauf von VM1 zu VM2 zeigt, dass der Traffic zwischen VM1 und den anderen VM-Instanzen aufgrund eines ungültigen nächsten Hops für die Route zu den anderen VMs unterbrochen wurde.
Bei einer uneinheitlichen Konfiguration fehlt ein Netzwerktag in VM3, wodurch die Konfiguration des Load-Balancers in dessen Back-Ends uneinheitlich wird. Die Konfiguration für VM3 selbst ist jedoch gültig, da für die Konfiguration einer VM-Instanz kein Tag erforderlich ist.
Inkonsistente Konfiguration erkennen
Mit Konnektivitätstests können Sie regelmäßig auf uneinheitliche Konfigurationen prüfen. Diese Konfigurationen verursachen unter Umständen keine aktuellen Verbindungsprobleme, könnten jedoch unbeabsichtigt die Netzwerkredundanz verringern oder zu Leistungsproblemen führen.
Der Load-Balancer ist so konfiguriert, dass Traffic an eine externe IP-Adresse von 35.184.176.28 gesendet wird. Der Traffic zu dieser Adresse wird auf drei Back-Ends verteilt: VM1, VM2 und VM3. Aufgrund eines fehlenden Netzwerktags in VM3 lässt die VPC-Firewallregel (Virtual Private Cloud) Traffic von externen IP-Bereichen zwar zu VM1 und VM2 zu, lehnt diesen Traffic jedoch zu VM3 ab.
Der folgende Trace von den zulässigen Quellbereichen, die für den Load-Balancer konfiguriert sind, zu der externen Ziel-IP-Adresse des Load-Balancers enthält die gewünschte Konfiguration und die Inkonsistenz. VM1 und VM2 sind erreichbar, VM3 ist jedoch nicht erreichbar. Nur die beiden Back-Ends sind erreichbar, da VM3 die Systemdiagnose nicht bestanden hat.
