OpenVPN hlási active (exited)? Nájdite inštanciu, ktorú ste spustili

Skontrolujete tunel, spustíte systemctl status openvpn a dostanete active (exited) bez Main PID a s prázdnym zoznamom procesov. Prirodzené čítanie je, že služba sa spustila a zomrela, takže otvoríte unit, nájdete /bin/true a usúdite, že balík je pokazený. V balíku pre Debian je tento stav wrapper, ktorý pracuje podľa návrhu, a tunel žije v jednej z inštančných jednotiek, ktoré spúšťa. Súhrnná jednotka vám nikdy nepovie, ktorá inštancia ju postavila.

Čo active (exited) na tejto jednotke naozaj znamená

Zabalená jednotka je jednorazová úloha: jej ExecStart je /bin/true a RemainAfterExit=yes je to, čo drží dokončenú jednotku hlásenú ako active (exited). Odoberte túto direktívu a tá istá úspešná úloha /bin/true skončí v inactive (dead), čo je presne stav, ktorý ľudia očakávajú a v opačnom smere ho čítajú nesprávne. Príkaz je len zástupný prvok a jednotka podáva správu o práci, ktorú vykonávajú iné jednotky. Na tomto usporiadaní nie je nič pokazené a nahradenie /bin/true mení zmluvu balíka, nie tunel.

Wrapper deleguje. Spúšťa inštančné jednotky, ktoré dodáva konfigurácia balíka alebo jej systemd generátor, a preto prázdny zoznam procesov o tuneli nič nedokazuje. Keď nie je vybraná žiadna inštancia, wrapper napriek tomu uspeje a napriek tomu nič nespustí. Stav odpovedá na to, či wrapper bežal, nie na to, či existuje tunel.

Čítajte tri riadky výstupu status, nie slovo v zátvorke. Loaded pomenúva súbor jednotky, ktorý systemd prečítal, Active nesie časovú pečiatku posledného úspešného behu a chýbajúci Main PID zodpovedá dokončenej jednorazovej úlohe. Tieto tri riadky sú aj spôsob, ako odlíšiť tento wrapper od služby, ktorá spadla sekundu po štarte.

Vypíšte jednotky, skôr než status prečítate znova

Opýtajte sa systemd, čo existuje, skôr než sa opýtate, čo beží. Šablóna môže byť nainštalovaná, hoci nie je vytvorená žiadna inštancia, a tunel nesie len vytvorená jednotka. Začnite s načítanou sadou:

systemctl list-units 'openvpn*'

Tento zoznam je to, čo systemd v tejto chvíli načítal, a je to najbližšie k inventáru tunelov. Nainštalované súbory jednotiek odpovedajú na inú otázku a tento zoznam stále ukazuje šablónu, keď nie je nič vytvorené:

systemctl list-unit-files 'openvpn*'

Čítajte oba zoznamy spolu, pretože šablóna v druhom a inštancia v prvom sú dve rôzne odpovede. Existujúca šablóna a bežiaca inštancia nie sú ten istý fakt a len druhé znamená tunel. Usporiadania balíkov sa líšia aj medzi distribúciami a verziemi OpenVPN. Staršia šablóna openvpn@, oddelená dvojica client a server a distribučný wrapper môžu byť všetky legitímne vo vlastnom balení.

Prispôsobte sa svojmu stroju, nie návodu, ktorý ste našli. Názov inštancie vo výstupe niekoho iného môže byť office, zatiaľ čo váš je home alebo work. Prechádza metóda, nie reťazec.

Choďte od názvu inštancie k súboru, ktorý číta

V upstream šablóne client je pracovný adresár jednotky /etc/openvpn/client a jej príkaz odtiaľ berie %i.conf, takže openvpn-client@office číta /etc/openvpn/client/office.conf. Potvrďte toto mapovanie na nainštalovanej jednotke namiesto dôvery v príklad, pretože šablóna, ktorú máte, môže byť staršia alebo distribúciou prepísaná:

systemctl cat [email protected]

Čítajte drop-in súbory, ktoré sa objavujú na konci tohto výstupu, pretože súbor pod .d/ môže zmeniť ExecStart, pracovný adresár alebo cestu ku konfigurácii. Profil, ktorý ste stiahli ako office.ovpn, nie je súbor, ktorý inštancia otvára. Táto medzera je bežný dôvod, prečo chyba pomenuje cestu, ktorú ste nikdy neupravovali.

Relatívne cesty vnútri profilu sú ďalšia pasca. Presunutie hlavného súboru pri zachovaní relatívnych odkazov ca, cert a key vymení chybu chýbajúceho súboru za inú chybu chýbajúceho súboru. Druhá ukazuje na súbor, o ktorého existencii ste boli presvedčení, a preto je adresár profilu dôležitejší než názov súboru.

Spustite ju a potom čítajte journal tejto inštancie

Spustite inštanciu, ktorú ste práve skontrolovali, pretože log súhrnnej jednotky nebude obsahovať chyby tunela. Potom čítajte journal tohto bootu a hľadajte v tomto poradí chybu konfigurácie, chybu prístupu k súboru a chybu pripojenia, pretože každá zlyháva v inej fáze štartu.

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

Spustenie a povolenie sú samostatné rozhodnutia: start spustí jednotku teraz, enable zariadi ďalší boot a enable --now robí oboje v jednom kroku. daemon-reload znova načíta definície jednotiek a nereštartuje bežiaci proces ani neaplikuje upravený profil. Po zmene profilu reštartujte inštanciu, pretože to znova načíta súbor.

Nedávajte na ten istý tunel druhého správcu

NetworkManager a správcovia relácií OpenVPN 3 majú vlastný stav pripojenia a inštancia systemd vedľa jedného z nich stavia na ten istý tunel dvoch vlastníkov. Príznakom je tunel, ktorý sa zdvihne a o pár sekúnd je nahradený, alebo ten, ktorý odmieta zostať zastavený. Vyberte správcu, ktorého vaša distribúcia dokumentuje pre pracovnú plochu, a na serveri systemd používajte zámerne.

Pred spustením inštancie skontrolujte, či už existuje vlastník. Keď applet na ploche zobrazuje pripojenie, inštancia, ktorú spustíte, súťaží s ním namiesto toho, aby ho doplnila. Vypnite správcu, ktorého nepoužívate, namiesto toho, aby ste púšťali oboch a dúfali, že poradie vydrží. Tento konflikt vysvetľuje aj journaly, v ktorých sa tunel nadviaže a potom ho zrúti proces, ktorý ste nikdy nespustili.

Odpovedzte na pôvodnú otázku názvom inštancie, súborom, ktorý prečítala, a riadkom journalu, ktorý zlyhal. Poznámky OpenVPN k integrácii so systemd opisujú usporiadanie šablóny a mapovanie súboru, cez ktoré sa názov inštancie rozlišuje.