Risoluzione dei problemi di accesso al server dei metadati

Questo documento mostra come risolvere i problemi relativi ai metadati di Compute Engine o server web.

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

• Errore durante la risoluzione del nome di dominio del server dei metadati
• La connessione al server dei 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. Autenticazione è Il processo di verifica dell'identità per l'accesso ai servizi e alle API di Google Cloud. Per eseguire codice o esempi da un ambiente di sviluppo locale, puoi eseguire l'autenticazione 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 ulteriori informazioni, vedi Esegui l'autenticazione per l'utilizzo di REST nella documentazione sull'autenticazione di Google Cloud.

Errori del server

Il server dei metadati potrebbe restituire il codice di stato Error 503 nel seguente modo: 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 in caso di errore della VM raggiungere il server 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 verificare, esegui il comando seguenti 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 l'output, la VM è connessa al server dei metadati è necessaria un'ulteriore azione. Se i comandi hanno esito negativo, esegui la seguenti:

      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 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 viene sovrascritta in un'ora se DNS di zona vengono applicate alle VM nel tuo progetto. Nel caso il tuo progetto sta ancora utilizzando DNS globale, il parametro Verrà ripristinato il protocollo DHCP predefinito per il file resolv.conf in 24 nell'orario lavorativo locale del TAM.

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

         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 :

         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 dei metadati e non devi fare altro è obbligatorio. Se i comandi non funzionano:

      1. Verifica che sia presente una route permanente al server dei metadati esegui questo 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 metodo 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 la mappatura tra il dominio del server dei metadati e il relativo indirizzo IP esiste:

         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 il comando seguente 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 e inviati dall'interno di una VM vengono gestiti dal server proxy.

Quando utilizzi 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 NO_PROXY sia per l'indirizzo IP che per il nome host.

Se non imposti la configurazione di NO_PROXY, potresti visualizzare errori durante l'esecuzione di comandi Google Cloud CLI o di query direttamente sul server di metadati poiché le chiamate al numero metadata.google.internal verranno inviate al senza doverli risolvere localmente sull'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 relativo al proxy, aggiungi il nome host e l'indirizzo IP del server di metadati a la variabile di ambiente NO_PROXY 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 verificare che le intestazioni siano conformi con le linee guida per la formattazione dell'intestazione RFC 7230 Sezione 3.2. Se il formato dell'intestazione non supera questi controlli, si verifica quanto segue:

• La richiesta è stata accettata. Tuttavia, riceverai consigli che potresti le VM che effettuano richieste al server di metadati con una formattazione errata headers. I suggerimenti vengono inviati una volta per VM. Puoi accedere a questi consigli utilizzando il 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 formattata in modo errato.

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

Non valido: contiene uno spazio vuoto tra il nome dell'intestazione e i due punti

Metadata-Flavor : Google

Valido: non devono esserci spazi vuoti tra le intestazioni nome e due punti, lo spazio vuoto 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 dei metadati, consulta Accedi ai metadati della VM.