Почему ваш клиент OpenVPN остаётся выключенным после одного тайм-аута

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

Начните с того, что юнит действительно сделал, а не с того, что утверждает мониторинг. systemctl status openvpn-client@office и journalctl -u openvpn-client@office -n 50 показывают причину выхода и последнюю строку, которую клиент записал перед уходом.

Процесс завершился до того, как кто-то заметил

Клиент, исчезающий без ошибки, обычно завершился намеренно. Поведение определяет профиль, а не менеджер служб: ping-exit завершает процесс, как только вторая сторона перестаёт отвечать, тогда как ping-restart сохраняет процесс и переподключается внутри него. Ограничения сеанса и таймеры бездействия снаружи дают ту же картину: без туннеля и без тревоги.

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

Выбор между ping-exit и ping-restart

Выберите ping-restart для ноутбука или удалённой площадки, которая должна сама себя вылечить, а ping-exit оставьте для случаев, когда мёртвый туннель должен остановить процесс, чтобы что-то другое могло на него отреагировать. Цифры менее важны, чем связь: ping 10 с ping-restart 60 означает десять секунд тишины перед проверкой и шестьдесят перед перезапуском, что агрессивно на мобильном канале с потерями и разумно на проводном. Запишите причину рядом со строкой, иначе следующий читатель решит, что значения по умолчанию были намеренными.

Затем убедитесь, что завершился именно процесс. Юнит, который сообщает об активности при мёртвом туннеле, — другая неисправность, разбираемая ниже.

Наблюдение, которое действительно перезапускает юнит

На хосте с systemd наименьшее долговременное изменение — один drop-in файл: Restart=on-failure и RestartSec=10 в /etc/systemd/system/[email protected]/restart.conf. Drop-in читается только тогда, когда systemd перезагружает свои определения, поэтому после этого выполните systemctl daemon-reload. Проверьте с помощью systemctl show -p Restart -p ExecMainStatus openvpn-client@office, а не предполагайте, что значение применилось. Экземпляр в имени файла должен быть профилем, который юнит действительно загружает, поэтому файл, написанный для office, ничего не делает для openvpn-client@home.

on-failure игнорирует один случай: чистый выход со статусом ноль. Некоторые пути разборки заканчиваются так, поэтому читайте записанный статус, а не верьте формулировке страницы руководства. Если ваш клиент сдаётся с нулём, вам нужен Restart=always, и цена — действительно сломанный профиль возвращается снова и снова, пока не сработает ограничение скорости запуска и журнал не заполнится.

Restart=always срабатывает и после намеренной остановки. Используйте systemctl stop для обслуживания и маскируйте юнит, если он должен оставаться выключенным, пока вы работаете.

Поймайте утечку, пока туннель выключен

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

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

Проверьте это, намеренно остановив клиента. Выполните systemctl stop openvpn-client@office, затем curl -m 5 https://example.com, который должен провалиться, а не увенчаться успехом через физический канал. Успех означает, что правило межсетевого экрана отсутствует или слишком разрешающее.

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