Systemd sau NetworkManager: cine pornește VPN-ul la boot?
Trei mecanisme pot ridica același profil Ubuntu, fiecare cu un declanșator diferit. Comparați-le, păstrați un singur proprietar și retrageți duplicatul.
Două mașini Ubuntu din aceeași imagine, un singur profil VPN, rezultate opuse la autentificare: pe una tunelul este deja sus înainte să apară desktopul, pe cealaltă nu urcă niciodată. Profilul nu este variabila aici. Ce diferă este care dintre trei componente a primit ordinul să îl pornească, iar acele trei nu împart un singur comutator.
Compararea lor alături este mai rapidă decât ghicitul. Fiecare eșuează într-un mod recognoscibil, și exact asta face comparația utilă.
Trei pornitoare cu trei declanșatoare diferite
Serviciul openvpn împachetat este calea cea mai veche. Scriptul lui init citește o listă de pornire automată din /etc/default/openvpn. Dacă lista este comentată sau lăsată goală, scriptul pornește fiecare configurație găsită în acel director în loc de singura pe care ați adăugat-o. Un singur fișier adăugat pentru un tunel poate ridica mai multe în tăcere.
| Starter | What triggers it | Typical failure |
|---|---|---|
| Init script and templated units | Boot, plus anything in the autostart list | Starts every config, not the one you meant |
| NetworkManager secondary | Activation of the base Wi-Fi or Ethernet profile | Nothing happens until that base link comes up |
| Hand-written unit or wrapper | Whatever its WantedBy and ExecStart say | Runs a different binary or environment than your shell |
Al doilea rând este cel pe care oamenii îl configurează greșit. NetworkManager deține profilul importat și îl va porni, dar doar ca secundar al unei alte conexiuni, ceea ce înseamnă că declanșatorul aparține legăturii de rețea și nu VPN-ului.
Comparați costul configurării și aria de aplicare
Calea prin scriptul init costă o linie și acoperă fiecare configurație de pe mașină. Este potrivită pentru un router și greșită pentru un laptop care se conectează la rețele diferite. Calea prin NetworkManager costă o căutare de UUID și leagă tunelul de o conexiune de bază. Urcă în rețeaua de la birou și rămâne jos într-o rețea de hotel.
Un unit scris de mână costă cel mai mult și oferă cel mai mult control, inclusiv ordinea față de alte servicii. Aria de aplicare este factorul decisiv. Dacă mașina are o rețea și un tunel, serviciul împachetat este cinstit și previzibil. Dacă tunelul trebuie să urmeze o rețea Wi-Fi anume, secundarul este singurul dintre cele trei care exprimă acea condiție fără scripturi suplimentare.
Alegeți un proprietar și eliminați-i pe ceilalți
Un profil pornit de doi proprietari produce o sincronizare care se schimbă între porniri, ceea ce este mai rău decât oricare dintre mecanisme singur. Alegeți proprietarul, apoi dezactivați calea concurentă intenționat, nu din greșeală.
# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'
# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"Dacă calea retrasă este cea împachetată, faceți-o în ordinea corectă: setați AUTOSTART la none, rulați systemctl daemon-reload pentru ca uniturile generate să preia noua listă, apoi dezactivați instanța de șablon pe care nu o mai doriți. Dacă săriți reîncărcarea, uniturile vechi rămân active și pare că schimbarea nu a avut niciun efect.
O oprire care se blochează este o problemă separată cu un răspuns limitat. TimeoutStopSec limitează cât timp așteaptă systemd înainte de a trimite SIGKILL. Un fișier drop-in este locul potrivit pentru a-l seta, deoarece editarea unitului împachetat pierde schimbarea la următoarea actualizare.
Verificați ce a pornit de fapt
Reporniți și citiți dovezile în loc să aveți încredere în fișierul de configurare. Unitul care deține tunelul va arăta o stare activă și un moment de pornire care corespunde bootului, iar interfața VPN va exista înainte să vă autentificați.
systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0Aici mai încape o verificare: confirmați că ExecStart al unitului indică binarul la care vă gândiți. Un client compilat local sau un pachet snap are adesea nevoie de o cale explicită sau de un înveliș snap run, pentru că systemd nu moștenește ordinea de căutare a shell-ului dvs. Compararea command -v openvpn cu fișierul unitului lămurește asta în câteva secunde.
Scrieți proprietarul ales în notele mașinii, lângă numele profilului. Următoarea persoană care depanează un tunel lipsă va porni de la acea linie în loc să repete comparația.