Résoudre les problèmes de configuration de vos connecteurs sur site

Cette page fournit des instructions détaillées pour vous aider à résoudre les problèmes de configuration d'un connecteur IAP sur site. Pour obtenir des informations de dépannage supplémentaires, consultez la section Débogage de Cloud Service Mesh.

Résoudre les problèmes liés à l'erreur 500

Voici différents problèmes et solutions possibles pour vous aider à résoudre une erreur 500 que vous recevez lorsque vous tentez d'accéder à votre application.

L'application sur site n'est pas connectée au Google Cloud réseau

Il est possible que votre application sur site ne soit pas connectée au Google Cloud réseau. Vérifiez la connectivité en pinguant l'application sur site à partir de l'une des instances Compute Engine du connecteur sur site. Si le point de terminaison du connecteur sur site est inaccessible, déboguez la connectivité et les paramètres du réseau avant de continuer.

Envoy n'est pas correctement installé dans les VM

Pour vérifier qu'Envoy est correctement installé, procédez comme suit :

  1. Connectez-vous à l'une des VM Compute Engine à partir du connecteur sur site. Le nom de la VM du connecteur sur site commence par opc-on-prem-app-deployment-ig-${app}.
  2. Dans Cloud Console, contrôlez que les vérifications d'état du service de backend d'équilibrage de charge opc-on-prem-app-deployment-gclb-urlmap s'affichent en vert.
  3. Si le service de backend ne semble pas opérationnel, connectez-vous en SSH à l'une des instances : 
    gcloud compute ssh INSTANCE_NAME --zone=ZONE_NAME

  4. Vérifiez qu'Envoy est opérationnel en exécutant la commande suivante : 

     ps aux | grep envoy
    Plusieurs processus doivent être en cours d'exécution, autres que grep envoy.

    Exemple de résultat :

    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. Vérifiez que le répertoire des journaux Envoy a bien été créé à l'adresse /var/log/envoy/.

  6. Assurez-vous que le bucket gce-mesh est accessible par les VM en exécutant la commande suivante : 

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

L'échec de l'une des validations de cette étape signifie qu'Envoy n'est pas correctement installé. Pour plus d'informations, consultez les journaux de démarrage situés à l'adresse /var/log/daemon.log.

Si vous avez constaté lors des étapes précédentes qu'Envoy n'est pas en cours d'exécution, l'une des raisons peut être VPC Service Controls. Le script de démarrage des VM télécharge l'image Envoy à partir du bucket gce-mesh. Si les règles VPC Service Controls n'autorisent pas la connexion, le déploiement du connecteur sur site ne sera pas possible.

Pour vous assurer qu'Envoy s'installe correctement, autorisez l'accès au bucket de stockage gce-mesh dans VPC Service Controls, dans le projet hôte. Assurez-vous également que le VPC dispose d'une règle de routage pour autoriser le trafic vers l'Internet public. Cela permet de déployer Envoy. Pour plus d'informations, consultez la section Règles d'entrée et de sortie.

Votre application sur site n'est pas connectée à Envoy

Si vous pouvez pinguer l'application sur site à partir de la VM, mais que vous ne pouvez pas utiliser le connecteur sur site, il est possible qu'Envoy ne puisse pas se connecter à l'application.

Pour vérifier qu'Envoy peut se connecter à votre application sur site, essayez d'appeler Envoy depuis la machine sur laquelle il est exécuté. À l'aide de SSH,connectez-vous à la VM opc-on-prem-app-deployment-ig-${app} et exécutez la commande suivante. Vous pouvez trouver le numéro de port Envoy dans Groupes d'instances > Détails > Mappage des noms des ports. 

curl -x -v localhost:${envoy_port}

Si le point de terminaison n'est pas accessible, vérifiez les points suivants :

  • /var/log/envoy/envoy.err.log pour tous les journaux d'erreurs. Si aucun journal d'erreur n'est disponible, exécutez la commande suivante pour vérifier que Cloud Service Mesh est activé et qu'il peut configurer Envoy : 
    sudo curl 0.0.0.0:15000/config_dump
  • Vérifiez que TRAFFICDIRECTOR_INTERCEPTION_LISTENER est défini. Si TRAFFICDIRECTOR_INTERCEPTION_LISTENER n'est pas défini, Cloud Service Mesh ne peut pas configurer Envoy.
  • Vérifiez l'absence de messages d'erreur dans chaque écouteur.

Les autorisations de compte Envoy et Cloud Service Mesh ne sont pas définies

Si l'erreur GRPC 403 s'affiche dans le journal envoy.err.log ou si TRAFFICDIRECTOR_INTERCEPTION_LISTENER ne s'affiche pas dans la configuration Envoy, vous n'avez peut-être pas défini les autorisations de compte appropriées.

Vérifiez que le compte de service de la VM dispose des autorisations d'accès TD pour xDS v3 :

Résoudre les erreurs ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Si le navigateur affiche l'erreur ERR_SSL_VERSION_OR_CIPHER_MISMATCH sans rediriger les utilisateurs vers la page de connexion, vérifiez l'état des certificats sur la Google Cloud page d'informations de l'équilibreur de charge.

Notez que le provisionnement d'un certificat géré par Google peut prendre jusqu'à 60 minutes.

Résoudre les problèmes d'installation d'Envoy

Si le connecteur sur site est déployé et que le certificat a été provisionné, mais que la connexion échoue toujours, cela peut indiquer qu'Envoy n'est peut-être pas installé correctement sur les VM.

Pour vérifier si Envoy est installé, connectez-vous en SSH à l'une des VM et exécutez la commande suivante :

  •  ps aux | grep envoy
    Plusieurs processus doivent être en cours d'exécution, autres que grep envoy.
  •  netstat -tlpn
    Le port d'administration Envoy 127.0.0.1:15000 doit être à l'écoute.

Si l'une des actions précédentes échoue, procédez comme suit pour atténuer le problème :

  1. Assurez-vous que l'accès privé à Google est activé sur le sous-réseau sur lequel le connecteur est déployé.
  2. Assurez-vous que VM Manager (API OS Config) est activé.

Résoudre les problèmes d'échec de déploiement sur les ressources IamMemberBinding

Si le connecteur sur site est en cours de déploiement ou de mise à jour et qu'il rencontre une PERMISSION_DENIED erreur liée aux IamMemberBinding ressources, cela peut être dû au fait que le compte de service Google APIs Service Agent ne s'est pas vu attribuer le OWNER rôle requis lors de l'activation d'IAP pour les applications sur site.

Exemples d'erreurs de déploiement :

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"}}

Si ces erreurs s'affichent lors du déploiement, vérifiez que le compte de service Google APIs Service Agent dispose du rôle OWNER, puis réessayez.