OpenVPN sa nespustí bez chyby? Pozrite sa do journalu

Príkaz sa vráti, služba sa zobrazí ako zlyhaná a do terminálu sa nedostane nič, čo pripomína vysvetlenie. To ticho je príznak, ktorý ľudia opisujú ako „OpenVPN sa nespustí“, a takmer nikdy neznamená, že program zomrel bez toho, aby niečo povedal. Znamená, že správa išla do kanála, ktorý ste nečítali, alebo že to, čo ste spustili, nebolo to, čo ste nakonfigurovali. Oba prípady sa dajú diagnostikovať za menej ako minútu, keď prestanete považovať profil za podozrivý.

Výstup pohlcujú štyri miesta: journal jednotky, zásuvný modul, ktorý vlastní pripojenie, druhý koniec tunela a iný binárny súbor než ten, o ktorom si myslíte, že beží. Každé má vlastnú kontrolu.

Ticho znamená, že ste sa nepozerali na správny kanál

Volanie v popredí tlačí do vášho terminálu. Jednotka tlačí do journalu a zlyhaná jednotka môže skončiť skôr, než čokoľvek zapíše, ak je zlyhanie v tom, ako bola spustená, a nie v tom, čo jej bolo povedané. Ten rozdiel je dôležitý: žiadny záznam v journalu znamená, že proces nikdy skutočne nebežal, zatiaľ čo jeden záznam a po ňom ukončenie znamená, že bežal a niečo odmietol.

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

Pridajte systemctl show -p Result -p ExecMainStatus openvpn-client@office na oddelenie čistého ukončenia od signálu. Stav 1 s Result=exit-code je rozhodnutie programu; Result=signal alebo časový limit ukazujú skôr na prostredie a žiadna úprava profilu to nezmení. Zapíšte obe hodnoty, skôr než čokoľvek reštartujete, pretože reštart vymaže prechodný stav, ktorý ich vytvoril.

Názov inštancie je súčasťou cesty

Zabalená šablónová jednotka neprijíma cestu k súboru. Prijíma názov inštancie a ten sa pripojí k adresáru, aby sa profil našiel: office v balíkoch Debian a Ubuntu sa prekladá na /etc/openvpn/client/office.conf. Súbor s názvom office-v2.conf, spustený ako @office sa nikdy nečíta a jednotka ticho skončí, pretože z jej pohľadu nebolo čo robiť. Adresár na hľadanie sa líši medzi klientskym a serverovým režimom, takže tá istá chyba ukazuje úplne inam, keď prepnete šablónu.

Tento nesúlad je najčastejším zdrojom tichého zlyhania a v profile nie je viditeľný, pretože profil je v poriadku. Vypíšte, čo skutočne existuje, a porovnajte oba názvy znak po znaku vrátane každej prípony, ktorú balík očakáva.

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

Ak je jednotka povolená, ale nie je uvedená žiadna inštancia, samotné povolenie môže odkazovať na názov, ktorý bol neskôr premenovaný. Opätovné povolenie správnej inštancie zvyčajne stačí a starý zanechaný súbor jednotky sa oplatí zmazať, aby nemýlil ďalšieho človeka. Zanechaný súbor jednotky je maličkosť, ktorá niekoho neskôr stojí hodinu.

Keď tunel vlastní zásuvný modul, terminál nič nevidí

Pripojenie spustené z appletu na ploche vlastní NetworkManager a jeho výstup OpenVPN ide do journalu tejto služby, nie do žiadneho shellu, ktorý máte otvorený. Spustiť klienta ručne a nič nevidieť je v tomto usporiadaní očakávané, pretože ručne spustený proces nie je ten, ktorý nesie pripojenie.

Vyhľadajte v journalu službu, ktorá ho vlastní, a potom zopakujte parsovanie s podrobnosťou, ktorú dokážete čítať. Dva príkazy nižšie sa pozerajú na rôznych vlastníkov toho istého zlyhania.

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

Samostatné spustenie slúži na čítanie správ, nie na nahradenie spravovaného pripojenia, a obe sa potom líšia: integrácia DNS, trasy a životnosť patria zásuvnému modulu. Oprava chyby parsovania v samostatnom spustení automaticky neopraví preklad názvov, keď applet prevezme kontrolu, takže obe pozorovania držte oddelene.

Dva binárne súbory, jedna PATH

Ručne zostavená inštalácia pod /usr/local vyhráva pri volaní zo shellu, pretože /usr/local/sbin predchádza /usr/sbin v predvolenom PATH Ubuntu. Jednotka nepoužíva váš PATH; spúšťa absolútnu cestu zapísanú v ExecStart. Verzia, ktorá funguje vo vašom termináli, a verzia, ktorá zlyháva ako služba, teda môžu byť naozaj rôzne programy.

Porovnajte obe, skôr než čokoľvek prestavíte. Rozhoduje tretí príkaz.

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

Ďalší rozdiel v prostredí sa skrýva na tom istom mieste. Zabalená jednotka sa spolieha na adresár za behu pod /run, ktorý pre ňu vytvára systemd; ručne napísaná náhradná jednotka, ktorá toto nastavenie vynechá, môže zlyhať skôr, než otvorí jediný súbor, a zlyhanie vyzerá ako všeobecné odmietnutie bez akéhokoľvek hlásenia OpenVPN.

Zlyhania, ktoré klient nedokáže nahlásiť

Niektoré výsledky sa rozhodujú na vzdialenom konci. Brána, ktorá odpovie stavom HTTP a zatvorí pripojenie, vám už povedala o svojom stave, a užitočný ďalší krok je jej log alebo účet za prihlasovacími údajmi, nie vaše miestne súbory. V tomto scenári nie je nič miestne pokazené a úprava profilu na kompenzáciu robí ďalšiu diagnostiku ťažšou. Prečítajte si ten log, skôr než sa dotknete konfigurácie klienta.

Ďalší tichý prípad je klient, ktorý pracuje správne. Tunel v klientskom režime nikdy nepočúva na porte, takže kontrola, ktorá očakáva otvoreného poslucháča, nič nenahlási a bude vyzerať ako zlyhanie. Potvrďte, ktorý režim ste spustili, skôr než z prázdneho zoznamu portov vyvodíte záver.

Prechádzajte vrstvy po poriadku: existuje jednotka a je názov inštancie správny, dostalo sa niečo do journalu alebo do súboru --log, ktorý binárny súbor a profil skutočne bežali, a je zlyhanie miestne alebo vzdialené. Každá odpoveď odoberie vrstvu. Začínať profilom znamená prepísať súbor, ktorý možno nikdy nebol otvorený.