Wie behebe ich Instance-Metadatenprobleme auf meiner EC2-Linux-Instance?

Kurzbeschreibung

Amazon EC2 greift lokal über HTTP-Anforderung an den IPv4-Endpunkt 169.254.169.254 oder den IPv6-Endpunkt [fd00:ec2::254] auf Instance-Metadaten innerhalb der Instance zu. Um auf die Instance-Metadaten zuzugreifen, musst du den Instance Metadata Service (IMDS) verwenden. IMDSv1 benötigt kein Authentifizierungstoken, aber IMDSv2 benötigt ein Sitzungstoken für erhöhte Sicherheit.

Beim Abrufen von Instance-Metadaten können die folgenden Probleme auftreten:

• HTTP-Anforderungsfehler wie Timeouts und HTTP 400- oder 404-Fehler
• Fehler bei der IMDSv2-Tokenanforderung
• Softwarespezifische Probleme bei der Handhabung
• Falsch konfigurierte Netzwerk-Schnittstelle oder Routing-Tabelle
• Proxy- oder NAT-Gateway-Konfigurationen, die den Metadatenzugriff blockieren
• (nur IPv6) Ein IMDSv6-Endpunkt, der nicht aktiviert ist
• Fehlende oder veraltete Instance-Profilanhänge für AWS Identity and Access Management (IAM)
• Lokale Firewalls wie iptables oder firewalld, die den Zugriff auf 169.254.169.254 blockieren
• Hohes Anforderungsvolumen, das zu gedrosselten Metadatenanforderungen führt

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

HTTP-Anforderungsfehler beheben

Ergreife die folgenden Maßnahmen zur Problembehandlung auf der Grundlage des HTTP-Fehlermeldung, das du erhältst.

(nur IMDSv1) Fehler „404 - Not Found“

Der HTTP 404-Fehler tritt auf, wenn du eine ungültige URL eingibst oder wenn du die IAM-Rolle deiner Instance aktualisiert, die Rolle jedoch nicht aktualisiert hast.

Um diesen Fehler zu beheben, vergewissere dich, dass du die richtige URL verwendest. Trenne außerdem die IAM-Rolle der Instance und hänge sie dann erneut an.

Starte und stoppe dann die Instance, um die Änderungen zu übernehmen.

(nur IMDSv2) Fehler „400 - Bad Request“

Der HTTP 400-Fehler tritt auf, wenn die PUT-Anforderung ein ungültiges Token verwendet oder wenn die Software falsche Header sendet. Beispielsweise speichern einige FortiGate- oder Matillion-Agenten IMDSv2-Token nicht im Cache oder verwenden sie nicht wieder.

Um diesen Fehler zu beheben, führe den folgenden Befehl aus, um ein neues Token für die PUT-Anforderung zu generieren:

$ TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl

Überprüfe außerdem die System- oder Anwendungsprotokolle auf Prozesse mit langer Laufzeit, deren Token aktualisiert werden müssen.

(nur IMDSv2) Fehler „401 - Unauthorized“

Der HTTP 401-Fehler tritt auf, wenn die GET-Anforderung ein ungültiges Token verwendet.

Um diesen Fehler zu beheben, führe den folgenden Befehl aus, um ein neues Token für die GET-Anfrage zu generieren:

$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

Überprüfe außerdem die System- oder Anwendungsprotokolle auf Prozesse mit langer Laufzeit, deren Token aktualisiert werden müssen.

Fehler „403 - Forbidden“

Der HTTP 403-Fehler tritt auf, wenn du IMDS auf Instance-Ebene deaktivierst, oder wenn eine Sicherheitsgruppe, Firewall oder Routing-Tabelle den Instance-Zugriff blockiert. Der Fehler kann auch auftreten, wenn du IMDSv2 verwenden musst, der Client jedoch IMDSv1 verwendet.

Um dieses Problem zu beheben, führe den folgenden AWS-CLI-Befehl describe-instances aus, um die IMDS-Konfiguration zu überprüfen:

aws ec2 describe-instances --instance-ids your_instance_id --query 'Reservations[].Instances[].MetadataOptions'

Hinweis: Ersetze your_instance_id durch die Instance-ID.

Wenn HttpEndpoint auf disabled gesetzt ist, führe den folgenden Befehl modify-instance-metadata-options aus, um IMDS zu aktivieren:

aws ec2 modify-instance-metadata-options --instance-id your_instance_id --http-endpoint enabled

Hinweis: Ersetze your_instance_id durch die Instance-ID.

Stelle sicher, dass die Konfiguration den ausgehenden HTTP-Zugriff auf 169.254.169.254 ** (für IPv4) oder[fd00:ec2::254]** (für IPv6) von der Instance aus zulässt.

Wenn die Instance einen Proxy, eine NAT-Konfiguration, einen Load Balancer oder mehrere interne Netzwerk-Hops verwendet, empfiehlt es sich, HttpputResponseHopLimit auf 2 oder höher zu konfigurieren. Konfiguriere einen Hop-Wert, der hoch genug ist, damit die Token-Antwort die Netzwerkschichten durchqueren kann. Standardmäßig erlaubt HttpPutResponseHopLimit nur 1 Hop. Um diesen Wert zu erhöhen, führe den folgenden Befehl modify-instance-metadata-options aus:

aws ec2 modify-instance-metadata-options --instance-id your_instance_id --http-put-response-hop-limit 2

Hinweis: Ersetze your_instance_id durch die Instance-ID.

Prüfe, ob Probleme mit der Proxy-Konfiguration vorliegen

Wenn die Instance eine Proxy verwendet, um auf das Internet zuzugreifen, musst du die IMDS-IP-Adresse vom ausschließen. Wenn du dies nicht tust, erhältst du möglicherweise HTTP 403- und 404-Fehler oder Verbindungs-Timeouts.

Um die IMDS-IP-Adressen vom Proxy auszuschließen, führe den folgenden Befehl aus, um die Umgebungsvariable no_proxy festzulegen:

export no_proxy='169.254.169.254,[fd00:ec2::254]'

**Hinweis:**Einige Anwendungen, wie Matillion, Fortigate oder benutzerdefinierte Dienste, verwenden möglicherweise nicht die no_proxy-Einstellungen auf Systemebene. In diesem Szenario konfigurierst du no_proxy in der Anwendung. Achte bei einer Dual-Stack-Konfiguration darauf, sowohl die IPv4- als auch die IPv6-Metadaten-Endpunkte auszuschließen.

Stelle sicher, dass du die IPv6-Unterstützung aktiviert hast

Wenn du ein reines IPv6-Subnetz verwendest, führe den folgenden Befehl modify-instance-metadata-options aus, um die IPv6-Unterstützung für IMDS explizit zu aktivieren:

aws ec2 modify-instance-metadata-options \
  --instance-id your_instance_id \
  --http-protocol-ipv6 enabled

Hinweis: Ersetze your_instance_id durch die Instance-ID.

Wenn du die Endpunkte der Virtual Private Cloud(VPC) mit strengen Sicherheitsgruppenregeln verwendest, stelle sicher, dass diese den Zugriff über Port 80 (HTTP) auf die Metadaten-IP-Adresse zulassen.

Stelle bei Fortigate- oder Matillion-Anwendungen sicher, dass die Software IMDSv2-Sitzungstoken unterstützt.

Behebe veraltete Netzwerkkonfigurationen, veraltete IAM-Rollenzuordnungen oder interne Softwareprobleme

Starte die Instance neu.

Überprüfe deine lokalen Firewall-Regeln

Führe den folgenden Befehl aus, um zu überprüfen, ob lokale Firewall-Blöcke iptables verwenden, um den Zugriff auf den IMDS-Endpunkt zu blockieren:

sudo iptables -L

Beispielausgabe eines blockierten Endpunkts:

Chain OUTPUT (policy ACCEPT)
target     prot opt source    destination
REJECT     tcp  --  anywhere  169.254.169.254  owner UID match 1000-10000 reject-with icmp-port-unreachable

Führe den folgenden Befehl aus, um nach Regeln zu suchen, die den Datenverkehr zu 169.254.169.254 blockieren:

curl http://169.254.169.254/latest/meta-data/

Wenn eine Regel den Verkehr blockiert, erhältst du eine Ausgabe, die dem folgenden Beispiel ähnelt:

curl: (7) Failed to connect to 169.254.169.254 port 80 after 0 ms: Connection refused

Führe den folgenden Befehl aus, um die Blockierregel zu entfernen:

sudo iptables -D OUTPUT -p tcp -d 169.254.169.254 -m owner --uid-owner 1000-10000 -j REJECT

Wenn es sich bei der Instance um eine Dual-Stack-Instance handelt, stelle sicher, dass keine IPv6-Firewall-regeln die [fd00:ec2::254] IPv4-Adresse blockieren. Wenn deine iptables leer sind, aber der Datenverkehr immer noch blockiert ist, überprüfe die Firewall-Daemons des Betriebssystems (OS) wie firewalld oder ufw. Suche auch nach Sicherheitsagenten wie Antiviren- oder Firewall-Software, die möglicherweise versteckte Regeln durchsetzen.

Prüfe, ob Amazon EC2 die Anfrage gedrosselt hat

Amazon EC2 drosselt den Datenverkehr zum IMDS auf der Grundlage der Anzahl der Pakete pro Sekunde (PPS). Jede Elastic Netzwork-Schnittstelle, die mit der Instance verbunden ist, hat ein maximales Kontingent von 1024 PPS für metadatenbezogenen Verkehr. Wenn die PPS-Rate dieses Kontingent überschreitet, erhältst du die Fehlermeldung „HTTP 5xx“, der Metadatenabruf schlägt fehl oder die Anwendung läuft ab.

Gehe wie folgt vor, um diese Drosselungs-Probleme zu minimieren:

• Implementiere eine exponentielle Backoff- und Wiederholungslogik in der Anwendung, wenn du auf IMDS zugreifst.
• Erkundige dich bei dem Anbieter oder aktualisiere die Software auf die neueste Version, um sicherzustellen, dass sie IMDSv2 unterstützt.
• Wenn du IMDSv2 verwendest, generiere ein Token einmal und verwende es während der Time-to-Live (TTL) für mehrere Metadatenabfragen wieder.
• Führe ein Upgrade auf die neueste IMDSv2-Version durch, um sicherzustellen, dass die Konfiguration die Wiederverwendung von Token und exponentielles Backoff korrekt implementiert.
• Frage Instance-Metadaten nicht häufig ab.
• Verwende Instance-Caching in der Anwendung, wo immer dies möglich ist.

Wenn die Software Metadatenanfragen in einer engen Schleife ohne Verzögerung überflutet, kann es zu Drosselungs- oder Metadatenfehlern kommen. Verwende tcpdump-, strace- oder app debug-Protokolle, um nach häufigen wiederholten Aufrufen an 169.254.169.254 zu suchen. Um Drosselungsereignisse zu überwachen, führe den folgenden Befehl aus, um den Netzwerkschnittstellentreiber auf die Metrik linklocal_allowance_exceeded zu überprüfen:

ethtool -S eth0

Hinweis: Ersetze eth0 durch den Namen der Netzwerkschnittstelle. Überprüfe in der Ausgabe linklocal_allowance_exceeded auf einen Wert, der nicht 0 ist, um eine Drosselung zu identifizieren.

Beispielausgabe:

linklocal_allowance_exceeded: 245

Die vorherige Beispielausgabe zeigt, dass Amazon EC2 245 Pakete an IMDS gedrosselt hat, weil ein PPS-Kontingent überschritten wurde.

Ähnliche Informationen

Verwendung eines Proxys auf Amazon EC2-Instances

Zugriff auf Instance-Metadaten für eine EC2-Instance

Beschränke den Zugriff auf den Instance-Metadatendienst

Drosselung von Abfragen