OpenVPN не запускается: читайте первую строку, а не конфигурацию

VPN, который умирает в первую секунду, — совсем другой зверь, чем тот, который подключается и затем падает, и обычная ошибка — считать их одним и тем же. Здесь нет ни рукопожатия, ни обмена сертификатами, ни маршрута для осмотра. Одна строка в журнале решает, какое из нескольких несвязанных исправлений применимо, и её пропуск стоит полдня правки конфигурации, которую так и не прочитали. Сначала прочитайте эту строку.

Три команды только для чтения приведут вас туда: сначала journalctl -u openvpn@server -b --no-pager, затем systemctl status openvpn@server, и ss -lunp для UDP-слушателей и их владельцев.

Первая строка выбирает ветку

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

Следите за циклом повторов, который скрывает исходную строку. Юнит с политикой перезапуска может похоронить первый сбой под дюжиной одинаковых, поэтому journalctl -b, отфильтрованный по юниту и прочитанный сверху, лучше хвоста.

Кто ещё держит порт 1194

Виновник обычно не второй сервер, который кто-то намеренно настроил. Ждите клиента, запущенного вручную и всё ещё живого в другом терминале, второй профиль, случайно выбравший тот же порт, или пакет поставщика, чей собственный туннель держит 1194. Владелец сокета появляется в ss -lunp; передайте этот PID в systemctl status, чтобы узнать, отвечает ли за него юнит. Остановите его через собственный путь управления, а не сигналом.

Сигнал процессу, управляемому юнитом, обычно вызывает перезапуск, и тот же сбой через мгновение появляется снова как новая проблема. Используйте systemctl stop для юнита, собственную команду службы пакета для установки поставщика, а сигнал — только для того, что вы сами запустили в этом shell.

Оставшиеся юниты после удаления

Удаление стирает бинарники; файлы юнитов, написанные вручную, обычно в /etc/systemd/system, это переживают. Тогда Systemd снова пытается запустить юнит, указывающий на путь, которого больше нет, и сообщение касается этого отсутствующего файла, а не вчерашнего удаления. systemctl status показывает путь фрагмента юнита ближе к верху, поэтому проверьте его с помощью dpkg -S, прежде чем что-либо удалять. Как только сирота исчезнет, systemctl daemon-reload и systemctl reset-failed очищают состояние; иначе каждая последующая проверка статуса его наследует.

Когда which openvpn отвечает чем-то из /usr/local, задействованный бинарник пришёл от установщика поставщика, а не из apt. Такой установщик обычно приносит свой слушатель, свою загрузочную запись и свой каталог конфигурации, поэтому удаление видимой команды оставляет сокет занятым.

Удалите его так, как документирует поставщик, убедитесь с помощью ss -lunp, что порт свободен, и добавьте клиент дистрибутива только если он вам нужен.

Приведите состояние в порядок перед повтором

Очистите состояние сбоя, прежде чем делать из него выводы: systemctl reset-failed убирает счётчики, и systemctl status затем сообщает текущее состояние юнита, а не его историю. Запустите его один раз и читайте журнал именно этого запуска, а не сводное состояние машины. Юнит, который сообщает об активности, пока туннель ничего не передаёт, — отдельная проблема, и гораздо более частая. Обе сливаются в баг-репортах, потому что обе заканчиваются словами пользователя о том, что VPN не работает.

Запишите, какую ветку вы выбрали: конфликт портов, отсутствующий бинарник, отсутствующая конфигурация. В следующий раз распознать будет быстрее.