vpn.persistent continua a tentar, mas não o mantém ligado

O NetworkManager expõe uma propriedade, vpn.persistent, e as pessoas pedem-lhe que responda a quatro perguntas diferentes ao mesmo tempo. A documentação de origem é cuidadosa: a persistência aplica-se quando o serviço VPN a suporta e o perfil a ativa, e a ligação é então convidada a sobreviver a mudanças de ligação e interrupções até uma desconexão explícita. A mesma documentação mostra também que a propriedade tem o valor false por omissão, o que não é o que a maioria dos planos de recuperação assume. Leia-o como um pedido de tentativa, não como a promessa de um resultado.

A que a definição se compromete realmente

Um valor guardado num perfil é uma instrução para o gestor, e o gestor tem de entregar essa instrução a um plugin VPN que saiba o que fazer com ela. Se o plugin instalado ignorar a propriedade, o perfil ativa-se de qualquer forma e o registo fica silencioso, o que é o pior dos dois mundos para quem for depurar mais tarde. Nada dentro de um perfil pode obrigar um plugin a implementar um comportamento que não tem, por isso o único resultado visível é uma ausência.

É por isso que a condição na documentação importa mais do que o interruptor. Verifique que plugin e que versão tem realmente, e escreva a versão ao lado da descrição da ligação para que a pessoa seguinte não tenha de a redescobrir. Uma política de recuperação construída sobre um indicador não implementado falha exatamente uma vez em produção e sempre no momento mais inconveniente.

Tratar a propriedade como uma tentativa também estabelece a expectativa correta para os testes. Não verifica se o indicador está definido; verifica se aconteceu alguma coisa quando a ligação caiu. São experiências diferentes, e só uma delas vale uma tarde.

Quatro perguntas fundidas numa

A ativação pergunta o que põe a VPN de pé em primeiro lugar. Um perfil do NetworkManager pode estar ligado a uma conexão base, um serviço OpenVPN gerido separadamente tem o seu próprio arranque, e acrescentar um terceiro lançador a essa disposição dá-lhe dois proprietários com ideias diferentes sobre quem manda. Decida que componente é dono do arranque antes de acrescentar outro gatilho.

A recuperação pergunta o que acontece quando a ligação muda ou desaparece, e é essa a questão estreita que o vpn.persistent aborda. A vivacidade pergunta se o cliente consegue perceber que o extremo remoto deixou de responder, e o comportamento de keepalive ou de reinício do OpenVPN responde a isso no seu lugar; os dois mecanismos são frequentemente descritos com a mesma palavra e implementados em locais diferentes. Teste-os em separado, com ferramentas diferentes, ou vai atribuir um comportamento ao outro.

A intenção pergunta se a reconexão é sequer desejada, e é a questão a que a sondagem de estado não consegue responder. Uma paragem deliberada e uma interrupção produzem o mesmo estado inativo, por isso tudo o que reconecta por ausência está a adivinhar uma decisão humana. Adivinhar está bem até ao momento em que passa por cima de alguém.

Uma lista de verificação que as separa

Execute os eventos por ordem em vez de ler a configuração e raciocinar sobre ela, e registe o que cada um mostra com uma marca temporal.

Primeiro, ative a conexão base pretendida e confirme que a VPN subiu pelo gatilho que esperava e não por um mecanismo de que se tinha esquecido de estar instalado. Segundo, durante uma interrupção aprovada, compare os eventos VPN do gestor, o estado de recuperação do cliente proprietário e um pedido novo a um recurso privado. Terceiro, desligue deliberadamente, espere e confirme que nada reinicia o perfil nas suas costas.

O terceiro passo é o que as pessoas saltam, e é o que encontra o defeito real com mais frequência. Um cão de guarda que sonda um perfil ativo e se reconecta quando ele falta desfará alegremente uma desconexão intencional do utilizador. Do ponto de vista do utilizador isso não é resiliência; é uma máquina que não obedece. Pergunte-lhes antes de acrescentar um.

Escreva os resultados no mesmo documento que a descrição da ligação. Uma política de recuperação vale tanto quanto a última vez que alguém a viu falhar de propósito. As marcas temporais tornam a diferença visível para quem ler as notas a seguir.

A autenticação faz parte da recuperação

Reconectar não é um ato puramente de rede. Se o fluxo aprovado exigir um desafio novo, um código de utilização única ou um segredo a que o contexto de ativação não consegue chegar, nenhuma definição de persistência o pode produzir do nada.

Isso explica um padrão conhecido: a ligação recupera numa máquina com o porta-chaves desbloqueado e falha na mesma máquina após um reinício. A camada de rede fez exatamente o que lhe foi pedido e a camada de credenciais não tinha nada para oferecer.

Corrija o fluxo de credenciais em vez de encurtar o intervalo de nova tentativa. Tentativas mais rápidas contra um pedido a que ninguém consegue responder geram ruído no registo e uma falsa impressão de que algo está a ser tentado.

A persistência não é um kill switch

A propriedade tenta manter ou restaurar a relação VPN. Não decide o que as aplicações podem fazer enquanto a VPN está em baixo, e não bloqueia nada por si mesma.

Se o requisito é que nenhum tráfego saia fora do túnel, isso é uma política separada com o seu próprio mecanismo, os seus próprios testes e os seus próprios modos de falha. Assumir que a persistência cobre isso transforma uma decisão de segurança num acidente.

Registe as duas metades nas notas de recuperação: o que a VPN tentou e que tráfego de aplicações foi permitido enquanto a tentativa decorria.