A VPN quebra após uma atualização do cliente? Compare a negociação

As atualizações substituem o componente que analisa o seu perfil e negocia o túnel. A primeira falha após uma atualização é evidência sobre uma alteração específica, não um veredicto sobre a versão. Guardar esse erro com a versão e o carimbo temporal é o passo mais valioso que pode dar antes de reinstalar seja o que for.

Dois mecanismos explicam a maioria destas quebras. Separá-los é o trabalho.

O que a negociação mudou por baixo de si

O OpenVPN negoceia a cifra do canal de dados em vez de a retirar de uma única diretiva, e as opções que controlam essa negociação mudaram de significado entre versões. Um perfil escrito para um cliente mais antigo pode ligar-se e depois não chegar a acordo sobre um canal de dados, o que se manifesta como uma desconexão em vez de um erro de configuração claro. As versões mais recentes também endurecem ou retiram comportamentos herdados e trazem um modo de compatibilidade para pares que ainda não migraram. Uma atualização pode, por isso, quebrar um perfil que funcionava sem tocar num único byte do ficheiro.

O efeito no cliente é assimétrico. O canal de controlo sobe, a autenticação tem êxito e o túnel morre depois, o que é a assinatura de um desencontro de negociação e não de um perfil rejeitado.

Leia a versão instalada antes de teorizar sobre o servidor. Essa cadeia é um facto local que pode verificar sem pedir acesso a ninguém.

O perfil pode ser analisado e significar outra coisa

Uma diretiva que sobrevive à análise não é necessariamente uma diretiva que ainda faz o que o seu autor pretendia. As opções podem ser aceites por compatibilidade e ignoradas, renomeadas ou aplicadas num caso mais estreito do que antes. Como nada dá erro, o perfil parece correto enquanto o comportamento por baixo mudou. É esse silêncio que torna estas regressões caras.

Pergunte que linhas são realmente responsáveis pelo resultado negociado e depois confronte-as com a documentação da versão que executa agora. Essa comparação é curta, e é nela que está a diferença entre uma correção e um retrocesso.

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

A plataforma mexeu-se ao mesmo tempo

As versões do cliente raramente chegam sozinhas. Uma atualização do sistema operativo, um pedido de permissão que agora exige uma autorização explícita ou uma política gerida aplicada ao dispositivo podem chegar na mesma semana e produzir uma falha da qual o cliente é culpado. As plataformas móveis acrescentam uma camada própria, porque a aplicação pede um túnel ao sistema e o sistema decide o que esse túnel pode encaminhar.

Registe essas alterações separadamente na linha temporal. Quando a autenticação tem êxito mas as rotas ou a resolução de nomes falham, a fase interessante é a que vem depois do handshake, e enfraquecer a validação do certificado não lhe tocará.

Teste novamente o evento que iniciou o relatório

Reproduza a sequência original e não uma versão simplificada: a ligação inicial, a aplicação que falhou e uma reconexão comum após uma mudança de rede. Um túnel que sobe em condições de teste e ainda assim cai no caminho de reconexão não está corrigido, e a diferença costuma assinalar onde vive o defeito real. Um relatório que omite o passo de reconexão fecha um erro que continua aberto.

Obtenha o perfil suportado pelo operador ou a correção do fornecedor pelo canal verificado em vez de reverter tudo. Uma descida de versão ampla também repõe as correções de segurança que a atualização trazia, e essa troca raramente vale uma ligação a funcionar.