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 Traffic Director-Debugging.
Fehler 500 beheben
Im Folgenden finden Sie verschiedene Probleme und mögliche Lösungen, mit denen Sie bei dem Versuch, auf Ihre Anwendung zuzugreifen, einen 500-Fehler beheben können.
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:
- 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}. - Prüfen Sie in der Cloud Console, ob die Systemdiagnosen des Load-Balancing-Back-End-Dienstes
opc-on-prem-app-deployment-gclb-urlmapgrün sind. - 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
Prüfen Sie mit dem folgenden Befehl, ob Envoy ausgeführt wird:
ps aux | grep envoy
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 60Prüfen Sie, ob das Envoy-Logverzeichnis unter
/var/log/envoy/erstellt wurde.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 gce-mesh-Bucket 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 gce-mesh-Storage-Bucket 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 eine SSH-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.
shell curl -x -v localhost:${envoy_port}Wenn der Endpunkt nicht erreichbar ist, prüfen Sie Folgendes:
/var/log/envoy/envoy.err.logfür alle Fehlerlogs. Wenn keine Fehlerlogs vorhanden sind, prüfen Sie, ob Traffic Director 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_LISTENERfestgelegt ist. WennTRAFFICDIRECTOR_INTERCEPTION_LISTENERnicht festgelegt ist, konnte Traffic Director Envoy nicht konfigurieren. - Suchen Sie in jedem Listener nach Fehlermeldungen.
Die Berechtigungen für das Envoy- und Traffic Director-Konto 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:
- Prüfen Sie die Berechtigungen: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#grant.
- Prüfen Sie das Konto: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#enable-service.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH Fehler 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 Detailseite des Google Cloud-Load-Balancers.
Die Bereitstellung eines von Google verwalteten Zertifikats kann bis zu 60 Minuten dauern.
Fehlerbehebung bei der Envoy-Installation
Wenn der lokale Connector erfolgreich bereitgestellt und das Zertifikat bereitgestellt wurde, die Verbindung aber immer noch fehlschlägt, kann dies darauf hindeuten, dass Envoy auf den VMs möglicherweise nicht korrekt installiert ist.
Stellen Sie eine SSH-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
grep envoy.netstat -tlpn
Wenn eine der vorherigen Aktionen fehlschlägt, ergreifen Sie die folgenden Maßnahmen, um das Problem zu beheben:
- Achten Sie darauf, dass der private Google-Zugriff in dem Subnetz aktiviert ist, das vom Connector bereitgestellt wird.
- Prüfen Sie, ob VM Manager (OS Config API) aktiviert ist.
Fehlerbehebung bei Bereitstellungsfehlern bei IamMemberBinding-Ressourcen
Wenn der lokale Connector gerade bereitgestellt oder aktualisiert wird und den Fehler PERMISSION_DENIED für die Ressourcen IamMemberBinding zurückgibt, kann dies daran liegen, dass dem Dienstkonto Google APIs Service Agent beim Aktivieren von IAP für lokale Anwendungen nicht die Rolle OWNER zugewiesen wurde.
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 gewährt wurde, und versuchen Sie es noch einmal.