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 de tu conector local de IAP. Para obtener información adicional sobre la solución de problemas, consulta Depuración de Traffic Director.

Soluciona problemas del error 500

A continuación, se presentan 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 del conector local de Compute Engine. Si no se puede acceder al extremo del conector local, depura la conectividad y la configuración de 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, verifica 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 observas que Envoy no se ejecuta en los pasos anteriores, uno de los motivos podría ser los Controles del servicio de VPC. La secuencia de comandos de inicio en las VM 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 garantizar que Envoy se instale de forma correcta, permite el acceso al depósito 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 se pueda conectar a tu aplicación local, intenta realizar una llamada a Envoy desde la máquina en la que se ejecuta Envoy. Establece una conexión SSH con 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 nombre de puerto. 

shell 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, verifica si Traffic Director está habilitado y puede configurar Envoy mediante la ejecución del siguiente comando: 
    sudo curl 0.0.0.0:15000/config_dump
  • Verifica que TRAFFICDIRECTOR_INTERCEPTION_LISTENER esté configurado. Si TRAFFICDIRECTOR_INTERCEPTION_LISTENER no está configurado, Traffic Director no podría configurar Envoy.
  • Comprueba si hay mensajes de error en cada objeto de escucha.

No se configuraron los permisos de la cuenta de Envoy y Traffic Director

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:

  • Verifica los permisos: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#grant
  • Verifica la cuenta: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#enable-service

Soluciona errores 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 de Google 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 implementó correctamente y se aprovisionó el certificado, pero la conexión sigue fallando, esto podría indicar que Envoy podría no estar 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:

  •  ps aux | grep envoy
    Debe haber más de un proceso en ejecución, además de grep envoy.
  •  netstat -tlpn
    El puerto de administrador de Envoy 127.0.0.1:15000 debería estar escuchando.

Si alguna de las acciones anteriores falla, sigue estos pasos para mitigar el problema:

  1. Asegúrate de que el Acceso privado a Google esté habilitado en la subred en la que se implementará el conector.
  2. Asegúrate de que VM Manager (API de configuración del SO) esté habilitado.

Solución de problemas de implementación fallida en recursos IamMemberBinding

Si el conector local se está implementando o actualizando y encuentra un error PERMISSION_DENIED relacionado con los recursos IamMemberBinding, puede deberse a que a la cuenta de servicio Google APIs Service Agent no se le otorgó el rol OWNER como se requiere cuando habilitas 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 el rol de OWNER y vuelve a intentarlo.