Fehlerbehebung bei Zugriffsproblemen mit Metadatenserver

In diesem Dokument wird beschrieben, wie Sie Probleme mit dem Compute Engine-Metadatenserver beheben.

Compute Engine-VMs speichern Metadaten auf einem Metadatenserver. VMs haben automatisch ohne zusätzliche Autorisierung Zugriff auf die Metadatenserver API. Manchmal können VMs jedoch aus einem der folgenden Gründe keinen Zugriff mehr auf den Metadatenserver haben:

  • Fehler beim Auflösen des Metadatenserver-Domainnamens
  • Die Verbindung zum Metadatenserver wird durch einen der folgenden Schritte blockiert:
    • Firewallkonfiguration auf Betriebssystemebene
    • Proxy-Einrichtung
    • Benutzerdefiniertes Routing

Wenn VMs nicht auf den Metadatenserver zugreifen können, funktionieren möglicherweise einige Prozesse nicht.

Informationen zur Fehlerbehebung bei gke-metadata-server finden Sie unter Fehlerbehebung bei GKE-Authentifizierungsproblemen.

Hinweise

  • Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud -Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren.
    <x0A>

    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. After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      2. Set a default region and zone.

        3. REST

        Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.

          After installing the Google Cloud CLI, initialize it by running the following command: 

          gcloud init

          If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

        Weitere Informationen finden Sie in der Dokumentation zur Google Cloud -Authentifizierung unter Für die Verwendung von REST authentifizieren.

Probleme mit Servercodes beheben

Die folgenden Servercodes werden zurückgegeben, wenn Sie Aufrufe an den Compute Engine-Metadatenserver senden. In diesem Abschnitt erfahren Sie, wie Sie auf die einzelnen Servercodes reagieren, die vom Metadatenserver zurückgegeben werden.

Häufige Servercodes

Diese Servercodes werden häufig vom Metadatenserver zurückgegeben.

Server code Beschreibung Lösung
200 OK: Die Anfrage war erfolgreich. –
400 Bad Request:Dieser Fehlerstatus wird für viele verschiedene Szenarien zurückgegeben, z. B. wenn eine Anfrage falsche Abfrageparameter enthält oder die Anforderungen für diesen Endpunkt nicht erfüllt wurden. Fehlermeldung auf Vorschläge zur Behebung des Fehlers prüfen
403 Verboten:Dieser Fehlerstatus wird in den folgenden Szenarien zurückgegeben:
  • Der angeforderte Endpunkt ist durch Projekt- oder Instanzeinstellungen deaktiviert.
  • Die Anfrage besteht die Sicherheitsprüfungen nicht. Dieses Problem kann auftreten, wenn Ihre TCP-Verbindung zum Server auf der Netzwerkebene geschlossen wurde.
 Prüfen Sie die Projekt- und Instanzeinstellungen, um sicherzustellen, dass der Endpunkt aktiviert ist, oder prüfen Sie Ihre Netzwerkkonfiguration.
404 Nicht gefunden:Der angeforderte Endpunkt ist nicht vorhanden. Anfragepfad korrigieren
429 Zu viele Anfragen:Dieses Problem tritt auf, weil für einige Endpunkte eine Ratenbegrenzung verwendet wird, um eine Überlastung des zugrunde liegenden Dienstes zu verhindern. Es wird dringend empfohlen, Wiederholungsversuche mit exponentiellem Backoff zu verwenden. Weitere Informationen finden Sie in der Liste der ratenbeschränkten Endpunkte. Warten Sie einige Sekunden und versuchen Sie es dann noch einmal.
503 Dienst nicht verfügbar:Der Metadatenserver ist nicht bereit, Anfragen zu bearbeiten. Der Metadatenserver kann den Statuscode Error 503 in den folgenden Fällen zurückgeben:
  • Der Metadatenserver wird noch gestartet
  • Der Metadatenserver wird gerade migriert.
  • Der Metadatenserver ist vorübergehend nicht verfügbar.
  • Auf dem Hostcomputer wird ein Wartungsereignis ausgeführt
  • Der Metadatenserver kann 503 zurückgeben, wenn für einige Endpunkte Ratenbegrenzung erfolgt.
 503er-Fehler sind vorübergehend und sollten nach höchstens wenigen Sekunden behoben sein. Warte einige Sekunden und versuche es dann noch einmal.

Seltene Servercodes

Diese Servercodes werden zwar selten, können aber auch vom Metadatenserver zurückgegeben werden.

Server code Beschreibung Lösung
301 Dauerhaft verschoben:Diese Option wird für Pfade mit Weiterleitungen bereitgestellt. Anfragepfad aktualisieren
405 Nicht zulässig:Dieser Fehlercode wird zurückgegeben, wenn eine nicht unterstützte Methode angefordert wird.

Der Metadatenserver unterstützt nur GET-Vorgänge, mit Ausnahme von Metadaten, die vom Gast geschrieben werden können. Diese ermöglichen SET-Vorgänge.		 Methode in Ihrem Anfragepfad aktualisieren

Fehlercodes für Endpunkte mit Ratenbegrenzung

Für die folgenden Endpunkte gilt eine Ratenbegrenzung und sie geben möglicherweise Fehlercodes zurück. Informationen zum Umgang mit diesen zurückgegebenen Fehlercodes finden Sie unter Anleitung für Wiederholungsversuche.

Endpunkt Statuscode Beschreibung
oslogin/ 429 Die Ratenbegrenzungen für OS Login gelten für Nutzer-, Autorisierungs- und Gruppenanfragen.
instance/service-accounts/identity 503 Der Endpunkt für die Identitätssignierung gibt möglicherweise die Antwortcodes 429 oder 503 zurück, um eine Antwort mit Ratenbegrenzung anzugeben.
instance/service-accounts/default/token 429 Für im Metadatenserver im Cache gespeicherte Tokens gilt keine Ratenbegrenzung. Für nicht im Cache gespeicherte Tokens gilt eine Ratenbegrenzung.
instance/guest-attributes/ 429, 503 Anfragen für Gastattribute werden möglicherweise gedrosselt, wenn Sie 3 QPS oder 10 QPM überschreiten. Wenn die Anfragen gedrosselt werden, werden die Fehlercodes 429 oder 503 zurückgegeben.

Anleitung für Wiederholungsversuche

Der Metadatenserver gibt regelmäßig die Fehlercodes 503 und 429 zurück. Damit Ihre Anwendungen stabil sind, empfehlen wir, eine Wiederholungslogik für Anwendungen zu implementieren, die den Metadatenserver abfragen. Wir empfehlen außerdem, in Ihren Skripten exponentiellen Backoff zu implementieren, um möglichen Ratenbeschränkungen Rechnung zu tragen.

Fehlerbehebung bei fehlgeschlagenen Anfragen an den Metadatenserver

Die folgenden Beispiele können auftreten, wenn Ihre VM den Metadatenserver nicht erreicht:

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

Wenn Ihre VM den Zugriff auf den Metadatenserver verloren hat, gehen Sie so vor:

Linux

  1. Stellen Sie eine Verbindung zu Ihrer Linux-VM her.

  2. Führen Sie auf Ihrer Linux-VM die folgenden Befehle aus, um die Verbindung zum Metadatenserver zu testen:

    1. Fragen Sie den Domain Name Server ab:

      nslookup metadata.google.internal

      Die Ausgabe sollte in etwa so aussehen:

      Server:         169.254.169.254
Address:        169.254.169.254#53

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

    2. Prüfen Sie, ob der Metadatenserver erreichbar ist. Überprüfen Sie das Ergebnis mit folgenden Befehlen:

      ping -c 3 metadata.google.internal

      Die Ausgabe sollte in etwa so aussehen:

      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

      Die Ausgabe sollte in etwa so aussehen:

      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. Wenn die Ausgabe der vorherigen Befehle mit der vorgeschlagenen Ausgabe übereinstimmt, ist Ihre VM mit dem Metadatenserver verbunden und es sind keine weiteren Maßnahmen erforderlich. Wenn die Befehle fehlschlagen, gehen Sie so vor:

      1. Überprüfen Sie, ob der Nameserver für den Metadatenserver konfiguriert ist:

        cat /etc/resolv.conf

        Die Ausgabe sollte in etwa so aussehen:

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

        Wenn die Ausgabe nicht die vorherigen Zeilen enthält, finden Sie in der Dokumentation Ihres Betriebssystems Informationen zum Bearbeiten der DHCP-Richtlinie, um die Nameserver-Konfiguration auf 169.254.169.254 zu setzen. Dies liegt daran, dass Änderungen an /etc/resolv.conf in einer Stunde überschrieben werden, wenn die zonalen DNS-Einstellungen auf die VMs in Ihrem Projekt angewendet werden. Falls Ihr Projekt noch ein globales DNS verwendet, wird die Datei resolv.conf in 24 Stunden auf das Standard-DHCP zurückgesetzt.

      2. Prüfen Sie, ob die Zuordnung zwischen dem Domainnamen des Metadatenservers und seiner IP-Adresse vorhanden ist:

        cat /etc/hosts

        Die folgende Zeile sollte in der Ausgabe angezeigt werden:

        169.254.169.254 metadata.google.internal  # Added by Google

        Wenn die Ausgabe nicht die vorherige Zeile hat, führen Sie den folgenden Befehl aus:

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

Windows

  1. Stellen Sie eine Verbindung zu Ihrer Windows-VM her.

  2. Führen Sie in Ihrer Windows-VM die folgenden Befehle aus:

    1. Fragen Sie den Domain Name Server ab:

      nslookup metadata.google.internal

      Die Ausgabe sollte in etwa so aussehen:

      Server:  UnKnown
Address:  10.128.0.1

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

    2. Prüfen Sie, ob der Metadatenserver erreichbar ist. Überprüfen Sie das Ergebnis mit folgenden Befehlen:

      ping -n 3 metadata.google.internal

      Die Ausgabe sollte in etwa so aussehen: 

      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

      Die Ausgabe sollte in etwa so aussehen:

      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. Wenn die Ausgabe der vorherigen Befehle mit der vorgeschlagenen Ausgabe übereinstimmt, ist Ihre VM mit dem Metadatenserver verbunden und es sind keine weiteren Maßnahmen erforderlich. Wenn die Befehle fehlschlagen, gehen Sie so vor:

      1. Überprüfen Sie mit folgendem Befehl, ob eine persistente Route zum Metadatenserver vorhanden ist:

        route print

        Die Ausgabe sollte Folgendes enthalten:

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

        Wenn die Ausgabe nicht die vorherige Zeile hat, fügen Sie die Route mit den folgenden Befehlen hinzu:

        $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. Prüfen Sie, ob die Zuordnung zwischen dem Domainnamen des Metadatenservers und seiner IP-Adresse vorhanden ist:

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

        Die folgende Zeile sollte in der Ausgabe angezeigt werden:

        169.254.169.254 metadata.google.internal  # Added by Google

        Wenn die Ausgabe nicht die vorherige Zeile hat, führen Sie den folgenden Befehl aus:

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

Fehlerbehebung bei fehlgeschlagenen Anfragen bei der Verwendung eines Netzwerkproxys

Ein Netzwerk-Proxyserver verhindert den direkten Zugriff der VM auf das Internet. Alle innerhalb einer VM gesendeten Abfragen werden stattdessen vom Proxyserver verarbeitet.

Wenn Sie eine Anwendung verwenden, die Anmeldedaten vom Metadatenserver abruft, z. B. ein Authentifizierungstoken, benötigt die VM direkten Zugriff auf den Metadatenserver. Wenn sich die VM hinter einem Proxy befindet, müssen Sie die Konfiguration NO_PROXY sowohl für die IP-Adresse als auch für den Hostnamen festlegen.

Wenn Sie die NO_PROXY-Konfiguration nicht einrichten, kann es zu Fehlern kommen, wenn Sie Google Cloud CLI-Befehle ausführen oder den Metadatenserver direkt abfragen, da die Aufrufe an metadata.google.internal an den Proxy gesendet werden, ohne sie lokal auf der Instanz selbst aufzulösen.

Das folgende Beispiel zeigt einen möglichen Fehler:

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

Fügen Sie der Umgebungsvariable NO_PROXY den Hostnamen und die IP-Adresse des Metadatenservers hinzu, um dieses Proxyproblem zu beheben:

Linux

  1. Stellen Sie eine Verbindung zu Ihrer Linux-VM her.

  2. Führen Sie in Ihrer Linux-VM die folgenden Befehle aus:

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

    Führen Sie den folgenden Befehl aus, um die Änderungen zu speichern:

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

Windows

  1. Stellen Sie eine Verbindung zu Ihrer Windows-VM her.

  2. Führen Sie in Ihrer Windows-VM die folgenden Befehle aus:

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

    Führen Sie den folgenden Befehl aus, um die Änderungen zu speichern:

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

Fehlerbehebung bei fehlgeschlagenen Anfragen an den HTTPS-Metadatenserver-Endpunkt

In diesem Abschnitt werden einige der Fehler beschrieben, die bei der Abfrage des HTTPS-Metadatenserver-Endpunkts auftreten können.

Die in diesem Abschnitt aufgeführten Fehler werden zurückgegeben, wenn Sie eine Abfrage mit dem cURL-Tool ausführen. Die zurückgegebene Fehlermeldung ist jedoch für andere Tools ähnlich.

Falsches Clientzertifikat

Die folgenden Fehler treten auf, wenn Sie einen falschen Wert für das Flag -E angeben.

  • 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

Geben Sie den korrekten Pfad zum Client-Identitätszertifikat an, um dieses Problem zu beheben. Informationen zum Speicherort von Zertifikaten für die Clientidentität finden Sie unter Zertifikate für die Clientidentität.

Falscher Hostname

Der folgende Fehler tritt auf, wenn der Hostname, der für den Zugriff auf den Metadatenserver verwendet wird, im Zertifikat nicht gefunden wird.

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

Prüfen Sie zur Behebung dieses Problems, ob die Stamm-URL oder der Hostname in Ihrer Abfrage metadata.google.internal ist. Weitere Informationen zur Stamm-URL für den Metadatenserver finden Sie unter Bestandteile einer Metadatenanfrage.

Falsches Stamm- oder Clientzertifikat

Wenn Sie den HTTPS-Metadatenserver-Endpunkt abfragen, wird möglicherweise der folgende Fehler angezeigt:

curl: (77) error setting certificate verify locations:

Dies kann in den folgenden Fällen passieren:

  • Der Pfad für das --cacert-Flag ist möglicherweise falsch formatiert
  • Das Root-Zertifikat fehlt möglicherweise im Truststore.

Um dieses Problem zu beheben, müssen Sie beim Abfragen des HTTPS-Endpunkts sowohl das Stammzertifikat als auch das Clientzertifikat angeben. Informationen zu Speicherorten von Zertifikaten finden Sie unter Wo werden Zertifikate gespeichert?

Führen Sie beispielsweise die folgende Abfrage aus, um das Boot-Image für eine VM abzufragen:

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"

Fehlerbehebung bei falschem Header-Format

Der Metadatenserver führt Formatierungsprüfungen durch, um sicherzustellen, dass die Header der Header-Formatierungsrichtlinie RFC 7230, Abschnitt 3.2 entsprechen. Wenn das Headerformat diese Prüfungen nicht besteht, passiert Folgendes:

  • Die Anfrage wird akzeptiert. Sie erhalten jedoch Empfehlungen, dass VMs Anfragen mit falsch formatierten Headern an den Metadatenserver senden. Empfehlungen werden einmal pro VM gesendet. Sie können über die Google Cloud CLI oder die Recommender REST API auf diese Empfehlungen zugreifen.

    Nachdem Sie die Empfehlung übernommen haben, setzen Sie den Empfehlungsstatus auf succeeded.

  • Ab dem 20. Januar 2024 lehnt der Metadatenserver jede Anfrage mit einem falsch formatierten Header ab.

Im Folgenden finden Sie Beispiele für gültige und ungültige Header-Anfrageformate.

Nicht gültig: enthält Leerzeichen zwischen dem Headernamen und dem Doppelpunkt

Metadata-Flavor : Google

Gültig: Zwischen dem Headernamen und dem Doppelpunkt sind keine Leerzeichen vorhanden. Leerzeichen nach dem Doppelpunkt werden von der Prüfung ignoriert.

Metadata-Flavor: Google

Gültig: die Kopfzeile enthält keine Leerzeichen

Metadata-Flavor:Google

Weitere Informationen zum Abfragen des Metadatenservers finden Sie unter Auf VM-Metadaten zugreifen.

Fehlerbehebung beim Abrufen von Tokens

Wenn Sie den Metadatenserver abfragen, wird möglicherweise einer der folgenden Fehler angezeigt:

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

Diese Fehler können auftreten, wenn das Dienstkonto, das an die VM angehängt ist, deaktiviert ist. Um diese Fehler zu beheben, aktivieren Sie das Dienstkonto oder hängen Sie ein anderes Dienstkonto an.