OpenVPN не запускается без ошибки? Загляните в journal

Команда возвращается, служба отображается как сбойная, и в терминал не попадает ничего похожего на объяснение. Эта тишина — симптом, который люди описывают как «OpenVPN не запускается», и почти никогда не означает, что программа умерла, ничего не сказав. Это значит, что сообщение ушло в канал, который вы не читали, или что запущенное вами не было тем, что вы настроили. Оба случая диагностируются меньше чем за минуту, как только вы перестаёте считать профиль подозреваемым.

Вывод поглощают четыре места: journal юнита, плагин, которому принадлежит соединение, другой конец туннеля и другой бинарный файл, а не тот, который, по вашему мнению, работает. У каждого своя проверка.

Тишина означает, что вы смотрели не в тот канал

Запуск на переднем плане печатает в ваш терминал. Юнит печатает в journal, а сбойный юнит может завершиться ещё до того, как что-либо запишет, если причина в том, как его запустили, а не в том, что ему сказали. Эта разница важна: отсутствие записи в journal означает, что процесс никогда по-настоящему не работал, тогда как одна запись и последующий выход означают, что он работал и что-то отклонил.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Добавьте systemctl show -p Result -p ExecMainStatus openvpn-client@office чтобы отделить чистый выход от сигнала. Статус 1 с Result=exit-code — это решение программы; Result=signal или тайм-аут указывают скорее на окружение, и никакое редактирование профиля этого не изменит. Запишите оба значения, прежде чем что-либо перезапускать, потому что перезапуск стирает то переходное состояние, которое их создало.

Имя экземпляра — часть пути

Упакованный шаблонный юнит не принимает путь к файлу. Он принимает имя экземпляра, и это имя добавляется к каталогу, чтобы найти профиль: office в пакетах Debian и Ubuntu разрешается в /etc/openvpn/client/office.conf. Файл с именем office-v2.conf, запущенный как @office никогда не читается, и юнит тихо завершается, потому что с его точки зрения делать было нечего. Каталог поиска различается в клиентском и серверном режимах, поэтому одна и та же ошибка при смене шаблона указывает совсем в другое место.

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

Когда туннелем владеет плагин, терминал ничего не видит

Соединение, запущенное из апплета рабочего стола, принадлежит NetworkManager, и его вывод OpenVPN идёт в journal этой службы, а не в какую-либо открытую вами оболочку. Запускать клиент вручную и не видеть ничего в такой схеме ожидаемо, потому что запущенный вручную процесс — не тот, который несёт соединение.

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

Два бинарных файла, один PATH

Сборка, установленная вручную в /usr/local выигрывает при вызове из оболочки, потому что /usr/local/sbin идёт раньше /usr/sbin в PATH Ubuntu по умолчанию. Юнит не использует ваш PATH; он выполняет абсолютный путь, записанный в ExecStart. Поэтому версия, которая работает в вашем терминале, и версия, которая сбоит как служба, могут быть действительно разными программами.

Сравните обе, прежде чем что-либо пересобирать. Третья команда — та, что решает спор.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Ещё одно различие окружения прячется в том же месте. Упакованный юнит полагается на каталог времени выполнения в /run который создаёт для него systemd; написанный вручную заменяющий юнит, пропускающий эту настройку, может сбоить ещё до открытия хотя бы одного файла, и сбой выглядит как общий отказ без какого-либо сообщения OpenVPN.

Сбои, о которых клиент не может сообщить

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

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

Проходите слои по порядку: существует ли юнит и правильное ли имя экземпляра, дошло ли что-то до journal или до файла --log , какой бинарный файл и профиль действительно работали, и локален ли сбой или удалён. Каждый ответ убирает один слой. Начинать с профиля — значит переписывать файл, который, возможно, никогда не открывался.