vpn.persistent sigue intentándolo, pero no te mantiene conectado

NetworkManager expone una propiedad, vpn.persistent, y la gente le pide que responda cuatro preguntas distintas a la vez. Su documentación original es cuidadosa: la persistencia se aplica cuando el servicio VPN la admite y el perfil la habilita, y entonces se pide a la conexión que sobreviva a los cambios de enlace y a las interrupciones hasta una desconexión explícita. La misma documentación muestra también que la propiedad vale false por defecto, que no es lo que asumen la mayoría de los planes de recuperación. Léelo como una petición de intento, no como una promesa de resultado.

A qué se compromete realmente el ajuste

Un valor guardado en un perfil es una instrucción para el gestor, y el gestor tiene que entregar esa instrucción a un complemento VPN que sepa qué hacer con ella. Si el complemento instalado ignora la propiedad, el perfil se activa igualmente y el registro se queda callado, que es lo peor de los dos mundos para quien depure el problema después. Nada dentro de un perfil puede obligar a un complemento a implementar un comportamiento que no tiene, así que el único resultado visible es una ausencia.

Por eso la condición de la documentación importa más que el interruptor. Comprueba qué complemento y qué versión tienes realmente, y escribe la versión junto a la descripción de la conexión para que la siguiente persona no tenga que redescubrirlo. Una política de recuperación basada en un indicador no implementado falla exactamente una vez en producción y siempre en el momento más inconveniente.

Tratar la propiedad como un intento también fija la expectativa correcta para las pruebas. No compruebas si el indicador está puesto; compruebas si ocurrió algo cuando cayó el enlace. Son experimentos distintos, y solo uno de ellos vale una tarde.

Cuatro preguntas que se funden en una

La activación pregunta qué levanta la VPN en primer lugar. Un perfil de NetworkManager puede atarse a una conexión base, un servicio OpenVPN gestionado por separado tiene su propio arranque, y añadir un tercer lanzador a ese arreglo te da dos propietarios con ideas distintas sobre quién manda. Decide qué componente es dueño del arranque antes de añadir otro disparador.

La recuperación pregunta qué ocurre cuando el enlace cambia o desaparece, que es la cuestión estrecha que aborda vpn.persistent. La vitalidad pregunta si el cliente puede saber que el extremo remoto dejó de responder, y el comportamiento de keepalive o de reinicio de OpenVPN responde a eso en su lugar; los dos mecanismos suelen describirse con la misma palabra y se implementan en lugares distintos. Pruébalos por separado, con herramientas distintas, o atribuirás un comportamiento al otro.

La intención pregunta si se quiere la reconexión siquiera, y es la cuestión que el sondeo de estado no puede responder. Una parada deliberada y una interrupción producen el mismo estado inactivo, así que cualquier cosa que reconecte por ausencia está adivinando una decisión humana. Adivinar está bien hasta el momento en que pasa por encima de alguien.

Una lista de comprobación que las mantiene separadas

Ejecuta los eventos en orden en lugar de leer la configuración y razonar sobre ella, y registra qué muestra cada uno con una marca de tiempo.

Primero, activa la conexión base prevista y confirma que la VPN subió por el disparador que esperabas y no por un mecanismo que habías olvidado que estaba instalado. Segundo, durante una interrupción aprobada, compara los eventos VPN del gestor, el estado de recuperación del cliente propietario y una petición nueva a un recurso privado. Tercero, desconecta a propósito, espera y confirma que nada reinicia el perfil a tus espaldas.

El tercer paso es el que la gente se salta, y es el que encuentra el defecto real más a menudo. Un vigilante que sondea si hay un perfil activo y se reconecta cuando no lo hay deshará alegremente una desconexión intencionada del usuario. Desde la silla del usuario eso no es resiliencia; es una máquina que no obedece. Pregúntales antes de añadir uno.

Escribe los resultados en el mismo documento que la descripción de la conexión. Una política de recuperación es tan buena como la última vez que alguien la vio fallar a propósito. Las marcas de tiempo hacen visible la diferencia para quien lea las notas después.

La autenticación forma parte de la recuperación

Reconectarse no es un acto puramente de red. Si el flujo aprobado necesita un desafío nuevo, un código de un solo uso o un secreto al que el contexto de activación no puede llegar, ningún ajuste de persistencia puede producirlo de la nada.

Eso explica un patrón conocido: la conexión se recupera en una máquina con un llavero desbloqueado y falla en la misma máquina tras un reinicio. La capa de red hizo exactamente lo que se le pidió y la capa de credenciales no tenía nada que ofrecer.

Arregla el flujo de credenciales en lugar de acortar el intervalo de reintento. Los reintentos más rápidos contra una petición que nadie puede responder generan ruido en el registro y una falsa impresión de que se está intentando algo.

La persistencia no es un kill switch

La propiedad intenta mantener o restaurar la relación VPN. No decide qué pueden hacer las aplicaciones mientras la VPN está caída, y no bloquea nada por sí misma.

Si el requisito es que no salga tráfico fuera del túnel, eso es una política aparte con su propio mecanismo, sus propias pruebas y sus propios modos de fallo. Suponer que la persistencia lo cubre convierte una decisión de seguridad en un accidente.

Registra las dos mitades en las notas de recuperación: qué intentó la VPN y qué tráfico de aplicaciones se permitió mientras el intento estaba en curso.