Как хаотичные подсети убивают масштабируемость

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Есть темы, о которых на конференциях говорят, что называется, с горящими глазами, например SD‑WAN, Zero Trust, VXLAN, EVPN и другие новомодные истории.А есть унылая, неинтересная IP‑адресация, про которую обычно не пишут много постов, не делают эффектных презентаций, её откладывают «на потом», когда будет время.

Однако именно ошибки в планировании адресного пространства очень часто приводят к серьезным проблемам по прошествии нескольких лет. Давайте рассмотрим несколько типичных сценариев, в которых многие из вас, скорее всего, узнают свою сеть.

Стихийное распределение

Классическая проблема для многих быстроразвивающихся компаний возникает, когда в результате роста появляется множество новых филиалов. Каждая новая площадка получает первый свободный диапазон с маской /24, который дежурный инженер находит в голове или в старой табличке Excel.

То есть, речь не идет о последовательном выделении адресных пространств по принципу 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24...

В итоге подсети разбросаны по всему диапазону 10.0.0.0/8 без какой‑либо логики: 10.1.5.0/24, 10.7.12.0/24, 10.3.99.0/24, 10.200.1.0/24 и так далее

И вроде бы формально сеть функционирует, есть и маршрутизация, и связность. Но стоит задать один простой вопрос: «А какие подсети относятся к филиалам Сибири?» И ответить на него будет не так просто, так как придется лезть в документацию (если она есть, и если она актуальная) и сопоставлять вручную.

Наследие слияний

Да, филиалы и их адресация — это проблема, но бывают случаи и похуже. Например, компания поглощает другую, у которой уже есть своя, скажем прямо, немаленькая сеть с исторической адресацией, привычками и своими «ну так сложилось».

В итоге после объединения мы получаем пересечения адресных пространств. К примеру, где‑то подсеть 192.168.1.0/24 в головном офисе и точно такой же диапазон в новом филиале.

Соответственно, VPN поднимается, но трафик не идёт.

В итоге мы получаем танцы с двойным NAT и прочие прелести пересекающихся диапазонов.

Экономия на спичках

А еще многие сетевые администраторы при планировании диапазонов адресов не учитывают будущие перспективы роста. Например, мы выделяем отделу с 20 сотрудниками подсеть /27, потому что не хотим тратить адреса зря.

Однако через год этот отдел объединяют с другим, сотрудников становится больше 30, и подсеть логично заканчивается. И нам снова приходится вручную переделывать всю сеть в лучшем (для бизнеса) случае ночью, ну а в худшем — с простоем в рабочее время.

Просто проверь себя

Для того, чтобы понять, есть ли у вас проблемы с IP‑планом мы предлагаем ответить честно на несколько вопросов:

• Во‑первых, можете ли вы за минуту сказать, сколько свободных /24 (или аналогичных типовых диапазонов) осталось в вашем регионе?

• Во‑вторых, используется ли единый инструмент для учета адресов (сразу предвижу ответ: «А чем не устраивает Excel на ноуте админа?»).

• Также можете ли вы суммировать маршруты филиалов одного региона одной строкой и есть ли у вас зарезервированное пространство под будущие филиалы?

• Помимо этого, привязаны ли VLAN к сайтам, или номера VLAN “плавают” от филиала к филиалу, и присутствуют ли пересекающиеся подсети между площадками.

• И, возможно, главный вопрос: если уволится человек, который «помнит все адреса», сеть продолжит жить?

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

Теперь давайте разберем наиболее распространенные и дорогие ошибки, допущенные при построении сети.

Старый добрый overlapping

Пересекающиеся подсети — это, пожалуй, самая дорогая и при этом самая распространенная ошибка в нашем списке. И не потому, что она сложная, а потому что ломает всё сразу и требует много времени на исправление.

Как правило, пересечения подсетей возникают при слияниях и поглощениях компаний. Мы говорили об этом чуть выше.

Например, две компании годами использовали одни и те же два диапазона (по классике) 192.168.0.0/24 и 192.168.1.0/24, и при объединении начались проблемы.

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

И, наконец, дефолтные диапазоны. «Все используют 192.168.1.0/24, и мы тоже будем». Это работает до тех пор, пока вы не попытаетесь соединить две такие сети.

Почему это катастрофа

Главная проблема не в том, что трафик не идёт, а в том, что инженеры начинают «лечить» это двойным NAT. По своей сути, двойной NAT — это костыль, который позволяет двум сетям с одинаковыми адресами общаться через прослойку трансляции.

И вроде бы здесь использование NAT звучит как решение, но на практике эта технология ломает работу различных протоколов, например VoIP (SIP/RTP), так как SIP не любит трансляцию адресов.

В результате RTP‑потоки уходят не туда, голос пропадает, звонки срываются и происходит еще много чего интересного. Кроме того, Active Directory, а точнее протокол Kerberos, чувствителен к именам и адресам, и аутентификация может начать «плавать».

Различные бизнес‑приложения тоже могут начать глючить, например, если клиент видит сервер по одному адресу, а сервер клиента — по другому.

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

Давайте разберем реальный пример пересечения подсетей.

Головной офис основной компании использует 10.0.0.0/24, в поглощаемая компания тоже эта подсеть. После подключения по VPN бухгалтерия филиала не видит 1С в центре, и в качестве решения инженеры поднимают двойной NAT. 1С начинает работать, но падают сессии, потому что сервер видит клиента как 10.0.0.10, а клиент на самом деле 10.0.0.10 в другой сети. Начинается настройка переадресации, переконфигурирование, тратятся недели работы.

На самом деле, здесь правильным решением является не двойной NAT, а унылая миграция одной из сетей на новую адресацию. Это больно, но это делается один раз, в отличии от множества прыжков с двойной трансляцией.

Как все это исправлять

Определившись с основными проблемами сетевого планирования, давайте теперь составим план лечения.

• Начать нужно с инвентаризации, то есть построения полной карты адресации всех площадок. Сделать это можно, например, с помощью анализа конфигов работающего сетевого оборудования и, конечно, опроса администраторов площадок. Уж они‑то должны знать свои сети!

• Затем необходимо найти все пересечения диапазонов адресов. Сделать это можно с помощью скрипта или сторонних инструментов.

• Дальше определяемся, какая сеть «переезжает» и в какие диапазоны, а NAT можно использовать только как временный костыль с датой истечения и планом замены.

Просто /24 на каждый филиал» — это не план

Идея назначить маску 24 в каждый филиал, несмотря на свою кажущуюся простоту, в реальности рискует создать серьезные проблемы.

Гораздо лучшим решением здесь будет использование принципа иерархии. То есть, адресное пространство должно отражать топологию сети, а не наоборот.

Например, вот так:

Глобальный пул → Регион → Площадка → Сегмент

• Глобальный пул: 10.0.0.0/8

• Регион «Сибирь»: 10.1.0.0/16

• Филиал «Новосибирск»: 10.1.0.0/20

• Сегмент «Данные»: 10.1.0.0/24

• Сегмент «Голос»: 10.1.1.0/24

• Сегмент «Гости»: 10.1.2.0/24

Из такой иерархии сразу видно, что всё, начинающиеся на 10.1, это Сибирь, а на 10.1.0 — Новосибирск. Теперь всё вполне логично, и любой сетевик сможет без труда разобраться в этом адресном плане.

Суммаризация (route summarization) представляет собой объявление одного маршрута вместо сотни, то есть вместо 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24… 10.1.15.0/24 вы объявляете один 10.1.0.0/20.

В результате вы получаете уменьшение таблиц маршрутизации на порядки. Ядро сети не знает о каждой подсети в каждом филиале, вместо этого оно знает о регионе. Также вы получаете быструю сходимость, так как если филиал отвалился, ядру не нужно будет пересчитывать сотни маршрутов, вместо этого оно просто перестаёт получать один агрегат.

И наконец, мы получим стабильность, так как флаппинг одной подсети внутри филиала не перегружает таблицу маршрутизации всей сети.

Давайте рассмотрим пример плохого плана адресации.

Допустим, у нас филиалы получают адреса вразнобой:

1. Филиал А: 10.1.5.0/24

2. Филиал Б: 10.7.12.0/24

3. Филиал В: 10.3.99.0/24

Суммаризовать эти диапазоны невозможно, так как каждый маршрут представляет собой отдельную запись и таблица маршрутизации растёт линейно с числом филиалов. То есть чем больше у вас записей, тем больше ресурсов требуется маршрутизатору на ее обработку.

А вот пример хорошего плана

• Регион «Запад»: 10.1.0.0/16

• Филиал А: 10.1.0.0/20

• Филиал Б: 10.1.16.0/20

• Филиал В: 10.1.32.0/20

Один маршрут 10.1.0.0/16 покрывает весь регион, и таблица маршрутизации ядра не растёт с числом филиалов, так как она растёт только с числом регионов. Это и есть разница между «работает» и «масштабируется».

Отсутствие запаса и неверный размер подсетей

«Нам хватит /24» — фраза, которая стоила многим компаниям недель простоя. И ведь в первый год‑полтора действительно хватает, а дальше…

Например, /24 на филиал с 200 сотрудниками, а ведь в подсети /24 всего 254 адреса. Но нужны VLAN для данных, голоса, гостей, management, принтеров, камер. И 200 сотрудников в одном VLAN — это широковещательный домен размером с небольшой город. А ведь количество сотрудников может увеличиться, и тогда такой подсети точно не хватит.

Или /28 на точку доступа с расчётом «нам хватит 10 адресов», но /28 — это 14 адресов. Через год появляется гостевая сеть, IoT‑датчики, камеры, и адреса быстро заканчиваются.

Отсутствие резерва под будущие подсети, когда гостевая сеть, IoT, СКУД, камеры, тестовые стенды — всё это появляется внезапно. И если под них нет зарезервированного адресного пространства, вам придётся всё переделывать.

В качестве решения предлагается использовать простое правило: планировать количество адресов с коэффициентом роста ×2–3 на горизонте 5 лет. То есть, если сегодня в филиале 50 сотрудников, планируйте на 150, а если сегодня три VLAN, то планируйте шесть.

При нехватке адресов мы не сможем выделить отдельный VLAN для гостей, и в результате гостей приходится пускать в корпоративную сеть, а это не очень безопасно.

Отсутствие свободных адресов приводит к тому, что мы не можем добавить новые узлы в сеть, и в результате приходится выполнять ручной передел всей подсети. 

Шаблон выделения адресов на филиал

Пример для филиала на 100–150 сотрудников:

Итого филиалу выделяется /20 (4096 адресов) и это с запасом на годы вперёд.

О документировании

Но проблемы с планированием адресных пространств не ограничиваются только пересечениями и жадностью администраторов. Зачастую причиной ошибок является не выстроенный должным образом процесс учета адресных пространств. Ну да, мы будем говорить про Excel, который вроде бы всех устраивает.

Например, возможна ситуация, когда два инженера могут выделить одну и ту же подсеть в разных филиалах. А так как их записи могут оказаться в разных вкладках файла Excel, узнать об этом вы можете через несколько месяцев.

Также в таблицах нет истории, то есть мы не знаем, кто выделил этот диапазон, когда и зачем.

Очень часто в таблицах отсутствует привязка VLAN и площадкам, то есть таблица адресов живёт отдельно от таблицы VLAN и от схемы сети.

Ну и классика, файл живёт на ноутбуке уволенного инженера, и никто не сделал копию. И это не шутка, а реальная история, которая повторяется из компании в компанию.

Здесь лучшим решением проблемы будет использование инструментов класса IPAM. Данные приложения позволяют автоматически выявлять пересечения сетевых диапазонов. Например, при выделении новой подсети система сообщит, что этот диапазон уже занят.

Также IPAM позволит привязать подсеть к конкретному сайту, VLAN или устройству. Многие подобные решения имеют также API для автоматизации взаимодействия с другими системами. В результате, наши новые филиалы будут подключаться по шаблону, а не вручную.

В качестве примеров подобных инструментов можно выделить решения с открытым кодом NetBox, phpIPAM. И здесь важно понимать, что для сети из 20 с лишним филиалов IPAM становится уже не роскошью, а необходимостью, стоимость внедрения которой окупится на первом же предотвращённом конфликте.

Но IPAM работает только тогда, когда есть выстроенный процесс планирования выделения адресных пространств. Так, мы должны понимать, кто владеет IPAM и как происходит выделение адресных (заявка → проверка → выделение) и кто их утверждает. Отдельно стоит продумать процесс освобождения адресов при закрытии филиала.

Важно усвоить, что без выстроенного и работающего процесса IPAM превращается в ещё одну таблицу, которую никто не обновляет.

Подведем итог

Хаос в адресации, является, выражаясь языком DevOps техническим долгом с процентами. Чем дольше вы тянете, тем дороже потом вам обойдется миграция. IP‑план стоит недорого на старте, всего несколько дней работы архитектора. И стоит миллионы при переделке, так как включает в себя простой, выполнение миграции и разбор инцидентов.

Подводя итог, стоит отметить, что пересечения подсетей это не «если», а «когда», и планировать нужно заранее, особенно если впереди слияние или поглощение. Иерархия и суммаризация это то то, что отличает сеть, которая масштабируется, от сети, которая разваливается на сотом филиале.

И IPAM — это не роскошь, а необходимость, так как без него даже идеальный план превращается в Excel на ноутбуке уволенного инженера.

Так что, проведите аудит текущей адресации, заведите IPAM, и задокументируйте процесс. И сделайте все это до открытия следующего филиала или до начала следующего слияния.

Когда сеть растёт, проблемы часто проявляются уже после того, как изменения становятся дорогими: появляются пересечения адресов, непонятные маршруты, ручные обходные решения и зависимость от знаний отдельных специалистов.

На бесплатных уроках можно подробнее разобраться, как проводить аудит инфраструктуры и искать уязвимые места в сетях.

• 7 октября, 20:00. «GitOps‑практики: развертываем сервис через ArgoCD». Записаться

• 21 октября, 20:00. «Пентест инфраструктуры: поиск слепых зон IDS/IPS». Записаться

Больше полезных материалов по инфраструктуре смотрите в дайджесте.