Fehlerbehebung bei Downstream-Verbindungen

Auf dieser Seite wird beschrieben, wie Sie Probleme mit ausgehenden Verbindungen für Looker (Google Cloud Core)-Instanzen beheben, die eine private IP-Konfiguration mit Private Service Connect verwenden.

Wenn bei Ihrer ausgehenden Private Service Connect-Verbindung ein Fehler auftritt, verwenden Sie den folgenden Entscheidungsbaum, um mit der Fehlerbehebung zu beginnen.

Weitere Informationen finden Sie in der Dokumentation zu ausgehendem Zugriff von Looker (Google Cloud Core) auf externe Dienste mit Private Service Connect.

Verbindungsfehler beheben

Auch wenn der Status der Private Service Connect-Verbindung Accepted lautet, können Verbindungsfehler auftreten, wenn Looker (Google Cloud Core) versucht, Ihren Dienst zu erreichen.

Probleme mit der Hostnamensauflösung

Wenn Sie in der Looker (Google Cloud Core)-UI beim Testen einer Datenbankverbindung oder wenn Looker (Google Cloud Core) versucht, eine Verbindung zu Ihrem Dienst herzustellen, den Fehler „Unknown host“ erhalten, kann dies darauf hindeuten, dass die DNS-Auflösung für den Hostnamen fehlgeschlagen ist, den Sie für die ausgehende Private Service Connect-Verbindung konfiguriert haben.

Führen Sie in diesem Fall die folgenden Schritte zur Fehlerbehebung aus:

  • Prüfen Sie, ob der in Looker (Google Cloud Core) für den Dienst konfigurierte Hostname korrekt ist und mit dem Hostnamen übereinstimmt, für den ein DNS-Eintrag vorhanden sein sollte.
  • Prüfen Sie, ob Ihr Load-Balancer und Ihr Backend-Dienst fehlerfrei sind.
  • Testen Sie die Verbindung von einer VM in Ihrer Producer-VPC, um sicherzustellen, dass der Backend-Dienst über die Weiterleitungsregel des Load-Balancers erreichbar ist. Sie können eine temporäre VM in derselben VPC und Region wie Ihr Load-Balancer erstellen und mit einem Tool wie curl oder telnet die Verbindung zur IP-Adresse und zum Port des Dienstes testen.

Wenn die Probleme mit der Hostnamensauflösung weiterhin bestehen, wenden Sie sich an den Cloud Customer Care.

Zeitlimits für Verbindungen

Wenn bei Verbindungen von Looker (Google Cloud Core) zu Ihrem Dienst ein Zeitlimit überschritten wird, kann dies an Firewallregeln in Ihrer Producer-VPC liegen, die Traffic vom Private Service Connect-NAT-Subnetz blockieren, oder an anderen Netzwerkproblemen.

  • Prüfen Sie Ihre Firewallregeln, um sicherzustellen, dass eingehender Traffic vom Private Service Connect-NAT-Subnetz zu den Back-Ends Ihres Load-Balancers zugelassen wird.
  • Verwenden Sie Virtual Private Cloud-Flusslogs und Load-Balancer-Logging (z. B. interne Application Load Balancer-Logs oder interne Passthrough-Network Load Balancer-Logs), um Verbindungsprobleme zu diagnostizieren. Mit Virtual Private Cloud-Flusslogs können Sie feststellen, ob Traffic vom NAT-Subnetz Ihren Load-Balancer erreicht, und Load-Balancer-Logs können Details dazu liefern, ob Traffic erfolgreich an fehlerfreie Back-Ends weitergeleitet wird.

Ausgehende Private Service Connect-Konfiguration überprüfen

So prüfen Sie, ob die Verbindung zwischen der Looker (Google Cloud Core)-Instanz und Ihrem Netzwerk korrekt hergestellt wurde:

Status des Private Service Connect-Endpunkts der Looker (Google Cloud Core)-Instanz prüfen

So prüfen Sie den Status der ausgehenden Dienstanhangverbindung in der Konfiguration der Looker (Google Cloud Core)-Instanz:

  1. Rufen Sie in der Google Cloud Console die Looker Seite auf.
  2. Klicken Sie auf den Namen der Instanz, für die Sie die Verbindung prüfen möchten.
  3. Suchen Sie im Abschnitt Networking (Netzwerk) unter Service attachment (Dienstanhang) den Endpunkt, bei dem Sie die Fehlerbehebung durchführen.
  4. Prüfen Sie, ob der Status Accepted lautet.

Wenn der Status Pending lautet, kann dies einen der folgenden Gründe haben:

  • Die Verbindungseinstellung des Dienstanhangs ist nicht auf „Alle Verbindungen automatisch akzeptieren“ festgelegt und die Verbindung wurde nicht manuell genehmigt.
  • Das Projekt der Looker (Google Cloud Core)-Instanz ist nicht auf der Zulassungsliste des Dienstanhangs.

Um den Status Pending zu beheben, prüfen Sie die Konfiguration des Dienstanhangs und sorgen Sie dafür, dass die Verbindungseinstellung auf Automatically accept all connections festgelegt ist oder dass das Looker (Google Cloud Core)-Projekt explizit zugelassen wurde.

Wenn die Domain oder der Anhang-URI falsch ist, führen Sie den Befehl gcloud looker instances update noch einmal mit den richtigen Werten aus. Dieser Befehl überschreibt alle vorhandenen Anhänge. Daher müssen alle ausgewählten Anhänge enthalten sein. Weitere Informationen finden Sie unter Looker (Google Cloud Core)-Instanzeinstellungen bearbeiten.

Konfiguration des Dienstanhangs des Erstellers prüfen

Sie sollten auch die Konfiguration des Dienstanhangs in Ihrem Producer-Projekt prüfen, um sicherzustellen, dass er richtig eingerichtet ist, um Verbindungen von Looker (Google Cloud Core) zu empfangen.

Rufen Sie in der Google Cloud Console Netzwerkdienste > Private Service Connect auf und klicken Sie auf den Tab Veröffentlichte Dienste. Klicken Sie auf den Dienstanhang, der für die Verbindung verwendet wird, um die Details aufzurufen.

Prüfen Sie, ob die folgenden Anforderungen erfüllt sind:

  • Der Dienstanhang ist mit einer gültigen Zielweiterleitungsregel und einem dedizierten Private Service Connect-NAT-Subnetz konfiguriert.
  • Die Verbindungseinstellung ist auf Accept automatically festgelegt. Wenn die Verbindungseinstellung Accept for selected networks oder Accept for selected projects lautet, prüfen Sie, ob die Verbindung vom Projekt von Looker (Google Cloud Core) genehmigt wurde.
  • Der Zieldienst verweist auf die richtige Weiterleitungsregel.
  • Das NAT-Subnetz ist richtig konfiguriert und hat ausreichend IP-Adressraum.
  • Der URI des Dienstanhangs, der der Looker (Google Cloud Core)-Instanz zur Verfügung gestellt wird, ist korrekt.

Sie können die Konfiguration des Dienstanhangs über die Google Cloud Console oder mit dem gcloud compute service-attachments update Befehl aktualisieren.

Firewallregeln bestätigen

Traffic von Looker (Google Cloud Core) gelangt über das Private Service Connect-NAT-Subnetz in Ihre VPC. Sie benötigen Firewallregeln, die es diesem Traffic ermöglichen, die Back-Ends des Load-Balancers zu erreichen.

So prüfen Sie Ihre Firewallregeln:

  1. Ermitteln Sie den IP-Bereich des Private Service Connect-NAT-Subnetzes, das für Ihren Dienstanhang konfiguriert ist.
  2. Rufen Sie in der Google Cloud Console die Seite Firewall in Ihrer Producer-VPC auf.
  3. Prüfen Sie, ob eine Firewallregel für eingehenden Traffic vorhanden ist, die TCP-Traffic vom Private Service Connect-NAT-Subnetz zu den Back-Ends Ihres Load-Balancers auf dem von Ihrem Dienst verwendeten Port zulässt. Die Regel muss die folgenden Kriterien erfüllen:
    • Quellfilter: Die Quell-IP-Bereiche umfassen den Private Service Connect-NAT-Subnetzbereich.
    • Ziele: Die Regel gilt für die Back-Ends des internen Load-Balancers (z. B. über Netzwerk-Tags).
    • Protokolle und Ports: Die Regel lässt TCP-Traffic auf dem Port des Zieldienstes zu.

Wenn keine solche Regel vorhanden ist oder eine Regel mit höherer Priorität diesen Traffic ablehnt, erstellen Sie eine Firewallregel für eingehenden Traffic, um Traffic vom Private Service Connect-NAT-Subnetz zuzulassen.

Konfiguration des Load-Balancers und der Netzwerk-Endpunktgruppe prüfen

Ihr Dienst wird Looker (Google Cloud Core) über einen internen Load-Balancer und eine Netzwerk-Endpunktgruppe (Network Endpoint Group, NEG) zur Verfügung gestellt, die auf Ihren Dienst verweist. Prüfen Sie, ob diese Komponenten fehlerfrei und richtig konfiguriert sind.

So prüfen Sie die NEG-Konfiguration:

  1. Rufen Sie in der Google Cloud Console Netzwerkdienste > Load Balancing auf.
  2. Klicken Sie auf Ihren Load-Balancer und dann auf den Backend-Dienst, um die Details aufzurufen.
  3. Klicken Sie in den Details des Backend-Dienstes auf den Namen der Netzwerk-Endpunktgruppe.
  4. Prüfen Sie den Typ der Netzwerk-Endpunktgruppe:
    • Für lokale oder Multi-Cloud-Dienste, die über Cloud VPN oder Cloud Interconnect erreichbar sind, sollte der Typ Hybridkonnektivitäts-NEG (NON_GCP_PRIVATE_IP_PORT) sein.
    • Für öffentliche Internetdienste wie Git-Anbieter sollte der Typ Internet-NEG (INTERNET_FQDN_PORT) sein.
  5. Prüfen Sie im Abschnitt Netzwerkendpunkte, ob die IP-Adresse und der Port (für Hybrid-NEGs) oder der FQDN und der Port (für Internet-NEGs) korrekt mit Ihrem Zieldienst übereinstimmen.

Wenn die NEG falsch konfiguriert ist, müssen Sie sie möglicherweise aktualisieren oder eine neue erstellen.

DNS-Auflösung und -Routing prüfen

Wenn Sie keine Verbindung von Looker (Google Cloud Core) herstellen können, aber andere Schritte zur Fehlerbehebung keine Probleme zeigen, testen Sie die Verbindung in der Producer-VPC, um das Problem zu isolieren:

  1. Erstellen Sie eine temporäre Compute Engine-VM in derselben Producer-VPC und demselben Subnetz wie Ihr interner Load-Balancer.
  2. Testen Sie von dieser VM aus mit Tools wie telnet oder nc die Verbindung zur IP-Adresse der Weiterleitungsregel des Load-Balancers auf dem Port Ihres Dienstes, z. B. telnet LOAD_BALANCER_IP TARGET_PORT.

Wenn Sie eine Verbindung von der VM aus herstellen können, liegt das Problem wahrscheinlich im Pfad von Looker (Google Cloud Core) zu Ihrer VPC. Prüfen Sie noch einmal die Konfiguration des Dienstanhangs und der Looker (Google Cloud Core)-Instanz.

Wenn Sie keine Verbindung von der VM aus herstellen können, liegt das Problem wahrscheinlich in Ihrer Producer-VPC. Prüfen Sie die Weiterleitungsregel des Load-Balancers, den Status des Backend-Dienstes und die Firewallregeln in Ihrer VPC.

Spezifische Probleme mit der Dienstverbindung untersuchen

Bestimmte Zieldienste haben eindeutige Anforderungen oder Abhängigkeiten, wenn sie über Private Service Connect verbunden werden.

Snowflake: Sekundäre Speicherendpunkte

Der Snowflake JDBC-Treiber lädt Resultsets oder Metadaten häufig von einem Zwischenspeicherort in der Cloud (z. B. Amazon S3 oder Azure Blob Storage) und nicht vom primären Datenbankhost herunter. Wenn Looker (Google Cloud Core) diese sekundären Endpunkte nicht erreichen kann, können Verbindungen oder Abfragen fehlschlagen, insbesondere bei großen Resultsets.

So beheben Sie das Problem:

  1. Prüfen Sie die Looker (Google Cloud Core)-Logs auf Zeitüberschreitungsfehler, die auf externe Speicherdomains verweisen, z. B. s3.amazonaws.com oder blob.core.windows.net.
  2. Ermitteln Sie den genauen FQDN des Speicherendpunkts, der für Ihre Snowflake-Instanz erforderlich ist. Diese Informationen finden Sie in Ihren Snowflake-Logs oder beim Snowflake-Support.
  3. Jeder externe FQDN muss als separate ausgehende Verbindung konfiguriert werden. Erstellen Sie eine neue Private Service Connect-Konfiguration (Internet-NEG, Load-Balancer und Dienstanhang) für den FQDN des Speicherendpunkts.
  4. Fügen Sie die neue Dienstanhangkonfiguration der Konfiguration Ihrer Looker (Google Cloud Core)-Instanz hinzu.

Öffentliche Git-Anbieter: Ausgehender Traffic zum Internet

Looker (Google Cloud Core)-Instanzen mit einer privaten IP-Konfiguration haben keine Standardroute zum öffentlichen Internet. Wenn Sie eine Verbindung zu öffentlichen Git-Anbietern wie GitHub oder GitLab herstellen möchten, müssen Sie explizit einen ausgehenden Pfad konfigurieren.

So beheben Sie das Problem:

  1. Prüfen Sie, ob Sie versuchen, von einer Instanz mit privater IP-Adresse eine Verbindung zu einem öffentlichen Git-Anbieter herzustellen. Verbindungsfehler äußern sich häufig als allgemeine Zeitüberschreitungen oder SSL-Handshake-Fehler.
  2. Erstellen Sie eine ausgehende Private Service Connect-Verbindung mit einer Internet-NEG.
  3. Achten Sie darauf, dass die Internet-NEG für den richtigen Port konfiguriert ist (z. B. Port 22 für SSH oder Port 443 für HTTPS).
  4. Wenn Sie in Ihrer VPC eine DNS-Überschreibungsrichtlinie haben, die eine Routing-Schleife mit einer FQDN-basierten Internet-NEG erstellt, verwenden Sie stattdessen eine IP-basierte Internet-NEG (INTERNET_IP_PORT).

Action Hub und Marketplace

Der standardmäßige von Google gehostete Looker (Google Cloud Core) Marketplace und Action Hub sind öffentliche Internetdienste und sind standardmäßig nicht über Instanzen mit privater IP-Adresse zugänglich.

  • Action Hub: Wenn Sie Action Hub mit einer Instanz mit privater IP-Adresse verwenden möchten, müssen Sie einen selbst gehosteten privaten Action Hub-Server bereitstellen und über eine ausgehende Private Service Connect-Verbindung eine Verbindung zu ihm herstellen.
  • Marketplace: Wenn Sie eine Verbindung zum Looker Marketplace herstellen möchten, können Sie die Verbindung zum Marketplace in der Konfiguration der ausgehenden Verbindungen Ihrer Instanz aktivieren. Wenn diese Option aktiviert ist, verwendet Looker (Google Cloud Core) einen Secure Web Proxy, um eine direkte Verbindung zum Marketplace und github.com herzustellen. Weitere Informationen finden Sie unter Verbindung zum Looker Marketplace herstellen. Wenn Sie diese Verbindung nicht aktivieren, müssen Sie die Erweiterungen oder Blöcke manuell aus ihren Git-Repositories herunterladen und als lokale Projekte installieren.

Logs prüfen

VPC-Flusslogs und Load-Balancer-Logs (z. B. interne Application Load Balancer-Logs oder interne Passthrough-Network Load Balancer-Logs) können weitere Informationen zu Verbindungsproblemen liefern.

Aktivieren Sie VPC-Flusslogs für die vom Load-Balancer verwendeten Subnetze und aktivieren Sie das Logging für den Backend-Dienst Ihres internen Load-Balancers. Versuchen Sie dann, eine Verbindung von Looker (Google Cloud Core) herzustellen, um den Fehler zu reproduzieren.

Fragen Sie in Cloud Logging die VPC-Flusslogs ab und filtern Sie nach Traffic vom IP-Bereich des Private Service Connect-NAT-Subnetzes zur IP-Adresse des Load-Balancers. Wenn Traffic den Load-Balancer erreicht, fragen Sie die Load-Balancer-Logs nach Informationen zum Verbindungsstatus zum Backend ab.