Я создаю устройство, состоящее из нескольких подустройств, подключенных через Ethernet внутри устройства. Устройство подключится к клиентской сети. Клиентская сеть может использовать частные IP-адреса. Конфликт адресов с внутренней сетью будет проблемой (подустройство, подключенное к обеим сетям, будет запутано). IPv6 не вариант.
Стоит ли покупать адреса IPv4? Или, может быть, мне сойдет с рук TEST-NET-3 (203.0.113.0/24) или что-то в этом роде? Какая лучшая практика?
@yoonix отправил ссылку, по которой может быть решение.
Link-local, также известный как APIPA.
Если бы я был вашим клиентом, я бы чертовски уверен, что хотел бы иметь возможность настроить это сам и / или использовать DHCP (который, я не знаю, может быть, давно установленный стандарт?), Но в отсутствие это именно то, для чего предполагается использовать APIPA.
Изменить - учитывая, что теперь вы заявляете, что IP-адреса должны быть статическими для отдельных хостов в вашем решении, потому что они будут соответствовать правилам брандмауэра на вашем шлюзовом устройстве, я полагаю, что с вашей стороны потребуется немного усилий, чтобы заставить эту работу со ссылкой локальная адресация IPv4; усилия, которые вы говорите, что не потратите. Итак, вы по сути иметь чтобы сделать это настраиваемым. Вы можете отправить его со значением по умолчанию, которое с меньшей вероятностью будет использоваться клиентом, но у вас должен быть механизм, с помощью которого его можно изменить в случае конфликта. Либо клиентом, либо вами в рамках реализации / UAT.
Из Википедии: 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.
Одна вещь, которую вы, кажется, упускаете из виду: как вы предполагаете, что сможете общаться с устройством или что устройство сможет общаться с другими устройствами, и наоборот, если вы не настроите IP-адрес устройства. ДЛЯ клиентской сети? Если вы назначаете IP-адрес в сети, которая не используется в клиентской сети (вы: 192.168.1.0/24 - они: 10.0.0.0/8), то как вы предполагаете, что сетевая связь будет работать? Вот почему вы должны настроить устройство на использование DHCP из коробки и позволить клиенту статически настраивать его впоследствии.
Если вы не можете использовать DHCP, используйте APIPA.
Сделайте его настраиваемым.
Стоит ли покупать адреса IPv4?
Да. ПОПРОБУЙ ЭТО. Во-первых, вы не покупаете их, вы «сдаете в аренду» их членством. Во-вторых, для этого требуется AS и 2 восходящих канала. В-третьих, для этого нужна причина, а «мы не хотим предполагать правильную сетевую инфраструктуру» - причина, вызывающая смех (и отказ), а не выделение IP-адресов.
Или, может быть, я смогу обойтись с помощью TEST-NET-3 (203.0.113.0/24)
Возможно. До того дня, пока кто-то не спросит о стоимости ремонта из-за грубой небрежности.
Какая лучшая практика?
Сделайте его настраиваемым. Или используйте IPV6 - там можно уйти с некоторыми оговорками.
Теоретически любой частный диапазон IP-адресов может использоваться любой частной сетью, поэтому я сомневаюсь, что вы найдете лучшую практику или что-нибудь, что будет универсально применимо, если вы жестко запрограммируете адрес. Лучше всего сделать его настраиваемым и позволить клиентской сети назначать устройству частный адрес (например, через DHCP).
Если это не вариант, я считаю, что почти никто не использует верхнюю половину 172.16.0.0/12, вот что я использую. (Думаю, я бегу 172.25.0.0/16(если быть точным.) У меня еще не было столкновения адресов, и я использую VPN во многих частных сетях.
Если вам нужно использовать частный адрес IPv4, я думаю, что это лучшее, что вы сможете сделать с 10.0.0.0/8 блок широко используется и 192.168.0.0/16 блок по умолчанию почти для всего, останется только один 172.16.0.0/12. Конечно, этот блок часто используется для VPN, чтобы избежать конфликтов адресов из-за широкого использования других блоков частной сети, поэтому используйте верхние адреса, поскольку (по моему опыту) они наименее используемые подсети в этом блоке. .
Мы разрабатываем то же самое и решили использовать локальные адреса сайтов IPv6 со случайным префиксом fc00: nnnn.
Предполагая, что ни одно из этих подустройств не нуждается в прямом подключении за пределами устройства, вы должны использовать для этого петлевую сеть (127.0.0.0/8).
Может ли ваш «главный контроллер» запускать DHCP-сервер / предоставлять аренду DHCP на его «внутреннем» интерфейсе?
В прошлом я что-то делал для одного из коммерческих продуктов нашей компании, который мог бы пригодиться. Устройство имело два порта Ethernet, один из которых предназначался для «прямого» подключения с ПК. Проблема была похожей; мы хотели избежать конфликта IP-адресов с внутренней LAN клиента (возможно, в частной 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
Надеюсь это поможет.