vpn.persistent segue intentándoo, pero non te mantén conectado

NetworkManager expón unha propiedade, vpn.persistent, e a xente pídelle que responda catro preguntas distintas á vez. A súa documentación orixinal é coidadosa: a persistencia aplícase cando o servizo VPN a admite e o perfil a habilita, e entón pídese á conexión que sobreviva aos cambios de enlace e ás interrupcións ata unha desconexión explícita. A mesma documentación mostra tamén que a propiedade vale false por defecto, que non é o que asumen a maioría dos plans de recuperación. Léeo como unha petición de intento, non como unha promesa de resultado.

A que se compromete realmente o axuste

Un valor gardado nun perfil é unha instrución para o xestor, e o xestor ten que entregar esa instrución a un complemento VPN que saiba que facer con ela. Se o complemento instalado ignora a propiedade, o perfil actívase igualmente e o rexistro queda calado, que é o peor dos dous mundos para quen depure o problema despois. Nada dentro dun perfil pode obrigar un complemento a implementar un comportamento que non ten, así que o único resultado visible é unha ausencia.

Por iso a condición da documentación importa máis que o interruptor. Comproba que complemento e que versión tes realmente, e escribe a versión xunto á descrición da conexión para que a seguinte persoa non teña que redescubrilo. Unha política de recuperación baseada nun indicador non implementado falla exactamente unha vez en produción e sempre no momento máis inconveniente.

Tratar a propiedade como un intento tamén fixa a expectativa correcta para as probas. Non comprobas se o indicador está posto; comprobas se ocorreu algo cando caeu o enlace. Son experimentos distintos, e só un deles vale unha tarde.

Catro preguntas que se fusionan nunha

A activación pregunta que levanta a VPN en primeiro lugar. Un perfil de NetworkManager pode ligarse a unha conexión base, un servizo OpenVPN xestionado por separado ten o seu propio arranque, e engadir un terceiro lanzador a ese arranxo dache dous propietarios con ideas distintas sobre quen manda. Decide que compoñente é dono do arranque antes de engadir outro disparador.

A recuperación pregunta que ocorre cando o enlace cambia ou desaparece, que é a cuestión estreita que aborda vpn.persistent. A vitalidade pregunta se o cliente pode saber que o extremo remoto deixou de responder, e o comportamento de keepalive ou de reinicio de OpenVPN responde a iso no seu lugar; os dous mecanismos adoitan describirse coa mesma palabra e impleméntanse en lugares distintos. Próbaos por separado, con ferramentas distintas, ou atribuirás un comportamento ao outro.

A intención pregunta se se quere a reconexión sequera, e é a cuestión que o sondeo de estado non pode responder. Unha parada deliberada e unha interrupción producen o mesmo estado inactivo, así que calquera cousa que reconecte por ausencia está adiviñando unha decisión humana. Adiviñar está ben ata o momento en que pasa por riba de alguén.

Unha lista de comprobación que as mantén separadas

Executa os eventos en orde en lugar de ler a configuración e razoar sobre ela, e rexistra que mostra cada un cunha marca de tempo.

Primeiro, activa a conexión base prevista e confirma que a VPN subiu polo disparador que esperabas e non por un mecanismo que esqueceras que estaba instalado. Segundo, durante unha interrupción aprobada, compara os eventos VPN do xestor, o estado de recuperación do cliente propietario e unha petición nova a un recurso privado. Terceiro, desconecta a propósito, espera e confirma que nada reinicia o perfil ás túas costas.

O terceiro paso é o que a xente salta, e é o que atopa o defecto real máis a miúdo. Un vixiante que sondea se hai un perfil activo e se reconecta cando non o hai desfará alegremente unha desconexión intencionada do usuario. Desde a cadeira do usuario iso non é resiliencia; é unha máquina que non obedece. Pregúntalles antes de engadir un.

Escribe os resultados no mesmo documento que a descrición da conexión. Unha política de recuperación é tan boa como a última vez que alguén a viu fallar a propósito. As marcas de tempo fan visible a diferenza para quen lea as notas despois.

A autenticación forma parte da recuperación

Reconectarse non é un acto puramente de rede. Se o fluxo aprobado necesita un desafío novo, un código dun só uso ou un segredo ao que o contexto de activación non pode chegar, ningún axuste de persistencia pode producilo da nada.

Iso explica un patrón coñecido: a conexión recupérase nunha máquina cun chaveiro desbloqueado e falla na mesma máquina tras un reinicio. A capa de rede fixo exactamente o que se lle pediu e a capa de credenciais non tiña nada que ofrecer.

Arranxa o fluxo de credenciais en lugar de acurtar o intervalo de reintento. Os reintentos máis rápidos contra unha petición que ninguén pode responder xeran ruído no rexistro e unha falsa impresión de que se está intentando algo.

A persistencia non é un kill switch

A propiedade tenta manter ou restaurar a relación VPN. Non decide que poden facer as aplicacións mentres a VPN está caída, e non bloquea nada por si mesma.

Se o requisito é que non saia tráfico fóra do túnel, iso é unha política aparte co seu propio mecanismo, as súas propias probas e os seus propios modos de fallo. Supoñer que a persistencia o cobre converte unha decisión de seguridade nun accidente.

Rexistra as dúas metades nas notas de recuperación: que intentou a VPN e que tráfico de aplicacións se permitiu mentres o intento estaba en curso.