Как отличить петлю маршрутизации от флаппинга маршрута на VPN-площадках

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

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

Три проверки, которые решают вопрос

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

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

Проверка первая: префикс стабилен или бурлит

Спросите ядро, что оно установило, а не что обещает файл конфигурации. На шлюзе Linux ip route get 10.20.30.40 выполняет тот же поиск, что и путь пересылки, включая таблицы политик, а ip route show 10.20.30.0/24 показывает саму запись. ip monitor route передаёт каждое изменение в момент его появления, и это самый быстрый способ наблюдать приход и уход префикса.

На маршрутизаторе с FRR или BIRD интересна не таблица пересылки. show ip bgp 10.20.30.0/24 возвращает выбранный путь и время его работы; время работы, сбрасываемое каждые несколько минут, — это флаппинг, который можно назвать, а не петля. show ip bgp summary показывает состояние соседей и число префиксов, поэтому постоянно падающий партнёр снимает вину с пути пересылки.

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

Проверка вторая: указывает ли следующий шаг обратно в туннель прихода

Петле нужно согласие двух шлюзов. На площадке, которая получает пакет, посмотрите на маршрут, которым пакет будет выходить: ip route get 10.20.30.40 from 10.10.5.20 с реальным адресом источника, потому что правило политики может ответить иначе, чем главная таблица. Затем повторите поиск на площадке, которая его отправила. Если каждая сторона выбирает другую следующим шагом для одного и того же префикса, петля доказана, и никакой захват ничего не добавит.

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

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

Проверка третья: читайте число шагов, а не звёздочки

traceroute -n -I 10.20.30.40 и mtr -n -r -c 20 10.20.30.40 оба показывают путь, и режим ICMP часто выживает при фильтрации, которая съедает UDP-зонды. Петля выглядит как короткая повторяющаяся последовательность одних и тех же двух адресов шлюзов с ростом TTL каждый раз. Обрыв выглядит как звёздочки после последнего ответившего шлюза, и один молчащий шаг ничего не доказывает.

Когда путь неоднозначен, читайте TTL на проводе. tcpdump -ni any -vv icmp на обоих шлюзах показывает TTL каждого пакета и адрес источника каждого ответа о превышении времени. Если пакет приходит на удалённую площадку с TTL ниже числа шагов, которые путь может содержать, что-то добавляет шаги, которых traceroute вам не показывает, и это бывает, когда межсетевой экран одной площадки отвечает на зонды от имени другой.

Почините владельца префикса, затем проверьте оба направления

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

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

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