OpenVPN afișează active (exited)? Găsiți instanța pe care ați pornit-o

Verificați tunelul, rulați systemctl status openvpn și primiți active (exited) fără Main PID și cu o listă de procese goală. Citirea firească este că serviciul a pornit și a murit, așa că deschideți unitatea, găsiți /bin/true și concluzionați că pachetul este stricat. În ambalajul Debian acea stare este wrapperul care lucrează conform proiectării, iar tunelul trăiește într-una dintre unitățile de instanță pe care le pornește. Unitatea agregată nu vă va spune niciodată care instanță a construit-o.

Ce înseamnă de fapt active (exited) pe această unitate

Unitatea împachetată este o sarcină unică: ExecStart-ul ei este /bin/true, iar RemainAfterExit=yes este ceea ce ține o unitate terminată raportată ca active (exited). Scoateți acea directivă și aceeași sarcină /bin/true reușită se termină în inactive (dead), exact starea pe care oamenii o așteaptă și o citesc greșit în direcția opusă. Comanda este doar un substituent, iar unitatea raportează despre munca pe care o fac alte unități. Nimic din această aranjare nu este stricat, iar înlocuirea /bin/true schimbă contractul de ambalare, nu tunelul.

Wrapperul deleagă. Pornește unitățile de instanță pe care le furnizează configurația pachetului sau generatorul ei systemd, de aceea o listă de procese goală nu dovedește nimic despre tunel. Când nu este selectată nicio instanță, wrapperul reușește totuși și totuși nu pornește nimic. Starea răspunde dacă wrapperul a rulat, nu dacă există un tunel.

Citiți cele trei linii ale ieșirii status, nu cuvântul dintre paranteze. Loaded numește fișierul de unitate pe care l-a citit systemd, Active poartă marca de timp a ultimei rulări reușite, iar absența Main PID se potrivește cu o sarcină unică terminată. Acele trei linii sunt și modul de a distinge acest wrapper de un serviciu care a căzut o secundă după pornire.

Listați unitățile înainte de a citi din nou statusul

Întrebați systemd ce există înainte de a întreba ce rulează. Un șablon poate fi instalat fără ca vreo instanță să fie creată, iar doar o unitate creată poartă un tunel. Începeți cu setul încărcat:

systemctl list-units 'openvpn*'

Acea listă este ce a încărcat systemd în acest moment și este cel mai apropiat lucru de un inventar al tunelurilor. Fișierele de unitate instalate răspund la altă întrebare, iar acea listă arată în continuare un șablon când nu s-a creat nimic:

systemctl list-unit-files 'openvpn*'

Citiți ambele liste împreună, pentru că un șablon în a doua și o instanță în prima sunt răspunsuri diferite. Un șablon care există și o instanță care rulează nu sunt același fapt, iar doar al doilea înseamnă un tunel. Aranjamentele pachetelor variază și între distribuții și versiunile OpenVPN. Un șablon openvpn@ mai vechi, o pereche separată client și server și un wrapper de distribuție pot fi toate legitime în propriul ambalaj.

Adaptați-vă la mașina dumneavoastră, nu la tutorialul pe care l-ați găsit. Numele instanței din ieșirea altcuiva poate fi office, în timp ce al dumneavoastră este home sau work. Ceea ce se transferă este metoda, nu șirul.

Urmați numele instanței până la fișierul pe care îl citește

În șablonul client upstream directorul de lucru al unității este /etc/openvpn/client, iar comanda ei ia %i.conf de acolo, așa că openvpn-client@office citește /etc/openvpn/client/office.conf. Confirmați această mapare pe unitatea instalată în loc să vă bazați pe exemplu, pentru că șablonul pe care îl aveți poate fi mai vechi sau o rescriere a distribuției:

systemctl cat [email protected]

Citiți drop-in-urile care apar în josul acelei ieșiri, pentru că un fișier sub .d/ poate schimba ExecStart, directorul de lucru sau calea configurației. Un profil descărcat ca office.ovpn nu este fișierul pe care instanța îl deschide. Acea diferență este motivul obișnuit pentru care o eroare numește o cale pe care nu ați editat-o niciodată.

Căile relative din interiorul profilului sunt următoarea capcană. Mutarea fișierului principal în timp ce referințele ca, cert și key rămân relative schimbă o eroare de fișier lipsă cu o altă eroare de fișier lipsă. A doua indică un fișier despre care erați sigur că există, de aceea directorul profilului contează mai mult decât numele fișierului.

Porniți-o, apoi citiți jurnalul acelei instanțe

Porniți instanța pe care tocmai ați inspectat-o, pentru că jurnalul unității agregate nu va conține erorile tunelului. Apoi citiți jurnalul pentru această pornire și căutați în această ordine o eroare de configurație, o eroare de acces la fișier și o eroare de conexiune, pentru că fiecare eșuează într-o etapă diferită a pornirii.

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

Pornirea și activarea sunt decizii separate: start rulează unitatea acum, enable pregătește următoarea pornire, iar enable --now le face pe amândouă într-un singur pas. daemon-reload recitește definițiile unităților și nu repornește un proces care rulează și nu aplică un profil editat. După ce ați schimbat profilul, reporniți instanța, pentru că asta recitește fișierul.

Nu puneți un al doilea manager pe același tunel

NetworkManager și managerii de sesiune OpenVPN 3 au propriul lor stare a conexiunii, iar o instanță systemd lângă unul dintre ei pune doi proprietari pe același tunel. Simptomul este un tunel care urcă și este înlocuit câteva secunde mai târziu, sau unul care refuză să rămână oprit. Alegeți managerul pe care distribuția dumneavoastră îl documentează pentru desktop și folosiți systemd deliberat pe un server.

Verificați dacă există deja un proprietar înainte de a porni o instanță. Când o aplicație de desktop arată conexiunea, instanța pe care o porniți concurează cu ea în loc să o completeze. Dezactivați managerul pe care nu îl folosiți în loc să le rulați pe amândouă și să sperați că ordinea se păstrează. Acel conflict explică și jurnalele în care un tunel este stabilit și apoi demolat de un proces pe care nu l-ați pornit niciodată.

Răspundeți la întrebarea inițială cu numele instanței, fișierul pe care l-a citit și linia de jurnal care a eșuat. Notele OpenVPN despre integrarea cu systemd descriu aranjarea șablonului și maparea fișierului prin care se rezolvă numele instanței.