Точнее проблема актуальна когда хот-спот использует адреса частной сети 192.168.0.0/24 (по опыту самые распространённые адреса по умолчанию для сетевого оборудования). Ещё точнее, когда в головном офисе и/или ЦОД за VPN-сервером используется тот же диапазон адресов что и для хот-спота. Перестаёт работать статически маршрут через VPN, в сеть головного офиса на компьютере сотрудника. ОС в которой работает командированный направляет весь трафик для подсети 192.168.0.0/24 по маршруту "default" который ведёт в локалку хот-спота гостиницы. Соответственно ЦОД организации не доступен, работать сотрудник не может.
Есть известные костыли с NAT в любую сторону, но это костыли.
Мне в итоге пришлось за выходные дни (график работы предприятия позволял) перестроить всё адресное пространство организации. Это: ЦОД, ЦОД\Головной офис и 10 регионов. Гораздо эффективнее это делать при строительстве сети с нуля.
Схема такая:
За рисунок извиняюсь, было удобнее и быстрее сделать так )
Код региона берём отсюда, всем понятно и удобно. Почти все коды входят в диапазон 0-254.
Технически это не сложное решение позволяет администратору (сетевому в первую очередь) с первого взгляда понимать на 50% картину происходящего при возникновении не штатных ситуаций.
Так же удобно управлять QoS при следовании данному принципу.
Спасибо за внимание! Буду признателен за комментарии, критику и т.д.
Комментарии (19)
gotch
11.08.2021 08:07+1Что бы сказал Виктор Пелевин?
Октетно-региональная красота не имеет никакого технического смысла. Гораздо проще работать, когда управление адресным пространством удобно автоматизировано там же php IPAM.
Timnet Автор
11.08.2021 08:15За Виктора Олеговича не могу ничего сказать. А Вам признателен за комментарий, нашёл интересную информацию.
gotch
11.08.2021 08:37+1Критикую просто потому что в эту игру с регионами уже играл много лет назад.
Действительно для построения сети с нуля можно оттолкнуться от этой схемы. Но приводить к ней имеющуюся сеть как к святому Граалю адресации - не думаю, что есть смысл.
Вот пара неприятных недостатков
нерациональное использование адресов в регионах разных размеров
работает только на блоке 10.0.0.0/8
Бесконечнось серых адресов мнима. Как только вы попадаете в какую-нибудь ведомственную серую сеть или сеть холдинга, там уже все расписано до вас и реально существует дефицит серых адресов.
И чем чаще вы будете скрывать полезную информацию в адресе, тем чаще она случайно будет нарушаться. Даже элементарные вещи вроде четного/нечетного адреса на пир-паре рано или поздно приведет к бардаку и путанице.
С чистой совестью пиарую php IPAM. Это самый простой и удобный продукт для управления адресным пространством, который я встречал. Честно, больше не представляю работу без него.
lealxe
11.08.2021 08:33Точнее проблема актуальна когда хот-спот использует адреса частной сети 192.168.0.0/24 (по опыту самые распространённые адреса по умолчанию для сетевого оборудования). Ещё точнее, когда в головном офисе и/или ЦОД за VPN-сервером используется тот же диапазон адресов что и для хот-спота. Перестаёт работать статически маршрут через VPN, в сеть головного офиса на компьютере сотрудника. ОС в которой работает командированный направляет весь трафик для подсети 192.168.0.0/24 по маршруту "default" который ведёт в локалку хот-спота гостиницы. Соответственно ЦОД организации не доступен, работать сотрудник не может.
И об этом никто не задумался до этого момента?
AcidVenom
11.08.2021 08:36+2Вся красота разбивается, когда провайдер отдает одну из этих внутренних сетей узкой маской.
Protos
11.08.2021 10:13+1Мы просто ведем кликабельную таблицу, наши сетевые админы не видят проблемы. Сетей у нас только тех что зарегистрированы в базе ~2000.
SignFinder
11.08.2021 10:19+2Красота разбивается и при обычном расширении подсетей. Закончились адреса в 24 подсети-нужно добавить.
При наличии пустых подсетей-промежутков между выделяемыми подсетями это сводится к изменению маски в маршрутах с /24 на /23 и.т.п. и изменению настроек DHCP.
Когда подсети выдаются подряд (а региональные коды у нас идут подряд) - это невозможно без переструктурирования.
amarao
11.08.2021 12:28... На что только не пойдут люди, лишь бы не писать двоеточия в IP-адресах. В условиях IPv6 можно сесть и написать хороший numbering plan. А условиях IPv4 - нет. У вас мало всего. Мало белых адресов (дорого), мало серых адресов (бесценно). Вы не можете выстроить иерархию приличной компании на /8. Сколько бы вы не пытались, будет либо allocation pool с полной безнадёжностью в районе аггрегации, либо будут постоянные "не хватает".
Просто перейдите на IPv6. Но... Есть много важных причин (главная из которых - половина сотрудников, которые должны хорошо знать IPv6, не знают и боятся учить), по которым именно в этой конкретной ситуации IPv6 - не вариант. Будем нарезать /30 на 4 /32, ибо экономить надо.
Ds02006
11.08.2021 13:30+1До сих пор существует много оборудования, поддерживающего только IPv4 для своего мониторинга и управления. Например, операторское GSM-GPRS-оборудование (радиочасть). Data-plane вполне успешно несёт внутри себя IPv6, а вот управлять (control-plane) - только по IPv4. А когда это оборудование раскидано по всей огромной сети огромной страны - то IPv6 здесь не поможет.
amarao
11.08.2021 16:35Я стесняюсь уточнить, какого года это оборудование? И оно не поддерживает, или обслуживающий персонал боится его трогать, потому что "работает - не трогай", запасного давно нет, мануалов нет, экспертизы нет?
edo1h
И что делать с несколькими филиалами в одном регионе?
Timnet Автор
Свободные номера использовать в произвольном порядке.
Mchechulin
Я в такой же ситуации просто использовал следующую подсеть в этом же регионе. Чтобы было понятно, у меня было разбросано много маленьких /29 подсетей. И в итоге первая подсеть в регионе имела адрес 10.{телефонный код страны}.{код региона}.0, а вторая - 10.{телефонный код страны}.{код региона}.8. Но всё это добро работало без NAT, а доступ разграничивался на уровне маршрутизации между этими маленькими подсетями.