Una VPN secundaria pertenece a un perfil Wi-Fi, no a todos

Configure una VPN como secundaria de la conexión Wi-Fi del hogar y todo funciona, hasta que el portátil se une a otro punto de acceso y el túnel se queda caído. La nueva conexión es un objeto de configuración aparte con su propio UUID, y no tiene motivo alguno para conocer el vínculo que usted creó para su predecesora. Nada falló; la asociación simplemente nunca existió.

La referencia de conexiones de NetworkManager define las secundarias como UUID que se activan junto con una conexión base concreta. También señala que los perfiles VPN corrientes no implementan la activación automática como lo hacen las conexiones base. Ambas afirmaciones llevan a la misma conclusión: la asociación es por perfil, y alguien tiene que crearla para cada uno nuevo.

Qué es realmente una secundaria

Una conexión base tiene una identidad, un UUID y una lista de secundarias. Cuando se activa, el gestor también activa esas secundarias en orden, y así es como una VPN acaba siguiendo una red Wi-Fi sin un clic manual. La relación reside en la conexión base, escrita como cadenas UUID en lugar de nombres. Esa elección de representación no es casual; es lo que hace que la asociación sobreviva a un cambio de nombre.

Ese detalle sobre los nombres importa más de lo que parece. Cambiar el nombre de un perfil VPN deja intacto su UUID, de modo que las asociaciones existentes siguen funcionando. Borrar el perfil antiguo e importar uno nuevo produce un UUID nuevo, y toda asociación que apuntaba al antiguo ahora no apunta a nada.

Revise la lista existente antes de añadir nada. Un perfil doméstico con una secundaria no es una regla que encaje con cada SSID; es una fila en un objeto, y no se consultará cuando se active una base distinta.

Ponga la asociación donde se crean los perfiles

En una máquina personal, haga que adjuntar la secundaria prevista forme parte de añadir cada perfil Wi-Fi permitido. Es un hábito más que una función, pero un hábito que produce un estado coherente, y cuesta un comando o dos visitas al diálogo por red. Mantenga una nota breve de qué redes deben llevar el túnel, porque la lista es la política.

En dispositivos gestionados, haga que el flujo de aprovisionamiento cree la entrada Wi-Fi y su asociación VPN en el mismo paso, y aplique el mismo trato a los perfiles permitidos que ya existen. Distribuir un perfil VPN por sí solo deja las relaciones base sin especificar, y así es como una flota acaba con un túnel que solo usa la mitad de los portátiles.

Donde los usuarios aún puedan crear perfiles fuera de la ruta gestionada, decida explícitamente qué ocurre con esas entradas. Suponer que heredan una asociación no es una política; es una esperanza con un coste de soporte adjunto.

Planifique el cambio de identidad de la VPN

La fuente de aprovisionamiento necesita el UUID de la VPN prevista, no un nombre visible que alguien haya adivinado. Cuando el mantenimiento sustituya esa VPN por un objeto recién importado, actualice la plantilla de aprovisionamiento y las asociaciones existentes afectadas en el mismo cambio. Un cambio de nombre no es una sustitución, y tratar ambos como equivalentes es como una implantación que funciona se rompe una semana después.

Guarde el UUID junto al motivo por el que existe. Un ingeniero futuro que encuentre un UUID desnudo en una lista de secundarias no tendrá forma de saber si está vigente, y probablemente lo borre mientras ordena.

La activación no es la aplicación forzosa

Una solicitud de secundaria ocurre en el momento de la activación. No bloquea las aplicaciones durante el intervalo previo a que se complete la autenticación, y no detiene el tráfico después de que el túnel falle. Son propiedades distintas, proporcionadas por mecanismos distintos, y confundirlas produce un diseño que parece estricto en el perfil y es permisivo en la práctica.

Bloquear el tráfico directo es una función aparte con su propia configuración y sus propios modos de fallo, y debe tener en cuenta el tráfico que ha de llegar a la red antes de que exista cualquier túnel: portales cautivos, páginas de inicio de sesión, el propio extremo. Una política de bloqueo que no pueda satisfacerse antes de la autenticación deja la máquina fuera de la red que necesita.

Incluya esa distinción en las instrucciones que los usuarios leen de verdad. Una red Wi-Fi nueva puede pedir el túnel; la aplicación forzosa decide si algo puede salir cuando no se puede conectar. Los usuarios a quienes solo se cuenta la primera mitad informarán de que el diseño está roto.

Pruebe con un perfil genuinamente nuevo

Use una red de prueba aprobada y un perfil base recién creado, no la entrada doméstica que ya funciona. Observe la activación de la base, el UUID de secundaria solicitado y cualquier solicitud de autenticación en secuencia, y anote en qué etapa se atasca cuando se atasca. Un agente secreto que queda disponible tras el inicio de sesión del escritorio no está automáticamente presente en todos los contextos de arranque, así que un reinicio pertenece al plan de pruebas. Luego compruebe el recurso previsto y la ruta de fallo: ¿sube el túnel antes de que la aplicación lo necesite, y qué le ocurre a esa aplicación cuando falla la autenticación?

Luego compruebe el recurso previsto y la ruta de fallo: ¿sube el túnel antes de que la aplicación lo necesite, y qué le ocurre a esa aplicación cuando el túnel no puede autenticarse? Esas dos observaciones son los criterios de aceptación, y ninguna de ellas es visible en el propio perfil.