La VPN es reconnecta, però la sessió de l’aplicació continua fallant

El túnel torna, el client diu que està connectat i el navegador encara gira en una pàgina que carregava abans del tall. Una reconnexió de VPN restaura un camí i no restaura l’estat de connexió que les aplicacions i el costat remot van acumular al camí vell. Són dues coses diferents de reparar, i confondre-les us torna a la configuració de la VPN sense cap motiu.

Una prova les separa netament i triga deu segons. Envieu una petició nova a la mateixa destinació mentre l’antiga encara penja.

Què sobreviu a una reconnexió i què no

Un túnel és un conjunt de rutes, claus i adreces, i una reconnexió pot restaurar les tres coses mentre cada flux establert continua mort. El sistema operatiu manté un sòcol obert perquè l’aplicació ho va demanar, i el temps d’espera d’aquest sòcol pot ser a minuts o hores. A sota, el parell ha oblidat el flux, una entrada de traducció ha caducat o el camí passa ara per un punt final que mai no va veure l’encaixada de mans. Res de la seqüència de reconnexió no recorre els sòcols de l’aplicació per reparar-los.

Alguns clients afegeixen un ganxo que descarta les connexions velles en reconnectar, i la majoria no ho fa. El comportament aquí varia segons el client, la plataforma i la versió.

El costat remot també us ha oblidat

L’extrem llunyà guarda estat propi: una sessió TLS, un bloc de control TCP i, potser, una entrada de mapatge que lliga la vostra adreça i port al flux. Un dispositiu de traducció al camí pot fer caducar aquest mapatge durant el buit encara que el túnel es restableixi de pressa. Un cop el mapatge desapareix, arriben paquets per a un flux que el servidor ja no reconeix, i la resposta pot ser un reset que el client mai no mostra. Les aplicacions ho informen com una aturada i no com un error, perquè encara esperen un sòcol que no respondrà mai.

Els temps d’inactivitat del costat del servidor fan el mateix segons el seu propi calendari, i per això una sessió pot morir sense cap esdeveniment de xarxa. Una connexió que ha estat inactiva més temps del que el servidor espera ja se n’ha anat abans que noteu que el túnel s’ha mogut.

Una petició nova és la prova que les separa

Envieu una petició nova al mateix amfitrió mentre l’antiga encara penja i mireu totes dues. Si la petició nova té èxit, aleshores el túnel, la ruta i la resolució de noms funcionen, i la fallada queda limitada al flux vell. Si la petició nova també falla, teniu un problema de camí i l’estat de sessió de l’aplicació és una pista falsa.

Mantingueu qualsevol bloc de trànsit directe al seu lloc durant la prova. Una petició que té èxit per un camí alternatiu accidental no demostra res sobre el túnel.

Confirmeu-ho amb una connexió nova, no amb la vella

Les ordres següents mostren els sòcols encara oberts, inicien una petició nova i comproven si la taula de sessions encara té una entrada per al flux. Executeu la primera abans i després de la reconnexió perquè la diferència sigui visible. Substituïu l’amfitrió i el port pel vostre servei.

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 sòcol establert sense trànsit movent-se és la signatura que cal buscar, i una petició nova que retorna un codi d’estat mostra que el camí és viu. La taula de connexions respon si alguna cosa encara assigna el flux, i aquesta és la part que el client no pot veure. La consulta al resolutor cobreix l’altra meitat d’una càrrega de pàgina, ja que una fallada de nom i una connexió encallada es veuen igual en un navegador. Junts, aquestes quatre sortides separen una sessió vella d’un túnel trencat.

Anoteu el moment de la interrupció, el moment de la reconnexió i la diferència entre la petició vella i la nova. Aquest registre converteix una queixa vaga en un informe sobre el qual algú pot actuar.