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 für 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.

    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.

Serverfehler

Der Metadatenserver kann den Statuscode Error 503 in der folgenden Form zurückgeben:

  • Der Server ist vorübergehend nicht verfügbar.
  • Der Host führt ein Wartungsereignis aus

Erhält Ihre Anwendung einen Fehlercode 503, wiederholen Sie die Anfrage.

Fehlgeschlagene 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

Fehlerbehebung bei fehlgeschlagenen Anfragen an den Metadatenserver

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

Fehlgeschlagene 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"

Falsches Header-Format

Der Metadatenserver führt Formatierungsprüfungen durch, um zu gewährleisten, dass Header den Richtlinien zur Headerformatierung RFC 7230 Abschnitt 3.2 entsprechen. Wenn das Header-Format 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 auf diese Empfehlungen über die Google Cloud CLI oder die Recommender REST API 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.

Die folgenden Beispiele zeigen gültige und ungültige Headeranfrageformate.

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

Metadata-Flavor : Google

Gültig: kein Leerzeichen zwischen Headername und Doppelpunkt; Leerzeichen nach dem Doppelpunkt werden vom Diagnosetool ignoriert

Metadata-Flavor: Google

Gültig: die Kopfzeile enthält keine Leerzeichen

Metadata-Flavor:Google

Weitere Informationen zu Abfragen an Metadatenserver finden Sie unter Auf VM-Metadaten zugreifen.