Fehlerbehebung bei der Einrichtung des lokalen Connectors

Auf dieser Seite finden Sie eine detaillierte Anleitung zur Fehlerbehebung bei der Konfiguration des lokalen IAP-Connectors. Weitere Informationen zur Fehlerbehebung finden Sie unter Cloud Service Mesh-Debugging.

Fehler 500 beheben

Im Folgenden finden Sie verschiedene Probleme und mögliche Lösungen, um einen 500-Fehler zu beheben, 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 demGoogle Cloud -Netzwerk verbunden. Prüfen Sie die Verbindung, indem Sie die lokale Anwendung von einer der Compute Engine-Instanzen des lokalen Connectors pingen. Wenn der Endpunkt des lokalen Connectors nicht erreichbar ist, prüfen 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 Systemdiagnosen des Load-Balancing-Backend-Dienstes opc-on-prem-app-deployment-gclb-urlmap 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 mehrere Prozesse ausgeführt werden, die nicht grep envoy sind.

    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 in den vorherigen Schritten festgestellt haben, dass Envoy nicht ausgeführt wird, könnte dies an VPC Service Controls liegen. Das Startskript in den VMs lädt das Envoy-Image aus dem Bucket gce-mesh herunter. Wenn die VPC Service Controls-Regeln die Verbindung nicht zulassen, funktioniert die lokale Connector-Bereitstellung nicht.

Damit Envoy korrekt installiert wird, müssen Sie in VPC Service Controls im Hostprojekt Zugriff auf den Storage-Bucket gce-mesh gewähren. Außerdem muss die VPC eine Routingregel haben, die Traffic zum öffentlichen Internet zulässt. Dadurch kann Envoy bereitgestellt werden. Weitere Informationen finden Sie unter Regeln für ein- 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.

Wenn Sie prüfen möchten, ob Envoy eine Verbindung zu Ihrer lokalen Anwendung herstellen kann, versuchen Sie, von dem Computer, auf dem Envoy ausgeführt wird, einen Aufruf an Envoy zu senden. Stellen Sie über SSH eine Verbindung zur VM opc-on-prem-app-deployment-ig-${app} her und führen Sie den folgenden Befehl aus. Die Envoy-Portnummer finden Sie 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 mit dem folgenden Befehl, ob Cloud Service Mesh aktiviert ist und Envoy konfigurieren kann: 
    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 Envoy- und Cloud Service Mesh-Kontoberechtigungen sind nicht festgelegt

Wenn der Fehler GRPC 403 im envoy.err.log angezeigt 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:

Fehlerbehebung bei ERR_SSL_VERSION_OR_CIPHER_MISMATCH-Fehlern

Wenn der Browser den Fehler ERR_SSL_VERSION_OR_CIPHER_MISMATCH anzeigt, ohne zur Anmeldeseite weiterzuleiten, prüfen Sie den Status der Zertifikate auf der Detailseite desGoogle Cloud -Load-Balancers.

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

Fehlerbehebung bei Envoy-Installationsproblemen

Wenn der lokale Connector erfolgreich bereitgestellt und das Zertifikat bereitgestellt wurde, die Verbindung aber immer noch fehlschlägt, kann dies darauf hindeuten, dass Envoy möglicherweise nicht korrekt auf den VMs installiert ist.

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

  •  ps aux | grep envoy
    Es sollten mehrere Prozesse ausgeführt werden, die nicht grep envoy sind.
  •  netstat -tlpn
    Der Envoy-Administratorport 127.0.0.1:15000 sollte überwacht werden.

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

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

Fehlerbehebung bei Bereitstellungsfehlern für IamMemberBinding-Ressourcen

Wenn der lokale Connector bereitgestellt oder aktualisiert wird und ein PERMISSION_DENIED-Fehler im Zusammenhang mit IamMemberBinding-Ressourcen auftritt, liegt das möglicherweise daran, dass dem Google APIs Service Agent-Dienstkonto nicht die erforderliche OWNER-Rolle zugewiesen wurde, 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.