Solução de problemas de acesso ao servidor de metadados

Neste documento, mostramos como resolver problemas com o servidor de metadados do Compute Engine.

As VMs do Compute Engine armazenam metadados em um servidor de metadados. As VMs têm acesso automático à API do servidor de metadados, sem qualquer autorização adicional. No entanto, às vezes as VMs podem perder o acesso ao servidor de metadados devido a uma das seguintes causas:

  • Falha ao resolver o nome de domínio do servidor de metadados
  • A conexão com o servidor de metadados está bloqueada por uma das seguintes opções:
    • Configuração de firewall no nível do SO
    • Configuração de proxy
    • Roteamento personalizado

Quando as VMs não conseguem acessar o servidor de metadados, alguns processos podem falhar.

Para informações sobre como solucionar o gke-metadata-server, consulte Resolver problemas de autenticação do GKE.

Antes de começar

  • Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud. Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine da seguinte maneira.

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.

Erros do servidor

O servidor de metadados pode retornar o código de status Error 503 nas seguintes circunstâncias:

  • O servidor está temporariamente indisponível.
  • O host está realizando um evento de manutenção

Se o aplicativo receber o código do erro 503, tente novamente.

Falha nas solicitações ao servidor de metadados

Confira a seguir exemplos de erros que podem ocorrer se a VM falhar ao acessar o servidor de metadados:

curl: (6) Could not resolve host: metadata.google.internal

postAttribute error: Put "http://metadata.google.internal/computeMetadata/v1/instance/guest-attributes/guestInventory/ShortName": dial tcp: lookup metadata.google.internal on [::1]:53: read udp [::1]:58319->[::1]:53: read: connection refused

Solução de problemas de solicitações com falha para o servidor de metadados

Se a VM tiver perdido o acesso ao servidor de metadados, faça o seguinte:

Linux

  1. Conecte-se à VM do Linux.

  2. Na VM Linux, execute os seguintes comandos para testar a conectividade com o servidor de metadados:

    1. Consulte o Servidor de Nomes de Domínio:

      nslookup metadata.google.internal

      A saída será parecida com esta:

      Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   metadata.google.internal
Address: 169.254.169.254

    2. Verifique se o servidor de metadados está acessível. Para verificar, execute os seguintes comandos:

      ping -c 3 metadata.google.internal

      A saída será parecida com esta:

      PING metadata.google.internal (169.254.169.254) 56(84) bytes of data.
64 bytes from metadata.google.internal (169.254.169.254): icmp_seq=1 ttl=255 time=0.812 ms

      ping -c 3 169.254.169.254

      A saída será parecida com esta:

      PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.
64 bytes from 169.254.169.254: icmp_seq=1 ttl=255 time=1.11 ms

    3. Se a saída dos comandos anteriores corresponder à saída sugerida, sua VM estará conectada ao servidor de metadados e nenhuma outra ação será necessária. Se os comandos falharem, faça o seguinte:

      1. Verifique se o servidor de nomes está configurado para o servidor de metadados:

        cat /etc/resolv.conf

        A saída será parecida com esta:

        domain ZONE.c.PROJECT_ID.internal
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

        Se a saída não tiver as linhas anteriores, consulte a documentação do sistema operacional para saber como editar a Política de DHCP e manter a configuração do servidor de nomes como 169.254.169.254. Isso ocorre porque as alterações em /etc/resolv.conf serão substituídas em uma hora se as configurações de DNS zonal forem aplicadas às VMs no projeto. Caso seu projeto ainda esteja usando um DNS global, o arquivo resolv.conf vai ser revertido para o DHCP padrão em 24 horas.

      2. Verifique se existe o mapeamento entre o nome de domínio do servidor de metadados e o endereço IP dele:

        cat /etc/hosts

        Esta linha deve aparecer na saída:

        169.254.169.254 metadata.google.internal  # Added by Google

        Se a saída não tiver a linha anterior, execute o seguinte comando:

        echo "169.254.169.254 metadata.google.internal" >> /etc/hosts

Windows

  1. Conecte-se à VM do Windows:

  2. Na VM do Windows, execute os seguintes comandos:

    1. Consulte o Servidor de Nomes de Domínio:

      nslookup metadata.google.internal

      A saída será parecida com esta:

      Server:  UnKnown
Address:  10.128.0.1

Non-authoritative answer:
Name:    metadata.google.internal
Address:  169.254.169.254

    2. Verifique se o servidor de metadados está acessível. Para verificar, execute os seguintes comandos:

      ping -n 3 metadata.google.internal

      A resposta será parecida com esta: 

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255


      ping -n 3 169.254.169.254

      A saída será parecida com esta:

      Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255

    3. Se a saída dos comandos anteriores corresponder à saída sugerida, sua VM estará conectada ao servidor de metadados e nenhuma outra ação será necessária. Se os comandos falharem, faça o seguinte:

      1. Para verificar se há uma rota persistente para o servidor de metadados, execute o comando:

        route print

        A saída precisa conter o seguinte:

        Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
169.254.169.254  255.255.255.255         On-link        1

        Se a saída não tiver a linha anterior, adicione a rota usando os seguintes comandos:

        $Adapters = Get-NetKVMAdapterRegistry
$FirstAdapter = $Adapters | Select-Object -First 1
route /p add 169.254.169.254 mask 255.255.255.255 0.0.0.0 'if' $FirstAdapter.InterfaceIndex metric 1

      2. Verifique se existe o mapeamento entre o nome de domínio do servidor de metadados e o endereço IP dele:

        type %WINDIR%\System32\Drivers\Etc\Hosts

        Esta linha deve aparecer na saída:

        169.254.169.254 metadata.google.internal  # Added by Google

        Se a saída não tiver a linha anterior, execute o seguinte comando:

        echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts

Solicitações com falha ao usar um proxy de rede

Um servidor proxy de rede impede o acesso direto da VM à Internet. Todas as consultas enviadas de dentro de uma VM são processadas pelo servidor proxy.

Ao usar um aplicativo que recebe credenciais do servidor de metadados, como um token de autenticação, a VM requer acesso direto ao servidor de metadados. Se a VM estiver por trás de um proxy, defina a configuração NO_PROXY para o endereço IP e o nome do host.

Se você não definirNO_PROXY, você poderá ver erros ao executar os comandos da Google Cloud CLI ou consultar o servidor de metadados diretamente desde as chamadas parametadata.google.internal serão enviados ao proxy sem que sejam resolvidos localmente na própria instância.

Este é um exemplo de erro que você pode ver:

ERROR 403 (Forbidden): Your client does not have permission to get URL

Para resolver esse problema de proxy, adicione o nome do host e o endereço IP do servidor de metadados à variável de ambiente NO_PROXY da seguinte maneira:

Linux

  1. Conecte-se à VM do Linux.

  2. Na VM do Linux, execute os seguintes comandos:

    export no_proxy=169.254.169.254,metadata,metadata.google.internal

    Para salvar as alterações, execute o seguinte comando:

    echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment

Windows

  1. Conecte-se à VM do Windows:

  2. Na VM do Windows, execute os seguintes comandos:

    set NO_PROXY=169.254.169.254,metadata,metadata.google.internal

    Para salvar as alterações, execute o seguinte comando:

    setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /m

Resolver problemas de solicitações com falha para o endpoint do servidor de metadados HTTPS

Esta seção aborda alguns dos erros que podem aparecer ao consultar o endpoint do servidor de metadados HTTPS.

Os erros listados nesta seção são retornados quando você consulta usando a ferramenta cURL para consultar, mas a mensagem de erro retornada é semelhante para outras ferramentas.

Certificado do cliente incorreto

Os erros a seguir ocorrem se você fornecer um valor incorreto para a flag -E.

  • curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate
required, errno 0
  • curl: (58)  unable to set private key file:
  • curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory

Para resolver esse problema, forneça o caminho correto para o certificado de identidade do cliente. Para conferir o local dos certificados de identidade do cliente, consulte Certificados de identidade do cliente.

Nome do host incorreto

O erro a seguir ocorre se o nome do host usado para acessar o servidor de metadados não for encontrado no certificado.

curl: (60) SSL: no alternative certificate subject name matches target host name

Para resolver esse problema, verifique se o URL raiz ou o nome do host na consulta é metadata.google.internal. Para mais informações sobre o URL raiz do servidor de metadados, consulte Partes de uma solicitação de metadados.

Certificado raiz ou do cliente incorreto

O seguinte erro pode aparecer quando você consulta o endpoint do servidor de metadados HTTPS:

curl: (77) error setting certificate verify locations:

Isso pode acontecer nos seguintes cenários:

  • O caminho da flag --cacert pode estar incorreto
  • O certificado raiz pode estar ausente no repositório de confiança.

Para resolver esse problema, é necessário especificar o certificado raiz e o certificado do cliente ao consultar o endpoint HTTPS. Para saber onde os certificados estão armazenados, consulte Onde os certificados são armazenados.

Por exemplo, para consultar a imagem de inicialização da VM, execute a seguinte consulta:

user@myinst:~$ curl "https://metadata.google.internal/computeMetadata/v1/instance/image" \
    -E /run/google-mds-mtls/client.key \
    --cacert /run/google-mds-mtls/root.crt \
    -H "Metadata-Flavor: Google"

Formato de cabeçalho incorreto

O servidor de metadados realiza verificações de formatação para garantir que os cabeçalhos estejam em conformidade com a diretriz de formatação de cabeçalhos RFC 7230 Seção 3.2 (em inglês). Se o formato do cabeçalho falhar, estas verificações vão ocorrer:

  • A solicitação foi aceita. No entanto, você vai receber recomendações de VMs fazendo solicitações ao servidor de metadados com cabeçalhos formatados incorretamente. As recomendações são enviadas uma vez por VM. É possível acessar essas recomendações usando a Google Cloud CLI ou a API REST do recomendador.

    Depois de aplicar a recomendação, defina o estado da recomendação como succeeded.

  • A partir de 20 de janeiro de 2024, o servidor de metadados vai negar qualquer solicitação com um cabeçalho formatado incorretamente.

Veja a seguir exemplos de formatos de solicitação de cabeçalho válidos e inválidos.

Inválido: contém espaços em branco entre o nome do cabeçalho e dois pontos

Metadata-Flavor : Google

Válido: não há espaço em branco entre o nome do cabeçalho e os dois pontos, espaço em branco após os dois pontos é ignorado pelo verificador

Metadata-Flavor: Google

Válido: sem espaços em branco no cabeçalho

Metadata-Flavor:Google

Para mais informações sobre como fazer consultas ao servidor de metadados, consulte Acessar metadados da VM.