Туннель стоит, маршрут исчез: разделяем две неисправности VPN

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

Три этапа, которые выглядят как одно событие

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

Поэтому первый вопрос — какой этап сломался, а не какой протокол виноват. Ответ определяет, кому принадлежит инцидент и какой инструмент использует следующая проверка.

Сначала прочитайте установленный маршрут

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Ответ «unreachable» означает, что установленного маршрута нет вовсе, что указывает на отзыв или отсутствующую установку. Ответ, называющий физический интерфейс, означает, что трафик покинул туннель без чьего-либо решения, и следующая проверка — это выигравшее предпочтение. А ответ, называющий туннель, тогда как пакеты продолжают исчезать, указывает дальше по пути, на фильтрацию или на противоположную сторону.

Затем посмотрите на собственное представление протокола

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Сводка сообщает, установлена ли сессия, представление по префиксу — принят ли префикс, а поиск в ядре — установлен ли он. Чтение их в этом порядке не даёт спутать дрожание сессии с отзывом, а отзыв — с отказом по политике.

Когда часы расходятся

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

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

Восстановление без петли

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

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