Solucionar problemas de configuración de conectores on-premise

En esta página se ofrecen instrucciones detalladas para ayudarte a solucionar problemas con la configuración de tu conector on-premise de IAP. Para obtener más información sobre cómo solucionar problemas, consulta Depuración de Traffic Director.

Solucionar problemas con el error 500

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

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

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

Envoy no está instalado correctamente en las VMs

Sigue estos pasos para verificar que Envoy se ha instalado correctamente:

  1. Inicia sesión en una de las VMs de Compute Engine desde el conector local. El nombre de la VM del conector local empieza por opc-on-prem-app-deployment-ig-${app}.
  2. En la consola de Cloud, compruebe que las comprobaciones del estado del servicio de backend de balanceo de carga opc-on-prem-app-deployment-gclb-urlmap están en verde.
  3. Si el servicio backend no aparece como correcto, conéctate por SSH a una de las instancias: 
     gcloud compute ssh instance-name --zone=zone name

  4. Para comprobar que Envoy está en funcionamiento, ejecuta el siguiente comando: 

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

    Ejemplo de salida:

    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 haya creado en /var/log/envoy/.

  6. Asegúrate de que las VMs puedan acceder al bucket gce-mesh ejecutando el siguiente comando: 

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

Si alguna de las validaciones de este paso falla, significa que Envoy no se ha instalado correctamente. Consulta los registros de inicio en /var/log/daemon.log para obtener más información.

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

Para asegurarte de que Envoy se instala correctamente, permite el acceso al gce-mesh del proyecto host en Controles de Servicio de VPC. Además, asegúrate de que la VPC tenga una regla de enrutamiento que permita el tráfico a la red pública de Internet. 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 on-premise desde la VM, pero no puedes usar el conector on-premise, es posible que Envoy no pueda conectarse a la aplicación.

Para verificar que Envoy puede conectarse a tu aplicación local, prueba a hacer una llamada a Envoy desde la máquina en la que se está ejecutando. Accede a la VM mediante SSH 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 endpoint, comprueba lo siguiente:

  • /var/log/envoy/envoy.err.log para ver los registros de errores. Si no hay registros de errores, comprueba si Traffic Director está habilitado y puede configurar Envoy ejecutando el siguiente comando: 
    sudo curl 0.0.0.0:15000/config_dump
  • Verifica que TRAFFICDIRECTOR_INTERCEPTION_LISTENER esté configurado. Si no se ha definido TRAFFICDIRECTOR_INTERCEPTION_LISTENER, Traffic Director no podrá configurar Envoy.
  • Comprueba si hay mensajes de error en cada escucha.

No se han definido los permisos de la cuenta de Envoy y Traffic Director

Si ves el error GRPC 403 en envoy.err.log o 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 la 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

Solucionar errores de ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Si el navegador muestra el error ERR_SSL_VERSION_OR_CIPHER_MISMATCH sin redirigir a la página de inicio de sesión, compruebe el estado de los certificados en la página de detalles del balanceador de carga Google Cloud .

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

Solucionar problemas de instalación de Envoy

Si el conector local se ha implementado correctamente y el certificado se ha aprovisionado, pero la conexión sigue fallando, puede que Envoy no se haya instalado correctamente en las máquinas virtuales.

Para comprobar si Envoy está instalado, accede a una de las VMs a través de SSH 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 debe estar escuchando.

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

  1. Asegúrate de que la función Acceso privado de Google esté habilitada en la subred en la que se va a implementar el conector.
  2. Asegúrate de que VM Manager (API OS Config) esté habilitado.

Solucionar problemas de fallo de despliegue en recursos IamMemberBinding

Si el conector local se está implementando o actualizando y se produce un error PERMISSION_DENIED relacionado con los recursos de IamMemberBinding, puede deberse a que no se ha concedido el rol OWNER a la cuenta de servicio Google APIs Service Agent, tal como se requiere al habilitar IAP para aplicaciones 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 durante la implementación, comprueba que se haya concedido el rol OWNER a la cuenta de servicio Google APIs Service Agent y vuelve a intentarlo.