Netzwerkprobleme mit Looker (Google Cloud Core) beheben

Sie können häufige Probleme mit eingehenden und ausgehenden Verbindungen für Ihre Looker (Google Cloud Core)-Instanz in öffentlichen, privaten und hybriden Netzwerkkonfigurationen diagnostizieren und beheben. Wenn Sie Probleme mit benutzerdefinierten Domains, Private Service Connect, dem Zugriff auf private Dienste und dem kontrollierten Ausstieg beheben, können Sie den Nutzerzugriff auf Ihre Instanz wiederherstellen und Verbindungen zu Identitätsanbietern, externen Diensten und Datenbank-Back-Ends aufrechterhalten.

Benutzerdefinierte Domainbestätigung schlägt mit Fehlercode 9 fehl

Wenn Sie eine benutzerdefinierte Domain für eine Looker (Google Cloud Core)-Instanz konfigurieren, für die öffentliche Verbindungen verwendet werden, kann die Domainbestätigung mit dem Fehler code: 9 fehlschlagen.

Symptome

Wenn Sie in Ihrer Looker (Google Cloud Core)-Instanz auf dem Tab CUSTOM DOMAIN (Benutzerdefinierte Domain) auf VERIFY DOMAIN (Domain bestätigen) klicken, schlägt die Bestätigung fehl und es wird eine Fehlermeldung wie die folgende angezeigt:

DNS record is not created or not the same as public IP address (code: 9)

Der Status der benutzerdefinierten Domain bleibt Nicht bestätigt oder wird als Nicht verfügbar angezeigt.

Ursache

Obwohl die Fehlermeldung darauf hinweist, dass der DNS-A-Eintrag fehlt oder falsch ist, tritt dieser Fehler in der Regel aus einem der folgenden Gründe auf:

  • Restriktive CAA-Einträge: Die DNS-Konfiguration Ihrer Domain enthält CAA-Einträge (Certification Authority Authorization), die die Zertifizierungsstellen von Google nicht autorisieren, SSL/TLS-Zertifikate auszustellen. Da Looker (Google Cloud Core) von Google verwaltete Zertifikate für öffentliche Instanzen verwendet, schlägt die Zertifikatbereitstellung fehl.
  • Drittanbieter-CDN oder ‑Proxy: Für Looker (Google Cloud Core)-Instanzen mit öffentlichen Verbindungen wird ausschließlich die Load Balancer-Autorisierung (LB) für von Google verwaltete Zertifikate verwendet. Für die LB-Autorisierung muss der DNS-A-Eintrag Ihrer benutzerdefinierten Domain direkt in die öffentliche IP-Adresse des Looker (Google Cloud Core)-Ingress aufgelöst werden. Wenn Sie Traffic über ein Drittanbieter-CDN (Content Delivery Network), eine WAF (Web Application Firewall) oder einen Reverseproxy (z. B. Akamai oder Cloudflare) weiterleiten, schlägt die automatische LB-Autorisierung fehl.

Lösung

Verwenden Sie je nach Ursache des Fehlers die folgenden Methoden, um das Problem zu beheben:

Google-Zertifizierungsstellen in CAA-Einträgen autorisieren

Wenn für Ihre Domain CAA-Einträge verwendet werden, müssen Sie Ihre DNS-Einträge überprüfen und aktualisieren, um die Zertifikatanbieter von Google zuzulassen:

  1. Prüfen Sie die vorhandenen CAA-Einträge Ihrer Domain mit einem DNS-Lookup-Tool wie dig:

    dig CAA DOMAIN_NAME +short

    Ersetzen Sie DOMAIN_NAME durch Ihren benutzerdefinierten Domainnamen, z. B. example.com oder looker.example.com.

  2. Fügen Sie CAA-Einträge hinzu, um sowohl pki.goog als auch letsencrypt.org zu autorisieren:

    DOMAIN_NAME. IN CAA 0 issue "pki.goog"
DOMAIN_NAME. IN CAA 0 issue "letsencrypt.org"

    Wenn Sie beide Zertifizierungsstellen zulassen, wird eine zuverlässige automatische Bereitstellung und Verlängerung gewährleistet.

  3. Warten Sie nach der Aktualisierung Ihrer CAA-Einträge, bis die DNS-Weitergabe abgeschlossen ist, und klicken Sie dann in der Google Cloud -Konsole noch einmal auf DOMAIN BESTÄTIGEN.

Private Service Connect für Drittanbieter-CDNs und ‑Proxys verwenden

CDNs und Reverse-Proxys von Drittanbietern können nicht direkt vor einer öffentlichen Looker (Google Cloud Core)-Instanz platziert werden, da für die automatische Load Balancer-Autorisierung eine direkte DNS-Auflösung in die öffentliche IP-Adresse der Instanz erforderlich ist.

Wenn Sie eingehenden Traffic über ein Drittanbieter-CDN oder eine Drittanbieter-WAF weiterleiten möchten, stellen Sie Looker (Google Cloud Core) mit einer Private Service Connect-Architektur anstelle von öffentlichen Verbindungen bereit:

  1. Looker (Google Cloud Core)-Instanz mit aktiviertem Private Service Connect bereitstellen.
  2. Konfigurieren Sie einen externen Application Load Balancer mit einem Private Service Connect-Backend in Ihrem VPC-Netzwerk.
  3. Stellen Sie Ihr eigenes selbstverwaltetes oder von Google verwaltetes SSL-Zertifikat bereit und hängen Sie es an den externen Application Load Balancer an. Diese Architektur gibt Ihnen die Kontrolle über die TLS-Terminierung und ermöglicht es Ihnen, Traffic über Ihr CDN oder Ihre WAF weiterzuleiten.

Fehler bei der OpenID Connect-Authentifizierung mit kontrolliertem Ausstieg

Wenn Sie die OpenID Connect-Authentifizierung für eine Looker (Google Cloud Core)-Instanz einrichten, die mit Private Service Connect konfiguriert ist und für die kontrollierter ausgehender Traffic aktiviert ist, kann die Authentifizierung fehlschlagen.

Symptome

Wenn die Authentifizierung fehlgeschlagen ist, können folgende Symptome auftreten:

  • Der Looker-Endpunkt /openidconnect hängt im Browser etwa 60 Sekunden lang, bevor ein Fehler angezeigt wird oder ein Zeitüberschreitungsfehler mit 504 Upstream Request Timeout oder 504 Gateway Timeout auftritt.

  • Ihr Identitätsanbieter zeigt eine Fehlermeldung an, die darauf hinweist, dass der Redirect-URI nicht übereinstimmt, z. B.:

    AADSTS50011: The redirect URI specified in the request does not match the
redirect URIs configured for the application

    Diese Fehlermeldung ist irreführend, da der Weiterleitungs-URI, den Sie in Ihrem Identitätsanbieter konfiguriert haben, möglicherweise korrekt ist. Der eigentliche Fehler tritt auf, wenn Looker (Google Cloud Core) während des Backend-Austauschs den Token-Endpunkt des Identitätsanbieters nicht erreichen kann.

Ursache

Der automatisierte Bereitstellungs-Workflow für kontrollierten ausgehenden Traffic kann gelegentlich die erforderliche Secure Web Proxy-Netzwerkroute (looker-swp-route) im Mandantenprojekt für Looker (Google Cloud Core) nicht erstellen.

Wenn diese Route fehlt, kommt es bei Backend-Anfragen von Looker (Google Cloud Core) an den Token-Endpunkt des Identitätsanbieters zu einer Zeitüberschreitung, da die Instanz ausgehenden Traffic nicht über den sicheren Web-Proxy an das öffentliche Internet weiterleiten kann.

Lösung

Führen Sie die folgenden Schritte aus, um die Konfiguration für den kontrollierten ausgehenden Traffic zurückzusetzen und das System zu zwingen, die fehlende Netzwerkroute neu zu erstellen:

  1. Rufen Sie in der Google Cloud Console die Seite Looker auf:

    Zu Looker

  2. Klicken Sie auf den Namen der Instanz, die Sie aktualisieren möchten.

  3. Klicken Sie auf Bearbeiten.

  4. Maximieren Sie den Abschnitt Verbindungen und rufen Sie den Abschnitt Ausgehende Verbindungen konfigurieren auf.

  5. Notieren Sie alle vorhandenen voll qualifizierten Domainnamen (FQDNs), die im Abschnitt Global FQDN aufgeführt sind, z. B. die Endpunkte Ihres Identitätsanbieters.

  6. Löschen Sie alle FQDNs, die im Abschnitt Global FQDN aufgeführt sind.

  7. Entfernen Sie das Häkchen aus dem Kästchen Looker erlauben, eine Verbindung zu externen Diensten herzustellen, um den kontrollierten ausgehenden Traffic zu deaktivieren.

  8. Klicken Sie auf Speichern.

  9. Warten Sie, bis die Instanz aktualisiert wurde und die Konfigurationsänderungen abgeschlossen sind.

  10. Klicken Sie noch einmal auf Bearbeiten.

  11. Maximieren Sie den Bereich Verbindungen und setzen Sie ein Häkchen bei Looker erlauben, eine Verbindung zu externen Diensten herzustellen.

  12. Fügen Sie im Bereich Globaler FQDN die erforderlichen FQDNs für Ihren Identitätsanbieter und alle anderen externen Dienste wieder hinzu.

  13. Klicken Sie auf Speichern.

Durch das Zurücksetzen des kontrollierten Egress wird der automatische Bereitstellungsprozess ausgelöst, um die fehlende looker-swp-route-Netzwerkroute neu zu erstellen. Nachdem die Route erstellt wurde, können ausgehende Backend-Anfragen an den Identitätsanbieter abgeschlossen werden.

504-Fehler „Upstream Request Timeout“

Wenn Sie API-Aufrufe ausführen, lang andauernde Abfragen ausführen oder sich bei einem externen Dienst in einer Looker (Google Cloud Core)-Instanz authentifizieren, kann die Anfrage mit einem HTTP-504-Zeitüberschreitungsfehler fehlschlagen.

Symptome

In den folgenden Szenarien kann der Fehler 504 Upstream Request Timeout oder 504 Gateway Timeout auftreten:

  • Eingehende API-Aufrufe oder ‑Abfragen: API-Aufrufe an Looker-Endpunkte wie /result_format oder zeitaufwendige Abfragen in der Looker-Benutzeroberfläche schlagen nach etwa 30 Sekunden mit dem Fehler 504 auf einer Instanz fehl, die von einem Load Balancer geschützt wird.
  • Ausgehende Authentifizierung oder Verbindungen zu externen Diensten: Sie erhalten in Ihrem Browser einen 504-Fehler, nachdem Sie von der Anmeldeseite eines Identitätsanbieters zurückgekehrt sind oder wenn Sie eine Verbindung zu einem externen Dienst auf einer Instanz mit aktiviertem kontrollierten ausgehenden Traffic herstellen.

Ursache

Ein 504-Zeitüberschreitungsfehler tritt in der Regel aus einem der folgenden Gründe auf:

  • Zeitüberschreitung des Load-Balancer-Backend-Dienstes für eingehende Anfragen: Wenn auf Ihre Looker (Google Cloud Core)-Instanz über einen Cloud Load Balancing-Load Balancer zugegriffen wird, hat der Backend-Dienst des Load Balancers standardmäßig eine Zeitüberschreitung des Backend-Dienstes von 30 Sekunden. Wenn die kombinierte Ausführungszeit der Datenbankabfrage und die Rendering-Zeit der Looker-Nutzlast dieses Zeitlimit überschreiten, schließt der Load-Balancer die Verbindung und gibt einen HTTP-Fehler 504 zurück.
  • Ausgehende Domain mit kontrolliertem Ausgang blockiert: Die Looker (Google Cloud Core)-Instanz kann eine externe Domain nicht über den kontrollierten Ausgang erreichen. Im Gegensatz zu Fehlern bei fehlenden Routen bedeutet ein 504-Fehler bei ausgehenden Anfragen in der Regel, dass der Netzwerkpfad vorhanden ist, aber eine erforderliche Domain in der Zulassungsliste Global FQDN fehlt und blockiert wird oder die Anfrage am Gateway eine Zeitüberschreitung verursacht.

Lösung

Führen Sie je nach Ursache des Fehlers die Schritte in den folgenden Abschnitten aus, um das Problem zu beheben.

Zeitüberschreitungen des Load Balancers bei API-Aufrufen oder ‑Anfragen beheben

Verwenden Sie eine oder beide der folgenden Methoden, um 504-Fehler zu beheben, die durch das Zeitlimit des Backend-Dienstes des Load-Balancers verursacht werden:

  • Zeitlimit des Backend-Dienstes des Load Balancers erhöhen:

    1. Rufen Sie in der Google Cloud Console die Seite Load Balancing auf:

      Zu „Load Balancing“ gehen

    2. Klicken Sie auf Back-Ends und dann auf den Namen des Back-End-Dienstes, der mit Ihrer Looker-Instanz (Google Cloud Core) verknüpft ist.

    3. Klicken Sie auf Bearbeiten.

    4. Erhöhen Sie im Feld Zeitüberschreitung den Wert für das Zeitlimit, z. B. von 30 Sekunden auf 300 Sekunden, um auch die längsten Abfragen und API-Anfragen zu berücksichtigen.

    5. Klicken Sie auf Speichern.

  • Asynchronen API-Workflow verwenden: Wenn Sie die Looker API aufrufen, um Abfragedaten abzurufen, und das Load-Balancer-Zeitlimit nicht ändern können, verwenden Sie asynchrone Endpunkte anstelle von synchronen Anfragen. Rufen Sie create_query_task auf, um die Abfrage asynchron zu starten, und fragen Sie dann query_task_results ab, um die Ergebnisse nach Abschluss der Abfrage abzurufen.

Zeitüberschreitungen bei kontrolliertem ausgehenden Traffic beheben

So beheben Sie 504-Fehler, die auftreten, wenn Looker (Google Cloud Core) keine Verbindung zu einem externen Dienst oder Identitätsanbieter mit aktivierter kontrollierter Ausleitung herstellen kann:

  1. Erforderliche FQDNs bestätigen: Prüfen Sie in der Google Cloud -Konsole, ob alle Domains, die für Ihren externen Dienst oder Identitätsanbieter erforderlich sind, der Liste Globaler FQDN hinzugefügt wurden. OIDC-Authentifizierungsabläufe erfordern oft mehrere Endpunkte (z. B. Autorisierungs-, Token- und Nutzerinformationen-Endpunkte), die möglicherweise unterschiedliche Domains verwenden.
  2. Netzwerk-Trace aufzeichnen: Wenn der Fehler weiterhin auftritt, zeichnen Sie einen Browser-Netzwerk-Trace (HAR-Datei) auf, während Sie das Problem reproduzieren. Suchen Sie im Trace nach 504-Statuscodes oder fehlgeschlagenen HTTP-Anfragen, um Domains zu ermitteln, die während des Ablaufs kontaktiert wurden, aber nicht in Ihrer Liste Global FQDN enthalten sind.
  3. Konfiguration zurücksetzen: Wenn die erforderlichen FQDNs vorhanden sind, Anfragen aber weiterhin Zeitüberschreitungen verursachen, folgen Sie der Anleitung unter Lösung für OpenID Connect-Authentifizierungsfehler, um die Konfiguration für kontrollierten ausgehenden Traffic zurückzusetzen.

HttpClient:ConnectTimeoutError-Ausführung abgelaufen

Wenn Sie im Looker-Adminbereich eine OpenID Connect-Verbindung oder andere externe Netzwerkverbindungen testen, kann der Verbindungstest mit einem Zeitüberschreitungsfehler fehlschlagen.

Symptome

Wenn Sie im Looker-Admin-Bereich einen Verbindungstest ausführen (z. B. auf der Seite OpenID Connect Authentication), gibt Looker den folgenden Fehler zurück:

HttpClient:ConnectTimeoutError execution expired

Ursache

Dieser Fehler weist darauf hin, dass der Looker (Google Cloud Core)-Instanz der erforderliche Netzwerkpfad fehlt, um mit dem externen Dienst oder Identitätsanbieter zu kommunizieren. Dieses Problem tritt in der Regel auf, wenn eine der folgenden Bedingungen erfüllt ist:

  • Fehlende Routenweitergabe: Cloud Router verwendet die Standardeinstellungen und gibt keine VPC-Netzwerkrouten (z. B. benutzerdefinierte beworbene Routen) an die Looker (Google Cloud Core)-Instanz weiter.
  • Fehlende Internet-NEG: In Ihrem VPC-Netzwerk ist keine Internetnetzwerk-Endpunktgruppe (NEG) konfiguriert, um Traffic an den externen Dienst weiterzuleiten.

Lösung

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Cloud Router-Routenweitergabe konfigurieren: Prüfen Sie, ob der Cloud Router so konfiguriert ist, dass die erforderlichen VPC-Netzwerkrouten an Ihre Looker (Google Cloud Core)-Instanz weitergegeben werden. Dazu müssen Sie benutzerdefinierte beworbene Routen einrichten.
  2. Internet-NEG konfigurieren: Richten Sie ein Internet-NEG in Ihrem VPC-Netzwerk ein, damit die Looker (Google Cloud Core)-Instanz ausgehenden Traffic an den externen Identitätsanbieter oder ‑dienst weiterleiten kann.
  3. Zugriff auf private Dienste prüfen: Bei Instanzen, die den Zugriff auf private Dienste verwenden, muss Ihr VPC-Netzwerk ordnungsgemäß mit Google-Diensten gepeert sein. Weitere Informationen finden Sie unter Über den Zugriff auf private Dienste auf externe Dienste zugreifen.

Probleme mit Southbound Private Service Connect-Verbindungen

Bei Looker (Google Cloud Core)-Instanzen, die Private Service Connect für ausgehende Verbindungen zu Datenbank-Back-Ends oder veröffentlichten Diensten verwenden, können Verbindungsfehler auftreten, auch wenn der Endpunktstatus Accepted ist.

Häufige Probleme:

  • Fehler bei der Hostnamensauflösung: Wenn in Looker (Google Cloud Core) beim Testen einer Verbindung ein Unknown host-Fehler angezeigt wird, prüfen Sie, ob der konfigurierte Hostname mit dem DNS-Eintrag in Ihrem privaten Netzwerk übereinstimmt und ob der Backend-Load Balancer fehlerfrei funktioniert.
  • Zeitüberschreitungen bei Verbindungen: Wenn bei Verbindungen eine Zeitüberschreitung auftritt, prüfen Sie Ihre VPC-Firewallregeln, um zu bestätigen, dass eingehender Traffic vom Private Service Connect-NAT-Subnetz zu den Backends Ihres Load Balancers zugelassen ist.
  • Status „Ausstehend“ oder „Geschlossen“: Wenn der Status des Dienstanhangs Pending oder Closed ist, prüfen Sie, ob sich das Nutzerprojekt auf der Zulassungsliste des Dienstanhangs befindet und ob obligatorische TCP-Systemdiagnosen konfiguriert sind.
  • Fehler bei der Aktualisierung mit internem Fehler 13: Wenn Sie ausgehende Dienstanhänge mit Terraform oder der API aktualisieren, kann die Aktualisierung mit einem Internal error 13 fehlschlagen, wenn sich Ihre eingehende Konfiguration in einem Fehlerstatus befindet. Weitere Informationen finden Sie unter Interner Fehler 13 beim Aktualisieren von ausgehenden Dienstanhängen.

Detaillierte Diagnose-Workflows und ein Entscheidungsbaum finden Sie unter Fehlerbehebung bei Downstream-Verbindungen über Private Service Connect.

Interner Fehler 13 beim Aktualisieren von ausgehenden Dienstanhängen

Wenn Sie mit Terraform oder der Looker (Google Cloud Core)-API ausgehende (Egress-)Dienstanhänge für Private Service Connect auf einer vorhandenen Looker (Google Cloud Core)-Instanz hinzufügen, aktualisieren oder entfernen, kann die Aktualisierung mit einem internen Fehler fehlschlagen.

Symptome

Möglicherweise treten folgende Symptome auf:

  • Die Aktualisierung von Terraform oder der API schlägt mit einem Fehler ähnlich dem folgenden fehl:

    Error: Error waiting for Updating Instance: Error code 13, message: an internal error has occurred

  • Die Looker (Google Cloud Core)-Instanz kann keine Verbindung zu den Zieldiensten herstellen, auch wenn der Dienstanhang im VPC-Netzwerk des Diensterstellers den Verbindungsstatus Accepted anzeigt.

Ursache

Dieser Fehler tritt auf, wenn die eingehende Private Service Connect-Konfiguration (allowed_vpcs) der Instanz im Backend in einen Fehlerstatus wechselt.

Wenn Sie Terraform oder einen API-Client verwenden, um ausgehende Dienstanhänge (psc_service_attachments) zu aktualisieren, enthält die Anfrage-Payload in der Regel den gesamten psc_config-Block, der den Parameter allowed_vpcs enthält. Die Looker (Google Cloud Core) API versucht, die eingehende Konfiguration während des Updates zu validieren. Da sich allowed_vpcs in einem Fehlerstatus befindet, schlägt die Validierung fehl. Dadurch schlägt die gesamte Instanzaktualisierung mit dem Fehlercode 13 fehl und ausgehende Änderungen am Dienstanhang können nicht angewendet werden.

Lösung

Führen Sie den folgenden Workaround aus, um den Validierungsfehler für die eingehende Konfiguration zu umgehen und die Aktualisierungen des ausgehenden Service-Attachment anzuwenden:

  1. Kommentieren Sie in Ihrer Terraform-Konfiguration oder Ihrem API-Payload den Parameter allowed_vpcs im Block psc_config vorübergehend aus oder entfernen Sie ihn.

  2. Wenden Sie die Terraform-Konfiguration an oder senden Sie die API-Anfrage noch einmal, um Ihre ausgehenden Dienstanhänge (psc_service_attachments) zu aktualisieren.

    Da die Anfrage-Nutzlast allowed_vpcs nicht enthält, wird die Validierung für die eingehende Konfiguration übersprungen und die Änderungen am ausgehenden Dienstanhang werden angewendet.

  3. Nachdem die ausgehenden Dienstanhänge bereitgestellt und Verbindungen hergestellt wurden, stellen Sie den Parameter allowed_vpcs in Ihrer Terraform-Konfiguration oder Ihrem API-Payload wieder her.

  4. Wenden Sie die Terraform-Konfiguration noch einmal an.

Probleme mit Routen und Verbindungen für den Zugriff auf private Dienste

Bei Looker (Google Cloud Core)-Instanzen, die den Zugriff auf private Dienste verwenden, erfordert die ausgehende Kommunikation mit externen Diensten eine ordnungsgemäße Routenweitergabe und Netzwerkinfrastruktur:

  • Routenweitergabe: Prüfen Sie, ob Cloud Router so konfiguriert ist, dass VPC-Netzwerkrouten an die Looker (Google Cloud Core)-Instanz weitergegeben werden, z. B. benutzerdefinierte beworbene Routen.
  • Internet-Netzwerk-Endpunktgruppen: Wenn Ihre Instanz über den Zugriff auf private Dienste externe Endpunkte erreichen muss, muss in Ihrem VPC-Netzwerk eine Internet-Netzwerk-Endpunktgruppe (NEG) konfiguriert sein.

Wenn diese Routen oder Endpunktgruppen fehlen, schlagen Verbindungstests zu externen Endpunkten mit dem Fehler HttpClient:ConnectTimeoutError execution expired fehl.

Weitere Informationen finden Sie unter Über den Zugriff auf private Dienste auf externe Dienste zugreifen.

Diagnosetools und ‑logs

Verwenden Sie die folgenden Tools und Logs, um Netzwerkprobleme zu diagnostizieren:

  • Cloud Logging: In Cloud Logging können Sie Logs auf Instanzebene ansehen, um Verbindungsfehler und Systemereignisse zu erkennen. Weitere Informationen finden Sie unter Instanzlogs ansehen.
  • Looker-Systemaktivität: Wenn Sie sich als Administrator anmelden können, sehen Sie sich das Dashboard Nutzeraktivität in der Systemaktivität an. In diesem Dashboard werden die letzten fehlgeschlagenen Anmeldeversuche, die verwendete Authentifizierungsmethode und Fehlermeldungen angezeigt. Weitere Informationen finden Sie im Dashboard „Nutzeraktivität“.
  • VPC-Flusslogs: Prüfen Sie die VPC-Flusslogs, um festzustellen, ob Netzwerkverkehr von Looker (Google Cloud Core) Ihr Zielsubnetz erreicht oder durch Firewallregeln blockiert wird.
  • Cloud Customer Care: Wenn Sie die Schritte zur Fehlerbehebung ausgeführt haben und das Problem weiterhin besteht, wenden Sie sich an Cloud Customer Care.