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.

    Selecione a guia para como planeja usar as amostras nesta página:

    Console

    Quando você usa o console do Google Cloud para acessar os serviços e as APIs do Google Cloud, não é necessário configurar a autenticação.

    gcloud

    1. Instale a Google Cloud CLI e inicialize-a executando o seguinte comando: 

      gcloud init
    2. Defina uma região e uma zona padrão.

    REST

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

      Instale a Google Cloud CLI e inicialize-a executando o seguinte comando: 

      gcloud init

Erros comuns

Veja a seguir exemplos do que pode ser encontrado 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 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


      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

Solução de problemas de 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

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.