OpenVPN показує active (exited)? Знайдіть запущений вами екземпляр

Ви перевіряєте тунель, запускаєте systemctl status openvpn і отримуєте active (exited) без Main PID і з порожнім списком процесів. Природне прочитання — служба запустилася і померла, тому ви відкриваєте unit, знаходите /bin/true і робите висновок, що пакунок зламаний. У пакунку Debian цей стан — wrapper, який працює як задумано, а тунель живе в одному з instance-unit, які він запускає. Загальний unit ніколи не скаже, який екземпляр його збудував.

Що насправді означає active (exited) у цьому unit

Спакований unit — одноразове завдання: його ExecStart — /bin/true, а RemainAfterExit=yes — те, що утримує завершений unit у стані active (exited). Приберіть цю директиву, і те саме успішне завдання /bin/true завершиться в inactive (dead), а це саме той стан, якого люди чекають і який неправильно читають у зворотному напрямку. Команда — лише заповнювач, а unit повідомляє про роботу, яку виконують інші unit. У цій схемі нічого не зламано, і заміна /bin/true змінює контракт пакування, а не тунель.

Wrapper делегує. Він запускає instance-unit, які постачає конфігурація пакунка або її systemd-генератор, тому порожній список процесів нічого не доводить про тунель. Коли жоден екземпляр не вибрано, wrapper усе одно завершується успішно й усе одно нічого не запускає. Стан відповідає, чи запускався wrapper, а не чи існує тунель.

Читайте три рядки виводу status, а не слово в дужках. Loaded називає файл unit, який прочитав systemd, Active несе позначку часу останнього успішного запуску, а відсутність Main PID відповідає завершеному одноразовому завданню. Ці три рядки — ще й спосіб відрізнити цей wrapper від служби, що впала через секунду після старту.

Перелічіть unit, перш ніж знову читати status

Запитайте systemd, що існує, перш ніж питати, що працює. Шаблон може бути встановлений, поки жоден екземпляр не створено, і лише створений unit несе тунель. Почніть із завантаженого набору:

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

Читайте обидва списки разом, бо шаблон у другому й екземпляр у першому — різні відповіді. Наявний шаблон і працюючий екземпляр — не той самий факт, і лише друге означає тунель. Розкладки пакунків різняться й між дистрибутивами та версіями OpenVPN. Старий шаблон openvpn@, розділена пара client і server та wrapper дистрибутива можуть бути законними у своєму пакуванні.

Пристосовуйтеся до своєї машини, а не до знайденого посібника. Ім'я екземпляра в чужому виводі може бути office, тоді як ваше — home або work. Передається метод, а не рядок.

Ідіть від імені екземпляра до файлу, який він читає

В upstream-шаблоні client робочий каталог unit — /etc/openvpn/client, і його команда бере звідти %i.conf, тому openvpn-client@office читає /etc/openvpn/client/office.conf. Підтвердьте це зіставлення на встановленому unit, а не покладайтеся на приклад, бо ваш шаблон може бути старішим або переписаним дистрибутивом:

systemctl cat [email protected]

Читайте drop-in, які з'являються внизу цього виводу, бо файл під .d/ може змінити ExecStart, робочий каталог або шлях конфігурації. Профіль, який ви завантажили як office.ovpn, — це не файл, який відкриває екземпляр. Цей розрив — звичайна причина, чому помилка називає шлях, який ви ніколи не редагували.

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

Запустіть її, потім прочитайте журнал цього екземпляра

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Запуск і ввімкнення — різні рішення: start виконує unit зараз, enable влаштовує наступне завантаження, а enable --now робить обидві дії за один крок. daemon-reload перечитує визначення unit і не перезапускає працюючий процес і не застосовує змінений профіль. Після зміни профілю перезапустіть екземпляр, бо саме це перечитує файл.

Не ставте другий менеджер на той самий тунель

NetworkManager і менеджери сеансів OpenVPN 3 мають власний стан з'єднання, і екземпляр systemd поруч з одним із них ставить двох власників на той самий тунель. Симптом — тунель, що піднімається й через секунди замінюється, або той, що відмовляється залишатися зупиненим. Виберіть менеджер, який ваш дистрибутив документує для робочого столу, і на сервері свідомо використовуйте systemd.

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

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