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

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

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

Назовите отказ, который должен покрывать резерв

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

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

Перестаньте требовать от дистанции чего-либо обнаруживать

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

Для статических маршрутов это требует явного трекера:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

Проследите, куда идут пакеты самого зонда

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

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

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Определите, что означает результат зонда, прежде чем добавлять цели

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

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

Проверьте обратный путь и историю сеансов

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

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

Выполните последовательность приёмки

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

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