Моя компания устанавливает специализированные веб-серверы для отслеживания производительности HVAC коммерческих зданий. На каждой из этих машин есть два адаптера LAN - основной и дополнительный.
В соответствии с принципом работы системы предполагается, что только один порт может иметь доступ к сегментам внешней сети - система поддерживает только один шлюз по умолчанию между обоими портами, а не поддерживает отдельный шлюз для каждого отдельного адаптера. При разрешении адресов сервер сначала проверяет, разделяет ли IP-адрес назначения подсеть с любым адаптером, а затем отправляет внешний трафик на шлюз по умолчанию, используя тот адаптер, который находится в той же подсети, что и шлюз. Это создает проблемы, если оба адаптера находятся в одной подсети, поскольку устройство не знает, на какой адаптер перенаправлять внешний трафик.
В общем, моя компания контролирует адресацию вторичного порта, в то время как наши клиенты предоставляют нам адресацию для первичного порта, чтобы они могли получить к нему доступ в своей корпоративной локальной сети.
В идеальном мире я бы установил для этого вторичного порта стандартную конфигурацию IP, чтобы наши полевые специалисты могли напрямую подключаться к любому серверу, который мы устанавливаем, и не перенастраивать своих клиентов в зависимости от того, где они работают.
В настоящее время стандарт IP-адреса нашей компании составляет 192.168.1.100/24 для вторичного порта, за исключением всех тех мест, где заказчик оставил для своего сегмента локальной сети значение по умолчанию 192.168.1.x / 24, а наш стандарт больше не используется. окно.
Я хочу изменить стандарт своей компании, чтобы избежать этих конфликтов подсетей, чтобы нам не нужно было отслеживать, какие сайты являются исключениями из стандарта, но мне нужно знать: с какой конфигурацией подсети я меньше всего столкнусь? 192.168.1.X является очевидным, но по моему опыту я встречал много 10.x.x.x и 172.18.x.x. Это единственные основные диапазоны, которых мне следует избегать? Есть ли другой диапазон адресов, на который я мог бы с комфортом перенести наш стандарт, потому что обычная практика сетевых администраторов - избегать этого?
Ты можешь использовать fdc8:6837:6e34:2b0c::/64 чтобы избежать столкновений. Маловероятно, что кто-то другой использует этот префикс.
Этот префикс был создан в соответствии с RFC 4193. RFC 4193 работает следующим образом: вы начинаете с fd как первый октет, следующие пять октетов должны генерироваться случайным образом. Случайность этих пяти октетов гарантирует, что у вас будет лишь незначительная вероятность коллизий.
Такой подход приведет к /48 префикс, и вы можете использовать оставшиеся 80 бит по своему усмотрению. В приведенном выше примере я решил генерировать следующие 16 бит случайным образом, чтобы еще больше снизить вероятность коллизий.
Если вы настаиваете на использовании IPv4 (что я бы не рекомендовал, потому что IPv6 лучше соответствует указанным вами требованиям, чем IPv4), вы все равно можете черпать вдохновение из RFC 4193. При выборе префикса RFC 1918 вы можете сгенерировать несколько октетов в адрес случайно. Вы не обязаны использовать /24. Судя по вашим требованиям, думаю, /29 приставка могла бы быть более подходящей. Так ты можешь взять 10.0.0.0/8 и добавить 21 случайный бит, который может закончиться как 10.123.71.152/29.
Риск столкновения, если вы используете этот префикс, будет довольно низким, но все равно будет выше, чем с IPv6.
Существует несколько диапазонов IPv4-адресов, не маршрутизируемых через Интернет, помимо диапазонов частных адресов RFC 1918, из которых можно выбрать. На ум сразу приходят три линейки TEST-NET. Проверьте Реестр специальных адресов IANA IPv4.