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 не работи.

Забележете ја гранката што ја избравте: судир на портови, недостижен бинарен файл, недостижна конфигурација. Следниот пат ќе се препознава побрзо.