Resolução de problemas da configuração do conetor no local

Esta página fornece instruções passo a passo para ajudar a resolver problemas de configuração do conector no local do IAP. Para mais informações de resolução de problemas, consulte o artigo Depuração do Traffic Director.

Resolução de problemas do erro 500

Seguem-se vários problemas e possíveis soluções para ajudar a resolver um erro 500 que recebe quando tenta aceder à sua aplicação.

A aplicação no local não está ligada à Google Cloud rede

A sua aplicação no local pode não estar ligada à rede Google Cloud . Valide a conetividade enviando um ping para a aplicação no local a partir de uma das instâncias do Compute Engine do conetor no local. Se o ponto final do conetor no local estiver inacessível, depure a conetividade e as definições de rede antes de continuar.

O Envoy não está instalado corretamente nas VMs

Conclua os passos seguintes para verificar se o Envoy está instalado corretamente:

  1. Inicie sessão numa das VMs do Compute Engine a partir do conector no local. O nome da VM do conetor no local começa por opc-on-prem-app-deployment-ig-${app}.
  2. Na consola do Google Cloud, verifique se as verificações de funcionamento 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 for apresentado como saudável, faça SSH para uma das instâncias: 
     gcloud compute ssh instance-name --zone=zone name

  4. Verifique se o Envoy está em funcionamento executando o seguinte comando: 

     ps aux | grep envoy
    Deve haver mais do que um processo em execução, além do grep envoy.

    Exemplo de resultado:

    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 registo do Envoy foi criado em /var/log/envoy/.

  6. Certifique-se de que as VMs conseguem aceder ao contentor gce-mesh 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 neste passo falhar, o Envoy não está instalado corretamente. Reveja os registos de arranque em /var/log/daemon.log para mais informações.

Se observou que o Envoy não está a ser executado a partir dos passos anteriores, um dos motivos pode ser o VPC Service Controls. O script de arranque nas VMs transfere a imagem do Envoy do bucket gce-mesh. Se as regras dos VPC Service Controls não permitirem a ligação, a implementação do conetor no local não funciona.

Para garantir que o Envoy é instalado corretamente, permita o acesso ao contentor de armazenamento gce-mesh nos VPC Service Controls no projeto anfitrião. Além disso, certifique-se de que a VPC tem uma regra de encaminhamento para permitir o tráfego para a Internet pública. Isto permite a implementação do Envoy. Para mais informações, consulte o artigo Regras de entrada e saída.

A sua aplicação no local não está ligada ao Envoy

Se conseguir enviar um ping para a aplicação no local a partir da VM, mas não conseguir usar o conetor no local, é possível que o Envoy não consiga estabelecer ligação à aplicação.

Para verificar se o Envoy consegue estabelecer ligação à sua aplicação no local, experimente fazer uma chamada para o Envoy a partir da máquina onde o Envoy está a ser executado. Entre na VM através de SSH opc-on-prem-app-deployment-ig-${app} e execute o seguinte comando. Pode encontrar o número da porta do Envoy em Grupos de instâncias > Detalhes > Mapeamento de nomes de portas. 

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

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

  • /var/log/envoy/envoy.err.log para ver registos de erros. Se não existirem registos de erros, verifique se o Traffic Director está ativado e se consegue configurar o Envoy executando o seguinte comando: 
    sudo curl 0.0.0.0:15000/config_dump
  • Verifique se o TRAFFICDIRECTOR_INTERCEPTION_LISTENER está definido. Se TRAFFICDIRECTOR_INTERCEPTION_LISTENER não estiver definido, o Traffic Director não consegue configurar o Envoy.
  • Verifique se existem mensagens de erro em cada ouvinte.

As autorizações da conta do Envoy e do Traffic Director não estão definidas

Se vir o erro GRPC 403 no envoy.err.log ou se não vir TRAFFICDIRECTOR_INTERCEPTION_LISTENER na configuração do Envoy, pode não ter as autorizações de conta corretas definidas.

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

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

Resolução de problemas de erros ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Se o navegador apresentar o erro ERR_SSL_VERSION_OR_CIPHER_MISMATCH sem redirecionar para a página de início de sessão, verifique o estado dos certificados na Google Cloud página de detalhes do equilibrador de carga.

Tenha em atenção que o aprovisionamento de um certificado gerido pela Google pode demorar até 60 minutos.

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

Se o conector no local for implementado com êxito e o certificado tiver sido aprovisionado, mas a ligação continuar a falhar, isto pode indicar que o Envoy pode não estar instalado corretamente nas VMs.

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

  •  ps aux | grep envoy
    Deve haver mais do que um processo em execução, além do grep envoy.
  •  netstat -tlpn
    A porta de administração do Envoy 127.0.0.1:15000 deve estar a ouvir.

Se alguma das ações anteriores falhar, tome as seguintes medidas para mitigar o problema:

  1. Certifique-se de que o acesso privado à Google está ativado na sub-rede em que o conetor está a ser implementado.
  2. Certifique-se de que o VM Manager (API OS Config) está ativado.

Resolução de problemas de falha de implementação em recursos IamMemberBinding

Se o conector no local estiver a ser implementado ou atualizado e encontrar um erro PERMISSION_DENIED relacionado com recursos IamMemberBinding, pode dever-se ao facto de a conta de serviço Google APIs Service Agent não ter recebido a função OWNER, conforme necessário quando ativa o IAP para apps no local.

Exemplos de erros de implementaçã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 estiver a ver estes erros com a implementação, verifique se à Google APIs Service Agent conta de serviço foi atribuída a função OWNER e tente novamente.