VPN reconectada, mas a sessão da aplicação continua a falhar

O túnel volta, o cliente diz que está ligado, e o navegador continua a girar numa página que estava a carregar antes do corte. Uma reconexão de VPN restaura um caminho e não restaura o estado de ligação que as aplicações e o lado remoto acumularam no antigo. São duas coisas diferentes para reparar, e confundi-las manda-o de volta às definições da VPN sem razão.

Um teste separa-os de forma limpa, e leva dez segundos. Envie um novo pedido para o mesmo destino enquanto o antigo continua pendurado.

O que sobrevive a uma reconexão e o que não sobrevive

Um túnel é um conjunto de rotas, chaves e endereços, e uma reconexão pode restaurar os três enquanto cada fluxo estabelecido fica morto. O sistema operativo mantém um socket aberto porque a aplicação o pediu, e o tempo limite desse socket pode estar a minutos ou horas de distância. Por baixo, o par esqueceu o fluxo, uma entrada de tradução expirou, ou o caminho passa agora por um ponto final que nunca viu o handshake. Nada na sequência de reconexão percorre os sockets da aplicação e os repara.

Alguns clientes acrescentam um gancho que descarta ligações antigas na reconexão, e a maioria não. O comportamento aqui varia consoante o cliente, a plataforma e a versão.

O lado remoto também se esqueceu de si

A extremidade remota guarda estado próprio: uma sessão TLS, um bloco de controlo TCP e talvez uma entrada de mapeamento que liga o seu endereço e porto ao fluxo. Um dispositivo de tradução no caminho pode deixar esse mapeamento expirar durante a interrupção mesmo quando o túnel se restabelece depressa. Quando o mapeamento desaparece, chegam pacotes de um fluxo que o servidor já não reconhece, e a resposta pode ser um reset que o cliente nunca mostra. As aplicações comunicam isto como um bloqueio e não como um erro, porque continuam à espera de um socket que nunca responderá.

Os tempos limite de inatividade do lado do servidor fazem o mesmo segundo o seu próprio calendário, e é por isso que uma sessão pode morrer sem qualquer evento de rede. Uma ligação que esteve inativa mais tempo do que o servidor espera já desapareceu antes de notar que o túnel se moveu.

Um pedido novo é o teste que os separa

Envie um novo pedido para o mesmo anfitrião enquanto o antigo continua pendurado, e observe ambos. Se o novo pedido tiver sucesso, então o túnel, a rota e a resolução de nomes funcionam, e a falha fica confinada ao fluxo antigo. Se o novo pedido também falhar, tem um problema de caminho e o estado de sessão da aplicação é uma pista falsa.

Mantenha qualquer bloqueio de tráfego direto no lugar durante o teste. Um pedido que tem sucesso por um caminho alternativo acidental não prova nada sobre o túnel.

Confirme com uma ligação nova, não com a antiga

Os comandos abaixo mostram os sockets ainda abertos, iniciam um novo pedido e verificam se a tabela de sessões ainda tem uma entrada para o fluxo. Execute o primeiro antes e depois da reconexão para que a diferença seja visível. Substitua o anfitrião e a porta pelo seu próprio serviço.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Um socket estabelecido sem tráfego em movimento é a assinatura a procurar, e um pedido novo que devolve um código de estado mostra que o caminho está vivo. A tabela de ligações responde se algo ainda mapeia o fluxo, e essa é a parte que o cliente não consegue ver. A consulta ao resolvedor cobre a outra metade do carregamento de uma página, já que uma falha de nome e uma ligação bloqueada se parecem iguais num navegador. Juntas, essas quatro saídas separam uma sessão antiga de um túnel quebrado.

Registe a hora da interrupção, a hora da reconexão e a diferença entre o pedido antigo e o novo. Esse registo transforma uma queixa vaga num relatório sobre o qual alguém pode agir.