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

VPN, който умира в първата секунда, е различно животно от този, който се свързва и след това се проваля, и обичайната грешка е да се третират като едно и също. Тук няма handshake, няма обмен на сертификати и няма маршрут за проверка. Един ред в журнала решава кой от няколко несвързани ремонта се прилага, и пропускането му струва следобед редактиране на конфигурация, която така и не е прочетена. Прочетете този ред първо.

Три команди само за четене ви водят дотам: първо 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 за юнит, собствената команда за услуга на пакета за инсталация на доставчик и сигнал само за нещо, което сами сте стартирали в тази обвивка.

Остатъчни юнити след премахване

Премахването изтрива бинарните файлове; файловете на юнити, написани на ръка, обикновено под /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 не работи.

Отбележете клона, който поехте: конфликт на портове, липсващ бинарен файл, липсваща конфигурация. Следващият път ще бъде по-бързо за разпознаване.