Звезда или полносвязная сеть: какая топология VPN подходит вашим площадкам

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

Сначала посчитайте число связей между узлами

При N площадках полносвязная сеть требует N умножить на N минус один, делить на два, туннелей; концентратору нужно N. На пяти площадках это десять против пяти, что ещё звучит выполнимо. На пятнадцати это 105 против пятнадцати, и разница уже не арифметическая, а кадровая.

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

Пусть решает состав трафика, а не рисунок

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

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

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

Концентратору нужно сказать, чтобы он пересылал

Два работающих туннеля филиал — концентратор ещё не создают доступа между филиалами. Концентратору нужны включённая пересылка IP, маршрут в каждую сеть филиала, правило брандмауэра, разрешающее транзит, и рассчитанный обратный путь; каждому филиалу нужен маршрут к префиксам другой площадки. На Linux-концентраторе это net.ipv4.ip_forward=1 плюс цепочка FORWARD, которая молча не отбрасывает пару, а в IPsec на основе политик — селекторы трафика, перечисляющие подсеть удалённого филиала на обоих концах. У strongSwan заметки о пересылке охватывают сторону ядра и брандмауэра, когда не хватает именно этого слоя. Дешёвый тест: отправить трафик из одного филиала к сервису в другом, наблюдая за счётчиками концентратора; правило, которое никогда не растёт, означает, что неверен порядок, а не маршрут.

Центральная политика — тоже полезная часть. Филиалам можно разрешить доступ к общим сервисам, не давая доступа друг к другу, и эту матрицу доступа стоит записать явно. Отсутствующие маршруты — плохая замена правилу, которое человек может прочитать.

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

Сначала спроектируйте отказ, потом обычный путь

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

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

Ни один из проектов сам по себе не удерживает TCP-сеанс при переключении. Если приложение не может переподключиться, топология — не ваша проблема.

Выбирайте по стоимости изменений, затем проверьте маршруты

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

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

Храните обе схемы вместе с матрицей доступа и возвращайтесь к ним, когда добавляется площадка; стоимость, которой вы управляете, — это стоимость следующего изменения, а не элегантность текущей картинки.