Fehlerbehebung bei der Einrichtung des lokalen Connectors

Auf dieser Seite finden Sie eine Schritt-für-Schritt-Anleitung zur Fehlerbehebung bei der Konfiguration des lokalen IAP-Connectors. Weitere Informationen zur Fehlerbehebung finden Sie unter Cloud Service Mesh debuggen.

Fehler 500 beheben

Im Folgenden finden Sie verschiedene Probleme und mögliche Lösungen, mit denen Sie einen 500-Fehler beheben können, der beim Zugriff auf Ihre Anwendung auftritt.

Die lokale Anwendung ist nicht mit dem Google Cloud Netzwerk verbunden

Ihre lokale Anwendung ist möglicherweise nicht mit dem Google Cloud Netzwerk verbunden. Überprüfen Sie die Verbindung, indem Sie die lokale Anwendung von einer der lokalen Connector-Instanzen von Compute Engine anpingen. Wenn der lokale Connector-Endpunkt nicht erreichbar ist, debuggen Sie die Netzwerkverbindung und die Einstellungen, bevor Sie fortfahren.

Envoy ist nicht ordnungsgemäß auf den VMs installiert

Führen Sie folgende Schritte aus, um zu prüfen, ob Envoy ordnungsgemäß installiert wurde:

  1. Melden Sie sich vom lokalen Connector aus bei einer der Compute Engine-VMs an. Der Name der lokalen Connector-VM beginnt mit opc-on-prem-app-deployment-ig-${app}.
  2. Prüfen Sie in der Cloud Console, ob die opc-on-prem-app-deployment-gclb-urlmap Load-Balancing-Backend-Dienst-Systemdiagnosen grün anzeigen.
  3. Wird der Backend-Dienst nicht als fehlerfrei angezeigt, stellen Sie eine SSH-Verbindung zu einer der Instanzen her: 
    gcloud compute ssh INSTANCE_NAME --zone=ZONE_NAME

  4. Prüfen Sie mit dem folgenden Befehl, ob Envoy ausgeführt wird: 

     ps aux | grep envoy
    Es sollten mehr als ein Prozess ausgeführt werden, außer grep envoy.

    Beispielausgabe:

    envoy      943  0.0  0.0   5488  3076 ?        Ss   06:25   0:00 /bin/bash /usr/local/bin/run-proxy.sh
envoy      944  0.1  1.5 178928 57352 ?        Sl   06:25   1:23 /usr/local/bin/envoy --config-path /usr/local/etc/
envoy/envoy-proxy-bootstrap.json --allow-unknown-static-fields --disable-hot-restart --log-level info --drain-time-
s 60

  5. Prüfen Sie, ob das Envoy-Logverzeichnis unter /var/log/envoy/ erstellt wurde.

  6. Prüfen Sie, ob der Bucket "gce-mesh" von den VMs aus erreichbar ist. Führen Sie dazu folgenden Befehl aus: 

    gcloud storage cp gs://gce-mesh/service-proxy-agent/releases/service-proxy-agent-0.2.tgz .

Wenn eine der Validierungen in diesem Schritt fehlgeschlagen ist, ist Envoy nicht ordnungsgemäß installiert. Weitere Informationen finden Sie in den Startlogs unter /var/log/daemon.log.

Wenn Sie beobachtet haben, dass Envoy in den vorherigen Schritten nicht ausgeführt wird, könnte dies einen Grund für VPC Service Controls sein. Das Startskript in den VMs lädt das Envoy-Image aus dem Bucket gce-mesh herunter. Wenn die Regeln für VPC Service Controls die Verbindung nicht zulassen, funktioniert die lokale Connector-Bereitstellung nicht.

Damit Envoy korrekt installiert wird, müssen Sie den Zugriff auf den Storage-Bucket gce-mesh in VPC Service Controls im Hostprojekt zulassen. Achten Sie außerdem darauf, dass die VPC eine Routingregel hat, die Traffic zum öffentlichen Internet zulässt. Dadurch kann Envoy bereitgestellt werden. Weitere Informationen finden Sie unter Regeln für eingehenden und ausgehenden Traffic.

Ihre lokale Anwendung ist nicht mit Envoy verbunden

Wenn Sie die lokale Anwendung von der VM aus zwar anpingen, aber nicht den lokalen Connector verwenden können, kann Envoy möglicherweise keine Verbindung zur Anwendung herstellen.

Testen Sie, ob Envoy eine Verbindung zu Ihrer lokalen Anwendung herstellen kann. Rufen Sie dazu Envoy auf der Maschine auf, auf der Envoy ausgeführt wird. Stellen Sie über SSH eine Verbindung zur VM opc-on-prem-app-deployment-ig-${app} her und führen Sie den folgenden Befehl aus. Sie finden die Envoy-Portnummer unter Instanzgruppen > Details > Portnamenzuordnung. 

curl -x -v localhost:${envoy_port}

Wenn der Endpunkt nicht erreichbar ist, prüfen Sie Folgendes:

  • /var/log/envoy/envoy.err.log für alle Fehlerlogs. Wenn keine Fehlerlogs vorhanden sind, prüfen Sie, ob Cloud Service Mesh aktiviert ist und Envoy konfigurieren kann. Führen Sie dazu den folgenden Befehl aus: 
    sudo curl 0.0.0.0:15000/config_dump
  • Prüfen Sie, ob TRAFFICDIRECTOR_INTERCEPTION_LISTENER festgelegt ist. Wenn TRAFFICDIRECTOR_INTERCEPTION_LISTENER nicht festgelegt ist, konnte Cloud Service Mesh Envoy nicht konfigurieren.
  • Suchen Sie in jedem Listener nach Fehlermeldungen.

Die Berechtigungen für das Envoy- und Cloud Service Mesh-Konto sind nicht festgelegt

Wenn der Fehler GRPC 403 in envoy.err.log angezeigt wird oder TRAFFICDIRECTOR_INTERCEPTION_LISTENER in der Envoy-Konfiguration nicht angezeigt wird, sind möglicherweise nicht die richtigen Kontoberechtigungen festgelegt.

Prüfen Sie, ob das VM-Dienstkonto TD-Zugriffsberechtigungen für xDS v3 hat:

Fehler ERR_SSL_VERSION_OR_CIPHER_MISMATCH beheben

Wenn im Browser der Fehler ERR_SSL_VERSION_OR_CIPHER_MISMATCH angezeigt wird, ohne zur Anmeldeseite weiterzuleiten, prüfen Sie den Status der Zertifikate auf der Google Cloud Detailseite des Load-Balancers.

Die Bereitstellung eines von Google verwalteten Zertifikats kann bis zu 60 Minuten dauern.

Fehler bei der Envoy-Installation beheben

Wenn der lokale Connector erfolgreich bereitgestellt und das Zertifikat bereitgestellt wurde, die Verbindung aber weiterhin fehlschlägt, ist Envoy möglicherweise nicht korrekt auf den VMs installiert.

Stellen Sie über SSH eine Verbindung zu einer der VMs her und führen Sie den folgenden Befehl aus, um zu prüfen, ob Envoy installiert ist:

  •  ps aux | grep envoy
    Es sollten mehr als ein Prozess ausgeführt werden, außer grep envoy.
  •  netstat -tlpn
    Der Envoy-Admin-Port 127.0.0.1:15000 sollte aktiv sein.

Wenn eine der vorherigen Aktionen fehlschlägt, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Achten Sie darauf, dass der private Google-Zugriff im Subnetz aktiviert ist, in dem der Connector bereitgestellt wird.
  2. Achten Sie darauf, dass VM Manager (OS Config API) aktiviert ist.

Fehler bei der Bereitstellung für IamMemberBinding-Ressourcen beheben

Wenn beim Bereitstellen oder Aktualisieren des lokalen Connectors ein PERMISSION_DENIED Fehler im Zusammenhang mit IamMemberBinding Ressourcen auftritt, wurde dem Dienstkonto Google APIs Service Agent möglicherweise nicht die OWNER Rolle zugewiesen, die beim Aktivieren von IAP für lokale Anwendungen erforderlich ist.

Beispiele für Bereitstellungsfehler:

bind-iam-policy: {"ResourceType":"gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding","ResourceErrorCode":"403","ResourceErrorMessage":{"code":403,"message":"Policy update access denied.","status":"PERMISSION_DENIED","statusMessage":"Forbidden","requestPath":"https://cloudresourcemanager.googleapis.com/v1/projects/<project-ID>:setIamPolicy","httpMethod":"POST"}}

bind-storage-admin-account-iam-policy: {"ResourceType":"gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding","ResourceErrorCode":"403","ResourceErrorMessage":{"code":403,"message":"Policy update access denied.","status":"PERMISSION_DENIED","statusMessage":"Forbidden","requestPath":"https://cloudresourcemanager.googleapis.com/v1/projects/<project-ID>:setIamPolicy","httpMethod":"POST"}}

Wenn diese Fehler bei der Bereitstellung auftreten, prüfen Sie, ob dem Dienstkonto Google APIs Service Agent die Rolle OWNER zugewiesen ist, und versuchen Sie es noch einmal.