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 bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

    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

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

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

        gcloud init

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

Probleme mit Servercodes beheben

Die folgenden Servercodes werden zurückgegeben, wenn Sie den Compute Engine-Metadatenserver aufrufen. In diesem Abschnitt erfährst du, wie du auf jeden Servercode reagieren solltest, der vom Metadatenserver zurückgegeben wird.

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 in vielen verschiedenen Fällen zurückgegeben, z. B. wenn eine Anfrage ungültige Abfrageparameter enthält oder die Anforderungen für diesen Endpunkt nicht erfüllt sind. In der Fehlermeldung finden Sie Vorschläge zur Behebung des Fehlers.
404 Nicht gefunden:Der angeforderte Endpunkt existiert nicht. Anfragepfad korrigieren
429 Zu viele Anfragen:Dies tritt auf, weil einige Endpunkte eine Ratenbegrenzung verwenden, um eine Überlastung des zugrunde liegenden Dienstes zu verhindern. Warten Sie einige Sekunden und wiederholen Sie den Anruf.
503 Dienst nicht verfügbar:Der Metadatenserver ist nicht bereit. Der Metadatenserver kann den Statuscode Error 503 in der folgenden Form 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
 503-Fehler sind vorübergehend und sollten nach höchstens wenigen Sekunden behoben werden. Warten Sie einige Sekunden und wiederholen Sie den Anruf.

Seltene Servercodes

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

Server code Beschreibung Lösung
301 Permanent verschoben:Dieser Status wird für Pfade mit Weiterleitungen verwendet. Anfragepfad aktualisieren
403 Forbidden:Dieser Status wird zurückgegeben, wenn der Metadatenserver der Meinung ist, dass die Anfrage nicht sicher ist. Das kann passieren, wenn Ihre TCP-Verbindung zum Server auf der Netzwerkschicht geschlossen wurde. Netzwerkkonfiguration prüfen
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 von Gästen beschreibbar sind, für die SET-Vorgänge zulässig sind.		 Methode im Anfragepfad aktualisieren

Tipps für Wiederholungsversuche

Der Metadatenserver gibt regelmäßig die Fehlercodes 503 und 429 zurück. Um Ihre Anwendungen ausfallsicher zu machen, empfehlen wir Ihnen, eine Wiederholungslogik für Anwendungen zu implementieren, die den Metadatenserver abfragen. Wir empfehlen außerdem, in Ihren Scripts ein exponentielles Backoff zu implementieren, um mögliche Ratenbeschränkungen zu berücksichtigen.

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 Formatierungsüberprüfungen durch, um sicherzustellen, dass die Header den Formatierungsrichtlinien für Header gemäß RFC 7230 Abschnitt 3.2 entsprechen. Wenn das Headerformat diese Prüfungen nicht besteht, geschieht 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 angewendet 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 Formate von Anfrageheadern.

Ungü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 vom Prüftool 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.