VPN kopla til på nytt, men appøkta feilar framleis

Tunnelen er tilbake, klienten seier tilkopla, og nettlesaren snurrar framleis på ei side han lasta før brotet. Ei VPN-attsoppkopling gjenopprettar ein rute og gjenopprettar ikkje den tilkoplingsstilstanden som applikasjonane og fjerdsida samla på den gamle. Det er to ulike ting å reparere, og å blande dei sender deg tilbake til VPN-innstillingane utan grunn.

Éin test skil dei reint, og han tek ti sekund. Send ein ny førespurnad til same destinasjon medan den gamle heng.

Kva som overlever ei attoppkopling og kva som ikkje gjer det

Ein tunnel er eit sett med ruter, nøklar og adresser, og ei attoppkopling kan gjenoppretta alle tre medan kvar etablert flyt blir verande død. Operativsystemet held ein socket open fordi applikasjonen bad om det, og tidsavbrotet for den socketen kan vera minutt eller timar unna. Under det har motparten gløymt flyten, ei omsetjingsoppføring er gått ut, eller ruta går no gjennom eit endepunkt som aldri såg handtrykket. Ingenting i attoppkoplingssekvensen går gjennom socketane til applikasjonen og reparerer dei.

Nokre klientar legg til ein krok som slepp gamle tilkoplingar ved attoppkopling, og dei fleste gjer det ikkje. Åtferda her varierer etter klient, plattform og versjon.

Fjerdsida gløymde deg òg

Den fjernaste enden held sin eigen tilstand: ei TLS-økt, ein TCP-kontrollblokk og kanskje ei mapping-oppføring som bind adressa og porten din til flyten. Eining for omsetjing langs ruta kan la den mappinga gå ut i løpet av gapet sjølv når tunnelen blir gjenoppretta raskt. Når mappinga er borte, kjem pakkar for ein flyt som serveren ikkje lenger kjenner att, og svaret kan vera ein reset klienten aldri viser. Applikasjonar rapporterer dette som ein fastlåsing og ikkje som ein feil, fordi dei framleis ventar på ein socket som aldri vil svara.

Tidsavbrot for inaktivitet på serversida gjer det same etter sin eigen plan, og difor kan ei økt døy utan noka netthending i det heile. Ei tilkopling som har vore inaktiv lengre enn serveren ventar, er alt borte før du merkar at tunnelen har flytta seg.

Ein ny førespurnad er testen som skil dei

Send ein ny førespurnad til same vert medan den gamle framleis heng, og følg med på båe. Viss den nye førespurnaden lukkast, verkar tunnelen, ruta og namneoppslaget, og feilen er avgrensa til den gamle flyten. Viss den nye førespurnaden òg feilar, har du eit ruteproblem og økttilstanden til applikasjonen er eit falskt spor.

La kvar blokkering av direkte trafikk stå under testen. Ein førespurnad som lukkast gjennom ein tilfeldig reserveveg beviser ingenting om tunnelen.

Stadfest med ei ny tilkopling, ikkje den gamle

Kommandoane nedanfor viser socketane som framleis er opne, startar éin ny førespurnad og sjekkar om økttabellen framleis har ei oppføring for flyten. Køyr den første før og etter attoppkoplinga så skilnaden blir synleg. Byt ut verten og porten med din eigen teneste.

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

Ein etablert socket utan trafikk som rører seg er signaturen du leitar etter, og ein ny førespurnad som returnerer ein statuskode viser at ruta lever. Tilkoplingstabellen svarar på om noko framleis mappar flyten, og det er den delen klienten ikkje kan sjå. Resolver-førespurnaden dekkjer den andre halvdelen av ei sideinnlasting, sidan ein namnefeil og ei fastlåst tilkopling ser like ut i ein nettlesar. Saman skil dei fire utskriftene ei gammal økt frå ein øydelagd tunnel.

Noter avbrotstidspunktet, attoppkoplingstidspunktet og skilnaden mellom den gamle og den nye førespurnaden. Den notata gjer ei vag klage til ein rapport nokon kan handle på.