Failover de VPN: quando o caminho de retorno fica no túnel antigo

O túnel de reserva sobe, o primário cai e a aplicação continua estourando o tempo. Nos dois sites o estado do túnel parece saudável, e é isso que confunde. Um failover que move as requisições para a reserva mas deixa as respostas no caminho antigo não é failover. O guia abaixo testa o caminho de retorno, não apenas o handshake.

Registre primeiro as rotas nas duas pontas; uma visão de um só site não consegue mostrar um caminho assimétrico. É também o passo mais frequentemente ignorado sob pressão de tempo.

Registre as rotas dos dois sites antes do teste

Para cada prefixo protegido, escreva a rota primária, a rota de reserva e a preferência que escolhe entre elas. Inclua o gateway LAN atrás de cada endpoint VPN, porque o endpoint raramente é o último salto.

Métricas estáticas, rotas monitoradas e roteamento dinâmico expressam a elegibilidade de formas diferentes. Saiba qual o seu projeto usa e o que é preciso para a alternativa se tornar ativa. Escreva a condição ao lado da rota, por exemplo uma métrica mais baixa até a sonda falhar.

Faça isso nos dois sites. Uma reserva preferida de um lado e ignorada do outro produz exatamente a assimetria que você tenta evitar.

Observe requisições e respostas em cada fase

Use um aplicativo permitido e inofensivo e observe três fases: normal, falha do primário e restauração. Em cada fase, registre qual túnel leva a requisição e qual leva a resposta. Um endereço de par acessível não prova que o caminho protegido da aplicação funciona. Capture nos dois sites para que um fluxo unidirecional fique visível.

Se as requisições se movem e as respostas não, verifique a rota do site remoto até o prefixo do cliente e sua preferência pela reserva. Isso é uma decisão de roteamento, não uma falha do túnel.

Restaure a condição original após o teste e confirme que o primário volta a ser preferido. Um primário restaurado que não é preferido é um projeto de failover que não terminou.

Gerencie o estado da sessão quando o gateway muda

Firewalls e NAT podem manter o estado da conexão em um gateway, e uma mudança de caminho para outro gateway não o transporta. Algumas aplicações se reconectam sozinhas; outras falham até que a sessão seja restabelecida. Se a reserva muda a origem pública ou o endereço privado traduzido, as regras de acesso remoto também podem reagir. Documente qualquer reinício de sessão esperado em vez de prometer failover sem interrupção.

Mantenha endereçamento estável onde a aplicação exige. Um projeto de failover que muda o endereço de origem a cada sessão é uma escolha de projeto, e deve ser registrada. Essa escolha determina quanta interrupção os usuários realmente percebem.

Teste uma aplicação que mantém uma sessão longa, não apenas uma nova requisição.

Restaure o primário e verifique oscilação

Confirme que os anúncios de rota ou as preferências se estabilizam sem oscilar. Um primário oscilante pode ser mais perturbador do que uma queda clara, porque cada transição reinicia o estado.

Mantenha a administração do gateway acessível por um caminho de recuperação, para que o próprio teste não o deixe de fora. Registre as fases, os caminhos observados e o tempo de recuperação; esse registro é o que torna o próximo failover previsível. As notas do strongSwan sobre encaminhamento são úteis quando as pontas são hosts Linux.