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

Цикл, который скрывает первую ошибку

То, что вы видите, — повторяющийся блок, а не единичный сбой: попытка подключения, ошибка TLS, пауза и затем та же последовательность. Каждое повторение выталкивает исходную строку выше в журнале. Если юнит перезапускается при сбое, цикл может продолжаться часами, пока никто не прочитает причину. Симптом — цикл, хотя основная неисправность одна: проблема согласования.

Интерактивные сеансы это терпят, потому что временный сбой может исчезнуть при следующей попытке. Автоматические подключения не могут позволить себе такой же оптимизм: процесс должен остановиться, чтобы человек или монитор увидел состояние.

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

Механизм повторных попыток за циклом

Повтор — поведение по умолчанию, потому что несколько несвязанных тайм-аутов используют один механизм. connect-retry задаёт интервал между попытками подключения, connect-retry-max может ограничить, как часто пробуется каждая удалённая запись, а resolv-retry управляет повторными запросами имён. Неудача согласования TLS попадает в этот механизм как транспортное событие, поэтому клиент планирует ещё одну попытку вместо сообщения. Значение по умолчанию помогает на нестабильном канале и вредит при неисправности, которая не может исцелиться.

Опция --tls-exit меняет только случай согласования. Руководство описывает её как выход при неудаче согласования TLS, что уже, чем выход при любой ошибке. Тайм-ауты, сбои резолвера и отказы аутентификации сохраняют своё поведение.

Заставить клиент выходить при сбое TLS

Поместите tls-exit в профиль, который клиент действительно загружает, или передайте --tls-exit при запуске и запустите его один раз на переднем плане. Читайте код выхода и последнюю строку журнала, потому что супервизор реагирует именно на код. Ненулевой выход после неудачи согласования — это и есть желаемый результат. Если процесс продолжает пытаться вместо завершения, опция не в том профиле, который клиент действительно загружает.

Супервизор решает, будет ли этот выход видимым. Юнит systemd с Restart=always или Restart=on-failure запускает клиент снова, поэтому цикл продолжается, и опция будто ничего не делает. Проверьте политику, прежде чем винить клиент:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no позволяет процессу остаться остановленным, а Restart=on-failure всё равно перезапускает после ненулевого состояния. Если вы хотите, чтобы сбой был виден, но служба восстанавливалась после несвязанных аварий, задайте Restart=on-failure и используйте StartLimitBurst и StartLimitIntervalSec, чтобы остановить бурю перезапусков. Затем прочитайте состояние юнита, чтобы подтвердить последний код выхода: systemctl status сообщает его, а журнал хранит первую ошибку выше перезапусков.

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

Докажите это одноразовой конечной точкой

Чтобы увидеть поведение, прежде чем ему доверять, скопируйте профиль и направьте копию на конечную точку, которая принимает TCP-соединение, но никогда не говорит OpenVPN. Достаточно слушателя, который отвечает и затем молчит. С tls-exit клиент должен завершиться, когда рукопожатие не удаётся; без неё тот же профиль должен продолжать крутиться. Используйте копию, никогда не рабочий профиль.

Сравните два запуска по коду выхода и по первой строке ошибки, а не по тому, сколько длился каждый. Код говорит, сработала ли опция, а первая строка — какой этап не удался.

Удалите тестовый профиль, когда закончите. Копия с намеренно неверной конечной точкой — ловушка для любого, кто позже запустит каждый профиль в каталоге.

Этапы, до которых эта опция никогда не доходит

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

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

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

Похожие статьи