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 verworfen, da eine Compute Engine-Instanz Pakete mit einer fremden IP-Adresse nur senden oder empfangen kann, wenn die IP-Weiterleitung aktiviert ist.
Mögliche Ursache
Für die VM-Instanz ist die IP-Weiterleitung nicht aktiviert, aber die Quell- oder Ziel-IP-Adresse des Pakets, das sie durchläuft, stimmt nicht mit den IP-Adressen der Instanz überein. Das kann beispielsweise passieren, wenn das Paket über eine statische Route mit der VM-Instanz als nächsten Hop an die Instanz gesendet 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, es ist aufgrund der Verbindungsverfolgung zulässig.
Mögliche Ursache
Konnektivitätstests können ein Testpaket ablehnen, 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. Das Verbindungs-Tracking ermöglicht es Paketen für eine vorhandene Verbindung trotz der Firewallregel zurückzugeben.
Jedes VPC-Netzwerk hat zwei implizierte Firewallregeln, die ausgehenden Traffic nach überall ermöglichen und eingehenden Traffic von überall blockieren. Möglicherweise haben Sie auch eine Firewallregel für ausgehenden Traffic mit einer höheren Priorität.
Damit die Verbindung erfolgreich ist, benötigen Sie eine Firewallregel für ausgehenden Traffic an der Quelle, die den Zugriff auf den Zielendpunkt und die Firewallregel für eingehenden Traffic am Ziel zulässt, um diese Verbindung zuzulassen.
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.
Verworfen, da keine übereinstimmende Route gefunden wurde
Das Paket wird verworfen, da keine übereinstimmenden Routen vorhanden sind.
Mögliche Ursache
Es gibt keine aktive Route, die mit den Paketattributen (z. B. einer Ziel-IP-Adresse) im Paketnetzwerk und in der Region übereinstimmt.
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 eine Konfigurationsaktualisierung erhalten und in die Analyse einfließen.
Wenn Sie versuchen, über die interne IP-Adresse auf den Zielendpunkt zuzugreifen, prüfen Sie, ob das Quell- und Zielnetzwerk verbunden sind. Verwenden Sie dazu z. B. VPC Network Peering, Network Connectivity Center oder eine Hybridkonnektivitätslösung wie Cloud VPN.
Transitives VPC-Peering wird nicht unterstützt. Sie können die Quell- und Zielnetzwerke direkt oder mithilfe einer Hybridkonnektivitätslösung verbinden.
Wenn Sie versuchen, über das Internet auf den Zielendpunkt zuzugreifen, prüfen Sie, ob Sie eine Route für die Ziel-IP-Adresse mit dem nächsten Hop-Internetgateway haben.
Wenn das Paket die Netzwerk-Endpunktgruppe mit Hybridkonnektivität durchläuft, müssen zusätzliche Anforderungen für die Anwendbarkeit von Routen berücksichtigt werden. Einige Routen, die Sie in der Tabelle der Routenübersicht sehen, sind möglicherweise nicht für Traffic von hybriden NEGs verfügbar.
Weitere Informationen finden Sie unter Routen und Routen verwenden.
Paket wird an ein falsches Netzwerk gesendet
Das Paket wird an ein unbeabsichtigtes Netzwerk gesendet. Angenommen, Sie führen einen Test von einer Compute Engine-Instanz im Netzwerk network-1 zur Compute Engine-Instanz im Netzwerk network-2 aus, das Paket wird jedoch an das Netzwerk network-3 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 Routen, die für die Quellinstanz gelten. Weitere Informationen zum Erstellen und zur Anwendbarkeit von Routen finden Sie unter Routen und Routen verwenden.
IP-Adresse des nächsten Hops der Route wird nicht aufgelöst
Das Paket wird an ein Ziel über eine ungültige Route gesendet, deren IP-Adresse für den nächsten Hop 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 oder eine IPv6-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, für die 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 damit 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 internen Passthrough Network Load Balancern, die als nächster Hop dienen.
Die Next-Hop-Instanz der Route hat eine NIC im falschen Netzwerk
Das Paket wird an ein Ziel über eine ungültige Route gesendet, bei der die Compute Engine-Instanz des nächsten Hops keine NIC (Network Interface Controller) im Netzwerk der Route hat.
Mögliche Ursache
Die Compute Engine-Instanz, die als Next Hop der Route verwendet wird, muss eine NIC im Netzwerk der Route haben (nicht in einem 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 Next-Hop-Instanzen.
Die Next-Hop-Adresse der Route ist keine primäre IP-Adresse der VM
Das Paket wird an ein Ziel über eine ungültige Route gesendet, bei der die Next-Hop-IP-Adresse (next-hop-address) keine primäre IP-Adresse der Compute Engine-Instanz ist.
Mögliche Ursache
Die Next-Hop-IP-Adresse (next-hop-address) der Route muss eine primäre interne IPv4-Adresse der Compute Engine-Instanz sein.
Bereiche von Alias-IP-Adressen werden nicht unterstützt.
Empfehlungen
Prüfen Sie, ob die Next-Hop-IP-Adresse eine primäre interne IPv4-Adresse der Compute Engine-Instanz ist. Weitere Informationen finden Sie unter Überlegungen zu Next-Hop-Instanzen.
Der Typ der Next-Hop-Weiterleitungsregel der Route ist ungültig
Das Paket wird an ein Ziel über eine ungültige Route gesendet, wobei die Next-Hop-Weiterleitungsregel (next-hop-ilb) keine Weiterleitungsregel des internen Passthrough-Network-Load-Balancers ist.
Mögliche Ursache
Die Next-Hop-Weiterleitungsregel der Route muss eine Weiterleitungsregel des internen Passthrough-Network Load Balancers sein. Weitere Informationen finden Sie unter Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen.
Empfehlungen
Erstellen Sie eine Route, die auf eine unterstützte Weiterleitungsregel und nicht auf die ungültige 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-Quell-Instanz und wird mit einer Route mit dem nächsten Hop-Internet-Gateway abgeglichen.
Empfehlungen
Wenn Sie über das Internet auf das Ziel zugreifen möchten, muss die Compute Engine-Quell-Instanz eine Internetverbindung haben, z. B. eine externe IP-Adresse oder Cloud NAT. Verwenden Sie im Test die externe IP-Adresse des Zielendpunkts.
Wenn Sie über die interne IP-Adresse auf das Ziel zugreifen möchten, müssen Sie eine Verbindung zwischen dem Quell- und dem Zielnetzwerk herstellen (Routen erstellen). Sie haben dazu folgende Möglichkeiten:
- Wenn sich Ihr 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.
- Netzwerkkonnektivität mit VPC-Spokes des Network Connectivity Center konfigurieren
Wenn Sie bereits eine Verbindung zum Zielnetzwerk haben:
- Das Quellendpunkt-Netzwerk hat keine Route über diese Verbindung oder verwendet die Standardroute, die über das Internetgateway geleitet wird. Prüfen Sie in der Google Cloud Console die Liste der effektiven Routen und die Liste der Routen, die für die Quellinstanz gelten. Weitere Informationen zum Erstellen und zur Anwendbarkeit von Routen 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 nicht zulässig
Eine Compute Engine-Instanz mit nur einer internen IP-Adresse versucht, die externe IP-Adresse von Google APIs und Diensten zu erreichen, aber der privater Google-Zugriff ist im Subnetz der Instanz nicht aktiviert.
Empfehlungen
Sie können der Compute Engine-VM-Instanz auf folgende Arten erlauben, die externe IP-Adresse von Google APIs und Diensten zu erreichen:
- Aktivieren Sie den 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 Diensten über den VPN-Tunnel zu einem anderen Netzwerk zu erreichen. Der privater Google-Zugriff muss jedoch im Netzwerk des Quellendpunkts aktiviert sein.
Mögliche Ursache
Das Paket wird vom Quellendpunkt zur externen IP-Adresse der Google APIs und ‑Dienste über den Cloud VPN-Tunnel geleitet. Eine solche Konfiguration wird jedoch nicht unterstützt.
Empfehlungen
Wenn der Quellendpunkt ein Google Cloud-Endpunkt ist (z. B. eine Compute Engine-VM-Instanz), sollten Sie den privaten Google-Zugriff in seinem Quellsubnetz aktivieren.
Wenn es sich bei dem Quellendpunkt um einen lokalen Endpunkt handelt, finden Sie eine ausführliche Anleitung unter Privaten Google-Zugriff für lokale Hosts konfigurieren.
Nicht übereinstimmende 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 an einen Zielport, der nicht mit den von der Weiterleitungsregel unterstützten Ports übereinstimmt.
Empfehlungen
Bestätigen Sie das Protokoll und die Ports der Zielweiterleitungsregel.
Abweichende Region der Weiterleitungsregel
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, muss sich dieser in derselben Region wie die Weiterleitungsregel befinden.
Sorgen Sie bei einer Verbindung von einem lokalen Netzwerk dafür, dass der Client über Cloud VPN-Tunnel oder VLAN-Anhänge, die sich in derselben Region wie der Load Balancer befinden, auf den Load Balancer zugreift. Weitere Informationen finden Sie unter Interne Application Load Balancer und verbundene Netzwerke.
Sie können den globalen Zugriff auf internen Application Load Balancern und regionalen internen Proxy-Network Load Balancern aktivieren, um auf Clients in beliebigen Regionen zuzugreifen. Standardmäßig müssen sich die 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 Systemdiagnose für Load Balancer-Back-End
Firewalls blockieren die 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 für eingehenden Traffic erstellen, die Traffic von Google Cloud-Probern zu Ihren Back-Ends zulassen. Andernfalls gelten die Back-Ends als fehlerhaft.
Empfehlungen
Erstellen Sie Firewallregeln für eingehenden 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 ist standardmäßig blockiert und kann nicht durch 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: Senden von Traffic an TCP-Port 3310 an eine MySQL Cloud SQL-Instanz mit geöffnetem Port 3306.
- Senden von ausgehendem Traffic aus einer Version der App Engine-Standardumgebung, einer Cloud Run-Funktion oder einer Cloud Run-Revision, 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 verworfen, da für die Version der App Engine-Standardumgebung, die Cloud Run-Funktion oder die Cloud Run-Revision kein Connector für den 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 Version der App Engine-Standardumgebung, die Cloud Run-Funktion oder die Cloud Run-Revision konfiguriert.
Empfehlungen
Wenn Sie versuchen, über die private IP-Adresse auf den Zielendpunkt zuzugreifen, prüfen Sie, ob Sie einen Connector für den Serverloser VPC-Zugriff für die Version der App Engine-Standardumgebung, die Cloud Run-Funktion oder die Cloud Run-Revision konfiguriert haben.
Der Connector für Serverloser VPC-Zugriff wird nicht ausgeführt
Das Paket wurde gelöscht, da 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 den Serverloser VPC-Zugriff angehalten sind.
Empfehlungen
Eine Liste mit Schritten zur Fehlerbehebung finden Sie unter Fehlerbehebung.
Private Service Connect-Verbindung wird nicht akzeptiert
Das Paket wurde verworfen, da die Private Service Connect-Verbindung nicht akzeptiert wurde.
Mögliche Ursache
Der Private Service Connect-Endpunkt befindet sich in einem Projekt, das keine Verbindung zum Dienst herstellen darf. Weitere Informationen finden Sie unter Endpunktdetails ansehen.
Empfehlungen
Der Private Service Connect-Endpunkt muss sich in einem Projekt befinden, das für die Verbindung zum verwalteten Dienst genehmigt ist.
Zugriff auf den Private Service Connect-Endpunkt über ein Peering-Netzwerk
Das Paket wird an den Private Service Connect-Endpunkt im Peering-Netzwerk gesendet. Eine solche Konfiguration wird jedoch 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-Backends auf Google APIs und veröffentlichte Dienste zugreifen.