OpenVPN se nespouští bez chyby? Podívejte se do journalu

Příkaz se vrátí, služba se zobrazí jako selhaná a do terminálu nedorazí nic, co by připomínalo vysvětlení. To ticho je příznak, který lidé popisují jako „OpenVPN se nespouští“, a téměř nikdy neznamená, že program zemřel, aniž by něco řekl. Znamená, že zpráva šla do kanálu, který jste nečetli, nebo že to, co jste spustili, nebylo to, co jste nakonfigurovali. Oba případy lze diagnostikovat za méně než minutu, jakmile přestanete považovat profil za podezřelý.

Výstup pohlcují čtyři místa: journal jednotky, zásuvný modul, který vlastní připojení, druhý konec tunelu a jiný binární soubor, než o kterém si myslíte, že běží. Každé má svou vlastní kontrolu.

Ticho znamená, že jste se nedívali na správný kanál

Volání v popředí tiskne do vašeho terminálu. Jednotka tiskne do journalu a selhaná jednotka může skončit dřív, než cokoli zapíše, pokud je selhání v tom, jak byla spuštěna, a ne v tom, co jí bylo řečeno. Ten rozdíl je důležitý: žádný záznam v journalu znamená, že proces nikdy skutečně neběžel, zatímco jeden záznam následovaný ukončením znamená, že běžel a něco odmítl.

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

Přidejte systemctl show -p Result -p ExecMainStatus openvpn-client@office k oddělení čistého ukončení od signálu. Stav 1 s Result=exit-code je rozhodnutí programu; Result=signal nebo timeout ukazují spíš na prostředí a žádné množství úprav profilu to nezmění. Zapište obě hodnoty, než cokoli restartujete, protože restart smaže přechodný stav, který je vytvořil.

Název instance je součástí cesty

Zabalená šablonová jednotka nepřijímá cestu k souboru. Přijímá název instance a ten se připojí k adresáři, aby se profil našel: office se překládá na /etc/openvpn/client/office.conf v balíčcích pro Debian a Ubuntu. Soubor s názvem office-v2.conf spuštěný jako @office se nikdy nečte a jednotka tiše skončí, protože z jejího pohledu nebylo co dělat. Adresář pro hledání se liší mezi klientským a serverovým režimem, takže stejná chyba ukazuje úplně jinam, když přepnete šablonu.

Tento nesoulad je nejčastějším zdrojem tichého selhání a v profilu není vidět, protože profil je v pořádku. Vypište, co skutečně existuje, a porovnejte oba názvy znak po znaku, včetně jakékoli přípony, kterou balíček očekává.

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

Pokud je jednotka povolená, ale není uvedena žádná instance, může samotné povolení odkazovat na název, který byl později přejmenován. Znovu povolit správnou instanci obvykle stačí a starý zanechaný soubor jednotky stojí za smazání, aby nepletl dalšího člověka. Zanechaný soubor jednotky je maličkost, která někoho později stojí hodinu.

Když tunel vlastní zásuvný modul, terminál nic nevidí

Připojení spuštěné z appletu na ploše vlastní NetworkManager a jeho výstup OpenVPN jde do journalu této služby, ne do žádného shellu, který máte otevřený. Spustit klienta ručně a nic nevidět je v tomto uspořádání očekávané, protože ručně spuštěný proces není ten, který nese připojení.

Vyhledejte v journalu službu, která ho vlastní, a potom zopakujte parsování s podrobností, kterou můžete číst. Dva příkazy níže se dívají na různé vlastníky stejného selhání.

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

Samostatné spuštění slouží ke čtení zpráv, ne k nahrazení spravovaného připojení, a obojí se potom liší: integrace DNS, trasy a životnost patří zásuvnému modulu. Oprava chyby parsování v samostatném spuštění automaticky neopraví překlad názvů, jakmile applet převezme řízení, takže obě pozorování držte odděleně.

Dva binární soubory, jediná PATH

Ručně sestavená instalace pod /usr/local vyhrává při volání ze shellu, protože /usr/local/sbin předchází /usr/sbin ve výchozím PATH Ubuntu. Jednotka váš PATH nepoužívá; spouští absolutní cestu zapsanou v ExecStart. Verze, která funguje ve vašem terminálu, a verze, která selhává jako služba, tedy mohou být skutečně různé programy.

Porovnejte obě, než cokoli přestavíte. Rozhoduje třetí příkaz.

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

Ještě jeden rozdíl v prostředí se skrývá na stejném místě. Zabalená jednotka spoléhá na adresář za běhu pod /run , který pro ni systemd vytváří; ručně psaná náhradní jednotka, která toto nastavení vynechá, může selhat dřív, než otevře jediný soubor, a selhání vypadá jako obecné odmítnutí bez jakékoli zprávy OpenVPN.

Selhání, která klient nemůže nahlásit

Některé výsledky se rozhodují na vzdáleném konci. Brána, která odpoví stavem HTTP a zavře připojení, vám řekla o svém stavu, a užitečný další krok je její log nebo účet za přihlašovacími údaji, ne vaše místní soubory. V tom scénáři není nic místního rozbité a úprava profilu pro kompenzaci dělá další diagnostiku těžší. Přečtěte si ten log, než se dotknete konfigurace klienta.

Další tichý případ je klient, který pracuje správně. Tunel v klientském režimu nikdy neposlouchá na portu, takže kontrola, která očekává otevřený posluchač, nic nenahlásí a bude vypadat jako selhání. Potvrďte, který režim jste spustili, než z prázdného seznamu portů vyvodíte závěr.

Procházejte vrstvy popořadě: existuje jednotka a je název instance správný, dorazilo něco do journalu nebo do souboru --log, která binárka a profil skutečně běžely a je selhání místní, nebo vzdálené. Každá odpověď odebere vrstvu. Začínat profilem znamená přepisovat soubor, který možná nikdy nebyl otevřen.