Unha VPN secundaria pertence a un perfil Wi-Fi, non a todos

Configure unha VPN como secundaria da conexión Wi-Fi da casa e todo funciona, ata que o portátil se une a outro punto de acceso e o túnel queda abaixo. A nova conexión é un obxecto de configuración aparte co seu propio UUID, e non ten motivo ningún para coñecer o vínculo que vostede creou para o seu predecesor. Nada fallou; a asociación simplemente nunca existiu.

A referencia de conexións de NetworkManager define as secundarias como UUID que se activan xunto cunha conexión base concreta. Tamén sinala que os perfís VPN correntes non implementan a activación automática como o fan as conexións base. Ambas afirmacións levan á mesma conclusión: a asociación é por perfil, e alguén ten que creala para cada un novo.

Que é realmente unha secundaria

Unha conexión base ten unha identidade, un UUID e unha lista de secundarias. Cando se activa, o xestor tamén activa esas secundarias en orde, e así é como unha VPN acaba seguindo unha rede Wi-Fi sen un clic manual. A relación reside na conexión base, escrita como cadeas UUID en lugar de nomes. Esa elección de representación non é casual; é o que fai que a asociación sobreviva a un cambio de nome.

Ese detalle sobre os nomes importa máis do que parece. Cambiar o nome dun perfil VPN deixa intacto o seu UUID, de modo que as asociacións existentes seguen funcionando. Borrar o perfil antigo e importar un novo produce un UUID novo, e toda asociación que apuntaba ao antigo agora non apunta a nada.

Revise a lista existente antes de engadir nada. Un perfil doméstico cunha secundaria non é unha regra que encaixe con cada SSID; é unha fila nun obxecto, e non se consultará cando se active unha base distinta.

Pon a asociación onde se crean os perfís

Nunha máquina persoal, faga que anexar a secundaria prevista forme parte de engadir cada perfil Wi-Fi permitido. É un hábito máis que unha función, pero un hábito que produce un estado consistente, e custa un comando ou dúas visitas ao diálogo por rede. Manteña unha nota breve de que redes deben levar o túnel, porque a lista é a política.

Nos dispositivos xestionados, faga que o fluxo de aprovisionamento cree a entrada Wi-Fi e a súa asociación VPN no mesmo paso, e aplique o mesmo trato aos perfís permitidos que xa existen. Distribuír un perfil VPN por si só deixa as relacións base sen especificar, e así é como unha frota acaba cun túnel que só usa a metade dos portátiles.

Onde os usuarios aínda poidan crear perfís fóra da ruta xestionada, decida explicitamente que ocorre con esas entradas. Supoñer que herdan unha asociación non é unha política; é unha esperanza cun custo de soporte asociado.

Planifique o cambio de identidade da VPN

A fonte de aprovisionamento necesita o UUID da VPN prevista, non un nome visible que alguén adiviñase. Cando o mantemento substitúa esa VPN por un obxecto recentemente importado, actualice o modelo de aprovisionamento e as asociacións existentes afectadas no mesmo cambio. Un cambio de nome non é unha substitución, e tratar ambos como equivalentes é como unha implantación que funciona se rompe unha semana despois.

Garde o UUID xunto ao motivo polo que existe. Un enxeñeiro futuro que atope un UUID espido nunha lista de secundarias non terá forma de saber se está vixente, e probablemente o borre mentres ordena.

A activación non é a aplicación forzosa

Unha solicitude de secundaria ocorre no momento da activación. Non bloquea as aplicacións durante o intervalo previo a que se complete a autenticación, e non detén o tráfico despois de que o túnel falle. Son propiedades distintas, proporcionadas por mecanismos distintos, e confundilas produce un deseño que parece estrito no perfil e é permisivo na práctica.

Bloquear o tráfico directo é unha función aparte coa súa propia configuración e os seus propios modos de fallo, e debe ter en conta o tráfico que ten que chegar á rede antes de que exista calquera túnel: portais cativos, páxinas de inicio de sesión, o propio extremo. Unha política de bloqueo que non se poida satisfacer antes da autenticación deixa a máquina fóra da rede que necesita.

Inclúa esa distinción nas instrucións que os usuarios len de verdade. Unha rede Wi-Fi nova pode pedir o túnel; a aplicación forzosa decide se algo pode saír cando non se pode conectar. Os usuarios aos que só se lles conta a primeira metade informarán de que o deseño está roto.

Probe cun perfil verdadeiramente novo

Use unha rede de proba aprobada e un perfil base recentemente creado, non a entrada doméstica que xa funciona. Observe a activación da base, o UUID de secundaria solicitado e calquera solicitude de autenticación en secuencia, e anote en que etapa se atasca cando se atasca. Un axente secreto que queda dispoñible tras o inicio de sesión do escritorio non está automaticamente presente en todos os contextos de arranque, así que un reinicio pertence ao plan de probas. Logo comprobe o recurso previsto e a ruta de fallo: sobe o túnel antes de que a aplicación o necesite, e que lle ocorre a esa aplicación cando falla a autenticación?

Logo comprobe o recurso previsto e a ruta de fallo: sobe o túnel antes de que a aplicación o necesite, e que lle ocorre a esa aplicación cando o túnel non pode autenticarse? Esas dúas observacións son os criterios de aceptación, e ningunha delas é visible no propio perfil.