Risoluzione dei problemi di accesso al server dei metadati

Questo documento mostra come risolvere i problemi relativi al server di metadati di Compute Engine.

Le VM di Compute Engine archiviano i metadati su un server metadati. Le VM hanno automaticamente accesso all'API del server dei metadati senza alcuna autorizzazione aggiuntiva. Tuttavia, a volte le VM potrebbero perdere l'accesso al server dei metadati a causa di una delle seguenti cause:

• Impossibile risolvere il nome di dominio del server dei metadati
• La connessione al server di metadati è bloccata da una delle seguenti opzioni:
  • Configurazione del firewall a livello di sistema operativo
  • Configurazione del proxy
  • Routing personalizzato

Quando le VM non possono accedere al server dei metadati, alcuni processi potrebbero non riuscire.

Per informazioni sulla risoluzione dei problemi relativi a gke-metadata-server, consulta Risolvere i problemi di autenticazione GKE.

Prima di iniziare

• Se non l'hai già fatto, configura l'autenticazione. L'autenticazione è il processo mediante il quale viene verificata l'identità dell'utente per ottenere l'accesso ai servizi e alle API Google Cloud. Per eseguire codice o esempi da un ambiente di sviluppo locale, puoi eseguire l'autenticazione in Compute Engine come segue.
  

  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. Installa Google Cloud CLI, quindi initialize eseguendo questo comando:

     gcloud init

     Nota: se hai già installato gcloud CLI in precedenza, assicurati di disporre della versione più recente eseguendo gcloud components update.
  2. Set a default region and zone.

  REST

  Per utilizzare gli esempi di API REST in questa pagina in un ambiente di sviluppo locale, utilizzi le credenziali che fornisci a gcloud CLI.

  Installa Google Cloud CLI, quindi initialize eseguendo questo comando:

  gcloud init

  Per maggiori informazioni, consulta Autenticazione per l'utilizzo di REST nella documentazione sull'autenticazione di Google Cloud.

Errori del server

Il server di metadati potrebbe restituire il codice di stato Error 503 nelle seguenti circostanze:

• Il server è temporaneamente non disponibile
• L'host sta eseguendo un evento di manutenzione

Se l'applicazione riceve un codice di errore 503, riprova a eseguire la richiesta.

Richieste non riuscite al server dei metadati

Di seguito sono riportati alcuni esempi di errori che potresti riscontrare se la VM non riesce a raggiungere il server dei metadati:

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

Se la tua VM ha perso l'accesso al server dei metadati, segui questi passaggi:

Linux

1. Connettiti alla VM Linux.

2. Dalla VM Linux, esegui questi comandi per verificare la connettività al server di metadati:

   1. Esegui una query sul server dei nomi di dominio:

      nslookup metadata.google.internal
      

      L'output dovrebbe essere simile al seguente:

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

   2. Verifica che il server dei metadati sia raggiungibile. Per verificarlo, esegui questi comandi:

      ping -c 3 metadata.google.internal
      

      L'output dovrebbe essere simile al seguente:

      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
      

      L'output dovrebbe essere simile al seguente:

      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 l'output dei comandi precedenti corrisponde all'output suggerito, la VM è connessa al server di metadati e non sono necessarie ulteriori azioni. Se i comandi hanno esito negativo, segui questi passaggi:

      1. Verifica che il server dei nomi sia configurato sul server metadati:

         cat /etc/resolv.conf
         

         L'output dovrebbe essere simile al seguente:

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

         Se l'output non contiene le righe precedenti, fai riferimento alla documentazione del sistema operativo per informazioni su come modificare il criterio DHCP per mantenere la configurazione del server dei nomi su 169.254.169.254. Questo perché le modifiche a /etc/resolv.conf verranno sostituite entro un'ora se le impostazioni del DNS di zona vengono applicate alle VM all'interno del tuo progetto. Se il tuo progetto utilizza ancora un DNS globale, per il file resolv.conf verrà ripristinato il protocollo DHCP predefinito entro 24 ore.

      2. Verifica che esista la mappatura tra il nome di dominio del server dei metadati e il relativo indirizzo IP:

         cat /etc/hosts
         

         Nell'output dovrebbe essere presente la seguente riga:

         169.254.169.254 metadata.google.internal  # Added by Google
         

         Se l'output non include la riga precedente, esegui questo comando:

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

Windows

1. Connettiti alla tua VM Windows.

2. Dalla VM Windows, esegui questi comandi:

   1. Esegui una query sul server dei nomi di dominio:

      nslookup metadata.google.internal
      

      L'output dovrebbe essere simile al seguente:

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

   2. Verifica che il server dei metadati sia raggiungibile. Per verificarlo, esegui questi comandi:

      ping -n 3 metadata.google.internal
      

      L'output dovrebbe essere simile al seguente:

      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
      

      L'output dovrebbe essere simile al seguente:

      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 l'output dei comandi precedenti corrisponde all'output suggerito, la VM è connessa al server di metadati e non sono necessarie ulteriori azioni. Se i comandi hanno esito negativo, procedi nel seguente modo:

      1. Verifica che sia presente una route permanente al server dei metadati eseguendo il comando:

         route print
         

         L'output dovrebbe contenere quanto segue.

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

         Se l'output non include la riga precedente, aggiungi il percorso utilizzando i seguenti comandi:

         $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. Verifica che esista la mappatura tra il nome di dominio del server dei metadati e il relativo indirizzo IP:

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

         Nell'output dovrebbe essere presente la seguente riga:

         169.254.169.254 metadata.google.internal  # Added by Google
         

         Se l'output non include la riga precedente, esegui questo comando:

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

Richieste non riuscite durante l'utilizzo di un proxy di rete

Un server proxy di rete impedisce l'accesso diretto della VM a internet. Tutte le query inviate dall'interno di una VM vengono invece gestite dal server proxy.

Quando si utilizza un'applicazione che riceve le credenziali dal server dei metadati, ad esempio un token di autenticazione, la VM richiede l'accesso diretto al server dei metadati. Se la VM è protetta da un proxy, devi impostare la configurazione NO_PROXY sia per l'indirizzo IP sia per il nome host.

Se non imposti la configurazione NO_PROXY, potresti visualizzare errori durante l'esecuzione dei comandi di Google Cloud CLI o una query diretta al server di metadati, poiché le chiamate a metadata.google.internal verranno inviate al proxy senza che vengano risolte localmente nell'istanza stessa.

Di seguito è riportato un esempio di errore che potresti riscontrare:

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

Per risolvere questo problema del proxy, aggiungi il nome host e l'indirizzo IP del server di metadati alla variabile di ambiente NO_PROXY procedendo nel seguente modo:

Linux

1. Connettiti alla VM Linux.

2. Dalla VM Linux, esegui questi comandi:

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

   Per salvare le modifiche, esegui questo comando:

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

Windows

1. Connettiti alla tua VM Windows.

2. Dalla VM Windows, esegui questi comandi:

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

   Per salvare le modifiche, esegui questo comando:

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

Formato intestazione non corretto

Il server dei metadati esegue controlli di formattazione per garantire che le intestazioni siano conformi alle linee guida per la formattazione delle intestazioni RFC 7230 sezione 3.2. Se il formato dell'intestazione non supera questi controlli, si verifica quanto segue:

• La richiesta è stata accettata. Tuttavia, riceverai suggerimenti secondo cui le VM che effettuano richieste al server dei metadati con intestazioni formattate in modo errato. I suggerimenti vengono inviati una volta per VM. Puoi accedere a questi suggerimenti utilizzando Google Cloud CLI o l'API REST Recommender.

  Dopo aver applicato il consiglio, imposta lo stato del consiglio su succeeded.

• A partire dal 20 gennaio 2024, il server di metadati rifiuta qualsiasi richiesta con un'intestazione formattata in modo errato.

Di seguito sono riportati esempi di formati di richiesta di intestazione validi e non validi.

Non valido: contiene spazi vuoti tra il nome dell'intestazione e i due punti

Metadata-Flavor : Google

Valido: non ci sono spazi tra il nome dell'intestazione e i due punti. Lo spazio dopo i due punti viene ignorato dal controllo

Metadata-Flavor: Google

Valido: non sono presenti spazi vuoti nell'intestazione

Metadata-Flavor:Google

Per ulteriori informazioni su come eseguire query sul server di metadati, consulta Accedere ai metadati della VM.