Следите за VPN на роутере, не доверяя одному индикатору состояния

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

Пять проверок, по порядку, от пира наружу.

Проверка 1: состояние пира или ассоциации

Каждый протокол показывает собственное состояние. WireGuard показывает последнее рукопожатие и счётчики передачи для каждого пира через wg show. OpenVPN записывает состояние сеанса в свой файл состояния или интерфейс управления, а IPsec показывает ассоциации безопасности с помощью инструментов вроде ipsec statusall. Ловушка — читать метку времени как приговор: простаивающий пир WireGuard, которому нечего отправить, не выполнит рукопожатие недавно, и это не сбой.

Сравните метку времени с ожидаемым трафиком и настройками keepalive, прежде чем кого-то звать.

Проверка 2: выбранный маршрут

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

Эта проверка ловит отказ, которого индикатор состояния никогда не показывает.

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

Проверка 3: разрешённый путь приложения

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

Держите объём проверки скромным. Наблюдательный цикл не должен становиться трафиком, который он измеряет.

Проверка 4: что изменилось и когда

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

Храните журналы для переходов, а не для полезной нагрузки.

Проверка 5: оповещение должно называть границу

Оповещение «VPN упал» в половине случаев отправляет человека не туда. Оповещение «рукопожатие пира устарело на двенадцать минут», «маршрут к 10.20.0.0/16 отсутствует» или «проверка порта 445 не удаётся» указывает на конкретную проверку.

Ведите операционные счётчики, а не просматривайте полезные нагрузки. Счётчики отвечают на вопрос наблюдения, не собирая содержимое, которое вам не нужно.

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