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.
Wegen Firewall-Regel verworfen
Laut Konfigurationsanalyse wurde das Paket wegen einer Firewallregel verworfen, es sei denn, das Paket 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 Firewallrichtlinie ü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.
Wenn Sie jedoch eine Firewallregel für ausgehenden Traffic mit einer höheren Priorität haben, wird sie wirksam.
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 Firewallregeln verwenden.
Privater Traffic zum Internet
Ein Paket mit einer internen Zieladresse wurde an ein Internetgateway gesendet.
Mögliche Ursache
Die Ziel-IP-Adresse ist eine private IP-Adresse, die nicht über das Internet erreichbar ist. Das Paket verlässt die Quell-VM, es gibt jedoch keine interne Route zum Zielendpunkt und folgt dem Pfad zum Internetgateway.
Empfehlungen
Wenn Sie über das Internet auf die Ziel-IP-Adresse zugreifen möchten, muss Ihre VM über eine Internetverbindung verfügen und Sie können die öffentliche IP-Adresse des Zielendpunkts verwenden.
Wenn Sie über die private IP-Adresse auf die VM zugreifen möchten, müssen Sie eine Verbindung zwischen Netzwerken herstellen. Dies kann auf eine der folgenden Arten geschehen:
- Wenn sich Ihr Zielendpunkt in einem lokalen Netzwerk befindet, verwenden Sie 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. Dies ist eine empfohlene Lösung, wenn sich die Netzwerk-IP-Adressbereiche zwischen Ihren Netzwerken nicht überschneiden.
- Konfigurieren Sie Cloud VPN zwischen VPC-Netzwerken.
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. Achten Sie darauf, dass Routen auf beiden Seiten der Verbindung korrekt beworben werden.
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.
Weiterleitungsregeln stimmen nicht überein
Das Protokoll und die Ports der Weiterleitungsregel stimmen nicht mit dem Paketheader überein.
Mögliche Ursache
Das Protokoll und die Ports der Weiterleitungsregel stimmen nicht mit dem Paketheader überein oder das Paket stammt nicht aus derselben Region oder wird nicht in dieselbe Region wie der regionale Load-Balancer weitergeleitet.
Empfehlungen
Bestätigen Sie das Protokoll der Zielweiterleitungsregel und den Port.
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. VM oder VPC-Connector) in derselben Region wie der Load-Balancer 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 Internes HTTP(S)-Load-Balancing und verbundene Netzwerke.
Sie können globalen Zugriff auf einem internen TCP/UDP-Load-Balancer aktivieren, um von Clients in jeder Region auf den Zugriff zuzugreifen. Globaler Zugriff auf einen internen HTTP(S)-Load-Balancer ist nicht möglich.
Verworfen, da keine Route vorhanden
Verworfen, da keine Routen vorhanden.
Mögliche Ursache
Es gibt keine anwendbare Route zum Zielendpunkt. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf. Klicken Sie auf Routen. Filtern Sie die Routen für das VPC-Netzwerk, in dem sich die Quell-VM befindet, und bestätigen Sie, dass keine Route die Ziel-IP-Adresse enthält.
Empfehlungen
Wenn Sie versuchen, über die private IP-Adresse auf den Zielendpunkt zuzugreifen, müssen die Quell- und Zielnetzwerke verbunden sein.
Wenn Sie bereits eine Verbindung zwischen den Netzwerken haben, achten Sie darauf, dass die Routen auf beiden Seiten der Verbindung korrekt beworben werden. 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-Peering wird nicht unterstützt. Prüfen Sie die Verwendung von VPN oder Peering dieser beiden VPC-Netzwerke.
Wenn Sie versuchen, über das Internet auf den Zielendpunkt zuzugreifen, prüfen Sie, ob Sie eine Route für dieses Ziel über das Standard-Internetgateway haben.
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 Back-End-Dienst des Load-Balancers Back-Ends 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 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 App Engine-Standardumgebungsversion, einer Cloud Functions-Funktion oder einer Cloud Run-Überarbeitung 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 serverlosen VPC-Zugriff ist nicht konfiguriert
Das Paket wurde verworfen, da für die App Engine-Standardumgebungsversion, die Cloud Functions-Funktion oder die Cloud Run-Überarbeitung kein Connector für serverlosen VPC-Zugriff konfiguriert wurde.
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 für die App Engine-Standardumgebung, die Cloud Functions-Funktion oder die Cloud Run-Überarbeitung ist kein Connector für serverlosen VPC-Zugriff konfiguriert.
Empfehlungen
Wenn Sie versuchen, über die private IP-Adresse auf den Zielendpunkt zuzugreifen, müssen Sie einen Connector für serverlosen VPC-Zugriff für die Version der App Engine-Standardumgebung, die Cloud Functions-Funktion oder die Cloud Run-Überarbeitung konfiguriert haben.
Connector für serverlosen VPC-Zugriff wird nicht ausgeführt
Das Paket wurde verworfen, da der Connector für serverlosen VPC-Zugriff nicht ausgeführt wird.
Mögliche Ursache
Das Paket wurde verworfen, da alle Connector-Instanzen für den serverlosen VPC-Zugriff beendet wurden.
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 Endpunkt für Private Service Connect befindet sich in einem Projekt, das nicht für die Verbindung mit dem Dienst genehmigt ist. Weitere Informationen finden Sie unter Endpunktdetails ansehen.
Empfehlungen
Der Endpunkt von Private Service Connect muss sich in einem Projekt befinden, das für die Verbindung mit dem verwalteten Dienst genehmigt wurde.