Как проверить, действительно ли работает VPN-туннель в Linux

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

Флаги соединения описывают устройство, а не путь

Проверка, которую все копируют, ищет аппаратный адрес из одних нулей. Этот трюк в некоторых драйверах отделяет настоящий интерфейс от заглушки, а в остальных ничего не доказывает, потому что у tun-устройства вообще нет MAC, о котором можно сообщить. ip -brief link show tun0 вместо этого показывает флаги: UP означает, что администратор включил устройство, а LOWER_UP означает, что драйвер считает соединение пригодным. Прочитанные вместе, они говорят, что устройство существует и не отключено административно. Ни один из них не говорит, что пакету есть куда идти.

OpenVPN создаёт своё tun-устройство до установки маршрутов, поэтому флаги могут выглядеть безупречно, пока ничего не маршрутизировано. Считайте их предпосылкой, но никогда ответом.

Спросите, куда пойдёт пакет

Поиск маршрута отвечает на вопрос, на который флаги не способны. ip route get 10.8.0.1 from 10.8.0.2 называет интерфейс, адрес источника и таблицу, которую использовало бы ядро, — именно то, с чем нужно сверять разделённый туннель. Без адреса источника вы спрашиваете о другом, а при маршрутизации по политикам ответ может различаться в зависимости от источника. Это самый дешёвый честный тест, потому что он обращается к тем же правилам, которые будет использовать ваш трафик.

Для WireGuard добавьте рукопожатие. wg show печатает отметку времени последнего рукопожатия для каждого пира, и отметка, переставшая двигаться, означает, что пир исчез, что бы ни говорили флаги интерфейса. Настроенный интерфейс без недавнего рукопожатия — один из самых частых ложных положительных результатов в самодельном мониторинге.

Таблица 220 рассказывает историю IPsec

strongSwan устанавливает маршруты для согласованных селекторов в таблицу 220, когда установка маршрутов включена. ip route list table 220 поэтому отделяет согласованное от маршрутизированного: пустая таблица рядом с загруженным соединением означает, что SA IKE и CHILD поднялись, но никакой трафик в них не направляется. Проверьте ip xfrm state рядом, поскольку она перечисляет установленные ассоциации безопасности и их конечные точки.

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

Состояние менеджера и состояние демона — это разные списки

NetworkManager перечисляет только свои соединения. nmcli -t -f NAME,TYPE connection show --active ничего не возвращает для туннеля, запущенного напрямую через wg-quick или демоном OpenVPN.

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

Привяжите следующий шаг к нужной ему проверке

Опрос UDP-порта ничего не доказывает о готовности, потому что у UDP нет рукопожатия и nc -u удаётся, как только пакет выходит. Проверяйте то, что следующий шаг действительно потребляет: TCP-соединение к перенаправленному порту, запрос к хосту внутри туннеля, имя, которое разрешается только там. Ограничьте ожидание тайм-аутом и числом попыток и громко падайте, когда они исчерпаны.

Хуки лучше опроса, если клиент их предлагает. --up и --down скрипты OpenVPN запускаются после изменения состояния интерфейса, что полностью убирает гонку, но они работают с привилегиями, которые демон сохранил. Если OpenVPN опустился до непривилегированной учётной записи через user и group, хук работает от этой учётной записи. Тогда перезапуск системной службы требует sudo, разрешающего ровно эту команду. Поручите повтор менеджеру служб, а не циклу cron: ограниченная политика перезапуска с лимитом запусков выявляет сломанный туннель, тогда как безграничный цикл скрывает его бесконечно.