Aplicația nu trebuie să ruleze cât timp VPN-ul este pornit: ce impune acest lucru
Oprirea unei aplicații cât timp tunelul este activ nu este un kill switch. Decide cine deține schimbarea modului, ce blochează o repornire și ce poate face systemd și ce nu.
Kill switch-urile și regulile de ne-suprapunere indică în direcții opuse, ceea ce explică de ce setările obișnuite de VPN nu o exprimă niciodată pe a doua. Kill switch-ul reacționează la un tunel căzut, în timp ce această cerință reacționează la un tunel activ și ține o aplicație în afara imaginii. O singură decizie de proiectare rezolvă cea mai mare parte: dacă aplicația este oprită, împiedicată să pornească sau doar lipsită de acces la rețea. Alege acel strat înainte de a apela la o regulă de firewall sau la o buclă care ucide procese, pentru că o regulă impusă prin observare pierde o fereastră la fiecare lansare.
Mitul: un kill switch împiedică programele să pornească
Kill switch-urile sunt controale de trafic și sunt sinceri în privința asta: permit sau refuză pachetele în funcție de starea tunelului. Niciunul nu refuză pornirea unui program și niciunul nu inspectează care executabil a deschis un socket. O scurtătură de desktop, o sarcină programată și un ajutor din fundal ajung toate la rețea fără să treacă prin ceva care știe numele aplicației. Distanța dintre aceste două mecanisme este locul unde trăiește cea mai mare parte a confuziei.
Aranjamentul care decide cu adevărat dacă un program poate porni este controlul aplicațiilor. Pe Windows asta înseamnă AppLocker sau WDAC, iar pe macOS administrat înseamnă o listă de permisiuni impusă de profilul dispozitivului. Ambele sunt independente de tunel, motiv pentru care cele două cerințe fuzionează în același tichet și apoi niciuna nu este satisfăcută.
Numiți modul înainte de a numi instrumentul
Scrie regula ca o mașină de stări cu trei stări: utilizare obișnuită, sesiune de lucru cu VPN și ieșire. Suprapunerea interzisă aparține stării de mijloc, nu software-ului client.
Cine schimbă starea deține trei acțiuni în ordine: să termine lucrul aplicației, să ceară oprirea ei normală și să confirme că instanța a dispărut înainte ca tunelul să urce. Ordinea contează și la celălalt capăt, pentru că un VPN care se conectează primul și oprește programul al doilea a permis deja suprapunerea. Dacă cerința acoperă stabilirea conexiunii, așteptarea unui indicator conectat vine prea târziu.
Ce face de fapt un conflict bidirecțional
Pentru două servicii chiar gestionate de systemd, Conflicts= este simetric: pornirea unuia îl oprește pe celălalt. Referința unităților documentează acest comportament și cere separat o ordine explicită atunci când unul trebuie să termine oprirea înainte ca celălalt să pornească. Fără acele intrări de ordine, oprirea și pornirea se întrec, iar rezultatul depinde de moment.
Aceasta nu este o listă de interdicții. Conectează dependența invers și pornirea aplicației va opri în schimb VPN-ul, ceea ce este defecțiunea de care trebuie să te îndoiești când un tunel se deconectează singur într-un moment previzibil. O aplicație de desktop nu este o unitate systemd, iar o conexiune NetworkManager nu este nici ea, așa că acest model funcționează doar pentru serviciile pe care le înfășori singur.
Testează tranzițiile, nu doar prima lansare
Patru tranziții decid dacă cerința rezistă: intrarea în sesiune cu aplicația în execuție, relansarea ei la mijlocul sesiunii, o pornire eșuată a VPN-ului și o deconectare deliberată. Testează fiecare și păstrează rezultatul lângă fișierele unităților. Comenzile de mai jos citesc relația actuală și apoi exersează tranziția care contează cel mai mult.
systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active
A treia comandă ar trebui să lase aplicația inactivă, iar a patra ar trebui să listeze doar conexiunea tunelului cât timp rulează o sesiune. Un rezultat diferit înseamnă că tranziția nu este impusă deloc.
Relansarea în timpul sesiunii este cazul care expune un proiect bazat pe înveliș, pentru că o scurtătură pornită de pe desktop nu consultă niciodată un script de lansare. Dacă această ocolire contează, impunerea aparține controlului aplicațiilor și nu clientului VPN. Documentează și sfârșitul sesiunii și preferă o reluare deliberată redeschiderii fiecărui proces oprit la intrare. Notează rezultatul fiecărei tranziții în aceeași notă care păstrează fișierele unităților.