Облачному VPN нужен BGP: почему другие протоколы маршрутизации не работают

Ассоциация безопасности IPsec установлена, счётчики туннеля растут, а трафик к облачному префиксу исчезает. Тогда оператор пытается включить OSPF на клиентском маршрутизаторе, ожидает формирования соседства, и ничего не происходит. Туннель никогда не был недостающей частью: управляемый облачный VPN предоставляет определённый контракт маршрутизации, и на крупных платформах этот контракт — BGP. Пока не существует сессии и не принят префикс, туннель — лишь зашифрованный путь без пунктов назначения за ним.

Туннель поднят, а маршрута нет

Завершение фазы 1 и фазы 2 доказывает, что стороны согласны насчёт защиты, а не то, что какая-либо сторона знает, куда отправлять трафик. Это отдельные машины состояний с отдельными режимами отказа.

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

Что поставщик на самом деле даёт

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

Google Cloud описывает динамическую маршрутизацию BGP для HA VPN, где Cloud Router изучает маршруты соседей и передаёт подходящие пользовательские динамические маршруты в VPC. AWS Site-to-Site VPN описывает выбор между статической и динамической маршрутизацией и называет проверки работоспособности BGP полезными для переключения туннеля, одновременно поддерживая проверки состояния для устройств без BGP. Поведение одной платформы нельзя выводить из названия продукта другой.

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

Защита туннеля и достижимость — разные задачи

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

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

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

Где рушатся предположения об OSPF

OSPF, IS-IS или другой протокол внутри туннеля IPsec вполне возможен на самостоятельно управляемом устройстве, где вам принадлежат оба конца и схема пересылки. Этот факт ничего не говорит об управляемом сервисе, который предлагает только BGP как режим динамической маршрутизации.

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

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

Прочитайте требование сервиса, затем проектируйте

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

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

Храните контракт сервиса вместе с записью об изменении. Когда позже кто-то спросит, почему туннель не может работать с OSPF, ответ — граница продукта, а не ограничение протокола, и запись должна это указывать.