Резервные туннели MikroTik: что должен проверять Netwatch
Почему дистанции маршрутов недостаточно для проверки VPN и как не принять ответ через резервный туннель за восстановление основного.
- Контрольная цельДоступна только через проверяемый туннель
- Состояние путиОтличаем отказ сервиса от отказа связи
- ПереключениеМеняем нужный маршрут и сохраняем путь пробы
У сети есть основной и резервный туннели, у маршрутов стоят разные distance. Кажется, переключение уже готово. Но состояние интерфейса не всегда отражает доступность удалённой площадки: WireGuard-интерфейс может оставаться включённым, когда через него нельзя передать полезный трафик. Нужна проверка именно того пути, от которого зависит работа офиса.
Сначала формулируем, что считаем исправным
Ответ VPN-узла подтверждает один участок, а доступ к файловому серверу — другой. Если проверять только один сервер, его перезагрузка может выглядеть как отказ всего туннеля. Выберите устойчивую цель за нужным маршрутом и отдельно наблюдайте критичный сервис. Так решение о переключении не будет зависеть от случайной рабочей станции.
Netwatch умеет выполнять разные пробы: ICMP, TCP, HTTP и другие. Подбирайте проверку под вопрос. TCP-соединение на порт сообщает о доступности порта, но не подтверждает, что приложение выполнило операцию. HTTP-проверка полезна, если есть простой ответ, который действительно отражает нужную функцию.
Проба не должна уйти через соседний туннель
Представьте: основной канал отключён, а его контрольный адрес доступен через резерв. Netwatch видит ответ и объявляет основной канал исправным. Затем маршрут возвращается обратно и снова перестаёт работать. Получается переключение по кругу, хотя сама проверка всё время успешно отвечает.
Для каждого контролируемого пути заранее определите адрес цели, адрес источника, таблицу маршрутизации и обратный маршрут. src-address выбирает источник, но не создаёт отдельный маршрут автоматически. В простой схеме разные контрольные цели можно закрепить отдельными маршрутами /32 через свои туннели. При этом peer должен разрешать эти адреса, а проба не должна иметь обходного пути после отказа. Для VRF и policy routing проверяйте поведение в своей версии RouterOS отдельно.
# Просмотр текущей конфигурации и состояния
/tool/netwatch/print detail
/ip/route/print detail
/interface/wireguard/peers/print proplist=interface,last-handshake,rx,txНе отключаем способ обнаружить восстановление
Служебный путь пробы должен сохраняться, когда пользовательский маршрут выведен из работы. Если down-script отключает всё, включая маршрут до контрольной цели, up-событие может уже никогда не наступить. Скрипту нужен точный отбор своей записи: таблица, адрес назначения и уникальный комментарий. Широкий find по одному gateway способен захватить лишние маршруты.
Первый вариант лучше запускать только с записью событий в журнал, без изменения маршрутов. Проверьте, какой путь реально использовался, что произошло при потере цели и как система увидела её возвращение. После этого добавляйте переключение, задержку перед возвратом и защиту от частых колебаний состояния. Права скриптов проверяют отдельно; отключение проверки прав не должно быть способом исправить ошибку выбора маршрута.
Испытываем отказ, а не только нормальную работу
По очереди проверьте недоступность основного пути, отказ контрольной цели и восстановление связи. Затем убедитесь, что резерв действительно несёт пользовательский трафик и что возвращение основного не обрывает работу бесконечными переключениями. Успешный ping в штатном состоянии подтверждает меньше, чем один аккуратно проведённый тест отказа.