Лучший выбор частных адресов для «сети устройства»

8

Я создаю устройство, состоящее из нескольких подустройств, подключенных через Ethernet внутри устройства. Устройство подключится к сети клиента. Сеть клиента может использовать частные IP-адреса. Конфликт адресов с внутренней сетью будет проблемой (подустройство, подключенное к обеим сетям, будет перепутано). IPv6 не вариант.

Стоит ли покупать адреса IPv4? Или, может быть, я могу сойти с рук с помощью TEST-NET-3 (203.0.113.0/24) или что-то в этом роде? Какова лучшая практика?

networking local-area-network ip-address ipv4 rfc proski
источник
1
Потребуется ли сети клиентов прямой доступ к подустройствам или они будут подключаться к устройству только через сетевой порт типа «управление» на устройстве? Я спрашиваю, потому что EMC и другие используют частные оптоволоконные IP-коммуникации в своих сетях SAN для своих контроллеров и т. Д. С выделенным сетевым интерфейсом управления, который подключен к сети заказчика. NIC mgmt либо получает DHCP-адрес из локальной сети клиента, либо статически назначается для размещения в сети клиента.
TheCleaner
1
Нужно ли использовать стек TCP / IP для связи между вашими «подустройствами»? Если вы останетесь на втором уровне, у вас не возникнет проблем с конфликтами IP.
Jlehtinen
Клиентская сеть - это просто средство подключения к облачному сервису. Таким образом, шлюз клиента по умолчанию не должен пересекаться с внутренней сетью, иначе внешнее вспомогательное устройство будет неправильно перенаправлять пакеты. Одним из подустройств является только IPv4, другого способа управления им нет.
Проски
3
«IPv6 не вариант». У нас сейчас 2014 год. Это должен быть вариант. "Стоит ли покупать адреса IPv4?" Ну, если вы можете - в Азии они истощены, в том числе и в Европе ...
glglgl
1
Если устройства не поддерживают IPv6, я даже не буду рассматривать их покупать, потому что я бы тогда хорошо заменить их до ожидаемого срока службы устройства, с чем - то , что делает поддержку IPv6. (Ну, в любом случае, для клиентов. В моих сетях, которые уже имеют двойной стек, устройство, не поддерживающее IPv6, считается неподходящим для этой цели.)
Майкл Хэмптон,

Ответы:

10

@yoonix отправил ссылку, которая может иметь решение.

Link-local, также известный как APIPA.

169.254.0.0/16 - Это блок "link local". Как описано в RFC3927, он выделен для связи между хостами по одному каналу. Хосты получают эти адреса с помощью автоматической настройки, например, когда не удается найти DHCP-сервер.

Если бы я был вашим клиентом, я бы, конечно, захотел бы иметь возможность настроить это сам и / или использовать DHCP (который, я не знаю, может быть, давно установленный стандарт?), Но в отсутствие это именно то, для чего предполагается использовать APIPA.

Изменить. Учитывая, что теперь вы заявляете, что IP-адреса должны быть статическими для отдельных хостов в вашем решении, поскольку они будут соответствовать правилам брандмауэра на вашем устройстве шлюза, я полагаю, что вам потребуется немало усилий, чтобы эта работа работала со связью. локальная адресация IPv4; усилия, которые вы говорите, вы не будете тратить. Итак, вы по сути должны сделать это настраиваемым. Вы можете отправить его по умолчанию, который менее вероятно будет использоваться клиентом, но у вас должен быть механизм, с помощью которого он может быть изменен в случае конфликта. Либо клиентом, либо вами как частью реализации / UAT.

mfinni
источник
Устройство использует DHCP во внутренней сети для одного из подустройств ( без DHCP очень сложно настроить). Я не чувствую себя комфортно, когда DHCP-сервер раздает IP-адреса в локальном диапазоне ссылки, поскольку это явно запрещено: tools.ietf.org/html/rfc3927#section-1.6 Если нам не нужно было использовать DHCP внутри, это был бы мой первый выбор.
Проски
Нет, нет, как я прямо цитировал, APIPA (link-local) адреса - это то, что устройства будут назначать себе, если не удается найти DHCP-сервер. Я не предлагал вам использовать DHCP для назначения адресов APIPA.
mfinni
У подустройств есть определенные роли, и маршрутизатор должен настроить iptables в соответствии с этими ролями. Я не хочу, чтобы маршрутизатор обнаруживал адреса и соответственно изменял iptables. Кроме того, назначение случайных IP-адресов означает, что будут конфликты адресов, и я не уверен, что оборудование достаточно умен, чтобы разрешить их.
Проски
Прочтите это: tools.ietf.org/html/rfc3927 - все, что использует локальные ссылки, необходимо для обнаружения конфликтов.
mfinni
Я знаю это. Это никак не будет реализовано в продукте. У подустройств есть свои роли, и для них есть определенные конфигурации iptables.
Проски
5

Сделайте это настраиваемым.

Стоит ли покупать адреса IPv4?

Да. ПОПРОБУЙ ЭТО. Во-первых, вы не покупаете их, вы «арендуете» их по членству. Во-вторых, для этого требуются AS и 2 канала связи. В-третьих, для этого требуется причина, а «мы не хотим предполагать, что сетевая инфраструктура правильная» - это причина, приводящая к смеху (и отказу), а не к выделению IP-адресов.

Или, может быть, я могу сойти с рук с помощью TEST-NET-3 (203.0.113.0/24)

Возможно. До того дня, когда кто-то спросит у вас стоимость ремонта вещей из-за грубого пренебрежения.

Какова лучшая практика?

Сделайте это настраиваемым. Или используйте IPV6 - там вы можете получить некоторые оговорки.

TomTom
источник
Получение адресов IPv4 для внутреннего использования (а не маршрутизация их в Интернет) является вполне допустимым вариантом использования. К сожалению, в регионах APNIC и RIPE больше не осталось адресов IPv4, поэтому переход на IPv6 - действительно единственное решение на будущее ... Адреса ULA там кажутся хорошим вариантом.
Сандер Штеффанн
3
Это не действительный вариант использования. Не с ограниченным адресным пространством IPv4. Это то, что частные адреса для. И они не будут тратить его на компании, «не способные или не желающие следовать установленным процедурам консервации».
TomTom
Это, конечно, не правильный вариант использования сегодня, я не знаю, было ли это когда-либо. @SanderSteffann У вас есть какая-либо документация для подтверждения вашего утверждения?
mfinni
3
@ Проски ах, нет. Смотрите - адреса TEST-NET-3 предназначены для тестирования. Клиент, использующий их для тестирования, имеет действительный случай. SOmeone, отправляющие устройства, либо неосведомлены, либо умышленно игнорируют политики вокруг этих адресов, что является грубым пренебрежением. В обоих случаях.
TomTom
1
@SanderSteffann Я не знаю об APNIC, но RIPE, безусловно, имеет адреса IPv4 - около 14 миллионов из них (0,85 из / 8) в соответствии с последним обновлением статуса на их веб-сайте.
Жюль
5

  1. Из Википедии: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly.- Это говорит мне, что вы не должны использовать TEST-NET-3.

  2. Кажется, вы упускаете из виду одну вещь: как вы думаете, что вы сможете общаться с устройством или что устройство будет иметь возможность общаться с другими устройствами, и наоборот, если вы не настроите IP-адрес устройства ДЛЯ клиентской сети? Если вы назначаете IP-адрес в сети, которая не используется в клиентской сети (вы: 192.168.1.0/24 - Them: 10.0.0.0/8), то как, по вашему мнению, будет работать сетевое соединение? Вот почему вы должны настроить устройство для использования DHCP «из коробки» и позволить клиенту статически настроить его позже.

Если вы не можете использовать DHCP, используйте APIPA.

joeqwerty
источник
Там не будет общественного пользования. Внутренние адреса никогда не будут выставлены наружу. В коммуникации используется NAT. Но я не могу сделать NAT, когда обе сети используют перекрывающиеся адреса.
Проски
1
Хорошо, но мой ответ не о NAT. Как ваше устройство будет взаимодействовать с другими устройствами в той же внутренней сети, если оно использует IP-адрес, который не находится в той же подсети, что и внутренняя сеть?
Joeqwerty
Очевидно, что устройство включает в себя маршрутизатор, который имеет адреса в обеих сетях. Маршрутизатор делает NAT. Клиент общается с устройством только через облачный сервис.
Проски
Я не пытаюсь быть скупой, но как это очевидно? Мы знаем только то, что вы нам сообщаете в своем вопросе, и вы никогда не упоминали этот факт.
Joeqwerty
1
Может это я. Я, конечно, не имею в виду никаких обид, и, может быть, это прозвучит грубо, но как из-за утверждения «подустройство, подключенное к обеим сетям, может быть перепутано» подразумевается, что устройство имеет встроенный маршрутизатор или имеет функции маршрутизации? Мой компьютер имеет два сетевых интерфейса, каждый из которых подключен к другой сети, но мой компьютер не является маршрутизатором. Может я просто тупой. Я не читаю ничего в вашем вопросе, что наводит меня на мысль, что ваше устройство имеет встроенный маршрутизатор или имеет возможность маршрутизации. Во всяком случае, эта напыщенная речь не поможет вам, поэтому на этом я остановлюсь.
Joeqwerty
4

Теоретически, любой частный диапазон IP-адресов может использоваться любой частной сетью, поэтому я сомневаюсь, что вы найдете лучшую практику или что-нибудь, что будет универсально применимо, если вы жестко кодируете адрес. Рекомендуется сделать его настраиваемым и разрешить клиентской сети назначать устройству частный адрес (например, через DHCP).

Если это не вариант, я нахожу, что вряд ли кто-то использует верхнюю половину 172.16.0.0/12, так что это то, что я использую. (Я думаю, что я продолжаю работать 172.25.0.0/16, если быть точным.) У меня еще не было конфликта адресов, и я перехожу во многие частные сети.

Если вам нужно использовать частный адрес IPv4, я думаю, это лучшее, что вы сможете сделать, так как этот 10.0.0.0/8блок широко используется, а 192.168.0.0/16блок используется по умолчанию практически для всего, остался бы только один 172.16.0.0/12. Конечно, этот блок часто используется для VPN, чтобы избежать конфликтов адресов из-за широкого использования других блоков частной сети, поэтому используйте верхние адреса, поскольку (по моему опыту) они являются наименее используемыми подсетями в этом блоке. ,

HopelessN00b
источник
1
Если вы выберете случайный / 24 в диапазоне 10.0.0.0/8 и при условии разумного использования адресов существующими устройствами (т.е. используется не более горстки / 24 подсетей), я склонен думать о моих настройках сети как довольно сложный, учитывая, что он имеет 4 таких подсети [3 различных местоположения и vpn для маршрутизации между ними]), вероятность конфликта <0,01%. Как правило, я был бы готов пойти на этот риск в большинстве случаев.
Жюль
1
@Jules за исключением тех (к сожалению, распространенных) сетей, которые используют всю подсеть / 8 только потому, что она используется по умолчанию.
Грант
Маршрут в меньшую сеть имеет приоритет, чтобы он работал. Я мог бы на самом деле иметь / 29 внутри, чтобы еще больше снизить риск. Но не устранять этот риск, каким бы маленьким он ни был, было бы плохо. Служба поддержки должна знать об этом и проверять конфигурацию сети клиента.
Проски
2

Мы проектируем точно такую ​​же вещь и решили использовать локальные адреса сайтов IPv6 со случайным префиксом fc00: nnnn.

Майкл
источник
1
Плохой. Получить блок ULA.
TomTom
1

Предполагая, что ни одному из этих подустройств не требуется прямое подключение за пределами устройства, для этого следует использовать сеть с обратной связью (127.0.0.0/8).

RFC 5735 / Раздел 3

Loopback в Википедии

yoonix
источник
3
Как это могло бы работать? Его «подустройства» являются отдельными хозяевами. Loopback для хоста, чтобы общаться с самим собой.
mfinni
1
Хороший вопрос, я клянусь, я видел это раньше, но я не могу вспомнить, где. Я удалю свой ответ в ближайшее время.
yoonix
Но у этого документа есть еще одно предложение, которое мне нравится!
mfinni
На самом деле, я думаю об использовании 127.0.1.0/255 для внутренней сети. Не уверен, что будет лучше, чем TEST-NET-3.
Проски
1
Это не работает. Это петля. Хост, обменивающийся данными по адресу петли, ТОЛЬКО БУДЕТ ОБРАЩАТЬСЯ К СЕБЕ. Адрес петли размером с целую подсеть; он все еще только локальный.
mfinni
1

Может ли ваш «главный контроллер» запустить DHCP-сервер / предоставлять DHCP-аренду на своем «внутреннем» интерфейсе?

В прошлом я что-то делал для одного из коммерческих продуктов нашей компании, который мог бы пригодиться. Устройство имело два порта Ethernet, один из которых был предназначен для «прямого» подключения с ПК. Проблема была похожа; мы хотели избежать конфликта IP-адресов с внутренней локальной сетью клиента (возможно, в частной IP-сети), а также со всем миром.

Логика на этом устройстве состояла в том, чтобы динамически настроить DHCP-сервер («udhcpc», с помощью параметров командной строки) на «прямой» порт LAN (eth1) на основе его собственной конфигурации IP на его «общедоступном» порту LAN (eth0). Независимо от того, получил ли устройство свой собственный IP-адрес через DHCP или статическую настройку, модуль, который применил эту настройку, также изменил бы конфигурацию DHCP-сервера, чтобы избежать конфликта.

Например, если устройство получит адрес 192.168.0.100/netmask 255.255.255.0 (на eth0), оно настроит свой собственный DHCP-сервер (на eth1) для следующей доступной сети 192.168.1.0/255.255.255.0.

Он может выбрать одну из этих сетей (в порядке приоритета): 192.168.0.0/24 ... 192.168.254.0/24 172.16.0.0/16 ... 172.31.0.0/16 10.0.0.0/8

Надеюсь это поможет.

user1722483
источник
Что если я использую 192.168.0.0/16префикс своего сайта, но вы подключены только к VLAN, используя 192.168.0.0/24? Вы только что смирились, 192.168.1.0/24хотя я использую его в другой VLAN на том же сайте.
fukawi2
Это хорошая идея в теории. На практике одно из подустройств использует статический IP-адрес, а другое - DHCP-клиент. Ни один из них не настраивается в поставляемом продукте. Таким образом, адреса должны быть предварительно настроены, но локальные адреса не будут работать.
Проски