Чи слід використовувати локальні адреси посилань, де потрібна внутрішня IP-адреса, яка не є маршрутизованою?


11

У мене є мережевий прилад, який містить деякі функції балансування навантаження - в моїй конструкції ці функції призначені лише для використання всередині пристрою. НІКОЛИ не повинно ніколи говорити з ними зовнішньо, а крім того, клієнт мало IP-адрес у діапазоні IP пристроїв.

Чи було б прийнятним використовувати діапазон Link-Local для цих функцій? Наприклад, 169.254.1.1.

Примітка: Розглянутий пристрій забороняє використовувати IP-адреси з циклом зворотного зв'язку для цих функцій.


1
Якщо вони використовуються лише для спілкування від сервісу до сервісу в межах одного хоста, чи є якась причина, щоб ви не використовували петлю зворотної адреси?
YLearn

@YLearn Чесно кажучи, у мене насправді немає, хоча я не можу похитнути почуття, що це насправді не те, про що йдеться про петлю, але, можливо, я помиляюся? У будь-якому випадку, я пішов перевірити його, і прилад не дозволить вам нічого не налаштувати на IP-адресу з циклічним зворотним зв'язком!
Dan

Відповіді:


5

Ні , RFC3927 забороняє вручну призначати адреси в цьому блоці.

Замість цього ви повинні використовувати адресу утворюють блоки , що надаються RFC1918 , 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16. Ці адреси можна вільно використовувати, якщо маршрути не розміщуються в Інтернеті. Не забудьте вибрати підмережу, яка іншим чином не використовується у вашому оточенні.


Оскільки ви, можливо, не знаєте, які підмережі використовуються в навколишньому середовищі, найкраще зробити його налаштованим. Він міг би слідувати керівництву багатьох домашніх маршрутизаторів: вибрати 192.168.x.0/24підмережу за замовчуванням та дозволити адміністратору змінюватись x. Напевно, не повинно бути за замовчуванням 0 або 1, оскільки це звичайні параметри маршрутизаторів.
Бармар

4

Деталі RFC3927, здається, вважають це не зовсім коректно.

Так , ідіть головою. Причини, через які це заборонено , не збираються брати участь. Це набагато краще, ніж інші поширені ситуації, такі як командування 1.1.1.0/24.

Якщо ви хочете грати добре, ви можете використовувати 169.254.0.0/24або 169.254.255.0/24.

2.1. Вибір локальної адреси посилань

Коли хост хоче налаштувати локальну адресу IPv4 Link-Local, він вибирає адресу, використовуючи генератор псевдовипадкових чисел з рівномірним розподілом в діапазоні від 169.254.1.0 до 169.254.254.255 включно.

Для цього зареєстровано префікс IPv4 169.254 / 16 в IANA. Перші 256 та останні 256 адрес у префіксі 169.254 / 16 зарезервовані для подальшого використання, і НЕ МОЖЕ бути обраний хостом за допомогою цього динамічного механізму налаштування.


Чому ви б запропонували використовувати два діапазони, які IANA зарезервувала для подальшого використання? Це здається поганою порадою у випадку, якщо IANA з якихось причин вирішить використовувати ці зарезервовані діапазони.
YLearn

@YLearn Ви маєте рацію, це порушення специфікації. Однак інший варіант, що стосується цих адрес, є явним порушенням. Я відчуваю, що краще прийняти муркірський неправильний вибір.
84104

1
Отже, перефразовуючи свою відповідь та коментар, використання зарезервованих адрес - це порушення, а використання ручного призначення із створеного діапазону - порушення. Тож відповідь повинна бути "Ні, це погана ідея. Вам потрібно знайти краще рішення". Якщо люди повинні просто ігнорувати стандарти та технічні характеристики, коли їм незручно, то стандартизація, взаємодія та вся основа мереж / Інтернету піддаються ризику ..
YLearn,

Погодьтеся з @YLearn. Link-Local призначений для автоматичного присвоєння IP-адресів хосту, коли не вистачає DHCP, а не для ручної конфігурації для конкретних обставин. Вирізати шматок із діапазонів RFC1918 (навіть той, який наразі не використовується) був би єдиним допустимим варіантом.
Ешлі

3

Щоб відповісти на ваше запитання, ні ви не повинні. RFC3927 у розділі 1.6 забороняє цей тип використання.

Зокрема, останній абзац цього розділу говорить про це:

Адміністратори, які бажають налаштувати власні локальні адреси (використовуючи ручну конфігурацію, сервер DHCP або будь-який інший механізм, не описаний у цьому документі), повинні використовувати один із існуючих префіксів приватної адреси [RFC1918], а не префікс 169.254 / 16.

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

Моєю першою пропозицією було б використовувати інтерфейс із зворотним зв'язком. Інтерфейси зворотного зв'язку ідеально підходять для зв'язку між службами в межах одного хоста, які не потребують доступу поза цим хостом. Вони використовуються таким чином у ряді сервісів для інтерфейсів управління, тестування та інших цілей.

Ви сказали у своїх коментарях / редакціях, що прилад не дозволить вам цього робити. Ви не згадуєте версію постачальника / моделі чи коду, тому моя перша рекомендація - зв’язатися з продавцем. Якщо це дійсно дійсне використання пристрою, вони можуть бути готові скорегувати свій код, щоб дозволити використовувати інтерфейс зворотного зв'язку; вони, можливо, не розглядали цей випадок використання при написанні коду для перевірки IP-адрес. Або вони можуть сказати вам, чому це погана ідея і чому це слід робити іншим способом.

Якщо інтерфейс зворотного зв'язку справді не викликає сумнівів, тоді для цього слід використовувати адресний простір RFC1918 . Переконайтесь, що ви співпрацюєте з будь-яким відповідним персоналом ІТ, вибираючи діапазон IP для використання, щоб уникнути інших непередбачених проблем у мережі.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.