VPN u rilidh, por sesioni i aplikacionit vazhdon të dështojë

Tuneli kthehet, klienti thotë se është lidhur, dhe shfletuesi vazhdon të rrotullohet në një faqe që po ngarkonte para ndërprerjes. Një rilidhje VPN rikthen një rrugë dhe nuk rikthen gjendjen e lidhjes që aplikacionet dhe pala e largët grumbulluan në atë të vjetrën. Këto janë dy gjëra të ndryshme për t’u riparuar, dhe ngatërrimi i tyre ju kthen në cilësimet e VPN pa arsye.

Një test i ndan ato pastër, dhe zgjat dhjetë sekonda. Dërgoni një kërkesë të re në të njëjtin destinacion ndërsa e vjetra varet.

Çfarë i mbijeton një rilidhjeje dhe çfarë jo

Një tunel është një grup rrugësh, çelësash dhe adresash, dhe një rilidhje mund t’i rikthejë të treja ndërsa çdo rrjedhë e vendosur mbetet e vdekur. Sistemi operativ mban një soket të hapur sepse aplikacioni e kërkoi, dhe afati i atij soketi mund të jetë minuta ose orë larg. Nën të, pala tjetër ka harruar rrjedhën, një zë përkthimi ka skaduar, ose rruga kalon tani nëpër një pikë fundore që nuk e pa kurrë shtrëngimin e duarve. Asgjë në sekuencën e rilidhjes nuk kalon nëpër soketat e aplikacionit dhe nuk i riparon ato.

Disa klientë shtojnë një grep që hedh poshtë lidhjet e vjetra gjatë rilidhjes, dhe shumica nuk e bëjnë. Sjellja këtu ndryshon sipas klientit, platformës dhe versionit.

Pala e largët ju harroi edhe ju

Fundi i largët mban gjendjen e vet: një sesion TLS, një bllok kontrolli TCP dhe ndoshta një zë hartëzimi që lidh adresën dhe portin tuaj me rrjedhën. Një pajisje përkthimi në rrugë mund të lejojë që ai hartëzim të skadojë gjatë boshllëkut edhe kur tuneli rivendoset shpejt. Pasi hartëzimi zhduket, mbërrijnë paketa për një rrjedhë që serveri nuk e njeh më, dhe përgjigjja mund të jetë një reset që klienti nuk e shfaq kurrë. Aplikacionet e raportojnë këtë si ngecje dhe jo si gabim, sepse janë ende duke pritur një soket që nuk do të përgjigjet kurrë.

Afatet e pasivitetit në anën e serverit bëjnë të njëjtën gjë sipas orarit të tyre, prandaj një sesion mund të vdesë pa asnjë ngjarje rrjeti. Një lidhje që ka qenë pasive më gjatë nga sa pret serveri tashmë ka ikur përpara se të vini re se tuneli është zhvendosur.

Kërkesa e re është testi që i ndan

Dërgoni një kërkesë të re në të njëjtin host ndërsa e vjetra varet ende, dhe vëzhgoni të dyja. Nëse kërkesa e re ka sukses, atëherë tuneli, rruga dhe zgjidhja e emrave punojnë, dhe defekti kufizohet te rrjedha e vjetër. Nëse edhe kërkesa e re dështon, keni një problem rruge dhe gjendja e sesionit të aplikacionit është një gjurmë e rreme.

Mbajeni në vend çdo bllokim të trafikut të drejtpërdrejtë gjatë testit. Një kërkesë që ka sukses nëpër një rrugë rezervë aksidentale nuk provon asgjë për tunelin.

Konfirmoni me një lidhje të re, jo me atë të vjetrën

Komandat më poshtë tregojnë soketat ende të hapur, nisin një kërkesë të re dhe kontrollojnë nëse tabela e sesioneve mban ende një zë për rrjedhën. Ekzekutoni të parën para dhe pas rilidhjes që diferenca të jetë e dukshme. Zëvendësoni hostin dhe portin me shërbimin tuaj.

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

Një soket i vendosur pa trafik në lëvizje është shenja që duhet kërkuar, dhe një kërkesë e re që kthen një kod statusi tregon se rruga është e gjallë. Tabela e lidhjeve përgjigjet nëse diçka vazhdon ta hartëzojë rrjedhën, dhe kjo është pjesa që klienti nuk mund ta shohë. Kërkesa te zgjidhësi mbulon gjysmën tjetër të ngarkimit të një faqeje, sepse një dështim emri dhe një lidhje e bllokuar duken njësoj në një shfletues. Së bashku, këto katër dalje e ndajnë një sesion të vjetër nga një tunel i prishur.

Shënoni kohën e ndërprerjes, kohën e rilidhjes dhe diferencën midis kërkesës së vjetër dhe asaj të re. Ai shënim e kthen një ankesë të paqartë në një raport mbi të cilin dikush mund të veprojë.