O VPN secundară aparține unui profil Wi-Fi, nu tuturor

Configurați o VPN ca secundară a conexiunii Wi-Fi de acasă și totul funcționează, până când laptopul se alătură altui punct de acces și tunelul rămâne jos. Conexiunea nouă este un obiect de configurare separat, cu propriul UUID, și nu are niciun motiv să știe despre legătura pe care ați creat-o pentru predecesorul ei. Nimic nu s-a defectat; asocierea pur și simplu nu a existat niciodată.

Referința conexiunilor din NetworkManager definește secundarele ca UUID-uri care se activează împreună cu o anumită conexiune de bază. De asemenea, notează că profilurile VPN obișnuite nu implementează activarea automată așa cum o fac conexiunile de bază. Ambele afirmații duc la aceeași concluzie: asocierea este per profil, iar cineva trebuie să o creeze pentru fiecare profil nou.

Ce este de fapt o secundară

O conexiune de bază are o identitate, un UUID și o listă de secundare. Când se activează, managerul activează și acele secundare în ordine, și astfel o VPN ajunge să urmeze o rețea Wi-Fi fără un clic manual. Relația locuiește pe conexiunea de bază, scrisă ca șiruri UUID în loc de nume. Această alegere de reprezentare nu este întâmplătoare; ea este cea care permite asocierii să supraviețuiască unei redenumiri.

Acest detaliu despre nume contează mai mult decât pare. Redenumirea unui profil VPN lasă UUID-ul lui intact, astfel încât asocierile existente continuă să funcționeze. Ștergerea profilului vechi și importarea unuia nou produce un UUID nou, iar fiecare asociere care indica spre cel vechi nu mai indică spre nimic.

Examinați lista existentă înainte de a adăuga. Un profil de acasă cu o singură secundară nu este o regulă care se potrivește fiecărui SSID; este un rând într-un obiect și nu va fi consultat când se activează o altă bază.

Puneți asocierea acolo unde se creează profilurile

Pe o mașină personală, faceți din atașarea secundarei dorite o parte din adăugarea fiecărui profil Wi-Fi permis. Este un obicei, nu o funcție, dar un obicei care produce o stare consecventă și necesită o comandă sau două vizite în dialog pe rețea. Țineți o notă scurtă despre ce rețele ar trebui să poarte tunelul, deoarece lista este politica.

Pe dispozitivele gestionate, lăsați fluxul de provizionare să creeze intrarea Wi-Fi și asocierea ei VPN în același pas și aplicați același tratament profilurilor permise care există deja. Distribuirea unui profil VPN de unul singur lasă relațiile de bază nespecificate și astfel o flotă ajunge cu un tunel pe care doar jumătate dintre laptopuri îl folosesc.

Acolo unde utilizatorii pot încă crea profiluri în afara căii gestionate, decideți explicit ce se întâmplă cu acele intrări. A presupune că moștenesc o asociere nu este o politică; este o speranță cu un cost de suport atașat.

Planificați schimbarea identității VPN-ului

Sursa de provizionare are nevoie de UUID-ul VPN-ului dorit, nu de un nume afișat pe care cineva l-a ghicit. Când mentenanța înlocuiește acel VPN cu un obiect proaspăt importat, actualizați șablonul de provizionare și asocierile existente afectate în aceeași modificare. O redenumire nu este o înlocuire, iar tratarea celor două ca echivalente este modul în care o implementare funcțională se strică o săptămână mai târziu.

Păstrați UUID-ul lângă motivul pentru care există. Un inginer viitor care găsește un UUID gol într-o listă de secundare nu are cum să spună dacă este actual și probabil îl va șterge în timp ce face ordine.

Activarea nu este impunere

O cerere de secundară are loc în momentul activării. Nu blochează aplicațiile în intervalul dinaintea finalizării autentificării și nu oprește traficul după ce tunelul eșuează. Sunt proprietăți diferite, oferite de mecanisme diferite, iar confundarea lor produce un design care pare strict în profil și este permisiv în practică.

Blocarea traficului direct este o funcție separată, cu propria configurație și propriile moduri de eșec, și trebuie să țină cont de traficul care trebuie să ajungă la rețea înainte ca orice tunel să poată exista: portaluri captive, pagini de autentificare, chiar punctul final. O politică de blocare care nu poate fi îndeplinită înainte de autentificare încuie mașina în afara rețelei de care are nevoie.

Puneți această distincție în instrucțiunile pe care utilizatorii le citesc cu adevărat. O rețea Wi-Fi nouă poate cere tunelul; impunerea decide dacă ceva poate ieși atunci când nu se poate conecta. Utilizatorii cărora li se spune doar prima jumătate vor raporta designul ca fiind stricat.

Testați cu un profil cu adevărat nou

Folosiți o rețea de test aprobată și un profil de bază nou creat, nu intrarea de acasă care funcționează deja. Observați activarea bazei, UUID-ul secundar solicitat și orice prompt de autentificare în succesiune și notați în ce etapă se blochează când se blochează. Un agent secret care devine disponibil după autentificarea la desktop nu este automat prezent în fiecare context de pornire, așa că o repornire face parte din planul de testare. Apoi verificați resursa dorită și calea de eșec: tunelul urcă înainte ca aplicația să aibă nevoie de el și ce se întâmplă cu acea aplicație când autentificarea eșuează?

Apoi verificați resursa dorită și calea de eșec: tunelul urcă înainte ca aplicația să aibă nevoie de el și ce se întâmplă cu acea aplicație când tunelul nu se poate autentifica? Acele două observații sunt criteriile de acceptare și niciuna dintre ele nu este vizibilă în profilul însuși.