Was ist das Besondere an der IP-Adresse 169.254.169.254 für AWS? [geschlossen]


76

Diese IP scheint einen Dienst auszuführen, der viele nützliche Metadaten für meine Instanz bereitstellt , aber ich frage mich, warum 169.254.169.254 ? Was ist das Besondere an dieser IP-Adresse? Und ich frage mich auch, ob ich aufgrund der Tatsache, dass diese IP von diesem Dienst belegt ist, die Möglichkeit verpasse, eine Verbindung zu einem Server mit dieser IP im Internet herzustellen?


Antworten:


139

169.254.169.254 ist eine IP-Adresse aus dem reservierten lokalen IPv4-Link- Adressraum 169.254.0.0/16 (169.254.0.0 bis 169.254.255.255). Ähnlich wie bei den privaten Adressbereichen in RFC-1918 (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16) in dem Sinne, dass dieser Block auch nicht im Internet verwendet werden kann, ist Link Local weiter Sie sind nur über einen Router erreichbar¹ - sie sind standardmäßig nur im direkt verbundenen Netzwerk vorhanden.

AWS musste einen Service-Endpunkt erstellen, auf den von jedem System aus zugegriffen werden kann, und die Auswahl einer Adresse in diesem Block führt zu Konflikten mit keinem häufig verwendeten IP-Adressraum. Kluge Wahl.

Vermutlich wurde diese spezifische Adresse innerhalb des Blocks aufgrund ihrer Ästhetik oder ihrer leichten Erinnerung ausgewählt.


Lustige Tatsache! Die benachbarte Adresse 169.254.169.25 3 ist ein DNS-Resolver in VPC zusätzlich zu der Adresse , die Sie wahrscheinlich bei Offset 2 von der Basis Ihres VPC-Supernets kennen. Dies ist sehr praktisch, um Software zu konfigurieren, die unabhängig vom Betriebssystem (wie HAProxy) eigene DNS-Suchvorgänge ausführt, sodass die DNS-Resolver-Konfiguration in der Software nicht geändert werden muss, wenn sie in verschiedenen VPCs bereitgestellt wird. Es gibt keinen dokumentierten Grund zu der Annahme, dass diese Adresse einen "anderen" Resolver darstellt als die in Ihrem Adressblock, sondern nur eine andere Art, auf dasselbe zuzugreifen.


Aber warte, da ist noch mehr! 169.254.169. 123 bietet eine Stratum-3-NTP-Zeitquelle, mit der Instanzen ihre Systemuhrzeit mit ntpd oder chrony über den Amazon Time Sync Service verwalten können, ohne dass ein Internetzugang erforderlich ist . Dieser Dienst verwendet auch die Schaltsekundenlogik von Amazon, um Schaltsekunden über den Tag zu verteilen, an dem sie auftreten, anstatt die Uhr von 23:59:59 auf 23:59:60 auf 00:00:00 zu stellen, was problematisch sein kann.


¹ Über einen Router nicht erreichbar ist in den meisten IP-Stacks keine harte Einschränkung, da lokale Verbindungsadressen Gegenstand einer statischen Route sein können, diese Adressen jedoch im Allgemeinen nicht als routingfähig angesehen werden.


3
> Vom Betriebssystem unabhängige DNS-Lookups (wie HAProxy) Genau mein Anwendungsfall!
Rory Hart

Um zu verdeutlichen , dass es nichts AWS-spezifisches ist, Dokumente von einigen anderen Cloud-Anbietern: Vultr ; Digital Ocean ; Azure ; (Google verwendet metadata.google.internal, von dem ich vermute, dass es sich um dasselbe handelt, aber ich verwende es nicht, kann es also nicht überprüfen.)
OJFord

1
@OJFord ist korrekt, metadata.google.internal wird in 169.254.169.254 aufgelöst. Außerdem ist der zurückgegebene Wert für api metadata.google.internal / computeMetadata / v1 / instance /… tatsächlich 169.254.169.254
rupert160

2
@ Rupert160 ja, aber die ursprüngliche Frage war über AWS. Soweit ich weiß, folgten alle anderen Cloud-Anbieter dem von AWS festgelegten Beispiel bei der Verwendung dieser bestimmten Adresse, die keine eigentliche Bedeutung hat. Das Kopieren von AWS wurde in anderen Fällen durchgeführt, z. B. bei Google Cloud Storage, dessen XML-API mit S3 so "kompatibel" ist, dass die GCS-Dokumentation zum "Migrieren" ein Beispiel für das Signieren von Anforderungen einschließlich des Bereichs für Anmeldeinformationen enthält 20190301/us-east-1/s3/aws4_request.
Michael - sqlbot
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.