Résoudre les problèmes d'accès au serveur de métadonnées

Ce document explique comment résoudre les problèmes liés au serveur de métadonnées Compute Engine.

Les VM Compute Engine stockent les métadonnées sur un serveur de métadonnées. Les VM ont automatiquement accès à l'API du serveur de métadonnées sans aucune autorisation supplémentaire. Toutefois, les VM peuvent ne plus avoir accès au serveur de métadonnées pour l'une des causes suivantes :

  • Échec de la résolution du nom de domaine du serveur de métadonnées
  • La connexion au serveur de métadonnées est bloquée par l'un des éléments suivants :
    • Configuration du pare-feu au niveau du système d'exploitation
    • Configuration du proxy
    • Routage personnalisé

Lorsque les VM ne peuvent pas accéder au serveur de métadonnées, certains processus peuvent échouer.

Pour en savoir plus sur le dépannage de gke-metadata-server, consultez la page Résoudre les problèmes d'authentification GKE.

Avant de commencer

  • Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :

    Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :

    Console

    Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.

    gcloud

    1. Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante : 

      gcloud init
    2. Définissez une région et une zone par défaut.

    REST

    Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

      Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante : 

      gcloud init

Erreurs fréquentes

Voici des exemples que vous pouvez rencontrer si votre VM n'atteint pas le serveur de métadonnées :

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

Résoudre les échecs de requêtes adressées au serveur de métadonnées

Si votre VM a perdu l'accès au serveur de métadonnées, procédez comme suit :

Linux

  1. Connectez-vous à votre VM Linux.

  2. Depuis votre VM Linux, exécutez les commandes suivantes pour tester la connectivité au serveur de métadonnées :

    1. Interrogez le serveur de noms de domaine :

      nslookup metadata.google.internal

      Le résultat doit ressembler à ce qui suit :

      Server:         169.254.169.254
Address:        169.254.169.254#53

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

    2. Vérifiez que le serveur de métadonnées est accessible. Pour ce faire, exécutez les commandes suivantes :

      ping -c 3 metadata.google.internal

      Le résultat doit ressembler à ce qui suit :

      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

      Le résultat doit ressembler à ce qui suit :

      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. Si le résultat des commandes précédentes correspond au résultat suggéré, votre VM est connectée au serveur de métadonnées et aucune autre action n'est requise. Si les commandes échouent, procédez comme suit :

      1. Vérifiez que le serveur de noms est configuré sur le serveur de métadonnées :

        cat /etc/resolv.conf

        Le résultat doit ressembler à ce qui suit :

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

        Si le résultat ne contient pas les lignes précédentes, consultez la documentation de votre système d'exploitation pour en savoir plus sur la modification de la règle DHCP afin de conserver la configuration du serveur de noms sur 169.254.169.254. En effet, les modifications apportées à /etc/resolv.conf sont écrasées dans une heure si les paramètres DNS zonaux sont appliqués aux VM de votre projet. Si votre projet utilise toujours un DNS global, le fichier resolv.conf sera rétabli sur le DHCP par défaut dans 24 heures.

      2. Vérifiez que le mappage entre le nom de domaine du serveur de métadonnées et son adresse IP existe :

        cat /etc/hosts

        La ligne suivante doit s'afficher dans le résultat :

        169.254.169.254 metadata.google.internal  # Added by Google

        Si le résultat ne contient pas la ligne précédente, exécutez la commande suivante :

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

Windows

  1. Connectez-vous à votre VM Windows.

  2. Depuis votre VM Windows, exécutez les commandes suivantes :

    1. Interrogez le serveur de noms de domaine :

      nslookup metadata.google.internal

      Le résultat doit ressembler à ce qui suit :

      Server:  UnKnown
Address:  10.128.0.1

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

    2. Vérifiez que le serveur de métadonnées est accessible. Pour ce faire, exécutez les commandes suivantes :

      ping -n 3 metadata.google.internal

      Le résultat doit ressembler à ce qui suit :

      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

      Le résultat doit ressembler à ce qui suit :

      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. Si le résultat des commandes précédentes correspond au résultat suggéré, votre VM est connectée au serveur de métadonnées et aucune autre action n'est requise. Si les commandes échouent, procédez comme suit :

      1. Vérifiez qu'il existe une route persistante vers le serveur de métadonnées en exécutant la commande suivante :

        route print

        La sortie doit contenir les éléments suivants :

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

        Si le résultat ne contient pas la ligne précédente, ajoutez la route à l'aide des commandes suivantes :

        $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. Vérifiez que le mappage entre le nom de domaine du serveur de métadonnées et son adresse IP existe :

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

        La ligne suivante doit s'afficher dans le résultat :

        169.254.169.254 metadata.google.internal  # Added by Google

        Si le résultat ne contient pas la ligne précédente, exécutez la commande suivante :

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

Résoudre les échecs de requêtes lors de l'utilisation d'un proxy réseau

Un serveur proxy réseau empêche l'accès direct de la VM à Internet. Toutes les requêtes envoyées à partir d'une VM sont gérées par le serveur proxy à la place.

Lorsque vous utilisez une application qui obtient les identifiants du serveur de métadonnées, comme un jeton d'authentification, la VM nécessite un accès direct au serveur de métadonnées. Si la VM se trouve derrière un proxy, vous devez définir la configuration NO_PROXY pour l'adresse IP et le nom d'hôte.

Si vous ne définissez pas la configuration NO_PROXY, des erreurs peuvent se produire lors de l'exécution de commandes Google Cloud CLI ou de l'interrogation directe du serveur de métadonnées, car les appels à metadata.google.internal sont envoyés au proxy sans avoir été résolus localement sur l'instance elle-même.

Voici un exemple d'erreur possible :

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

Pour résoudre ce problème de proxy, ajoutez le nom d'hôte et l'adresse IP du serveur de métadonnées à la variable d'environnement NO_PROXY en procédant comme suit :

Linux

  1. Connectez-vous à votre VM Linux.

  2. Depuis votre VM Linux, exécutez les commandes suivantes :

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

    Pour enregistrer les modifications, exécutez la commande suivante :

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

Windows

  1. Connectez-vous à votre VM Windows.

  2. Depuis votre VM Windows, exécutez les commandes suivantes :

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

    Pour enregistrer les modifications, exécutez la commande suivante :

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

Format d'en-tête incorrect

Le serveur de métadonnées effectue des contrôles de mise en forme pour s'assurer que les en-têtes respectent la consigne de la section 3.2 du document RFC 7230. En cas d'échec du format d'en-tête, voici ce qui se produit :

  • La requête est acceptée. Toutefois, vous recevrez des recommandations indiquant que vos VM adressent des requêtes au serveur de métadonnées avec des en-têtes au format incorrect. Les recommandations sont envoyées une fois par VM. Vous pouvez accéder à ces recommandations à l'aide de Google Cloud CLI ou de l'API REST de l'outil de recommandation.

    Après avoir appliqué la recommandation, définissez son état sur succeeded.

  • À compter du 20 janvier 2024, le serveur de métadonnées refuse toute requête comportant un en-tête incorrect.

Vous trouverez ci-dessous des exemples de formats de requête d'en-tête valides et non valides.

Non valide : contient un espace entre le nom de l'en-tête et le signe deux-points

Metadata-Flavor : Google

Valide : aucun espace entre le nom de l'en-tête et deux-points, et les espaces après le signe deux-points sont ignorés par le vérificateur

Metadata-Flavor: Google

Valide : aucun espace dans l'en-tête

Metadata-Flavor:Google

Pour en savoir plus sur l'envoi de requêtes au serveur de métadonnées, consultez la section Accéder aux métadonnées de VM.