Почему BGP поверх VPN не управляет путём нижележащего уровня

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

Что люди думают, что покупает сессия

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

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

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

Что на самом деле несёт сессия

Спикер BGP открывает TCP-соединение к порту 179 своего партнёра, используя форматы сообщений и атрибуты пути, определённые в RFC 4271. Когда адрес партнёра находится внутри туннеля, туннель должен быть поднят, а адрес достижим до того, как сессия вообще начнётся. Завершённый обмен IKE — это не сосед BGP. Реализации IPsec на основе маршрутов пропускают трафик только тогда, когда существует подходящий маршрут туннеля, а реализация на основе политики требует адреса партнёра внутри защищённого селектора. Обратный порядок даёт классическое состояние, когда туннель зелёный, а сессия простаивает.

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

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

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

Куда всё ещё идут внешние пакеты

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

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

Честный ответ для обзора дизайна — список общих зависимостей: канал доступа, вышестоящий провайдер, объект и любое устройство с состоянием на обратном пути. Сессия через туннель не может убрать зависимость, над которой она не находится.

Три решения, которые стоит разделять

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

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

Режимы отказа, которые стоит планировать

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

Время отзыва — второе. Обнаружение зависит от таймеров удержания, от BFD, если вы его включили, от обнаружения мёртвого партнёра туннеля и от того, как быстро удалённая сторона перестаёт анонсировать. Существующие сессии — отдельная проблема: новый маршрут может восстановить новые соединения, пока установленные сессии TCP продолжают использовать устаревшие адреса, а межсетевые экраны с состоянием или NAT на пути могут держать записи, которые больше не совпадают. Поместите восстановление приложения в критерии приёмки вместо предположения, что изменение маршрута решает всё.

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

Что записать в контракт и как это проверить

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

Затем проверяйте с устройства, а не со схемы. Полезные команды на маршрутизаторах в стиле FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Добавьте два наблюдения, которые таблица маршрутизации дать не может. Захватите на внешнем интерфейсе, чтобы подтвердить, на какой адрес на самом деле нацелены инкапсулированные пакеты, например tcpdump -ni eth0 udp port 51820 для туннеля WireGuard или фильтр ESP для IPsec. Затем проследите к публичному адресу партнёра и сравните хопы с трассировкой внутри туннеля; если оба идут по одной цепочке провайдера, ваша избыточность живёт в политике маршрутизации, а не в сети.

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

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

• Назовите префиксы, которые каждая сторона может создавать, и те, которые она никогда не должна принимать.
• Ограничьте MSS на туннеле и подтвердите, что большие обновления действительно приходят.
• Перечислите общие зависимости нижнего уровня, а не количество туннелей.
• Измерьте реальный отзыв и отметьте, что делает приложение.