Por que a sua VPN cai sempre que as chaves rodam

A conexão funciona por uma hora e depois morre, e o cliente não relata nada mais útil que disconnected. Esse período é a pista, porque algo no intercâmbio de renovação difere do handshake inicial. O temporizador só decide quando você o encontra. Guarde as mensagens desse intercâmbio em vez do rótulo final.

Leia o estágio, não o rótulo

No IKEv2 a associação IKE e a associação CHILD são renovadas em cronogramas separados. Uma proposta aceitável para a primeira negociação não é automaticamente aceitável para a segunda. Uma pode concluir enquanto a outra é rejeitada, o que produz um túnel que existe pela metade. Capture o intercâmbio com a ferramenta que o possui em vez de uma linha do log do cliente:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

Para o OpenVPN, o evento equivalente é uma renegociação governada pela versão e pelas configurações de implantação. O comportamento de autenticação tem os próprios modos de falha. A mensagem que importa nomeia o estágio que falhou, e você deve registrá-la literalmente em vez de parafraseá-la num ticket.

Anote também os carimbos de tempo. Uma queda em intervalo fixo após a última negociação bem-sucedida é um achado muito diferente de uma que chega ao acaso durante o uso, e o intervalo costuma ser a única evidência que sobrevive.

Compare a proposta que falha

Uma proposta rejeitada produz uma mensagem clara no respondedor. A causa usual é uma diferença entre as duas pontas em algoritmo, comprimento de chave, grupo ou duração. A negociação CHILD inicial pode ter dado certo porque o outro lado a iniciou, o que significa que a lista de propostas do outro lado foi usada. Olhe as duas pontas antes de mudar qualquer coisa.

Divergências de duração merecem atenção especial, porque um valor que parecia generoso numa ponta pode fazer a outra iniciar uma renovação que não consegue concluir. A documentação do comportamento de troca de chaves descreve como a renovação da associação é disparada e como as duas pontas podem diferir nas suas expectativas de tempo. Compare o que cada ponta afirma suportar em vez do que o arquivo de configuração sugere.

Um perfil antigo ou um modelo de provedor podem fixar uma proposta que a versão atual já não oferece. A divergência só aparece quando uma nova negociação é forçada.

Separe um problema de credenciais de um par inalcançável

Uma renovação que falha na autenticação parece igual no cliente e completamente diferente no servidor. Se uma credencial é verificada de novo na renegociação, um certificado expirado, uma conta revogada ou uma senha alterada vão produzir uma queda exatamente no intervalo de renovação, enquanto todas as conexões anteriores tiveram sucesso. Um par inalcançável é a terceira possibilidade, e não produz rejeição alguma: os pacotes saem e nada responde. Esse caso costuma seguir uma mudança de rede em vez de um temporizador, então verifique se a falha vem depois de um roaming, de um período inativo ou de uma mudança de rota.

Distinga os três pelo que a ponta remota registrou. Uma rejeição com motivo, uma falha de autenticação e o silêncio são três correções diferentes. Reiniciar o cliente colapsa tudo numa observação inútil.

Verifique as datas do certificado e o estado da conta antes de culpar a rede. Ambos são baratos de inspecionar e ambos são invisíveis na mensagem do próprio cliente.

Force uma renovação e leia o resultado

Force uma renovação pelo método suportado pelo operador em vez de esperar uma hora pela próxima. Mantenha intacta a política de falha exigida enquanto faz isso. Desligar a verificação ou esticar as durações para um dia faz o sintoma sumir dos seus logs sem corrigir nada. Também deixa uma interrupção mais longa esperando pela próxima pessoa.

Quando a correção estiver no lugar, verifique o túnel renovado e então faça uma nova requisição a partir da aplicação. Uma sessão de aplicação que estava viva quando a associação mudou pode precisar da própria recuperação mesmo que o túnel esteja saudável de novo. Os usuários vão relatar isso como a VPN ainda quebrada.

Registre as versões da release, os temporizadores negociados e o estágio que falhou. A próxima recorrência poderá então ser comparada com esta em vez de ser descrita outra vez de memória.