Перепідключення клієнта OpenVPN: три засоби, три області

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

Запитайте, кого це має зачепити, перш ніж питати, який засіб використовувати.

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

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

Це не гарантує нового з'єднання. Чи повернеться клієнт, залежить від його налаштувань повторних спроб, залишкових віддалених записів, вимог автентифікації й того, чи ще працює контролюючий застосунок. Клієнт, що повертається, отримує новий ідентифікатор, тому порівняння ідентифікаторів — єдиний надійний спосіб відрізнити старе від нового.

UDP-повідомлення про вихід не є командою для окремого клієнта

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

Ніщо в ньому не вибирає довільного клієнта в довільний момент. Якщо ставитися до нього як до кнопки перепідключення, воно одночасно сягає всіх підключених сесій.

Сигнали діють на процес, а не на сесію

SIGUSR1 просить робочий процес перезапустити своє з'єднання без повторного читання конфігурації, а параметри збереження вирішують, що переживе цей перезапуск. SIGHUP іде далі: він повторно читає файл конфігурації й наново відкриває свої ресурси. SIGTERM і SIGINT вимагають упорядкованого завершення. Це операції рівня процесу: на сервері з багатьма клієнтами вони зачіпають кожну сесію, яку несе процес, а не ту, що вказана в заявці.

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

Визначте область до вибору засобу

Три питання це вирішують. Кого це має зачепити: одного користувача, усіх клієнтів одного сервера або демон і все, що він несе. Що має зберегтися: конфігурація, стан тунелю чи ніщо. Хто на це уповноважений: інтеграція керування, власник сервісу або мережевий оператор, який керує повідомленням про вихід. Дайте відповідь — і підходить лише один засіб.

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

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

Подія розриву доводить, що стара сесія завершилася. Вона нічого не каже про нову, яка автентифікується, отримує адресу, встановлює маршрути або досягає ресурсу, потрібного користувачеві. Перевірте новий ідентифікатор, потім стан тунелю, потім один реальний ресурс. Ці три кроки — різниця між перепідключенням і працюючим з'єднанням.

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