Konnektivitätstests können ein Testpaket aus einem der folgenden Gründe löschen.
Eine vollständige Liste möglicher Gründe finden Sie unter Status der Konfigurationsanalyse.
Fremde IP-Adresse nicht zulässig
Das Paket wird gelöscht, da eine Compute Engine-Instanz nur dann Pakete mit einer fremden IP-Adresse senden oder empfangen kann, wenn die IP-Weiterleitung aktiviert ist.
Mögliche Ursache
Für die VM-Instanz ist keine IP-Weiterleitung aktiviert, aber die Quell- oder Ziel-IP-Adresse des durch sie geleiteten Pakets stimmt nicht mit den IP-Adressen der Instanz überein. Dies kann beispielsweise der Fall sein, wenn das Paket über eine statische Route mit der VM-Instanz als nächsten Hop an die Instanz zugestellt wird.
Empfehlungen
Erstellen Sie eine Compute Engine-Instanz mit aktivierter IP-Weiterleitung oder legen Sie das entsprechende Attribut für die vorhandene Instanz fest. Weitere Informationen finden Sie unter IP-Weiterleitung für Instanzen aktivieren.
Wegen Firewall-Regel verworfen
Das Paket kann aufgrund einer Firewallregel gelöscht werden, es sei denn, das Paket wird aufgrund der Verbindungsverfolgung zugelassen.
Mögliche Ursache
Konnektivitätstests lehnen ein Testpaket möglicherweise ab, da das Paket mit einer blockierenden Firewallregel oder einer Firewallrichtlinienregel übereinstimmt. Die tatsächliche Datenebene kann jedoch das Paket durch die Verbindungsverfolgung in der Firewallregel weiterleiten. Durch die Verbindungsverfolgung können Pakete für eine bestehende Verbindung trotz der Firewallregel zurückgegeben werden.
Jedes VPC-Netzwerk hat zwei implizite Firewallregeln, die ausgehenden Traffic an alle Orte zulassen und eingehenden Traffic von überall blockieren. Möglicherweise haben Sie auch eine Firewallregel zum Ablehnen von ausgehendem Traffic mit höherer Priorität.
Damit die Verbindung hergestellt werden kann, benötigen Sie eine Firewallregel für ausgehenden Traffic an der Quelle, die den Zugriff auf den Zielendpunkt zulässt, und eine Firewallregel für eingehenden Traffic am Ziel, die diese Verbindung zulässt.
VPC-Firewallregeln sind zustandsorientiert. Wenn der angegebene Zielendpunkt in der Regel die Seite ist, die die Kommunikation initiiert, wird der Antworttraffic mit Verbindungs-Tracking automatisch zugelassen und es ist keine Firewallregel für eingehenden Traffic erforderlich.
Empfehlungen
Löschen Sie die "deny"-Regel oder erstellen Sie eine "allow"-Regel, die auf den Details in den Ergebnissen der Konnektivitätstests basiert. Weitere Informationen finden Sie unter Firewallrichtlinien und VPC-Firewallregeln verwenden.
Aufgrund fehlender übereinstimmender Route verworfen
Das Paket wird aufgrund fehlender übereinstimmender Routen verworfen.
Mögliche Ursache
Im Paketnetzwerk und in der Region gibt es keine aktive Route, die den Paketattributen (z. B. Ziel-IP-Adresse) entspricht.
Empfehlungen
Prüfen Sie die Liste der effektiven Routen in der Google Cloud Console. Wenn Sie gerade eine neue Route erstellt haben, kann es einige Zeit dauern, bis die Konnektivitätstests ein Konfigurationsupdate erhalten und in die Analyse eingebunden werden.
Wenn Sie versuchen, über seine interne IP-Adresse auf den Zielendpunkt zuzugreifen, müssen die Quell- und Zielnetzwerke verbunden sein (z. B. über VPC-Netzwerk-Peering, Network Connectivity Center oder eine Hybridkonnektivitätslösung wie Cloud VPN).
Beachten Sie, dass transitives VPC-Peering nicht unterstützt wird. Sie können die Quell- und Zielnetzwerke direkt oder mithilfe einer hybriden Konnektivitätslösung verbinden.
Wenn Sie versuchen, über das Internet auf den Zielendpunkt zuzugreifen, benötigen Sie eine Route für die Ziel-IP-Adresse mit dem Internetgateway des nächsten Hops.
Wenn das Paket die Netzwerk-Endpunktgruppe mit Hybridkonnektivität durchläuft, müssen zusätzliche Anforderungen an die Anwendbarkeit von Routen beachtet werden. Einige Routen, die Sie in der Tabelle mit der Routenansicht sehen, sind möglicherweise nicht für Traffic von Hybrid-NEGs verfügbar.
Weitere Informationen finden Sie unter Routen und Routen verwenden.
Das Paket wurde an ein falsches Netzwerk gesendet
Das Paket wird an ein unbeabsichtigtes Netzwerk gesendet. Beispiel: Sie führen einen Test von einer Compute Engine-Instanz im network-1-Netzwerk zur Compute Engine-Instanz im network-2-Netzwerk aus, aber das Paket wird an das network-3-Netzwerk gesendet.
Mögliche Ursache
Das Netzwerk network-1 hat eine Route mit einem Zielbereich, der die IP-Adresse der Zielinstanz mit dem nächsten Hop in einem anderen Netzwerk enthält (network-3 im Beispiel oben).
Empfehlungen
Prüfen Sie in der Google Cloud Console die Liste der effektiven Routen und die Liste der für die Quellinstanz geltenden Routen. Weitere Informationen zur Routenerstellung und applicability finden Sie unter Routen und Routen verwenden.
IP-Adresse des nächsten Hops der Route wurde nicht aufgelöst
Das Paket wird über eine ungültige Route an ein Ziel gesendet, wobei die IP-Adresse des nächsten Hops keiner Ressource zugewiesen ist.
Mögliche Ursache
Wenn es sich um eine Route mit next-hop-address handelt, muss die Adresse des nächsten Hops eine primäre interne IPv4-Adresse der Compute Engine-Instanz im VPC-Netzwerk der Route sein. Adressen in Peering-Netzwerken werden nicht unterstützt.
Wenn es sich um eine Route mit next-hop-ilb handelt, muss die Adresse des nächsten Hops eine Adresse des internen Passthrough-Network Load Balancers sein (Weiterleitungsregeln, die von anderen Load-Balancern, Protokollweiterleitung oder als Private Service Connect-Endpunkte verwendet werden, werden nicht unterstützt). Die IP-Adresse muss einer Ressource im VPC-Netzwerk der Route oder in einem Netzwerk zugewiesen sein, das über VPC-Netzwerk-Peering mit ihr verbunden ist.
Empfehlungen
Prüfen Sie, ob die IP-Adresse des nächsten Hops zu einer unterstützten Ressource gehört. Weitere Informationen finden Sie unter Überlegungen zu nächsten Hop-Instanzen und Überlegungen zu nächsten Hops des internen Passthrough-Network Load Balancers.
Instanz des nächsten Hops der Route hat eine NIC im falschen Netzwerk
Das Paket wird über eine ungültige Route an ein Ziel gesendet, wobei die Compute Engine-Instanz mit dem nächsten Hop keinen Network Interface Controller (NIC) im Netzwerk der Route hat.
Mögliche Ursache
Die Compute Engine-Instanz, die als nächster Hop der Route verwendet wird, muss eine NIC im Netzwerk der Route haben (kein Peering-VPC-Netzwerk).
Empfehlungen
Prüfen Sie, ob die Compute Engine-Instanz des nächsten Hops eine NIC im Netzwerk der Route hat. Weitere Informationen finden Sie unter Überlegungen zu Instanzen des nächsten Hops.
Adresse des nächsten Hops der Route ist keine primäre IP-Adresse der VM
Das Paket wird über eine ungültige Route an ein Ziel gesendet, wobei die IP-Adresse des nächsten Hops (next-hop-address) keine primäre IP-Adresse der Compute Engine-Instanz ist.
Mögliche Ursache
Die IP-Adresse des nächsten Hops (next-hop-address) der Route muss eine primäre interne IPv4-Adresse der Compute Engine-Instanz sein.
Alias-IP-Adressbereiche werden nicht unterstützt.
Empfehlungen
Prüfen Sie, ob die IP-Adresse des nächsten Hops eine primäre interne IPv4-Adresse der Compute Engine-Instanz ist. Weitere Informationen finden Sie unter Überlegungen zu Instanzen des nächsten Hops.
Der Weiterleitungsregeltyp für den nächsten Hop der Route ist ungültig
Das Paket wird über eine ungültige Route an ein Ziel gesendet, wobei die Weiterleitungsregel für den nächsten Hop (next-hop-ilb) keine Weiterleitungsregel des internen Passthrough-Network Load Balancers ist.
Mögliche Ursache
Die Weiterleitungsregel der Route für den nächsten Hop muss eine Weiterleitungsregel des internen Passthrough-Network Load Balancers sein. Weitere Informationen finden Sie unter Überlegungen zu nächsten Hops für internen Passthrough-Network Load Balancer.
Empfehlungen
Erstellen Sie eine Route, die auf eine unterstützte Weiterleitungsregel anstelle der ungültigen Route ausgerichtet ist.
Privater Traffic zum Internet
Ein Paket mit einer internen Zieladresse wurde an ein Internetgateway gesendet.
Mögliche Ursache
Die Ziel-IP-Adresse des Pakets ist eine private IP-Adresse, die nicht über das Internet erreichbar ist. Das Paket verlässt jedoch die Compute Engine-Quellinstanz und gleicht eine Route mit dem Internetgateway des nächsten Hops ab.
Empfehlungen
Wenn Sie über das Internet auf das Ziel zugreifen möchten, achten Sie darauf, dass die Compute Engine-Quellinstanz über eine Internetverbindung verfügt. Sie muss beispielsweise eine externe IP-Adresse haben oder Cloud NAT verwenden. Verwenden Sie außerdem die externe IP-Adresse des Zielendpunkts im Test.
Wenn Sie über die interne IP-Adresse auf das Ziel zugreifen möchten, müssen Sie eine Verbindung zwischen den Quell- und Zielnetzwerken herstellen (Routen erstellen). Dazu haben Sie folgende Möglichkeiten:
- Wenn sich der Zielendpunkt in einem lokalen Netzwerk befindet, verwenden Sie eine Network Connectivity Center-Lösung oder eine Hybridkonnektivitätslösung wie Cloud VPN oder Cloud Interconnect.
- Wenn Ihr Zielendpunkt in Google Cloud liegt:
- Konfigurieren Sie das VPC-Netzwerk-Peering zwischen VPC-Netzwerken.
- Konfigurieren Sie Cloud VPN zwischen VPC-Netzwerken.
- Konfigurieren Sie die Netzwerkverbindung mithilfe von VPC-Spokes von Network Connectivity Center.
Wenn Sie bereits eine Verbindung zum Zielnetzwerk haben:
- Das Quellendpunktnetzwerk hat keine Route über diese Verbindung oder verwendet die Standardroute, die durch das Internetgateway führt. Prüfen Sie in der Google Cloud Console die Liste der effektiven Routen und die Liste der für die Quellinstanz geltenden Routen. Weitere Informationen zum Erstellen von Routen und zur applicability finden Sie unter Routen und Routen verwenden.
Wenn Sie die Konnektivität zu einem lokalen Netzwerk von einem Peering-Netzwerk aus testen, finden Sie dieses Beispiel für benutzerdefiniertes Advertising, Netzwerk-Routingmodus und den Austausch benutzerdefinierter Routen.
Transitives VPC-Netzwerk-Peering wird nicht unterstützt. Sie können VPN oder Peering für diese beiden VPC-Netzwerke verwenden.
Privater Google-Zugriff ist nicht zulässig
Eine Compute Engine-Instanz, die lediglich eine interne IP-Adresse hat, versucht, die externe IP-Adresse von Google APIs und Google-Diensten zu erreichen, aber der privater Google-Zugriff ist im Subnetz der Instanz nicht aktiviert.
Empfehlungen
Sie können zulassen, dass die Compute Engine-VM-Instanz die externe IP-Adresse von Google APIs und Google-Diensten auf eine der folgenden Arten erreicht:
- Aktivieren Sie privaten Google-Zugriff für das Subnetz der Instanz.
- Weisen Sie der Compute Engine-NIC eine externe IP-Adresse zu.
- Aktivieren Sie Cloud NAT für das Subnetz der VM-Instanz.
Privater Google-Zugriff über VPN-Tunnel wird nicht unterstützt
Ein Quellendpunkt mit einer internen IP-Adresse versucht, die externe IP-Adresse von Google APIs und Google-Diensten über den VPN-Tunnel zu einem anderen Netzwerk zu erreichen. Dafür muss im Netzwerk des Quellendpunkts der privater Google-Zugriff aktiviert sein.
Mögliche Ursache
Das Paket vom Quellendpunkt zur externen IP-Adresse der Google APIs und Google-Dienste wird über den Cloud VPN-Tunnel weitergeleitet. Eine solche Konfiguration wird jedoch nicht unterstützt.
Empfehlungen
Wenn der Quellendpunkt ein Google Cloud-Endpunkt wie eine Compute Engine-VM-Instanz ist, sollten Sie privaten Google-Zugriff im Quellsubnetz aktivieren.
Wenn der Quellendpunkt ein lokaler Endpunkt ist, finden Sie eine ausführliche Anleitung unter Privater Google-Zugriff für lokale Hosts.
Abweichende Weiterleitungsregel
Das Protokoll und die Ports der Weiterleitungsregel stimmen nicht mit dem Paketheader überein.
Mögliche Ursache
Das Paket wird mit einem Protokoll gesendet, das von der Weiterleitungsregel nicht unterstützt wird, oder das Paket wird an einen Zielport gesendet, der nicht mit den von der Weiterleitungsregel unterstützten Ports übereinstimmt.
Empfehlungen
Prüfen Sie das Protokoll und die Ports für die Zielweiterleitungsregel.
Region der Weiterleitungsregel stimmt nicht überein
Für die Weiterleitungsregel ist kein globaler Zugriff aktiviert und ihre Region stimmt nicht mit der Region des Pakets überein.
Mögliche Ursache
Ebenfalls abhängig vom Load-Balancer und dessen Stufe ist eine Weiterleitungsregel entweder global oder regional. Weitere Informationen finden Sie in der Tabelle der Load-Balancer-Typen.
Wenn die Weiterleitungsregel regional ist, sollte sich der Client (z. B. die VM oder der VPC-Connector) in derselben Region wie der Load-Balancer befinden.
Empfehlungen
Wenn Sie eine Verbindung zum Load-Balancer über einen Google Cloud-Endpunkt wie eine Compute Engine-VM-Instanz herstellen, achten Sie darauf, dass sich dieser in derselben Region wie die Weiterleitungsregel befindet.
Achten Sie beim Herstellen einer Verbindung von einem lokalen Netzwerk aus darauf, dass der Client über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load-Balancer zugreift, die sich in derselben Region wie der Load-Balancer befinden. Weitere Informationen finden Sie unter Interne Application Load Balancer und verbundene Netzwerke.
Sie können den globalen Zugriff auf interne Application Load Balancer und regionale interne Proxy-Network Load Balancer aktivieren, um auf Clients in jeder Region zuzugreifen. Standardmäßig müssen sich Clients für diese Load-Balancer in derselben Region wie der Load-Balancer befinden. Weitere Informationen finden Sie unter Globalen Zugriff für interne Application Load Balancer aktivieren und Globalen Zugriff für regionale interne Proxy-Network Load Balancer aktivieren.
Firewall blockiert die Backend-Systemdiagnose des Load-Balancers
Firewalls blockieren Systemdiagnoseprüfungen an den Back-Ends und führen dazu, dass Back-Ends für den Traffic vom Load-Balancer nicht verfügbar sind.
Mögliche Ursache
Damit Systemdiagnosen funktionieren, müssen Sie Firewallregeln zum Zulassen von eingehendem Traffic erstellen, durch die Traffic von Google Cloud-Probern Ihre Back-Ends erreicht. Andernfalls gelten die Back-Ends als fehlerhaft.
Empfehlungen
Erstellen Sie Firewallregeln zum Zulassen von eingehendem Traffic gemäß der Tabelle Prüfungs-IP-Bereiche und Firewallregeln. Weitere Informationen finden Sie unter Erforderliche Firewallregeln.
Keine externe Adresse verfügbar
Eine VM-Instanz mit nur einer internen IP-Adresse hat versucht, über eine Route, deren nächster Hop das Standard-Internetgateway ist, auf externe Hosts zuzugreifen. Wird erwartet, wenn Cloud NAT im Subnetz nicht aktiviert ist oder es keine andere Standardroute gibt, die einen anderen nächsten Hop verwendet (z. B. eine Proxy-VM)
Mögliche Ursache
Eine Instanz mit nur einer internen IP-Adresse hat versucht, auf einen externen Host zuzugreifen, aber sie hatte keine externe IP-Adresse oder Cloud NAT wurde im Subnetz nicht aktiviert.
Empfehlungen
Wenn Sie auf externe Endpunkte zugreifen möchten, können Sie Ihrer Instanz eine externe IP-Adresse zuweisen. Alternativ können Sie Cloud NAT auf seinem Subnetz aktivieren, es sei denn, die Verbindung erfolgt über eine Proxyinstanz, die Zugriff auf das Internet gewährt.
Weiterleitungsregel ohne Instanzen
Für die Weiterleitungsregel sind keine Back-Ends konfiguriert
Mögliche Ursache
Für die Weiterleitungsregel, die Sie erreichen möchten, sind keine Back-Ends konfiguriert.
Empfehlungen
Prüfen Sie die Konfiguration des Load-Balancers und dafür, dass für den Backend-Dienst des Load-Balancers Backends konfiguriert sind.
Traffictyp ist blockiert
Die Art des Traffics ist blockiert und Sie können keine Firewallregel konfigurieren, um sie zu aktivieren. Weitere Details finden Sie unter Permanent blockierter Traffic.
Mögliche Ursache
Dieser Traffictyp wird standardmäßig blockiert und kann nicht durch das Erstellen von Firewallregeln aktiviert werden. Gängige Szenarien:
- Ausgehenden Traffic mit dem TCP-Port 25 (SMTP) an ein externes Ziel senden. Weitere Details finden Sie unter Permanent blockierter Traffic.
- Traffic an einen nicht unterstützten Port auf einer Cloud SQL-Instanz senden Beispiel: Traffic an TCP-Port 3310 an eine MySQL Cloud SQL-Instanz mit geöffnetem Port 3306 senden.
- Ausgehenden Traffic von einer Version der App Engine-Standardumgebung, einer Cloud Function oder einer Cloud Run-Version senden, die ein anderes Protokoll als TCP oder UDP verwendet
Empfehlungen
Informationen zu ausgehendem SMTP-Traffic (ausgehender Traffic zu einem externen Ziel mit TCP-Port 25) finden Sie unter E-Mails von einer Instanz senden.
Für das DHCP-Protokoll einschließlich UDP-IPv4-Pakete für den Zielport 68 (DHCPv4-Antworten) und UDP-IPv6-Pakete zum Zielport 546 (DHCPv6-Antworten) ist DHCP-Traffic nur vom Metadatenserver zulässig (169.254.169.254).
Prüfen Sie bei der Cloud SQL-Verbindung, ob der verwendete Port korrekt ist.
Connector für Serverloser VPC-Zugriff ist nicht konfiguriert
Das Paket wurde gelöscht, weil für die Version der App Engine-Standardumgebung, Cloud Function oder die Cloud Run-Version kein Connector für serverlosen VPC-Zugriff konfiguriert ist.
Mögliche Ursache
Die Ziel-IP-Adresse ist eine private IP-Adresse, die nicht über das Internet erreichbar ist. Das Paket verlässt die Quelle, aber es ist kein Connector für Serverloser VPC-Zugriff für die App Engine-Standardumgebungsversion, Cloud Function oder die Cloud Run-Version konfiguriert.
Empfehlungen
Wenn Sie versuchen, über seine private IP-Adresse auf den Zielendpunkt zuzugreifen, muss ein Connector für Serverloser VPC-Zugriff für die Version der App Engine-Standardumgebung, Cloud Function oder die Cloud Run-Version konfiguriert sein.
Connector für Serverloser VPC-Zugriff wird nicht ausgeführt
Das Paket wurde gelöscht, weil der Connector für serverlosen VPC-Zugriff nicht ausgeführt wird.
Mögliche Ursache
Das Paket wurde gelöscht, da alle Connector-Instanzen für Serverloser VPC-Zugriff beendet sind.
Empfehlungen
Eine Liste der Schritte zur Fehlerbehebung finden Sie unter Fehlerbehebung.
Private Service Connect-Verbindung wurde nicht akzeptiert
Das Paket wurde gelöscht, da die Private Service Connect-Verbindung nicht akzeptiert wurde.
Mögliche Ursache
Der Private Service Connect-Endpunkt befindet sich in einem Projekt, das nicht zum Herstellen einer Verbindung zum Dienst berechtigt ist. Weitere Informationen finden Sie unter Endpunktdetails ansehen.
Empfehlungen
Achten Sie darauf, dass sich der Private Service Connect-Endpunkt in einem Projekt befindet, das für die Verbindung zum verwalteten Dienst zugelassen ist.
Der Zugriff auf den Private Service Connect-Endpunkt über ein Peering-Netzwerk erfolgt
Das Paket wird an den Private Service Connect-Endpunkt im Peering-Netzwerk gesendet, aber eine solche Konfiguration wird nicht unterstützt.
Empfehlungen
Sie können eines der auf der Seite Bereitstellungsmuster für Private Service Connect beschriebenen Verbindungsmuster verwenden. Sie können auch über Private Service Connect-Back-Ends auf Google APIs und veröffentlichte Dienste zugreifen.