A VPN újracsatlakozott, az alkalmazás munkamenete mégis elakad

Az alagút visszatér, a kliens azt jelzi, hogy csatlakozva van, a böngésző pedig még mindig pörög egy oldalon, amelyet a megszakítás előtt töltött be. A VPN újracsatlakozása helyreállít egy útvonalat, és nem állítja helyre azt a kapcsolatállapotot, amelyet az alkalmazások és a távoli oldal a rég-in felhalmozott. Ez két különböző dolog javítanivaló, és összekeverésük ok nélkül küldi vissza a VPN-beállításokhoz.

Egyetlen teszt tisztán elválasztja őket, és tíz másodpercig tart. Küldjön új kérést ugyanarra a célra, amíg a régi lóg.

Mi éli túl az újracsatlakozást és mi nem

Az alagút útvonalak, kulcsok és címek halmaza, és az újracsatlakozás mindhármat helyreállíthatja, miközben minden létrejött folyam halott marad. Az operációs rendszer nyitva tart egy socketet, mert az alkalmazás kérte, és annak a socketnek az időkorlátja percek vagy órák távolságában lehet. Alatta a partner elfelejtette a folyamot, lejárt egy fordítási bejegyzés, vagy az útvonal olyan végponton halad át, amely soha nem látta a kézfogást. Az újracsatlakozás sorrendjében semmi nem járja végig az alkalmazás socketjeit és nem javítja meg őket.

Egyes kliensek horgot adnak hozzá, amely újracsatlakozáskor eldobja az elavult kapcsolatokat, a legtöbb azonban nem. A viselkedés itt kliensenként, platformonként és verzióként változik.

A távoli oldal is elfelejtette önt

A távoli vég a saját állapotát tartja: TLS-munkamenetet, TCP-vezérlőblokkot és talán egy leképezési bejegyzést, amely a címét és a portját a folyamhoz köti. Az útvonalon lévő fordítási eszköz a rés alatt lejárhatja ezt a leképezést, akkor is, ha az alagút gyorsan helyreáll. Amint a leképezés eltűnik, csomagok érkeznek egy olyan folyamhoz, amelyet a kiszolgáló már nem ismer fel, és a válasz egy reset lehet, amelyet a kliens soha nem mutat meg. Az alkalmazások ezt akadásként jelentik, nem hibaként, mert még mindig egy olyan socketre várnak, amely soha nem fog válaszolni.

A kiszolgáló oldali tétlenségi időkorlátok ugyanezt teszik a saját ütemtervük szerint, ezért egy munkamenet bármilyen hálózati esemény nélkül meghalhat. Az a kapcsolat, amely tovább volt tétlen, mint a kiszolgáló várja, már eltűnt, mielőtt észrevenné, hogy az alagút elmozdult.

Az új kérés az a teszt, amely elválasztja őket

Küldjön új kérést ugyanarra a gazdagépre, amíg a régi még lóg, és figyelje mindkettőt. Ha az új kérés sikerül, akkor az alagút, az útvonal és a névfeloldás működik, és a hiba az elavult folyamra korlátozódik. Ha az új kérés is elbukik, akkor útvonalproblémája van, és az alkalmazás munkamenet-állapota hamis nyom.

A teszt alatt hagyjon minden közvetlen forgalom-blokkot a helyén. Egy véletlen tartalék útvonalon sikerülő kérés semmit sem bizonyít az alagútról.

Új kapcsolattal erősítse meg, ne a régivel

Az alábbi parancsok megmutatják a még nyitott socketeket, elindítanak egy új kérést, és ellenőrzik, hogy a munkamenet-tábla még tart-e bejegyzést a folyamhoz. Futtassa az elsőt az újracsatlakozás előtt és után, hogy látható legyen a különbség. Cserélje ki a gazdagépet és a portot a saját szolgáltatására.

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

A mozgó forgalom nélküli létrejött socket az a jel, amelyet keresni kell, és a státuszkódot visszaadó új kérés mutatja, hogy az útvonal él. A kapcsolattábla megválaszolja, hogy leképez-e még valami a folyamot, és ez az a rész, amelyet a kliens nem láthat. A feloldó lekérdezése az oldalbetöltés másik felét fedi le, mert a névhiba és az elakadt kapcsolat ugyanúgy néz ki egy böngészőben. Együtt ez a négy kimenet elválasztja az elavult munkamenetet a törött alagúttól.

Jegyezze fel a megszakítás idejét, az újracsatlakozás idejét és a régi és az új kérés közötti különbséget. Ez a jegyzet homályos panaszt olyan jelentéssé alakít, amelyre valaki cselekedhet.