OpenVPN sa nespustí: čítajte prvý riadok, nie konfiguráciu

VPN, ktorá zomrie v prvej sekunde, je iné zviera než tá, ktorá sa pripojí a potom zlyhá, a obvyklou chybou je považovať ich za to isté. Nie je tu žiadny handshake, žiadna výmena certifikátov ani trasa na preskúmanie. O tom, ktorá z niekoľkých nesúvisiacich opráv platí, rozhoduje jeden riadok v žurnáli, a jeho preskočenie stojí popoludnie strávené úpravou konfigurácie, ktorá sa nikdy neprečítala. Prečítajte najprv ten riadok.

Dovedú vás tam tri príkazy len na čítanie: journalctl -u openvpn@server -b --no-pager najprv, systemctl status openvpn@server druhý a ss -lunp pre UDP poslucháče a ich vlastníkov.

Prvý riadok vyberá vetvu

Konflikt portov aj chýbajúci binárny súbor zabijú štart behom sekundy a zanechajú odlišné prvé riadky. Hlásenie o už použitej adrese pomenúva port; chýbajúci spustiteľný súbor pomenúva cestu, ktorá už neexistuje; zlyhaná podmienka alebo chýbajúci konfiguračný súbor pomenúva súbor. Tieto tri vedú k odlišným opravám a žiadnej z nich nepomôže preinštalovanie klienta. Prvé zlyhanie si skôr, než čokoľvek spustíte, skopírujte do poznámok.

Dávajte pozor na opakovanú slučku, ktorá skrýva pôvodný riadok. Jednotka so zásadou reštartu môže prvé zlyhanie zasypať tuctom rovnakých, takže journalctl -b filtrovaný podľa jednotky a čítaný od začiatku je lepší než koniec.

Kto ešte drží port 1194

Vinníkom zvyčajne nie je druhý server, ktorý niekto úmyselne nastavil. Očakávajte klienta spusteného ručne, ktorý stále žije v inom termináli, druhý profil, ktorý náhodou zvolil ten istý port, alebo dodávateľský balíček, ktorého vlastný tunel drží 1194. Vlastník socketu sa objaví v ss -lunp; toto PID odovzdajte systemctl status, aby ste zistili, či je zodpovedná jednotka. Zložte ho cez jeho vlastnú riadiacu cestu, nie signálom.

Signál procesu spravovanému jednotkou zvyčajne spustí reštart a to isté zlyhanie sa o chvíľu vráti a vyzerá ako nový problém. Pre jednotku použite systemctl stop, pre dodávateľskú inštaláciu vlastný servisný príkaz balíčka a signál len pre niečo, čo ste spustili ručne v tom shelli.

Zvyšné jednotky po odstránení balíkov

Odstránenie balíka zmaže binárne súbory; ručne napísané jednotkové súbory, zvyčajne pod /etc/systemd/system, ho prežijú. Systemd potom opakuje jednotku ukazujúcu na cestu, ktorá už neexistuje, a správa sa týka tohto chýbajúceho súboru, nie včerajšieho odstránenia. systemctl status zobrazuje fragmentovú cestu jednotky blízko vrchu, takže ju pred čímkoľvek mazaním overte pomocou dpkg -S. Keď je osirenec preč, systemctl daemon-reload a systemctl reset-failed vyčistia stav; inak ho zdedí každá ďalšia kontrola stavu.

Keď which openvpn odpovie niečím pod /usr/local, binárny súbor v hre pochádza od dodávateľského inštalátora, nie z apt. Takýto inštalátor zvyčajne prináša vlastný poslucháč, vlastný štartovací záznam a vlastný konfiguračný adresár, takže odstránenie viditeľného príkazu nechá socket obsadený.

Odinštalujte ho podľa dokumentácie dodávateľa, overte, že port je voľný pomocou ss -lunp, a klientský balík distribúcie pridajte len vtedy, ak ho potrebujete.

Ustáľte stav pred opakovaním

Pred vyvodzovaním záverov vyčistite zlyhaný stav: systemctl reset-failed odstráni počítadlá a systemctl status potom hlási aktuálny stav jednotky, nie jej históriu. Spustite ju raz a čítajte žurnál tejto inštancie, nie súhrnný stav stroja. Jednotka hlásená ako aktívna, kým tunel nič neprenáša, je samostatný problém a oveľa bežnejší. V hláseniach o chybách sa oba zlievajú, pretože oba končia tým, že používateľ hovorí, že VPN nefunguje.

Poznamenajte si, ktorú vetvu ste si vybrali: konflikt portov, chýbajúci binárny súbor, chýbajúca konfigurácia. Ďalší výskyt rozpoznáte rýchlejšie.