OpenVPN nu pornește fără eroare? Uitați-vă în journal

Comanda revine, serviciul apare ca eșuat și nimic care să semene cu o explicație nu ajunge în terminal. Acea tăcere este simptomul pe care oamenii îl descriu ca «OpenVPN nu pornește», și aproape niciodată nu înseamnă că programul a murit fără să spună nimic. Înseamnă că mesajul a mers într-un canal pe care nu îl citeai, sau că ceea ce ai pornit nu era ceea ce ai configurat. Ambele cazuri pot fi diagnosticate în mai puțin de un minut odată ce încetezi să tratezi profilul ca suspect.

Patru locuri absorb ieșirea: journal-ul unității, pluginul care deține conexiunea, celălalt capăt al tunelului și un binar diferit de cel despre care crezi că rulează. Fiecare are propria verificare.

Tăcerea înseamnă că nu te uitai la canalul potrivit

Un apel în prim-plan tipărește în terminalul tău. O unitate tipărește în journal, iar o unitate eșuată poate ieși înainte de a scrie ceva dacă defectul este în modul în care a fost pornită și nu în ceea ce i s-a spus. Distincția contează: nicio intrare în journal înseamnă că procesul nu a rulat niciodată cu adevărat, în timp ce o intrare urmată de o ieșire înseamnă că a rulat și a respins ceva.

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

Adaugă systemctl show -p Result -p ExecMainStatus openvpn-client@office pentru a separa o ieșire curată de un semnal. Un status de 1 cu un Result=exit-code este o decizie a programului; Result=signal sau un timeout indică mediul, și nicio editare a profilului nu va schimba asta. Notează ambele valori înainte de a reporni orice, pentru că o repornire șterge starea tranzitorie care le-a produs.

Numele instanței face parte din cale

Unitatea de șablon împachetată nu acceptă o cale de fișier. Acceptă un nume de instanță, iar acel nume este adăugat la un director pentru a găsi profilul: office se rezolvă în /etc/openvpn/client/office.conf în pachetul Debian și Ubuntu. Un fișier numit office-v2.conf, pornit ca @office nu este niciodată citit, iar unitatea iese în tăcere pentru că din punctul ei de vedere nu era nimic de făcut. Directorul de căutare diferă între modul client și modul server, așa că aceeași greșeală indică un loc complet diferit când schimbi șablonul.

Această discrepanță este cea mai frecventă cauză a eșecului silențios și este invizibilă în profil pentru că profilul este în regulă. Listează ce există de fapt și compară cele două nume caracter cu caracter, inclusiv orice extensie pe care o așteaptă pachetul.

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

Dacă unitatea este activată dar nu este listată nicio instanță, activarea în sine poate face referire la un nume care a fost redenumit mai târziu. Reactivează instanța corectă este de obicei suficient, iar vechiul fișier de unitate rămas merită șters ca să nu încurce următoarea persoană. Un fișier de unitate uitat este un lucru mic care costă pe cineva o oră mai târziu.

Când pluginul deține tunelul, terminalul nu vede nimic

O conexiune pornită din appletul desktop este deținută de NetworkManager, iar ieșirea ei OpenVPN merge în journal-ul acelui serviciu și nu într-un shell pe care îl ai deschis. Să rulezi clientul manual și să nu vezi nimic este de așteptat în această aranjare, pentru că procesul pornit manual nu este cel care duce conexiunea.

Caută în journal serviciul care îl deține, apoi reprodu parsarea cu un nivel de detaliu pe care îl poți citi. Cele două comenzi de mai jos privesc proprietari diferiți ai aceleiași erori.

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

Rularea separată este pentru citirea mesajelor, nu pentru înlocuirea conexiunii gestionate, iar cele două diferă după aceea: integrarea DNS, rutele și durata de viață aparțin pluginului. Corectarea unei erori de parsare în rularea separată nu corectează automat rezolvarea numelor odată ce appletul preia controlul, așa că ține cele două observații separate.

Două binare, un PATH

O instalare construită manual sub /usr/local câștigă la un apel de shell, pentru că /usr/local/sbin precedă /usr/sbin în PATH-ul implicit Ubuntu. O unitate nu folosește PATH-ul tău; ea execută calea absolută scrisă în ExecStart. Deci versiunea care funcționează în terminalul tău și versiunea care eșuează ca serviciu pot fi programe cu adevărat diferite.

Compară cele două înainte de a reconstrui ceva. A treia comandă este cea care decide disputa.

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

Încă o diferență de mediu se ascunde în același loc. O unitate împachetată se bazează pe un director de rulare sub /run pe care systemd îl creează pentru ea; o unitate de înlocuire scrisă manual care omite această setare poate eșua înainte de a deschide un singur fișier, iar eșecul arată ca un refuz generic fără niciun mesaj OpenVPN.

Eșecuri pe care clientul nu le poate raporta

Unele rezultate se decid la capătul îndepărtat. Un gateway care răspunde cu un status HTTP și închide conexiunea ți-a spus despre propria stare, iar următorul pas util este logul lui sau contul din spatele acreditării, nu fișierele tale locale. Nimic local nu este stricat în acel scenariu, iar editarea profilului pentru compensare face diagnosticul următor mai greu. Citește acel log înainte de a atinge configurația clientului.

Un alt caz silențios este un client care funcționează corect. Un tunel în modul client nu ascultă niciodată pe un port, așa că o verificare care așteaptă un ascultător deschis nu va raporta nimic și va părea un eșec. Confirmă ce mod ai pornit înainte de a trage o concluzie dintr-o listă de porturi goală.

Lucrează straturile în ordine: unitatea există și numele instanței este corect, a ajuns ceva în journal sau în fișierul --log , ce binar și ce profil au rulat de fapt, și eșecul este local sau la distanță. Fiecare răspuns elimină un strat. A începe de la profil înseamnă a rescrie un fișier care poate nu a fost niciodată deschis.