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.

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. Dies kann beispielsweise passieren, wenn das Paket über eine statische Route mit der VM-Instanz als nächstem 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 gemäß einer Firewallregel gelöscht werden, sofern es nicht aufgrund des Verbindungs-Trackings zugelassen ist.

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. Wenn für die Firewallrichtlinienregel, die den Traffic abgelehnt hat, ein Netzwerkkontext angegeben ist, lesen Sie die Informationen zu Firewallrichtlinienregeln, um festzustellen, ob die Regel auf Ihren Anwendungsfall zutrifft.

Verworfen, da keine übereinstimmende Route vorhanden

Das Paket wird verworfen, da keine übereinstimmenden Routen vorhanden sind.

Mögliche Ursache

Im Paketnetzwerk und in der Paketregion gibt es keine aktive Route, die mit den Paketattributen (z. B. einer Ziel-IP-Adresse) ü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 ein Konfigurationsupdate erhalten und es in die Analyse aufgenommen wird.

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 nicht unterstützt wird. Sie können die Quell- und Zielnetzwerke direkt oder über eine 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 Internetgateway als nächsten Hop haben.

Wenn das Paket die Netzwerk-Endpunktgruppe mit Hybridkonnektivität durchläuft, beachten Sie die zusätzlichen Anforderungen für die Anwendbarkeit von Routen. Einige Routen in der Routenansichtstabelle sind möglicherweise nicht für Traffic von Hybrid-NEGs verfügbar.

Weitere Informationen finden Sie unter Routen und Routen verwenden.

Das Paket wird an ein falsches Netzwerk gesendet.

Das Paket wird an ein unbeabsichtigtes Netzwerk gesendet. Sie führen beispielsweise 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 obigen Beispiel).

Empfehlungen

Prüfen Sie in der Google Cloud Console die Liste der aktiven Routen und die Liste der Routen, die für die Quellinstanz gelten. Weitere Informationen zum Erstellen von Routen und zur Anwendbarkeit finden Sie unter Routen und Routen verwenden.

IP-Adresse des nächsten Hops der Route wird 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 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, der 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 diesem 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 Instanzen, die als nächster Hop dienen 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 über eine ungültige Route an ein Ziel gesendet, wobei die Compute Engine-Instanz des nächsten Hops keinen Netzwerk-Schnittstellen-Controller (NIC) im Netzwerk der Route hat.

Mögliche Ursache

Die Compute Engine-Instanz, die als nächster Hop einer 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 für den nächsten Hop 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 über eine ungültige Route an ein Ziel gesendet, wobei die Next-Hop-IP-Adresse (next-hop-address) keine primäre IP-Adresse der Compute Engine-Instanz ist.

Mögliche Ursache

Die IP-Adresse des nächsten Hops der Route (next-hop-address) 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 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 Weiterleitungsregel für den nächsten Hop der Route ist ungültig

Das Paket wird an ein Ziel mit einer ungültigen Route 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 für den nächsten Hop 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 statt auf die ungültige Route abzielt.

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 stimmt mit einer Route mit dem nächsten Hop-Internetgateway überein.

Empfehlungen

Wenn Sie über das Internet auf das Ziel zugreifen möchten, muss die Compute Engine-Quellinstanz über eine Internetverbindung verfügen, z. B. über eine externe IP-Adresse oder über 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 (Routen erstellen) zwischen dem Quell- und dem Zielnetzwerk herstellen. Dies kann auf eine der folgenden Arten geschehen:

  1. Wenn sich Ihr Zielendpunkt in einem lokalen Netzwerk befindet, verwenden Sie eine NCC-Lösung oder eine Hybridkonnektivitätslösung wie Cloud VPN oder Cloud Interconnect.
  2. Wenn Ihr Zielendpunkt in Google Cloudliegt:
    1. Konfigurieren Sie das VPC-Netzwerk-Peering zwischen VPC-Netzwerken.
    2. Konfigurieren Sie Cloud VPN zwischen VPC-Netzwerken.
    3. Konfigurieren Sie die Netzwerkverbindung mit VPC-Spokes des Network Connectivity Center.

  3. Wenn Sie bereits eine Verbindung zum Zielnetzwerk haben:

    1. Das Quellendpunkt-Netzwerk hat keine Route über diese Verbindung oder verwendet die Standardroute, die über das Internetgateway geleitet wird. Prüfen Sie die Liste der effektiven Routen und die Liste der Routen, die für die Quellinstanz gelten, in der Google Cloud Console. Weitere Informationen zum Erstellen von Routen und zur Anwendbarkeit 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 mit nur einer internen IP-Adresse 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 der Compute Engine-VM-Instanz auf eine der folgenden Arten erlauben, die externe IP-Adresse von Google APIs und Google-Diensten zu erreichen:

  1. Aktivieren Sie den privaten Google-Zugriff für das Subnetz der Instanz.
  2. Weisen Sie der Compute Engine-NIC eine externe IP-Adresse zu.
  3. 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, allerdings muss der privater Google-Zugriff im Netzwerk des Quellendpunkts 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 ist (z. B. eine Compute Engine-VM-Instanz), sollten Sie den 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.

Unbekannte interne Adresse

Die interne Ziel-IP-Adresse kann nicht in ein bekanntes Ziel aufgelöst werden.

Empfehlungen

  • Wenn Sie die Konnektivität für ein freigegebene VPC-Netzwerk testen, prüfen Sie, ob die Dienstprojekt-ID als Testeingabe angegeben ist.
  • Prüfen Sie, ob die IP-Adresse einem unterstützten Zielendpunkt zugewiesen ist.

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 das Paket wird an einen Zielport gesendet, der nicht mit den von der Weiterleitungsregel unterstützten Ports übereinstimmt.

Empfehlungen

Bestätigen Sie das Protokoll der Zielweiterleitungsregel und die Ports.

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 von einem Google Cloud -Endpunkt wie einer Compute Engine-VM-Instanz eine Verbindung zum Load Balancer 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 für 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 Systemdiagnose für Load-Balancer-Backend

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 für eingehenden Traffic erstellen, die Traffic von Google Cloud -Probern zu Ihren Backends 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.

Firewall blockiert Envoy-Proxy-Systemdiagnose des Load Balancers

Firewallregeln blockieren Systemdiagnoseprüfungen an die Envoy-Proxys, die vom Load Balancer verwendet werden.

Mögliche Ursache

Bei internen Application Load Balancern und internen Proxy-Network Load Balancern verwendet Google Systemdiagnoseprüfungen, um verwaltete Envoy-Proxys zu überwachen. Wenn eine regionale Netzwerk-Firewallrichtlinie Regeln enthält, die auf die Weiterleitungsregel des Load Balancers (--target-type=INTERNAL_MANAGED_LB) abzielen, kann eine Ablehnungsregel für eingehenden Traffic diese Prüfungen blockieren.

Dieser Drop tritt auf, wenn die Richtlinie keine Zulassungsregel für eingehenden Traffic mit höherer Priorität für die IP-Adressbereiche der Systemdiagnoseprüfungen hat. Infolgedessen werden die Systemdiagnoseprüfungen blockiert und die Envoy-Proxys gelten als nicht verfügbar.

Empfehlungen

Konfigurieren Sie eine Firewallregel für eingehenden Traffic mit höherer Priorität und dem Flag --target-type=INTERNAL_MANAGED_LB, um eingehenden Traffic aus den IP-Adressbereichen der SystemdiagnoseprüfungGoogle für die Weiterleitungsregel zuzulassen.

Weitere Informationen finden Sie unter Cloud NGFW-Ressourcen erstellen und Prüfungs-IP-Bereiche für ausgewählte verwaltete Envoy-basierte Load-Balancer-Frontends.

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

Die Weiterleitungsregel ist mit keinen Backends verknüpft.

Mögliche Ursache

Dieser Rückgang hat folgende Gründe:

  • An den Backend-Dienst des Load Balancers sind keine Backends angehängt.
  • Die Weiterleitungsregel verweist auf einen Ziel-Proxy, dessen Routingkonfiguration fehlt:
    • Application Load Balancer: Der Ziel-Proxy ist keiner URL-Zuordnung zugeordnet.
    • Proxy-Netzwerk-Load-Balancer, die SNI-Routing (Server Name Indication) verwenden: Der Ziel-Proxy ist keiner TLS-Route zugeordnet.

Empfehlungen

Prüfen Sie die Konfiguration des Load Balancers so:

  • Achten Sie darauf, dass dem Standard-Backend-Dienst Backends angehängt sind.
  • Achten Sie bei Application Load Balancern darauf, dass der Ziel-Proxy auf eine URL-Zuordnung verweist und dass an den oder die in der URL-Zuordnung definierten Backend-Dienste Backends angehängt sind.
  • Achten Sie bei Proxy-Network Load Balancern, die SNI-Routing verwenden, darauf, dass der Ziel-Proxy in mindestens einer TLS-Route referenziert wird und dass die in der TLS-Route definierten Backend-Dienste Backends haben.

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:

  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 Beispiel: Senden von Traffic an TCP-Port 3310 an eine MySQL Cloud SQL-Instanz mit geöffnetem Port 3306.
  3. Senden von ausgehendem Traffic von einer App Engine-Standardumgebungsversion, einer Cloud Run-Funktion, einer Cloud Run-Überarbeitung oder einem Cloud Run-Job, der 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.

Zugriff auf die Steuerungsebene des GKE-Cluster ist nicht autorisiert

Der Zugriff auf die Steuerungsebene des GKE-Cluster über die Quell-IP-Adresse ist nicht autorisiert.

Mögliche Ursache

Die von Ihnen verwendete Quell-IP-Adresse stimmt nicht mit den autorisierten Zugriffsregeln überein, die für Ihren GKE-Cluster konfiguriert sind. Weitere Informationen finden Sie unter Zugriff auf die Clusterendpunkte.

Empfehlungen

Aktualisieren Sie den Zugriff auf die GKE-Steuerungsebene, um die ausgewählte Quelle zuzulassen, wie unter Zugriff auf die Steuerungsebene ändern beschrieben.

Zugriff auf die Cloud SQL-Instanz ist nicht autorisiert

Der Zugriff auf die Cloud SQL-Instanz über die Quell-IP-Adresse ist nicht autorisiert.

Mögliche Ursache

Die von Ihnen verwendete Quell-IP-Adresse stimmt nicht mit den autorisierten Netzwerken überein, die für Ihre Cloud SQL-Instanz konfiguriert sind. Damit die Verbindung funktioniert, muss die IP-Adresse oder der Adressbereich Ihrer Clientanwendung als autorisiertes Netzwerk auf der Cloud SQL-Instanz konfiguriert sein.

Empfehlungen

Aktualisieren Sie den Zugriff auf die Cloud SQL-Instanz, um die ausgewählte Quell-IP-Adresse zuzulassen, wie unter Mit autorisierten Netzwerken autorisieren beschrieben.

Netzwerk-Tags werden von Direct VPC-Traffic in Firewallregeln für eingehenden Traffic nicht unterstützt.

Das Paket wird verworfen, da Direct VPC-Ausgang keine Quellnetzwerk-Tags in Firewallregeln für eingehenden Traffic unterstützt.

Mögliche Ursache

Das Abgleichen von Firewallregeln für eingehenden Traffic anhand von Quellnetzwerk-Tags wird für Cloud Run-Verbindungen über Direct VPC-Ausgang nicht unterstützt. Weitere Informationen finden Sie unter Einschränkungen.

Empfehlungen

Aktualisieren Sie Ihre Firewallregeln, um Quell-IP-Bereiche anstelle von Quellnetzwerk-Tags zu verwenden, damit Traffic von Cloud Run-Verbindungen über ausgehenden Direct VPC-Traffic abgeglichen wird.

Connector für Serverloser VPC-Zugriff ist nicht konfiguriert

Das Paket wurde verworfen, weil für die App Engine-Standardumgebungsversion, die Cloud Run-Funktion oder die Cloud Run-Überarbeitung oder den Cloud Run-Job 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, die Cloud Run-Funktion oder die Cloud Run-Überarbeitung oder den Cloud Run-Job konfiguriert.

Empfehlungen

Wenn Sie versuchen, über die private IP-Adresse auf den Zielendpunkt zuzugreifen, prüfen Sie, ob Sie einen Connector für Serverloser VPC-Zugriff für die App Engine-Standardumgebungsversion, die Cloud Run-Funktion oder die Cloud Run-Überarbeitung oder den Cloud Run-Job konfiguriert haben.

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

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

Mögliche Ursache

Das Paket wurde verworfen, weil alle Connector-Instanzen für den Serverloser VPC-Zugriff beendet wurden.

Empfehlungen

Eine Liste der Schritte zur Fehlerbehebung finden Sie unter Fehlerbehebung.

Private Service Connect-Verbindung wird nicht akzeptiert

Das Paket wurde verworfen, weil die Private Service Connect-Verbindung nicht akzeptiert wurde.

Mögliche Ursache

Der Private Service Connect-Endpunkt 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 Private Service Connect-Endpunkt muss sich in einem Projekt befinden, 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 Peering-Netzwerk gesendet. Eine solche Konfiguration wird jedoch nicht unterstützt.

Empfehlungen

Google empfiehlt, zu einer Hub-and-Spoke-Architektur mit Network Connectivity Center zu wechseln, um die Weitergabe von Private Service Connect-Verbindungen zu ermöglichen.

Alternativ können Sie eines der folgenden Verbindungsmuster verwenden:

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Support oder den Google Cloud -Ansprechpartner Ihres Diensterstellers.

Keine gültige Route von einem von Google verwalteten Netzwerk zum Ziel

Das Paket wird gelöscht, da keine gültige übereinstimmende Route vom Netzwerk des von Google verwalteten Dienstes zum Ziel vorhanden ist.

Diese Ursache für das Verwerfen gilt für alle von Google verwalteten Dienste, die von Konnektivitätstests unterstützt werden, einschließlich Cloud SQL und GKE.

Empfehlungen

Prüfen Sie, ob der von Google verwaltete Dienst so konfiguriert ist, dass Traffic an das Ziel gesendet wird.

  • Wenn das Ziel über lokale statische oder dynamische Routen erreichbar sein soll, die in Ihrem VPC-Netzwerk konfiguriert sind, müssen Sie dafür sorgen, dass das VPC-Netzwerk diese Routen in das Netzwerk des von Google verwalteten Dienstes exportiert. Dieses Muster ist üblich für Verbindungen von von Google verwalteten Diensten zu Zielen, die über Cloud VPN oder Cloud Interconnect erreichbar sind.

  • Wenn sich das Ziel in einem Subnetzwerk befindet, das mit privat verwendeten öffentlichen IP-Adressbereichen konfiguriert ist, müssen Sie dafür sorgen, dass Ihr Netzwerk die entsprechenden Subnetzrouten in das Netzwerk des von Google verwalteten Dienstes exportiert.

  • Wenn das Ziel eine über das Internet routingfähige externe IP-Adresse ist, muss der von Google verwaltete Dienst für diesen Verbindungspfad konfiguriert sein. Einige Arten von Cloud SQL-Instanzen unterstützen beispielsweise keine ausgehenden externen Verbindungen.

  • Wenn das Ziel über dynamische Routen erreichbar sein soll, die über VPC-Netzwerk-Peering in das Netzwerk des von Google verwalteten Dienstes importiert wurden, wird möglicherweise das Limit für dynamische Routen pro Region und Peering-Gruppe für das Dienstnetzwerk erreicht. Wenn Sie der Meinung sind, dass dieses Limit erreicht wurde, reichen Sie eine Supportanfrage ein.