OpenVPN hlásí active (exited)? Najděte instanci, kterou jste spustili

Zkontrolujete tunel, spustíte systemctl status openvpn a dostanete active (exited) bez Main PID a s prázdným seznamem procesů. Přirozené čtení je, že služba nastartovala a zemřela, takže otevřete unit, najdete /bin/true a usoudíte, že je balíček rozbitý. V balíčku pro Debian je tento stav wrapper, který pracuje podle návrhu, a tunel žije v jedné z instančních jednotek, které spouští. Souhrnná jednotka vám nikdy neřekne, která instance ji postavila.

Co active (exited) na této jednotce skutečně znamená

Zabalená jednotka je jednorázová úloha: její ExecStart je /bin/true a RemainAfterExit=yes je to, co drží dokončenou jednotku hlášenou jako active (exited). Odeberte tuto direktivu a stejná úspěšná úloha /bin/true skončí v inactive (dead), což je přesně stav, který lidé očekávají a v opačném směru ho čtou špatně. Příkaz je zástupný prvek a jednotka podává zprávu o práci, kterou vykonávají jiné jednotky. Na tomto uspořádání není nic rozbité a nahrazení /bin/true mění smlouvu balíčku, nikoli tunel.

Wrapper deleguje. Spouští instanční jednotky, které dodává konfigurace balíčku nebo její systemd generátor, a proto prázdný seznam procesů o tunelu nic nedokazuje. Když není vybrána žádná instance, wrapper přesto uspěje a přesto nic nespustí. Stav odpovídá na to, zda wrapper běžel, ne na to, zda existuje tunel.

Čtěte tři řádky výstupu status, ne slovo v závorce. Loaded pojmenovává soubor jednotky, který systemd přečetl, Active nese časové razítko posledního úspěšného běhu a chybějící Main PID odpovídá dokončené jednorázové úloze. Tyto tři řádky jsou také způsob, jak tento wrapper odlišit od služby, která spadla sekundu po startu.

Vypište jednotky, než status přečtete znovu

Ptejte se systemd, co existuje, než se zeptáte, co běží. Šablona může být nainstalovaná, aniž je vytvořena instance, a tunel nese jen vytvořená jednotka. Začněte načtenou sadou:

systemctl list-units 'openvpn*'

Tento seznam je to, co systemd v tuto chvíli načetl, a je to nejblíž inventáři tunelů. Nainstalované soubory jednotek odpovídají na jinou otázku a tento seznam stále ukazuje šablonu, když není nic vytvořeno:

systemctl list-unit-files 'openvpn*'

Čtěte oba seznamy společně, protože šablona ve druhém a instance v prvním jsou různé odpovědi. Šablona, která existuje, a instance, která běží, nejsou stejný fakt a jen druhá znamená tunel. Uspořádání balíčků se liší i mezi distribucemi a verzemi OpenVPN. Starší šablona openvpn@, oddělená dvojice client a server a distribuční wrapper mohou být všechny legitimní ve vlastním balíčku.

Přizpůsobte se svému stroji, ne návodu, který jste našli. Název instance ve výstupu někoho jiného může být office, zatímco váš je home nebo work. Přenáší se metoda, ne řetězec.

Jděte od názvu instance k souboru, který čte

V upstream šabloně client je pracovní adresář jednotky /etc/openvpn/client a její příkaz odtud bere %i.conf, takže openvpn-client@office čte /etc/openvpn/client/office.conf. Ověřte toto mapování na nainstalované jednotce, místo abyste věřili příkladu, protože šablona, kterou máte, může být starší nebo přepsaná distribucí:

systemctl cat [email protected]

Čtěte drop-in soubory, které se objevují na konci tohoto výstupu, protože soubor pod .d/ může změnit ExecStart, pracovní adresář nebo cestu ke konfiguraci. Profil, který jste stáhli jako office.ovpn, není soubor, který instance otevírá. Tato mezera je obvyklý důvod, proč chyba uvádí cestu, kterou jste nikdy neupravovali.

Relativní cesty uvnitř profilu jsou další past. Přesunutí hlavního souboru při ponechání relativních odkazů ca, cert a key vymění chybu chybějícího souboru za jinou chybu chybějícího souboru. Druhá ukazuje na soubor, o jehož existenci jste byli přesvědčeni, a proto je adresář profilu důležitější než název souboru.

Spusťte ji a pak čtěte journal této instance

Spusťte instanci, kterou jste právě prozkoumali, protože log souhrnné jednotky nebude obsahovat chyby tunelu. Potom čtěte journal tohoto bootu a hledejte v tomto pořadí chybu konfigurace, chybu přístupu k souboru a chybu připojení, protože každá selhává v jiné fázi startu.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Spuštění a povolení jsou samostatná rozhodnutí: start spustí jednotku teď, enable zařídí příští boot a enable --now dělá obojí v jednom kroku. daemon-reload znovu načte definice jednotek a nerestartuje běžící proces ani neaplikuje upravený profil. Po změně profilu restartujte instanci, protože to znovu načte soubor.

Nedávejte na stejný tunel druhého správce

NetworkManager a správci relací OpenVPN 3 vlastní svůj stav připojení a instance systemd vedle jednoho z nich staví na stejný tunel dva vlastníky. Příznakem je tunel, který se zvedne a o pár sekund později je nahrazen, nebo ten, který odmítá zůstat zastavený. Vyberte správce, kterého vaše distribuce dokumentuje pro plochu, a na serveru systemd používejte záměrně.

Před spuštěním instance zkontrolujte, zda už nějaký vlastník existuje. Když applet na ploše zobrazuje připojení, instance, kterou spustíte, s ním soutěží, místo aby ho dokončila. Vypněte správce, který nepoužíváte, místo abyste pouštěli oba a doufali, že pořadí vydrží. Tento konflikt také vysvětluje journaly, v nichž se tunel naváže a pak ho zboří proces, který jste nikdy nespustili.

Odpovězte na původní otázku názvem instance, souborem, který přečetla, a řádkem journalu, který selhal. Poznámky OpenVPN k integraci se systemd popisují uspořádání šablony a mapování souboru, přes které se název instance rozlišuje.