Gründe für verworfene Testpakete

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.

Externe IP-Adresse unzulässig

Das Paket wird verworfen, da eine Compute Engine-Instanz empfangen nur dann Pakete mit einer fremden IP-Adresse, wenn die IP-Weiterleitung aktiviert ist.

Mögliche Ursache

Für die VM-Instanz ist die IP-Weiterleitung nicht aktiviert, aber für die Quelle oder Die Ziel-IP-Adresse des durchlaufenden Pakets stimmt nicht mit dem die IP-Adressen der Instanz. Dies kann beispielsweise der Fall sein, wenn das Paket mithilfe einer statischen Route mit der VM-Instanz als nächsten Hop an die Instanz ausgeliefert werden.

Empfehlungen

Erstellen Sie eine Compute Engine-Instanz mit aktivierter IP-Weiterleitung oder legen Sie für die vorhandene Instanz. Weitere Informationen finden Sie unter Aktivieren Sie die IP-Weiterleitung für Instanzen.

Wegen Firewall-Regel verworfen

Das Paket kann aufgrund einer Firewallregel gelöscht werden, es sei denn, das Paket ist aufgrund des Verbindungs-Trackings zulässig.

Mögliche Ursache

Konnektivitätstests können ein Testpaket ablehnen, da das Paket mit einem Firewallregel oder Firewallrichtlinien-Regel blockieren. Die tatsächliche Datenebene kann jedoch das Paket durch die Verbindungsverfolgung in der Firewallregel weiterleiten. Verbindungstracking ermöglicht Pakete für eine bestehende Verbindung, die trotz der Firewallregel zurückgegeben werden soll.

Jedes VPC-Netzwerk hat zwei implizierte Firewallregeln. die ausgehenden Traffic überall hin zulassen und eingehenden Traffic von überall. 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 den Zugriff auf den Zielendpunkt und eine Firewallregel für eingehenden Traffic das Ziel, 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 passende Route gefunden

Das Paket wird aufgrund fehlender übereinstimmender Routen verworfen.

Mögliche Ursache

Es gibt keine aktive Route, die den Paketattributen entspricht (z. B. eine Ziel-IP-Adresse) Adresse) im Paketnetzwerk und in der Region.

Empfehlungen

Prüfen Sie die Liste der aktiven Routen in in der Google Cloud Console. Wenn Sie gerade eine neue Route erstellt haben, kann das etwas dauern damit Konnektivitätstests ein Konfigurationsupdate erhalten und es einbinden in die Analyse einzubeziehen.

Wenn Sie versuchen, über die interne IP-Adresse auf den Zielendpunkt zuzugreifen, prüfen Sie, ob das Quell- und Zielnetzwerk verbunden sind (z. B. über VPC-Netzwerk-Peering Network Connectivity Center, oder eine Hybridkonnektivitätslösung wie Cloud VPN).

Beachten Sie, dass transitives VPC-Peering wird nicht unterstützt. Quell- und Zielnetzwerk verbinden oder mithilfe einer hybriden Konnektivitätslösung.

Wenn Sie versuchen, über das Internet auf den Zielendpunkt zuzugreifen, dass Sie eine Route für die Ziel-IP-Adresse mit dem nächsten Hop haben, Internetgateways.

Wenn das Paket die Netzwerk-Endpunktgruppe für Hybridkonnektivität durchläuft: Berücksichtigen Sie zusätzliche Anforderungen für die Anwendbarkeit von Routen. Einige Routen, die Sie in der Tabelle „Routenansicht“ sehen, sind möglicherweise nicht für den Traffic verfügbar aus Hybrid-NEGs.

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. Beispielsweise führen Sie eine von einer Compute Engine-Instanz im Netzwerk network-1 zum Compute Engine-Instanz im Netzwerk network-2, aber das Paket an das Netzwerk network-3 gesendet.

Mögliche Ursache

Das network-1-Netzwerk enthält eine Route mit einem Zielbereich, der den IP-Adresse der Zielinstanz mit dem nächsten Hop in einem anderen Netzwerk (network-3 im Beispiel oben).

Empfehlungen

Überprüfen Sie die Liste der effektiven Routen und die Liste der Routen für die Quellinstanz, in der Google Cloud Console. Weitere Informationen zur Routenerstellung und Anwendbarkeit finden Sie unter Routen und Routen verwenden

IP-Adresse des nächsten Hops der Route ist nicht aufgelöst

Das Paket wird über eine ungültige Route mit der IP-Adresse des nächsten Hops an ein Ziel gesendet Adresse ist keiner Ressource zugewiesen.

Mögliche Ursache

Wenn dies eine Route mit next-hop-address ist, 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 an. Adressen in Peering-Netzwerken sind nicht unterstützt.

Wenn dies eine Route mit next-hop-ilb ist, muss die Adresse des nächsten Hops eine Adresse des internen Passthrough-Network Load Balancers (Weiterleitungsregeln, die von anderen Lastenausgleichsmodulen verwendet werden, oder Private Service Connect-Endpunkte unterstützt). Die IP-Adresse muss einer Ressource in der VPC der Route zugewiesen sein oder in einem Netzwerk, 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 Weitere Informationen finden Sie unter Überlegungen zu Next-Hop-Instanzen. und Überlegungen zu den 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 mit dem nächsten Hop an ein Ziel gesendet Compute Engine-Instanz ohne Network Interface Controller (NIC) im Netzwerk der Route.

Mögliche Ursache

Die Compute Engine-Instanz, die als nächster Hop der Route verwendet wird, muss eine NIC in der das Netzwerk der Route (kein Peering-VPC-Netzwerk).

Empfehlungen

Prüfen, ob die Compute Engine-Instanz des nächsten Hops eine NIC hat das Netzwerk der Route. Weitere Informationen finden Sie unter Überlegungen zu Next-Hop-Instanzen

Adresse des nächsten Hops der Route ist keine primäre VM-IP-Adresse

Das Paket wird über eine ungültige Route mit der IP-Adresse des nächsten Hops an ein Ziel gesendet (next-hop-address) keine primäre IP-Adresse des Compute Engine-Instanz.

Mögliche Ursache

Die Next-Hop-IP-Adresse der Route (next-hop-address) muss eine primäre interne IP-Adresse sein IPv4-Adresse der Compute Engine-Instanz. 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 des Compute Engine-Instanz. Weitere Informationen finden Sie unter Überlegungen zu Next-Hop-Instanzen

Weiterleitungsregeltyp des nächsten Hops der Route ist ungültig

Das Paket wird über eine ungültige Route mit dem nächsten Hop an ein Ziel gesendet Weiterleitungsregel (next-hop-ilb) ist keine Weiterleitungsregel der internen Passthrough-Network Load Balancer.

Mögliche Ursache

Die Next-Hop-Weiterleitungsregel der Route muss eine Weiterleitungsregel der internen Passthrough-Network Load Balancer. Weitere Informationen finden Sie unter Überlegungen zu den nächsten Hops des internen Passthrough-Network Load Balancers

Empfehlungen

Erstellen Sie eine Route, die auf eine unterstützte Weiterleitungsregel anstelle der ungültigen Route.

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 sind. Das Paket verlässt jedoch Compute Engine-Quellinstanz und gleicht eine Route mit dem nächsten Hop ab Internetgateways.

Empfehlungen

Wenn Sie über das Internet auf das Ziel zugreifen möchten, achten Sie darauf, dass das Quellinstanz der Compute Engine eine Internetverbindung hat – für z. B. eine externe IP-Adresse hat oder Cloud NAT verwendet. und die externe IP-Adresse des Zielendpunkts im Test verwenden.

Wenn Sie über die interne IP-Adresse auf das Ziel zugreifen möchten, Verbindungen (Routen erstellen) zwischen Quelle und Zielnetzwerke. Dazu haben Sie folgende Möglichkeiten:

1. Wenn sich der Zielendpunkt in einem lokalen Netzwerk befindet, verwenden Sie ein Network Connectivity Center oder eine Hybridkonnektivitätslösung, wie z. B. Cloud VPN oder Cloud Interconnect.
2. Wenn Ihr Zielendpunkt in Google Cloud liegt:
   1. Konfigurieren Sie das VPC-Netzwerk-Peering zwischen VPC-Netzwerke
   2. Konfigurieren Sie Cloud VPN zwischen VPC-Netzwerken.
   3. Konfigurieren Sie die Netzwerkverbindung mithilfe von VPC-Spokes von Network Connectivity Center.

3. Wenn Sie bereits eine Verbindung zum Zielnetzwerk haben:

   1. Das Netzwerk des Quell-Endpunkts hat keine Route durch dieses oder nutzt die Standardroute über das Internet Gateway Überprüfen Sie die Liste der effektiven Routen. und die Liste der Routen für die Quellinstanz in der Google Cloud Console. Weitere Informationen zur Route Erstellung und Anwendbarkeit, siehe 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

Compute Engine-Instanz, die nur eine interne IP-Adresse hat, versucht, den externe IP-Adresse von Google APIs und Diensten, aber der privater Google-Zugriff ist nicht im Subnetz der Instanz aktiviert ist.

Empfehlungen

Sie können zulassen, dass die Compute Engine-VM-Instanz die externe IP-Adresse erreicht die Adresse der Google APIs und Google-Dienste auf folgende Weise verwenden:

1. Aktivieren Sie den privaten Google-Zugriff für die das Subnetz der Instanz.
2. Weisen Sie der Compute Engine-Netzwerkkarte eine externe IP-Adresse zu.
3. Aktivieren Sie Cloud NAT für das Subnetz der VM-Instanz.

Privater Google-Zugriff über einen VPN-Tunnel wird nicht unterstützt

Ein Quellendpunkt mit einer internen IP-Adresse versucht, die externe IP-Adresse zu erreichen Adresse von Google APIs und Diensten über den VPN-Tunnel zu einem anderen Netzwerk, Der privater Google-Zugriff muss jedoch im Netzwerk des Quell-Endpunkts aktiviert sein.

Mögliche Ursache

Das Paket vom Quellendpunkt zur externen IP-Adresse des Google APIs und Dienste werden durch den Cloud VPN-Tunnel geleitet, aber so Konfiguration wird nicht unterstützt.

Empfehlungen

Wenn der Quellendpunkt ein Google Cloud-Endpunkt ist (z. B. Compute Engine-VM-Instanz) Privater Google-Zugriff im Quellsubnetz angegeben.

Wenn der Quellendpunkt ein lokaler Endpunkt ist, verweisen Sie auf die Privater Google-Zugriff für lokale Hosts .

Weiterleitungsregel stimmt nicht überein

Das Protokoll und die Ports der Weiterleitungsregel stimmen nicht mit dem Paketheader überein.

Mögliche Ursache

Das Paket wird über ein Protokoll gesendet, das von der Weiterleitungsregel nicht unterstützt wird. oder das Paket wird an einen Zielport gesendet, der nicht mit den Ports übereinstimmt die von der Weiterleitungsregel unterstützt wird.

Empfehlungen

Prüfen Sie das Zielprotokoll und die Ports für die Weiterleitungsregel.

Region der Weiterleitungsregel stimmt nicht überein

Für die Weiterleitungsregel ist weder der globale Zugriff aktiviert noch für die zugehörige Region mit der Region des Pakets übereinstimmen.

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.

Bei einer regionalen Weiterleitungsregel ist der Client (z. B. die VM oder des VPC-Connector) muss sich in derselben Region wie der Load-Balancer.

Empfehlungen

Wenn Sie die Verbindung zum Load-Balancer über einen Google Cloud-Endpunkt herstellen, z. B. Compute Engine-VM-Instanz, die sich in derselben Region befindet als Weiterleitungsregel.

Achten Sie beim Herstellen einer Verbindung von einem lokalen Netzwerk darauf, dass der Client greift über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load-Balancer zu 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, um auf Clients in beliebigen Region Standardmäßig müssen sich die Clients für diese Load-Balancer in derselben Region befinden wie der Load-Balancer. 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 nicht für Traffic vom Load-Balancer verfügbar.

Mögliche Ursache

Damit Systemdiagnosen funktionieren, müssen Sie Firewallregeln zum Zulassen von eingehendem Traffic erstellen, zulassen, dass Traffic von Google Cloud-Probern Ihre Back-Ends erreicht. Andernfalls werden die Back-Ends als fehlerhaft betrachtet.

Empfehlungen

Erstellen Sie Firewallregeln zum Zulassen von eingehendem Traffic gemäß den Prüfungs-IP-Bereichen 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 für sein Subnetz, es sei denn, das Die Verbindung geht über eine Proxy-Instanz, 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 Firewallregeln. Gängige Szenarien:

1. Ausgehenden Traffic mit dem TCP-Port 25 (SMTP) an ein externes Ziel senden. Weitere Details finden Sie unter Permanent blockierter Traffic.
2. Traffic an einen nicht unterstützten Port auf einer Cloud SQL-Instanz senden Für Beispiel: Traffic an TCP-Port 3310 an eine MySQL-Cloud SQL-Instanz senden Port 3306 geöffnet ist.
3. Ausgehenden Traffic von einer Version der App Engine-Standardumgebung senden eine Cloud Functions-Funktion oder einen Cloud Run Version, 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 die Version der App Engine-Standardumgebung Cloud Functions-Funktion oder die Cloud Run-Version hat kein Connector für serverlosen VPC-Zugriff konfiguriert.

Mögliche Ursache

Die Ziel-IP-Adresse ist eine private IP-Adresse die nicht erreichbar ist. über das Internet. Das Paket verlässt die Quelle, aber es ist kein Connector für Serverloser VPC-Zugriff, der für den Version der App Engine-Standardumgebung, die Cloud Functions-Funktion oder Cloud Run Überarbeitung.

Empfehlungen

Wenn Sie versuchen, über die private IP-Adresse auf den Zielendpunkt zuzugreifen, Prüfen Sie, ob Sie einen Serverloser VPC-Zugriff konfiguriert haben Connector für die Version der App Engine-Standardumgebung, die Cloud Functions-Funktion, oder die Cloud Run-Version.

Connector für Serverloser VPC-Zugriff wird nicht ausgeführt

Das Paket wurde verworfen, weil der Connector für serverlosen VPC-Zugriff wird nicht ausgeführt.

Mögliche Ursache

Das Paket wurde verworfen, da der gesamte Serverloser VPC-Zugriff Connector-Instanzen beendet wurden.

Empfehlungen

Eine Liste der Schritte zur Fehlerbehebung finden Sie unter Fehlerbehebung.

Private Service Connect-Verbindung wird nicht akzeptiert

Das Paket wurde gelöscht, da die Private Service Connect-Verbindung wurde nicht akzeptiert.

Mögliche Ursache

Der Private Service Connect-Endpunkt befindet sich in einem Projekt, das nicht genehmigt wurde, eine Verbindung mit dem Dienst herzustellen. Weitere Informationen Informationen finden Sie unter Endpunktdetails ansehen.

Empfehlungen

Achten Sie darauf, dass sich der Private Service Connect-Endpunkt in einem Projekt, das für die Verbindung mit dem verwalteten Dienst genehmigt wurde.

Auf den Private Service Connect-Endpunkt wird über ein Peering-Netzwerk zugegriffen

Das Paket wird an den Private Service Connect-Endpunkt im verbundenen Peering-Netzwerken. Eine solche Konfiguration wird jedoch nicht unterstützt.

Empfehlungen

Verwenden Sie gegebenenfalls eines der im Private Service Connect-Bereitstellungsmuster Seite. Sie können auch auf Google APIs und veröffentlichte Dienste zugreifen, indem Sie Private Service Connect-Back-Ends