Статические маршруты или протокол маршрутизации через VPN между площадками?

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

Три условия решают

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

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

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

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

Сколько на самом деле стоит статическая маршрутизация

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

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

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

Сколько на самом деле стоит динамическая маршрутизация

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

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

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

Управляйте тем, что сессия маршрутизации может говорить

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

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

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

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

Проверяйте путь отказа, а не счастливый путь

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

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

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