keepalive в OpenVPN или restart в systemd: что восстанавливает туннель?

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

Три сбоя, которые выглядят как один

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

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

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

Во что на самом деле разворачивается keepalive

Директива keepalive — это сокращение, и развёртывание зависит от режима. На сервере keepalive 10 60 превращается в локальный ping каждые десять секунд, локальный тайм-аут перезапуска 120 секунд и значения 10 и 60, которые передаются клиентам. Тайм-аут сервера намеренно удвоен, чтобы клиент успел перезапуститься до того, как сервер сдастся. Читайте развёрнутую форму в работающей конфигурации, а не сокращение в профиле.

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

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

За чем не следит Restart=on-failure

Прочитайте установленный юнит, прежде чем добавлять переопределение. Restart=on-failure реагирует на документированные условия отказа процесса, что не то же самое, что слежение за состоянием соединения. Он не срабатывает из-за того, что началось внутреннее переподключение, а чистый выход имеет другую семантику, чем падение.

Это различие важно, потому что внутренний перезапуск сохраняет тот же процесс живым. Юнит ничего не видит, туннель восстанавливается сам, и это правильный результат.

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

ping-restart и ping-exit не взаимозаменяемы

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

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

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

Проверяйте каждый сбой как отдельный случай

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

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