Спланируйте частные диапазоны адресов VPN до того, как площадки столкнутся

Две площадки, которые обе используют 192.168.1.0/24, могут каждая выходить в интернет и при этом не достигать друг друга. Шлюз не выдаёт ошибку; он устанавливает один маршрут для этого префикса и отправляет каждый пакет тому партнёру, который запросил его первым. Ничто в рукопожатии, списке шифров или метрике интерфейса не говорит, какой партнёр ошибается. Планирование адресов — та часть проекта, которая решает это до чьего-либо подключения.

Проведите инвентаризацию каждого пространства, которое должно быть доступно

Запишите диапазоны, которые нужно маршрутизировать, а не только те, что вы настраиваете. Это локальные сети площадок, пулы клиентов VPN, облачные подсети, сети управления и внеполосные сети, лабораторные сегменты и сети, из которых пользователи обычно подключаются из дома. Потребительский маршрутизатор, поставляемый как 192.168.1.0/24, не гипотетичен, и тот же префикс встречается в отелях и конференц-центрах. Инвентаризация — это таблица префикса, владельца и назначения, и это единственный артефакт, который не даёт выдать один и тот же диапазон дважды.

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

Именно повторное использование делает это сложным: частное пространство конечно, и каждая организация считает 10.0.0.0/8 своим. План не может обещать, что будущая гостевая сеть не окажется на одном из ваших префиксов, поэтому проект должен сказать, что происходит, когда это случится. Два правила делают большую часть работы. Поместите пулы клиентов в один непрерывный блок, который можно просуммировать, и никогда не выделяйте диапазон, который уже маршрутизирует другая команда. Всё остальное — запись, которую кто-то поддерживает в актуальном состоянии.

Почему перекрытие побеждает таблицу маршрутизации

Маршрут — это префикс плюс следующий переход, а пересылка выбирает самый длинный подходящий префикс. Когда два партнёра оба требуют один и тот же 192.168.1.0/24, в таблице есть одна запись для него, поэтому трафик обеих площадок выходит через один и тот же туннель. Вторая площадка не настроена неправильно; она недоступна, потому что первая отвечает за те же адреса. Никакая метрика не может их разделить, потому что совпадение происходит до того, как метрики приняты во внимание.

Отказ асимметричен, и его легко прочитать неправильно. Узлы площадки A достигают шлюза и некоторых служб, а узлы площадки B не отвечают ни на что, и журнал показывает исправный туннель в обе стороны. Эта картина — коллизия адресов, а не сбой аутентификации или межсетевого экрана, и для её подтверждения нужен один дамп таблицы, сверенный с инвентаризацией.

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

Пул клиентов VPN — это диапазон, из которого шлюз выдаёт по одному адресу, поэтому его размер ограничивает одновременность. /24 вмещает 254 пригодных адреса, что щедро для небольшой команды и тесно для филиала, запускающего контейнеры; /22 ничего не стоит дополнительно в частном пространстве и снимает спор. Держите пул непрерывным и в стороне от каждой локальной сети площадки, чтобы сводный маршрут к клиентам никогда не проглатывал площадку. Резервируйте диапазон даже тогда, когда пул пуст, потому что незаписанный диапазон — тот, который выделит следующий инженер.

Площадки получают диапазоны, рассчитанные на ожидаемые узлы плюс рост, выровненные по границе, которая чисто суммируется. Намеренные промежутки между выделениями ничего не стоят и покупают место для последующей агрегации.

Затем проверьте направление, которое люди забывают: обратный путь. Каждому маршрутизатору площадки нужен маршрут к пулу клиентов, а концентратору нужен маршрут к каждому обслуживаемому префиксу площадки. Аккуратная таблица префиксов без пути назад к пулу — всё ещё сломанный проект, и симптом — одностороннее соединение, которое ни на что не отвечает. Держите оба направления в одной таблице и пересматривайте её при каждом добавлении площадки.

Трансляция и перенумерация решают разные задачи

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

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

Тестируйте с удалённой стороны до развёртывания

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

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

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