Уникальный IP адрес для дочерней платы

Question

[qehgt]

Коллеги, подскажите.

Есть устройство (назовём его «А»), которое работает в интранете, свой IP получает по DHCP.

Следующая версия этого устройства будет содержать дополнительный модуль (назовём его «В») — дочерняя плата, со свой собственной ОС. Связь между «А» и «В» будет происходить по TPC/IP, через дополнительный сетевой интерфейс. Устройству «В» никакой связи с ЛВС не нужно, желательно чтобы они вообще друг друга не видели.

Вопрос — как правильно назначать IP адрес для устройства «В»? Статически? Но где гарантия что этот адрес никогда не пересечётся с адресом в ЛВС? Динамически? А как именно?

Answer 1

[4dmonster]

Почитав ответы и комменты к ним, рискну предложить ещё варианты:
1. Когда настраиваимый по DHCP интерфейс не получает ответов, он присваивает себе адрес типа 169.254.X.Y, где X.Y — вычисляются по какомо-ту алгоритму от MAC адреса.

2. IPv6

3. Ну и в качестве мозгового штурма: попробуйте назначить ему такой адрес 127.0.0. 2. И настроить маршруты, вдруг взлетит.

Comments

[qehgt]

О, спасибо большое. Link-local address 169.254/16 — это, похоже, именно то, что нам надо.

[pietrovich]

Если использовать 169.254.x.x, то есть риск столкнуться с похожим адресом у девайся «А», когда DHCP упадет. Попробуйте посмотреть на 172.x.x.x сеть. Еще ни разу не видел чтобы ее кто-нибудь использовал во внутренних сетях ;)

[4dmonster]

Они перед самоназначением его самопроверяют.
А сети 172.x.x.x я дважды(если память не подводит) у провайдеров встречал.

[Владимир Дубровин]

169.254 можно использовать только при выполнении всех условий:
1. «внешний» интерфейс всегда подключен или при его переподключении сбрасывается внутренний интерфейс
2. на внешнем интерфейсе имеется возможность поднять ARP-прокси, которая будет отвечать адресом внутреннего интерфейса, чтобы ни одно другое устройство не село на тот же адрес.
3. для адреса назначаемому внутреннему интерфейсу будут производиться проверки предусмотренные RFC 3927, чтобы убедиться, что он не занят.

И все равно это не гарантирует ничего, т.к. amazon используется эту сеть для своих серверов, например.

Answer 2

[Andrew1000000]

Адреса не пересекутся, если два интерфейса, подключённые к А, будут иметь разные подсети. Соответственно, интерфейс, подключённый к интернету, получает данные о подсети автоматически. Нужно их посмотреть и для другого интерфейса назначить другую подсеть. Если напишете, какая ОС, думаю, будут конкретные инструкции.

Comments

[qehgt]

Т.е. надо анализировать, находимся ли (например) мы в подсети 10.x.x.x — и выбирать для «В» адрес из 192.168.x.x. Так?
ОС — линукс, только это ж не важно.

[Andrew1000000]

Обычно настройки локальной сети (подсеть) не так часто меняются. Т. е. можно просто посмотреть, что в локальной сети адреса 10.х.х.х и для устойства В назначать адрес из 192.168.х.х. А админа попросить, чтобы он предупредил, когда будет менять настройки сети.

[qehgt]

Устройство продаётся и дальше работает у клиента. Надо сделать так, чтобы было минимум (т.е. вообще не было в идеале) каких-либо дополнительный действий со стороны админов у клиента.

[Владимир Дубровин]

Знаю несколько крупных интернет-провайдеров, использующих 10.0.0.0/8 для клиентов, 192.168.0.0/16 для оборудования и 172.22.16.0/20 для собственной внутренней сети.

Answer 3

[SysCat]

Или можно в DHCP назначить резервирование по MAC адресу или добавить в диапазон не выдаваемых адресов.

Comments

[qehgt]

Нет, устройство «В» с интранетом связи иметь не должно (не желательно, вернее). Соответственно, и интранетовский DHCP оно не увидит.

Answer 4

[Евгений Яблоков]

Да и вовсе, если известен пул, из которого вдаются адреса из DHCP, миновать его при выдаче адрес «B».

Comments

[qehgt]

Пул заранее не известен и у разных клиентов — разный. Интересует есть ли простое и гарантированно работающее решение, подходящее к любой конфигурации интранета у клиента.

Answer 5

[Джок Таннер]

При старте генерировать случайную подсеть /30 в глобальном пространстве адресов. Если устройство будет работать в интрасети, то 100% ничего не пересечётся. Если устройство перенесут в Интернет, то вероятность косяка в маршрутизации чуть больше, чем 1:1000000000, и даже если косяк возникнет, то он легко решится перезапуском девайса.

Answer 6

[Владимир Дубровин]

Единственное корректное решение для IPv4, гарантирующее отсутствие конфликтов — зарегистрировать под это дело PI-сеть через RIPE и выделить /30 из этой сети.
www.ripe.net/ripe/docs/ripe-524#8
Из недостатков — ежегодная плата.

Comments

[qehgt]

Хм… Покупать диапазон для внутреннего IP адреса, который, вообще-то, никто видеть не должен? Спасибо, не надо.

[Владимир Дубровин]

А тогда не парьтесь и делайте проще — берите любую приватную сетку, например 10ю, назначайте оттуда диапазон, документируйте и давайте возможность поменять — так поступают даже достаточно крупные производители, тот же Microsoft для настроек удаленного доступа в отсутствии DHCP. А вот 169.254 для таких целей не годится, не должно быть двух сегментов где используются эти адреса.

[Владимир Дубровин]

Но вообще-то не так это дорого. Если вы в хороших отношениях с провайдером, имеющим собственный LIR — то может быть и вообще бесплатно. Если через посредников, на этом специализирующихся — порядка $200/год за блок адресов.

Answer 7

[gescheit]

А чем вариант с IPv6 не подходит? link-local адреса будут зависеть от мака и вряд-ли пересекутся.

Comments

[Владимир Дубровин]

Чтобы MAC не пересекся, строго говоря, тоже надо OUI регистрировать.

[gescheit]

Думаете они производят ethernet порты и не имеют собственного OUI?

[Владимир Дубровин]

Судя по описанному, это скорее готовая писишная платформа, у которой мак-адрес физического интерфейса будет или от производителя материнки или от broadcom/marvel. Решение без регистрации OUI есть — купить две сетевых карты, взять их MACи после чего торжественно запереть в сейф. Но как-то это не по-промышленному, использовать чужой OUI.