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 описывают раскладку шаблона и сопоставление файла, через которое разрешается имя экземпляра.