Un VPN secundari pertany a un perfil Wi-Fi, no a tots

Configureu una VPN com a secundària de la connexió Wi-Fi de casa i tot funciona, fins que l'ordinador portàtil s'uneix a un altre punt d'accés i el túnel es queda aturat. La connexió nova és un objecte de configuració separat amb el seu propi UUID, i no té cap motiu per conèixer el vincle que vau crear per al seu predecessor. Res no s'ha espatllat; l'associació simplement no ha existit mai.

La referència de connexions de NetworkManager defineix les secundàries com a UUID que s'activen juntament amb una connexió base concreta. També assenyala que els perfils VPN ordinaris no implementen l'activació automàtica com ho fan les connexions base. Les dues afirmacions porten a la mateixa conclusió: l'associació és per perfil, i algú l'ha de crear per a cada un de nou.

Què és realment una secundària

Una connexió base té una identitat, un UUID i una llista de secundàries. Quan s'activa, el gestor també activa aquestes secundàries en ordre, i així és com una VPN acaba seguint una xarxa Wi-Fi sense un clic manual. La relació viu a la connexió base, escrita com a cadenes UUID en lloc de noms. Aquesta elecció de representació no és casual; és el que fa que l'associació sobrevisqui a un canvi de nom.

Aquest detall sobre els noms importa més del que sembla. Canviar el nom d'un perfil VPN deixa el seu UUID intacte, de manera que les associacions existents continuen funcionant. Esborrar el perfil antic i importar-ne un de nou produeix un UUID nou, i tota associació que apuntava a l'antic ara no apunta a res.

Reviseu la llista existent abans d'afegir-hi res. Un perfil de casa amb una secundària no és una regla que encaixi amb cada SSID; és una fila en un objecte, i no es consultarà quan s'activi una base diferent.

Poseu l'associació on es creen els perfils

En una màquina personal, feu que adjuntar la secundària prevista formi part d'afegir cada perfil Wi-Fi permès. És un hàbit més que una funció, però un hàbit que produeix un estat coherent, i requereix una ordre o dues visites al diàleg per xarxa. Manteniu una nota breu de quines xarxes han de portar el túnel, perquè la llista és la política.

En dispositius gestionats, feu que el flux de provisió creï l'entrada Wi-Fi i la seva associació VPN en el mateix pas, i apliqueu el mateix tractament als perfils permesos que ja existeixen. Distribuir un perfil VPN sol deixa les relacions base sense especificar, i així és com una flota acaba amb un túnel que només fa servir la meitat dels portàtils.

On els usuaris encara poden crear perfils fora del camí gestionat, decidiu explícitament què passa amb aquestes entrades. Suposar que hereten una associació no és una política; és una esperança amb un cost de suport adjunt.

Planifiqueu el canvi d'identitat de la VPN

La font de provisió necessita l'UUID de la VPN prevista, no un nom de visualització que algú hagi endevinat. Quan el manteniment substitueixi aquesta VPN per un objecte acabat d'importar, actualitzeu la plantilla de provisió i les associacions existents afectades en el mateix canvi. Un canvi de nom no és una substitució, i tractar les dues coses com a equivalents és com un desplegament que funciona es trenca una setmana després.

Emmagatzemeu l'UUID al costat del motiu pel qual existeix. Un enginyer futur que trobi un UUID nu en una llista de secundàries no tindrà manera de saber si és vigent, i probablement l'esborrarà mentre endreça.

L'activació no és l'aplicació forçosa

Una sol·licitud de secundària es produeix en el moment de l'activació. No bloqueja les aplicacions durant l'interval abans que es completi l'autenticació, i no atura el trànsit després que el túnel falli. Són propietats diferents, proporcionades per mecanismes diferents, i confondre-les produeix un disseny que sembla estricte al perfil i és permissiu a la pràctica.

Bloquejar el trànsit directe és una funció separada amb la seva pròpia configuració i els seus propis modes de fallada, i ha de tenir en compte el trànsit que ha d'arribar a la xarxa abans que existeixi cap túnel: portals captius, pàgines d'inici de sessió, el mateix punt final. Una política de bloqueig que no es pot satisfer abans de l'autenticació deixa la màquina fora de la xarxa que necessita.

Poseu aquesta distinció en les instruccions que els usuaris llegeixen realment. Una xarxa Wi-Fi nova pot demanar el túnel; l'aplicació forçosa decideix si alguna cosa pot sortir quan no es pot connectar. Els usuaris a qui només s'ha explicat la primera meitat informaran que el disseny està trencat.

Proveu amb un perfil genuïnament nou

Feu servir una xarxa de prova aprovada i un perfil base creat de nou, no l'entrada de casa que ja funciona. Observeu l'activació de la base, l'UUID de secundària sol·licitat i qualsevol sol·licitud d'autenticació en seqüència, i anoteu en quina etapa s'encalla quan s'encalla. Un agent secret que esdevé disponible després de l'inici de sessió d'escriptori no hi és automàticament en cada context d'arrencada, així que un reinici pertany al pla de prova. Després comproveu el recurs previst i el camí de fallada: s'aixeca el túnel abans que l'aplicació el necessiti, i què passa amb aquesta aplicació quan l'autenticació falla?

Després comproveu el recurs previst i el camí de fallada: s'aixeca el túnel abans que l'aplicació el necessiti, i què passa amb aquesta aplicació quan el túnel no pot autenticar-se? Aquestes dues observacions són els criteris d'acceptació, i cap de les dues no és visible al mateix perfil.