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 Cloud Service Mesh.

Como solucionar problemas de erro 500

A seguir, apresentamos vários problemas e possíveis soluções para ajudar você a resolver um erro 500 que aparece ao tentar acessar o aplicativo.

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

Talvez seu aplicativo local não esteja conectado à Google Cloud rede. 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 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. Usando SSH,conecte-se à VM opc-on-prem-app-deployment-ig-${app} e execute o seguinte comando. Encontre o número da porta do Envoy em Grupos de instâncias > Detalhes > Mapeamento de nomes de porta. 

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 Cloud Service Mesh 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 Cloud Service Mesh não poderá configurar o Envoy.
  • Verifique se há mensagens de erro em cada listener.

As permissões da conta do Envoy e do Cloud Service Mesh não foram definidas

Se você vir o erro GRPC 403 no 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:

Como solucionar problemas de erros ERR_SSL_VERSION_OR_CIPHER_MISMATCH

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 Google Cloud página de detalhes do balanceador de carga.

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

Como solucionar problemas de instalação do Envoy

Se o conector local for implantado com sucesso e o certificado tiver sido provisionado, mas a conexão ainda estiver falhando, isso poderá indicar que o Envoy não está instalado corretamente nas VMs.

Para verificar se o Envoy está instalado, conecte-se via SSH a 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, realize as seguintes ações para atenuar 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.

Como solucionar problemas de falha de implantação em recursos IamMemberBinding

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

Exemplo 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 você estiver recebendo esses erros com a implantação, verifique se a conta de serviço do Google APIs Service Agent recebeu o papel OWNER e tente novamente.