Должен ли я использовать локальные адреса, для которых требуется внутренний IP-адрес без маршрутизации?

11

У меня есть сетевое устройство, которое содержит некоторые функции балансировки нагрузки - в моем дизайне эти функции предназначены только для внутреннего использования в устройстве. Ничто не должно НИКОГДА говорить с ними внешне, и, кроме того, клиенту не хватает IP-адресов в диапазоне IP-адресов устройств.

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

NB. Данное устройство не позволяет использовать петлевые IP-адреса для этих функций.

networking

— Дэн
источник

1

Если они используются только для связи от службы к службе на одном и том же хосте, есть ли причина, по которой вы бы не использовали адрес обратной связи?

— YLearn

@YLearn Честно говоря, у меня их нет, хотя я не могу избавиться от ощущения, что дело не в петлевом адресе, но, возможно, я ошибаюсь? В любом случае, я пошел протестировать его, и устройство не позволит вам ничего настраивать на петлевых IP!

— Дан

5

Нет , RFC3927 запрещает ручное назначение адресов в этом блоке.

Вместо этого вы должны использовать адрес образуют блоки , предоставляемые RFC1918 , 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16. Эти адреса могут свободно использоваться при условии, что маршруты не объявляются в интернете. Не забудьте выбрать подсеть, которая иначе не используется в вашей среде.

— 84104
источник

Поскольку вы можете не знать, какие подсети используются в среде, лучше сделать ее настраиваемой. Он мог последовать примеру многих домашних маршрутизаторов: выбрать 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, он выбирает адрес с помощью генератора псевдослучайных чисел с равномерным распределением в диапазоне от 169.254.1.0 до 169.254.254.255 включительно.

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

— 84104
источник

Почему вы предлагаете использовать два диапазона, которые 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-адресов для использования во избежание любых других непредвиденных проблем в сети.

— YLearn
источник