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

Résoudre les problèmes liés aux codes de serveur

Les codes de serveur suivants sont renvoyés lorsque vous effectuez des appels au serveur de métadonnées Compute Engine. Consultez cette section pour savoir comment répondre à chaque code de serveur renvoyé par le serveur de métadonnées.

Codes de serveur courants

Ces codes de serveur sont fréquemment renvoyés par le serveur de métadonnées.

Code du serveur Description Solution
200 OK : la demande a été acceptée. N/A
400 Requête incorrecte : ce code d'état d'erreur est renvoyé dans de nombreux cas différents, par exemple lorsqu'une requête comporte des paramètres de requête incorrects ou que les exigences de ce point de terminaison n'ont pas été respectées. Consultez le message d'erreur pour obtenir des suggestions sur la façon de le corriger.
403 Interdit : cet état d'erreur est renvoyé dans les scénarios suivants :
  • Le point de terminaison demandé est désactivé par les paramètres du projet ou des instances
  • La requête échoue aux contrôles de sécurité. Ce problème peut se produire si votre connexion TCP au serveur a été fermée au niveau de la couche réseau.
 Vérifiez les paramètres de votre projet et de votre instance pour vous assurer que le point de terminaison est activé, ou vérifiez la configuration de votre réseau.
404 Introuvable : le point de terminaison demandé n'existe pas. Corriger le chemin d'accès de la requête
429 Nombre de requêtes trop élevé : cela se produit, car certains points de terminaison utilisent une limitation du débit pour éviter de surcharger le service sous-jacent. Nous vous recommandons vivement d'réessayer avec un intervalle exponentiel entre les tentatives. Pour en savoir plus, consultez la liste des points de terminaison soumis à une limite de débit. Patientez quelques secondes, puis réessayez d'appeler.
503 Service indisponible : le serveur de métadonnées n'est pas prêt à répondre aux requêtes. Le serveur de métadonnées peut renvoyer le code d'état Error 503 dans les cas suivants :
  • Le serveur de métadonnées est toujours en cours de démarrage
  • Le serveur de métadonnées est en cours de migration
  • Le serveur de métadonnées est temporairement indisponible.
  • La machine hôte effectue un événement de maintenance.
  • Le serveur de métadonnées peut renvoyer un code 503 lorsque certains points de terminaison sont soumis à une limitation du débit.
 Les erreurs 503 sont temporaires et devraient se résoudre au bout de quelques secondes au maximum. Pour résoudre le problème, patientez quelques secondes, puis réessayez d'appeler.

Codes serveur rares

Ces codes de serveur, bien que rares, peuvent également être renvoyés par le serveur de métadonnées.

Code du serveur Description Solution
301 Moved Permanently : fourni pour les chemins d'accès qui ont des redirections Mettre à jour le chemin de la requête
405 Non autorisé : ce code d'erreur est renvoyé si une méthode non compatible est demandée.

Le serveur de métadonnées n'accepte que les opérations GET, à l'exception des métadonnées accessibles en écriture par les invités, qui autorisent les opérations SET.		 Mettre à jour la méthode dans le chemin de la requête

Codes d'erreur des points de terminaison avec débit limité

Les points de terminaison suivants sont soumis à une limitation du débit et peuvent renvoyer des codes d'erreur. Pour gérer ces codes d'erreur renvoyés, consultez Conseils pour les nouvelles tentatives.

Point de terminaison Code d'état Description
oslogin/ 429 Les limites de débit d'OS Login sont partagées entre les requêtes d'utilisateur, d'autorisation et de groupe.
instance/service-accounts/identity 429 Le point de terminaison de signature d'identité renvoie le code de réponse 429 pour indiquer une réponse limitée en termes de fréquence.
instance/service-accounts/default/token 429 Les jetons mis en cache sur le serveur de métadonnées ne sont pas soumis à une limite de débit. Les jetons non mis en cache sont soumis à une limitation du débit.
instance/guest-attributes/ 429, 503 Les requêtes d'attributs d'invité peuvent être limitées si vous dépassez 3 RPS ou 10 requêtes par minute. En cas de limitation du débit, les codes d'erreur 429 ou 503 sont renvoyés.

Redémarrer l'assistance guidée

Le serveur de métadonnées renvoie régulièrement les codes d'erreur 503 et 429. Pour rendre vos applications résilientes, nous vous recommandons d'implémenter une logique de nouvelle tentative pour les applications qui interrogent le serveur de métadonnées. Nous vous suggérons également d'implémenter un intervalle exponentiel entre les tentatives dans vos scripts pour tenir compte de toute limitation du débit possible.

Résoudre les échecs de requêtes adressé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

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 pour les VM utilisant IPv4 :

      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 vous utilisez une instance IPv6 uniquement, vérifiez que le serveur de métadonnées IPv6 est accessible. Pour ce faire, exécutez la commande suivante :

      ping -c 3 fd20:ce::254

      Le résultat doit ressembler à ce qui suit :

      PING fd20:ce::254(fd20:ce::254) 56 data bytes
64 bytes from fd20:ce::254: icmp_seq=1 ttl=255 time=1.11 ms

    4. 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. Si les paramètres DNS zonaux sont appliqués aux VM de votre projet, les modifications apportées à /etc/resolv.conf sont écrasées dans une heure. Si votre projet utilise toujours un DNS global, le fichier resolv.conf est 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 169.254.169.254 with 32 bytes of data:
Reply from 169.254.169.254: bytes=32 time=1ms TTL=255

    3. Si votre VM dispose d'une adresse IPv6, vérifiez qu'une instance IPv6 uniquement est accessible. Pour ce faire, exécutez la commande suivante :

      ping -n 3 fd20:ce::254

      Le résultat doit ressembler à ce qui suit pour les VM IPv6 :

      Pinging fd20:ce::254 with 32 bytes of data:
Reply from fd20:ce::254: bytes=32 time=1ms TTL=255

    4. 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,fd20:ce::254,metadata,metadata.google.internal

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

    echo no_proxy=169.254.169.254,fd20:ce::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,fd20:ce::254,metadata,metadata.google.internal

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

    setx NO_PROXY 169.254.169.254,fd20:ce::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 aborde 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 est introuvable 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 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 l'emplacement des certificats, consultez 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"

Résoudre les problèmes de 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.

Résoudre les problèmes d'obtention de jeton

L'une des erreurs suivantes peut s'afficher lorsque vous interrogez le serveur de métadonnées :

  • ERROR: gcloud crashed (MetadataServerException): HTTP Error 401: Unauthorized
  • curl: (22) The requested URL returned error: 401

Ces erreurs peuvent se produire si le compte de service associé à la VM est désactivé. Pour résoudre ces erreurs, activez le compte de service ou associez un autre compte de service.