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 en savoir plus sur le dépannage, consultez la page Débogage Traffic Director.

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

Vous trouverez ci-dessous divers problèmes et solutions possibles qui vous aideront à remédier à une erreur 500, qui pourrait se produire lorsque vous tentez d'accéder à votre application.

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

Il est possible que votre application sur site ne soit pas connectée au réseau Google Cloud. 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 la console Cloud, vérifiez que les vérifications de l'état du service de backend d'équilibrage de charge opc-on-prem-app-deployment-gclb-urlmap sont 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 :

    gsutil 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é. Connectez-vous en SSH à 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.

shell 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 Traffic Director 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, Traffic Director ne peut pas configurer Envoy.
  • Vérifiez l'absence de messages d'erreur dans chaque écouteur.

Les autorisations de compte Envoy et Traffic Director 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 :

  • Vérifiez les autorisations : https://cloud.google.com/traffic-director/docs/prep-for-envoy-setup#grant
  • Vérifiez le compte : https://cloud.google.com/traffic-director/docs/preprocess-for-envoy-setup#enable-service

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 page d'informations de l'équilibreur de charge Google Cloud.

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

Résoudre un problème d'installation d'Envoy

Si le connecteur sur site a bien été déployé et que le certificat a été provisionné, mais que la connexion échoue encore, cela peut indiquer qu'Envoy a peut-être été mal installé 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 administrateur Envoy 127.0.0.1:15000 doit écouter.

Si l'une des actions précédentes échoue, prenez les mesures suivantes pour limiter le problème:

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

Résoudre les échecs de déploiement sur les ressources IamMemberBinding

Si le connecteur sur site est en cours de déploiement ou de mise à jour et rencontre une erreur PERMISSION_DENIED liée aux ressources IamMemberBinding, il est possible que le rôle OWNER n'ait pas été attribué au compte de service Google APIs Service Agent 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 vous rencontrez ces erreurs lors du déploiement, vérifiez que le compte de service Google APIs Service Agent dispose du rôle OWNER, puis réessayez.