Чому ваш клієнт 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 пристрій живе довше за сеанс, і перевірка повідомляє про здоров'я, коли нічого не передається.