Rulați sarcinile post-VPN din dispatcher, nu din if-up

Un script care trebuie să ruleze după ce VPN-ul urcă are nevoie de un eveniment de la componenta care deține conexiunea. Un fișier plasat într-un director vechi de hook-uri de rețea nu este un callback pentru fiecare VPN pe care NetworkManager, pppd sau un proces OpenVPN independent îl pot crea. Fiecare dintre acești proprietari raportează alt eveniment cu alt mediu, așa că proprietarul trebuie identificat înainte de a alege hook-ul. Altfel scriptul este corect și pur și simplu nu rulează niciodată.

Pentru un VPN administrat de NetworkManager, dispatcher-ul este locul potrivit, iar vpn-up este acțiunea potrivită.

Folosiți vpn-up, nu evenimentul interfeței

Dispatcher-ul distinge up de vpn-up. Primul raportează o interfață activată; al doilea raportează o conexiune VPN activată. Faptul că Wi-Fi urcă înseamnă doar că legătura de bază există; tunelul poate încă negocia sau poate nu se autentifică niciodată.

Scriptul primește interfața și acțiunea, în timp ce detaliile conexiunii vin prin mediu, inclusiv UUID-ul profilului și interfața IP a VPN-ului. Citiți acele variabile în loc să deduceți identitatea din numele dispozitivelor.

Limitați potrivirea la o singură conexiune

Potriviți după UUID-ul conexiunii sau după altă identitate oferită de dispatcher, nu după un prefix tun sau ppp0. Numele interfețelor nu sunt stabile, pot exista mai multe tuneluri în același timp, iar două profiluri pot purta același nume afișat. Potrivirea unui prefix tun înseamnă că scriptul va rula în cele din urmă pentru o conexiune pe care nimeni nu intenționa să o atingă. Poate rula și de două ori pentru un profil când o reconectare reconstruiește dispozitivul.

Faceți sarcina idempotentă. Un callback care adaugă o rută la fiecare apel umple în cele din urmă tabelul cu duplicate, iar a doua copie este cea care strică rutarea.

Știți ce nu dovedește activarea

vpn-pre-up rulează înainte ca NetworkManager să raporteze VPN-ul complet activat, iar managerul așteaptă acele scripturi. Folosiți o etapă blocantă doar când sarcina chiar aparține acolo, pentru că o verificare lentă întârzie activarea pe care toate celelalte componente așteaptă să o vadă.

Prezența rutelor nu dovedește că o aplicație ascultă, că un nume privat se rezolvă sau că există o sesiune de utilizator. Verificați-le separat cu un timp limitat, și raportați care strat a eșuat în loc să reîncercați întregul lanț.

Respectați contextul în care rulează scriptul

Scripturile dispatcher-ului rulează ca root, în afara oricărei sesiuni de utilizator. Nu presupuneți că mediul utilizatorului autentificat, sesiunea grafică sau un portchei deblocat sunt disponibile. Nimeni nu ar trebui să răspundă la lipsa unui context de desktop făcând fiecare acreditiv citibil pentru fiecare proces. Țineți munca sesiunii de utilizator într-un serviciu de utilizator sau într-un ajutor de sesiune căruia callback-ul îi poate semnala fără a imita utilizatorul.

Proprietatea și permisiunile asupra scriptului contează și ele. Un fișier executat ca root pe care orice utilizator îl poate înlocui este o cale de escaladare a privilegiilor, și este o constatare independentă de corectitudinea logicii VPN.

Planificați deconectarea care nu se declanșează niciodată

NetworkManager documentează că vpn-pre-down nu este emis pentru deconectări forțate, cum ar fi o terminare neașteptată sau pierderea conectivității. De aceea, o curățare construită doar în jurul unui pre-down lin este incompletă prin construcție. Orice stare partajată pe care scriptul o modifică are nevoie de un alt proprietar care o poate restabili după o cădere, iar acea cale de recuperare trebuie testată, nu presupusă.

Testați hook-ul cu o conexiune normală, o reconectare, o deconectare intenționată și un cablu smuls. Înregistrați UUID-ul, acțiunea și interfața care s-a declanșat, fără a înregistra secrete. Acea înregistrare este singura dovadă de încredere că hook-ul a rulat pentru conexiunea pe care o intenționați, și ea face următoarea modificare sigură.