Como solucionar problemas da configuração do conector local

Nesta página, fornecemos instruções passo a passo para resolver problemas com a configuração do conector local do IAP. Para mais informações sobre solução de problemas, consulte Depuração do Traffic Director.

Como solucionar problemas de erro 500

Veja a seguir vários problemas e possíveis soluções para ajudar você a resolver um erro 500 recebido ao tentar acessar seu aplicativo.

O aplicativo local não está conectado à rede do Google Cloud

Talvez seu aplicativo local não esteja conectado à rede do Google Cloud. Verifique a conectividade ao dar um ping no aplicativo local em uma das instâncias do conector local do Compute Engine. Se o endpoint do conector local estiver inacessível, depure a conectividade e as configurações da rede antes de continuar.

O Envoy não está instalado corretamente nas VMs

Conclua as etapas a seguir para verificar se o Envoy está instalado corretamente:

  1. Faça login em uma das VMs do Compute Engine usando o conector local. O nome da VM do conector local começa com opc-on-prem-app-deployment-ig-${app}.
  2. No console do Google Cloud, verifique se as verificações de integridade do serviço de back-end de balanceamento de carga opc-on-prem-app-deployment-gclb-urlmap estão verdes.
  3. Se o serviço de back-end não aparecer como íntegro, conecte-se via SSH a uma das instâncias: 
     gcloud compute ssh instance-name --zone=zone name

  4. Emita o seguinte comando para verificar se o Envoy está em execução: 

     ps aux | grep envoy
    É necessário ter mais de um processo em execução, além do grep envoy.

    Um exemplo de saída:

    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. Verifique se o diretório de registros do Envoy foi criado em /var/log/envoy/.

  6. Verifique se o bucket gce-mesh pode ser acessado pelas VMs emitindo o seguinte comando: 

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

Se alguma das validações desta etapa falhar, o Envoy não será instalado corretamente. Para mais informações, revise os registros de inicialização em /var/log/daemon.log.

Se você observou que o Envoy não está sendo executado nas etapas anteriores, um dos motivos pode ser o VPC Service Controls. O script de inicialização nas VMs faz o download da imagem do Envoy do bucket gce-mesh. Se as regras do VPC Service Controls não permitirem a conexão, a implantação do conector local não funcionará.

Para garantir que o Envoy seja instalado corretamente, permita o acesso ao bucket de armazenamento gce-mesh no VPC Service Controls no projeto host. Além disso, verifique se a VPC tem uma regra de roteamento que permita o tráfego para a Internet pública. Isso permite que o Envoy seja implantado. Para mais informações, consulte Regras de entrada e de saída.

O aplicativo local não está conectado ao Envoy

Se for possível dar um ping no aplicativo local da VM, mas não usar o conector local, é possível que o Envoy não consiga se conectar ao aplicativo.

Para verificar se o Envoy pode se conectar ao seu aplicativo local, tente fazer uma chamada para o Envoy na máquina em que o Envoy está sendo executado. SSH no opc-on-prem-app-deployment-ig-${app} da VM e execute o seguinte comando: Encontre o número da porta do Envoy em Grupos de instâncias > Detalhes > Mapeamento de nomes de porta. 

shell curl -x -v localhost:${envoy_port}

Se o endpoint não estiver acessível, verifique o seguinte:

  • /var/log/envoy/envoy.err.log para registros de erros; Se não houver registros de erros, verifique se o Traffic Director está ativado e é possível configurar o Envoy. Para isso, execute o seguinte comando: 
    sudo curl 0.0.0.0:15000/config_dump
  • Verifique se TRAFFICDIRECTOR_INTERCEPTION_LISTENER está definido. Se TRAFFICDIRECTOR_INTERCEPTION_LISTENER não estiver definido, o Traffic Director não poderá configurar o Envoy.
  • Verifique se há mensagens de erro em cada listener.

As permissões da conta do Envoy e do Traffic Director não foram definidas

Se você vir o erro GRPC 403 na envoy.err.log ou não vir TRAFFICDIRECTOR_INTERCEPTION_LISTENER na configuração do Envoy, talvez as permissões de conta corretas não tenham sido definidas.

Verifique se a conta de serviço da VM tem permissões de acesso TD para xDS v3:

  • Verifique as permissões: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#grant
  • Verifique a conta: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#enable-service

Solução de problemas de ERR_SSL_VERSION_OR_CIPHER_MISMATCH erro

Se o navegador mostrar o erro ERR_SSL_VERSION_OR_CIPHER_MISMATCH sem redirecionar para a página de login, verifique o status dos certificados na página de detalhes do balanceador de carga do Google Cloud.

O provisionamento de um certificado gerenciado pelo Google pode levar até 60 minutos.

Solução de problemas de instalação do Envoy

Se o conector local for implantado e o certificado provisionado, mas a conexão ainda falhar, isso pode indicar que o Envoy não foi instalado corretamente nas VMs.

Para verificar se o Envoy está instalado, use SSH em uma das VMs e execute o seguinte comando:

  •  ps aux | grep envoy
    É necessário ter mais de um processo em execução, além do grep envoy.
  •  netstat -tlpn
    A porta de administrador do Envoy 127.0.0.1:15000 precisa estar detectando.

Se alguma das ações anteriores falhar, faça o seguinte para minimizar o problema:

  1. Verifique se o Acesso privado do Google está ativado na sub-rede em que o conector está sendo implantado.
  2. Verifique se o VM Manager (API OS Config) está ativado.

Solução de problemas de falha de implantação em recursos de IamMemberBinding

Se o conector local estiver sendo implantado ou atualizado e encontrar um erro PERMISSION_DENIED relacionado a recursos IamMemberBinding, isso pode acontecer porque a conta de serviço Google APIs Service Agent não recebeu o papel OWNER conforme necessário ao ativar o IAP para apps locais.

Exemplos de erros de implantação:

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

Se esses erros aparecerem na implantação, verifique se a conta de serviço Google APIs Service Agent recebeu a função OWNER e tente novamente.