Переподключение клиента OpenVPN: три средства, три области

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

Спросите, кого это должно затронуть, прежде чем спрашивать, какое средство использовать.

Один экземпляр: интерфейс управления

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

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

Уведомление о выходе UDP — не команда для отдельного клиента

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

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

Сигналы действуют на процесс, а не на сессию

SIGUSR1 просит работающий процесс перезапустить своё соединение без повторного чтения конфигурации, а параметры сохранения решают, что переживёт этот перезапуск. SIGHUP идёт дальше: он повторно читает файл конфигурации и заново открывает свои ресурсы. SIGTERM и SIGINT требуют упорядоченного завершения. Это операции уровня процесса: на сервере с многими клиентами они затрагивают каждую сессию, которую несёт процесс, а не ту, что указана в заявке.

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

Определите область до выбора средства

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

Добавление неаутентифицированного слушателя управления ради кнопки переподключения передаёт любому, кто дотянется до порта, гораздо больше, чем эта кнопка.

Проверяйте новую сессию, а не разрыв

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

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