OpenVPN la pornirea în Ubuntu: NetworkManager sau systemd?

Majoritatea ghidurilor prezintă această alegere ca fiind cosmetică: fie lăsați NetworkManager să ridice tunelul, fie activați o instanță systemd și ați terminat. Cele două căi diferă într-un singur lucru care decide rezultatul pe o mașină fără ecran, și acesta nu are nimic de-a face cu ce instrument este mai nou. NetworkManager deblochează secretele printr-o sesiune; o instanță systemd nu are nicio sesiune de deblocat. Alegeți-o pe cea al cărei mod de tratare a secretelor se potrivește cu mașina din fața dumneavoastră.

Tot restul, de la instalarea rutelor la comportamentul la reconectare, decurge din acea primă decizie.

Brelocul este diferența de care nu vorbește nimeni

Când NetworkManager deține un profil VPN, parola poate sta în brelocul de conectare, care este deblocat când un utilizator se conectează. Asta funcționează bine pe un laptop: persoana este prezentă, brelocul se deschide, tunelul urcă. Pe un server care pornește nesupravegheat nu este nimeni care să deblocheze ceva, așa că profilul așteaptă un secret care nu sosește niciodată. Conexiunea pare configurată și nu se activează niciodată.

Instanța systemd evită această problemă citind un fișier de acreditări de pe disc, ceea ce face din fișier lucrul pe care îl protejați. chmod 400 plus proprietatea root este minimul, iar fișierul ar trebui să rămână în afara copiilor de siguranță și a șabloanelor de imagine pe care nu le controlați.

Atașarea VPN-ului la o conexiune nu garantează pornirea

În nm-connection-editor, selectați conexiunea prin cablu sau fără fir în locul VPN-ului, deschideți fila General, bifați opțiunea de conectare automată la un VPN și numiți profilul. NetworkManager activează apoi VPN-ul ca conexiune secundară când cea primară atinge starea conectat. Aceasta este o dependență, nu o regulă de firewall. Pachetele pot ieși încă în secundele dinaintea ridicării tunelului, iar un secret salvat care nu se deblochează lasă mașina online fără el.

Dacă cerința este ca nimic să nu iasă fără tunel, spuneți-o și construiți un întrerupător de urgență, pentru că această setare nu vă va oferi unul. Testați și suspendarea și reluarea, deoarece conexiunea secundară este reevaluată la întoarcere.

Instanța systemd are nevoie de un nume de fișier care se potrivește

Puneți profilul în directorul de client așteptat de pachet, de exemplu /etc/openvpn/client/office.conf, și referiți din interior fișierul de acreditări cu auth-user-pass office.cred. Numele instanței este numele fișierului fără sufix, așa că openvpn-client@office citește office.conf. Activați-o cu sudo systemctl enable --now openvpn-client@office și confirmați corespondența cu systemctl cat openvpn-client@office în loc să vă încredeți într-un exemplu dintr-un blog.

Căile din interiorul profilului sunt rezolvate relativ la directorul de lucru al unității, nu la profilul în sine, așa că o linie relativă ca sau auth-user-pass poate eșua la pornire deși funcționează când o testați manual. Folosiți căi absolute pentru tot ce unitatea trebuie să găsească. Apoi citiți journalctl -u openvpn-client@office -b după o pornire reală; o unitate care raportează activ fără tunel numește de obicei un fișier lipsă în acel jurnal.

Pachetele mai vechi livrează un alt nume de șablon, așa că systemctl list-unit-files 'openvpn*' stabilește care există pe acest host.

Comportamentul la reconectare este o decizie separată

Un profil cu ping-restart reconstruiește tunelul după ce cade, iar o unitate cu o directivă de repornire face ceva similar la nivel de serviciu. Sunt politici pe care le alegeți, nu valori implicite pe care le moșteniți. Dacă conexiunea ar trebui să urce doar la cerere, eliminați deliberat comportamentul de repornire și notați de ce. Dacă unitatea pornește înainte ca rețeaua să fie utilizabilă, are nevoie de o politică de reîncercare, pentru că o încercare eșuată la pornire nu se repetă singură.

Oprirea este la fel de literală: sudo systemctl disable --now openvpn-client@office oprește instanța care rulează și elimină legătura de pornire. Doar dezactivarea lasă tunelul să ruleze până la următoarea repornire, ceea ce surprinde pe oricine testează dezactivând și vede interfața rămânând sus.

Reporniți, apoi verificați patru lucruri în ordine

Repornirea serviciului testează serviciul; repornirea mașinii testează calea de pornire. După repornire, confirmați că unitatea a urcat, apoi că există o rută pentru subrețeaua îndepărtată, apoi ce adresă prezintă mașina internetului și, în final, că numele se rezolvă prin tunel. Acele patru verificări eșuează în această ordine când ceva nu este în regulă, ceea ce face ca primul eșec să fie cel util.

O unitate activă fără rută înseamnă de obicei că profilul s-a conectat, dar serverul nu a împins nicio rută, sau că ruta a fost instalată pe o interfață care a dispărut ulterior. O rută fără căutare de nume funcțională indică spre configurația DNS, nu spre tunelul în sine.

Decideți dinainte ce trebuie să se întâmple când tunelul nu poate urca. Revenirea la conectivitate simplă este o politică și ar trebui scrisă, în loc să fie lăsată în seama managerului care a pornit primul.