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 :

    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

      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.

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

        gcloud init

      Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud.

Erreurs de serveur

Le serveur de métadonnées peut renvoyer le code d'état Error 503 dans les cas suivants :

  • Le serveur est temporairement indisponible.
  • L'hôte effectue un événement de maintenance.

Si votre application reçoit un code d'erreur 503, relancez votre requête.

Échecs de requêtes envoyées au serveur de métadonnées

Voici des exemples d'erreurs 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

É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

Résoudre les échecs de requêtes adressées au point de terminaison du serveur de métadonnées HTTPS

Cette section décrit certaines des erreurs que vous pouvez rencontrer lorsque vous interrogez le point de terminaison du serveur de métadonnées HTTPS.

Les erreurs regroupées dans cette section sont renvoyées lorsque vous effectuez une requête à l'aide de l'outil cURL. Toutefois, le message d'erreur renvoyé est semblable pour les autres outils.

Certificat client incorrect

Les erreurs suivantes se produisent si vous fournissez une valeur incorrecte pour l'option -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

Pour résoudre ce problème, indiquez le chemin d'accès correct au certificat d'identité du client. Pour afficher l'emplacement des certificats d'identité du client, consultez la page Certificats d'identité du client.

Nom d'hôte incorrect

L'erreur suivante se produit si le nom d'hôte utilisé pour accéder au serveur de métadonnées n'est pas trouvé sur le certificat.

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

Pour résoudre ce problème, vérifiez que l'URL racine ou le nom d'hôte de votre requête est metadata.google.internal. Pour en savoir plus sur l'URL racine du serveur de métadonnées, consultez la section Composantes d'une requête de métadonnées.

Certificat racine ou client incorrect

L'erreur suivante peut s'afficher lorsque vous interrogez le point de terminaison du serveur de métadonnées HTTPS :

curl: (77) error setting certificate verify locations:

Cela peut se produire dans les scénarios suivants :

  • Le chemin d'accès de l'option --cacert est incorrect
  • Le certificat racine est manquant du magasin de confiance

Pour résoudre ce problème, vous devez spécifier à la fois le certificat racine et le certificat client lorsque vous interrogez le point de terminaison HTTPS. Pour connaître les emplacements des certificats, consultez la section Où sont stockés les certificats.

Par exemple, pour interroger l'image de démarrage d'une VM, exécutez la requête suivante :

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"

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.