Aplicación VPN del proveedor frente a NetworkManager: ¿quién posee el estado?
Un perfil nombra un complemento, no el comportamiento del cliente del proveedor. Traza quién posee el registro, el DNS, el bloqueo y las actualizaciones antes de cambiar un portátil gestionado.
Importar un perfil no es lo mismo que sustituir un cliente. NetworkManager guarda un tipo de complemento junto con datos y secretos específicos del complemento, y el complemento que posee ese tipo decide qué puede hacer la conexión. Todo lo que la aplicación del proveedor superpone, desde el registro hasta el bloqueo permanente, vive fuera del archivo. Que el cambio sea seguro depende de en qué capas de esas confías realmente.
El archivo nombra un complemento, no un conjunto de funciones
La referencia de ajustes de VPN de NetworkManager describe un tipo de servicio que selecciona el complemento, además de un diccionario de datos opaco y un diccionario de secretos que solo interpreta el complemento. El perfil es un contrato con una implementación, no una descripción de un comportamiento que cualquier cliente pueda reproducir. Dos clientes pueden hablar el mismo protocolo y aun así diferir en lo que negocian y en qué rutas de datos habilitan. La etiqueta de un protocolo te dice qué es el túnel, nunca qué hace el cliente de alrededor con él.
Compara, pues, requisitos en lugar de envoltorios. La pregunta no es si la alternativa puede conectarse, porque normalmente puede; es si cada requisito que hacía aceptable al cliente original sobrevive al traslado. Escribe esos requisitos antes de instalar nada, o la comparación se convierte en una caza de lo que se rompa primero.
Qué añade la aplicación del proveedor alrededor del túnel
Los clientes de proveedor suelen agrupar el registro y las comprobaciones de postura del dispositivo, un flujo de segundo factor con su propia interfaz, el bloqueo permanente, un canal de actualizaciones y herramientas de soporte. Parte de eso se sienta junto al protocolo, y parte es un producto aparte que solo comparte un instalador. NetworkManager puede sustituir el túnel y su enrutamiento, y los scripts de despachador pueden disparar acciones cuando la conexión cambia de estado. No reproduce un motor de bloqueo, un flujo de renovación de certificados ni una suposición sobre qué usuario puede levantar la conexión.
Más componentes no significa más seguro, y menos no significa más débil. La pregunta es qué componente aplica la política que te dijeron que siguieras. Si un auditor pregunta qué bloquea el tráfico cuando el túnel cae, la respuesta tiene que nombrar algo que de verdad lo haga, y un perfil que solo conecta no es esa respuesta.
Dónde difiere de verdad la propiedad
Lee esto como un mapa de propiedad y no como una lista de verificación, porque los fallos de abajo son huecos de propiedad y ninguna cantidad de configuración del cliente los cierra. Cada fila nombra la capa, el lado que suele tenerla hoy y dónde aparece primero el hueco.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
Empareja cada fila con una observación que puedas repetir, no con una sensación sobre el cliente. Un nombre resuelto por el resolutor previsto, una ruta que desaparece cuando el túnel se detiene y una conexión bloqueada tras una caída simulada son tres observaciones que juntas cubren la mayor parte de la tabla. Escribe la observación junto al requisito que demuestra, y conserva las que fallaron, porque una observación fallida es la única parte del registro que predice el siguiente incidente.
Cambiar sin superponer la propiedad
Ejecutar a la vez el cliente del proveedor y una conexión de NetworkManager para el mismo servicio es la forma más habitual de que estas comparaciones salgan mal. Ambos instalan rutas, ambos pueden fijar el DNS y ambos pueden tocar el estado del cortafuegos. Lo que mides entonces es una tercera disposición que no coincide con el comportamiento documentado de ninguno de los dos clientes.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"El primer comando te dice si el perfil es siquiera de tipo VPN. El segundo muestra el tipo de servicio del complemento y qué secretos están guardados, lo que importa cuando se espera una clave de un agente en lugar del archivo. El registro es donde un complemento que se cargó pero no pudo negociar lo dirá. Si ninguno de los tres muestra un problema, el hueco está en las capas de política por encima del túnel y no en la conexión.
Desconecta el cliente antiguo antes de habilitar la conexión nueva, mantén idénticos los extremos y la cuenta, y anota qué componente posee las rutas, los ajustes del resolutor y el bloqueo. Esa nota es lo que impide que la próxima actualización acabe con dos propietarios.