Soluciona problemas de la configuración de los conectores locales

En esta página, se proporcionan instrucciones paso a paso para ayudarte a solucionar problemas de configuración del conector local de IAP. Para obtener más información sobre la solución de problemas, consulta Depuración de Cloud Service Mesh.

Soluciona problemas del error 500

A continuación, se indican varios problemas y posibles soluciones para ayudarte a resolver un error 500 que recibes cuando intentas acceder a tu aplicación.

La aplicación local no está conectada a la red de Google Cloud

Es posible que tu aplicación local no esté conectada a la red de Google Cloud . Para verificar la conectividad, haz ping a la aplicación local desde una de las instancias de Compute Engine del conector local. Si no se puede acceder al extremo del conector local, depura la conectividad y la configuración de la red antes de continuar.

Envoy no está instalado de forma correcta en las VM

Completa los siguientes pasos para verificar que Envoy esté instalado de forma correcta:

  1. Accede a una de las VM de Compute Engine desde el conector local. El nombre de la VM del conector local comienza con opc-on-prem-app-deployment-ig-${app}.

  2. En la consola de Cloud, comprueba que las verificaciones de estado del servicio de backend de balanceo de cargas opc-on-prem-app-deployment-gclb-urlmap estén en color verde.

  3. Si el servicio de backend no se muestra como en buen estado, establece una conexión SSH con una de las instancias:

    gcloud compute ssh INSTANCE_NAME --zone=ZONE_NAME

  4. Ejecuta el siguiente comando para verificar que Envoy esté en funcionamiento:

    ps aux | grep envoy

    Debe haber más de un proceso en ejecución, además de grep envoy.

    Este es un resultado de ejemplo:

    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. Verifica que el directorio de registro de Envoy se cree en /var/log/envoy/.

  6. Ejecuta el siguiente comando para asegurarte de que las VM puedan acceder al bucket de gce-mesh:

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

Si alguna de las validaciones de este paso falló, Envoy no se instaló de forma correcta. Revisa los registros de inicio en /var/log/daemon.log para obtener más información.

Si observaste que Envoy no se ejecuta desde los pasos anteriores, uno de los motivos podría ser los Controles del servicio de VPC. La secuencia de comandos de inicio en las VMs descarga la imagen de Envoy desde el bucket gce-mesh. Si las reglas de los Controles del servicio de VPC no permiten la conexión, la implementación del conector local no funcionará.

Para asegurarte de que Envoy se instale correctamente, permite el acceso al bucket de almacenamiento gce-mesh en los Controles del servicio de VPC en el proyecto host. Además, asegúrate de que la VPC tenga una regla de enrutamiento para permitir el tráfico a la Internet pública. Esto permite que se implemente Envoy. Para obtener más información, consulta Reglas de entrada y salida.

Tu aplicación local no está conectada a Envoy

Si puedes hacer ping a la aplicación local desde la VM, pero no puedes usar el conector local, es posible que Envoy no pueda conectarse a la aplicación.

Para verificar que Envoy pueda conectarse a tu aplicación local, intenta realizar una llamada a Envoy desde la máquina en la que se ejecuta Envoy. Con SSH, conéctate a la VM opc-on-prem-app-deployment-ig-${app} y ejecuta el siguiente comando. Puedes encontrar el número de puerto de Envoy en Grupos de instancias > Detalles > Asignación de nombres de puertos.

curl -x -v localhost:${envoy_port}

Si no se puede acceder al extremo, verifica lo siguiente:

  • /var/log/envoy/envoy.err.log para cualquier registro de errores. Si no hay registros de errores, ejecuta el siguiente comando para verificar si Cloud Service Mesh está habilitado y puede configurar Envoy:

    sudo curl 0.0.0.0:15000/config_dump

  • Verifica que TRAFFICDIRECTOR_INTERCEPTION_LISTENER esté configurado. Si no se establece TRAFFICDIRECTOR_INTERCEPTION_LISTENER, Cloud Service Mesh no pudo configurar Envoy.

  • Comprueba si hay mensajes de error en cada objeto de escucha.

No se configuraron los permisos de la cuenta de Envoy y Cloud Service Mesh

Si ves el error GRPC 403 en envoy.err.log o si no ves TRAFFICDIRECTOR_INTERCEPTION_LISTENER en la configuración de Envoy, es posible que no tengas los permisos de cuenta correctos.

Verifica que la cuenta de servicio de VM tenga permisos de acceso TD para xDS v3:

Solución de problemas ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Si el navegador muestra el error ERR_SSL_VERSION_OR_CIPHER_MISMATCH sin redireccionar a la página de acceso, verifica el estado de los certificados en la página de detalles del balanceador de cargas deGoogle Cloud .

Ten en cuenta que el aprovisionamiento de un certificado administrado por Google puede tomar hasta 60 minutos.

Soluciona problemas de instalación de Envoy

Si el conector local se implementa de forma correcta y se aprovisionó el certificado, pero la conexión sigue fallando, es posible que Envoy no esté instalado correctamente en las VMs.

Para verificar si Envoy está instalado, establece una conexión SSH a una de las VMs y ejecuta el siguiente comando:

  • Verifica que Envoy se esté ejecutando:

    ps aux | grep envoy

    Debe haber más de un proceso en ejecución, además de grep envoy.

  • Verifica que el puerto de administrador de Envoy esté escuchando:

    netstat -tlpn

    El puerto de administrador de Envoy 127.0.0.1:15000 debería estar escuchando.

Si alguna de las acciones anteriores falla, realiza las siguientes acciones para mitigar el problema:

  1. Asegúrate de que el Acceso privado a Google esté habilitado en la subred en la que se implementa el conector.

  2. Asegúrate de que VM Manager (API de configuración del SO) esté habilitado.

Soluciona problemas de fallas de implementación en recursos de IamMemberBinding

Si el conector local se está implementando o actualizando y encuentra un error PERMISSION_DENIED relacionado con los recursos de IamMemberBinding, puede deberse a que no se otorgó el rol OWNER a la cuenta de servicio de Google APIs Service Agent, como se requiere cuando se habilita IAP para apps locales.

Ejemplos de errores de implementación:

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 ves estos errores con la implementación, verifica que la cuenta de servicio de Google APIs Service Agent tenga asignado el rol de OWNER y vuelve a intentarlo.