Що особливого у 169.254.169.254 IP-адресі для AWS? [зачинено]


80

Здається, на цій IP-адресі запущена служба, яка надає багато корисних метаданих для мого екземпляра, але мені цікаво, чому 169.254.169.254 ? Що особливого в цій IP-адресі? А також цікаво, чи факт того, що цей IP зайнятий цією службою, я втрачаю можливість підключитися до сервера з цим IP в Інтернеті?


Відповіді:


146

169.254.169.254 - це IP-адреса із зарезервованого простору місцевих адрес IPv4 Link 169.254.0.0/16 (169.254.0.0 - 169.254.255.255). Подібно до діапазонів приватних адрес у RFC-1918 (10.0.0.0/8, 172.16.0.0/12 та 192.168.0.0/16) у тому сенсі, що цей блок також не може використовуватися в Інтернеті, Link Local далі обмежені недоступністю через будь-який маршрутизатор¹ - за задумом вони існують лише у безпосередньо підключеній мережі.

AWS, необхідний для створення кінцевої точки служби, доступної з будь-якої системи, і вибір адреси в цьому блоці призводить до її конфлікту з не використовуваним простором IP-адрес. Розумний вибір.

Імовірно, ця конкретна адреса в блоці була обрана за її естетичну привабливість або її легко запам’ятати.


Смішний факт! Сусідня адреса 169.254.169.25 3 - це вирішувач DNS у VPC на додаток до тієї, з якою ви, мабуть, знайомі на відстані 2 від основи вашої супермережі VPC. Це дуже зручно для налаштування програмного забезпечення, яке робить власні пошуки DNS незалежно від ОС (наприклад, HAProxy), так що конфігурацію розв'язувача DNS у програмному забезпеченні не потрібно змінювати при розгортанні в різних VPC. Немає жодної задокументованої причини вважати, що ця адреса представляє "інший" засіб розпізнавання, ніж той, що знаходиться у вашому адресному блоці, просто інший спосіб доступу до одного і того ж.


Але почекайте, є ще! 169.254.169. 123 забезпечує джерело часу NTP stratum-3, дозволяючи екземплярам підтримувати свій системний годинник за допомогою ntpd або chrony, не вимагаючи доступу до Інтернету, від служби синхронізації часу Amazon . Ця послуга також використовує вторинну логіку Amazon для розподілу будь-яких стрибкових секунд протягом дня, коли вони відбуваються, а не годинник, що переходить з 23:59:59 до 23:59:60 до 00:00:00, що може бути проблематично.


¹ недоступність через будь-який маршрутизатор не є жорстким обмеженням для більшості стеків IP, оскільки локальні адреси посилань можуть бути предметом статичного маршруту, але ці адреси зазвичай не вважаються маршрутизуваними.


3
> Пошук DNS, незалежний від ОС (наприклад, HAProxy) Якраз мій випадок використання!
Рорі Харт,

Щоб підтвердити, що це не є специфічним для AWS, документацією від інших хмарних постачальників: Vultr ; Цифровий океан ; Блакитний ; (Google використовує те metadata.google.internal, що, як я підозрюю, вирішує те саме, але я не використовую його, тому не можу перевірити.)
OJFord,

1
@OJFord правильний, metadata.google.internal вирішує до 169.254.169.254, крім того, повертається значення api metadata.google.internal / computeMetadata / v1 / instance /… дійсно 169.254.169.254
rupert160

2
@ rupert160 так, але спочатку питання стосувалося AWS. Інші постачальники хмарних послуг, наскільки мені відомо, усі дотримувались керівних принципів, встановлених AWS, у використанні цієї конкретної адреси, яка не має внутрішнього значення. Копіювання з AWS траплялось і в інших випадках, таких як Google Cloud Storage, чий API XML настільки "сумісний" із S3, що документація "Міграції" GCS має приклад підписання запиту, включаючи область облікових даних 20190301/us-east-1/s3/aws4_request.
Майкл - sqlbot
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.