A VPN reconecta, pero a sesión da aplicación segue fallando

O túnel volve, o cliente di que está conectado e o navegador segue xirando nunha páxina que estaba cargando antes do corte. Unha reconexión de VPN restaura unha ruta e non restaura o estado de conexión que as aplicacións e o lado remoto acumularon na antiga. Son dúas cousas distintas que reparar, e confundilas devólveo aos axustes da VPN sen motivo.

Unha proba séparaas limpiamente, e tarda dez segundos. Envíe unha petición nova ao mesmo destino mentres a antiga segue colgada.

Que sobrevive a unha reconexión e que non

Un túnel é un conxunto de rutas, claves e enderezos, e unha reconexión pode restaurar as tres mentres cada fluxo establecido segue morto. O sistema operativo mantén un socket aberto porque a aplicación llo pediu, e o tempo de espera dese socket pode estar a minutos ou horas. Por debaixo, o par esqueceu o fluxo, unha entrada de tradución caducou ou a ruta pasa agora por un extremo que nunca viu o salto inicial. Nada na secuencia de reconexión percorre os sockets da aplicación e os repara.

Algúns clientes engaden un gancho que descarta as conexións vellas ao reconectar, e a maioría non. O comportamento aquí varía segundo o cliente, a plataforma e a versión.

O lado remoto tamén se esqueceu de vostede

O extremo afastado garda estado propio: unha sesión TLS, un bloque de control TCP e quizais unha entrada de mapeo que ata o seu enderezo e porto ao fluxo. Un dispositivo de tradución na ruta pode facer caducar ese mapeo durante o oco aínda que o túnel se restableza rápido. Unha vez que o mapeo desaparece, chegan paquetes dun fluxo que o servidor xa non recoñece, e a resposta pode ser un reset que o cliente nunca mostra. As aplicacións infórmano como un bloqueo e non como un erro, porque seguen esperando un socket que nunca responderá.

Os tempos de inactividade do lado do servidor fan o mesmo segundo o seu propio calendario, e por iso unha sesión pode morrer sen ningún evento de rede. Unha conexión que estivo inactiva máis tempo do que o servidor espera xa se foi antes de que note que o túnel se moveu.

Unha petición nova é a proba que as separa

Envíe unha petición nova ao mesmo host mentres a antiga segue colgada e observe ambas. Se a petición nova ten éxito, entón o túnel, a ruta e a resolución de nomes funcionan, e o fallo limítase ao fluxo vello. Se a petición nova tamén falla, ten un problema de ruta e o estado de sesión da aplicación é unha pista falsa.

Manteña calquera bloqueo de tráfico directo no seu sitio durante a proba. Unha petición que ten éxito por unha ruta alternativa accidental non demostra nada sobre o túnel.

Confirme cunha conexión nova, non coa vella

Os comandos seguintes mostran os sockets aínda abertos, inician unha petición nova e comproban se a táboa de sesións aínda ten unha entrada para o fluxo. Execute o primeiro antes e despois da reconexión para que a diferenza sexa visible. Substitúa o host e o porto polo seu propio servizo.

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

Un socket establecido sen tráfico en movemento é a sinatura que hai que buscar, e unha petición nova que devolve un código de estado mostra que a ruta está viva. A táboa de conexións responde se algo segue mapeando o fluxo, e esa é a parte que o cliente non pode ver. A consulta ao resolvedor cobre a outra metade dunha carga de páxina, xa que un fallo de nome e unha conexión atascada vense iguais nun navegador. Xuntos, esas catro saídas separan unha sesión vella dun túnel roto.

Anote a hora da interrupción, a hora da reconexión e a diferenza entre a petición vella e a nova. Ese rexistro converte unha queixa vaga nun informe sobre o que alguén pode actuar.