VPN herverbind, maar die app se sessie werk steeds nie

Die tonnel kom terug, die kliënt sê hy is verbind, en die blaaier draai steeds op ’n bladsy wat hy voor die onderbreking begin laai het. ’n VPN-herverbinding herstel ’n roete, en dit herstel nie die verbindingstoestand wat programme en die ander kant op die ou roete opgebou het nie. Dit is twee verskillende dinge om te herstel, en om hulle te verwar stuur jou sonder rede terug na die VPN-instellings.

Een toets skei hulle skoon, en dit neem tien sekondes. Stuur ’n nuwe versoek na dieselfde bestemming terwyl die ou een hang.

Wat ’n herverbinding oorleef en wat nie

’n Tonnel is ’n stel roetes, sleutels en adresse, en ’n herverbinding kan al drie herstel terwyl elke gevestigde vloei dood bly. Die bedryfstelsel hou ’n socket oop omdat die program dit gevra het, en daardie socket se tydlimiet kan minute of ure ver wees. Onder dit het die eweknie die vloei vergeet, ’n vertaalinskrywing het verval, of die roete loop nou deur ’n eindpunt wat nooit die handskud gesien het nie. Niks in die herverbindingsreeks stap deur die program se sockets en herstel hulle nie.

Sommige kliënte voeg ’n haak by wat verouderde verbindings laat val wanneer daar herverbind word, en die meeste doen nie. Die gedrag hier verskil per kliënt, platform en weergawe.

Die ander kant het jou ook vergeet

Die verre kant hou sy eie toestand: ’n TLS-sessie, ’n TCP-beheerblok, en moontlik ’n karteringinskrywing wat jou adres en poort aan die vloei bind. ’n Vertaaltoestel langs die roete kan daardie kartering gedurende die gaping laat verval, selfs wanneer die tonnel vinnig herstel. Sodra die kartering weg is, kom pakkette aan vir ’n vloei wat die bediener nie meer herken nie, en die antwoord kan ’n reset wees wat die kliënt nooit wys nie. Programme rapporteer dit as ’n stilstand eerder as ’n fout, omdat hulle steeds op ’n socket wag wat nooit sal antwoord nie.

Tydlimiete vir ledigheid aan die bedienerkant doen dieselfde op hul eie skedule, en daarom kan ’n sessie sterf sonder enige netwerkgebeurtenis. ’n Verbinding wat langer ledig was as wat die bediener verwag, is al weg voordat jy agterkom die tonnel het geskuif.

’n Nuwe versoek is die toets wat hulle skei

Stuur ’n nuwe versoek na dieselfde gasheer terwyl die ou een nog hang, en kyk na albei. As die nuwe versoek slaag, dan werk die tonnel, die roete en naamresolusie almal, en die fout is beperk tot die verouderde vloei. As die nuwe versoek ook misluk, het jy ’n roeteprobleem en die program se sessietoestand is ’n afleiding.

Hou enige blok vir direkte verkeer in plek tydens die toets. ’n Versoek wat deur ’n toevallige terugvalroete slaag, bewys niks oor die tonnel nie.

Bevestig met ’n nuwe verbinding, nie die oue nie

Die opdragte hieronder wys die sockets wat nog oop is, begin een nuwe versoek, en kyk of die sessietabel nog ’n inskrywing vir die vloei het. Voer die eerste een voor en na die herverbinding uit sodat die verskil sigbaar is. Vervang die gasheer en poort met jou eie diens.

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

’n Gevestigde socket waaroor geen verkeer beweeg nie, is die kenmerk om na te soek, en ’n nuwe versoek wat ’n statuskode teruggee, wys die roete leef. Die verbindingstabel antwoord of iets die vloei nog karteer, en dit is die deel wat die kliënt nie kan sien nie. Die naslaanvraag dek die ander helfte van ’n bladsylading, want ’n naamfout en ’n gestopte verbinding lyk in ’n blaaier identies. Saam skei daardie vier uitsette ’n verouderde sessie van ’n stukkende tonnel.

Teken die onderbrekingstyd, die herverbindingstyd en die verskil tussen die ou versoek en die nuwe een aan. Daardie rekord verander ’n vae klag in ’n verslag waarop iemand kan optree.