La VPN rekonektiĝis, sed la aplikaĵa seanco ankoraŭ fiaskas

La tunelo revenas, la kliento diras ke ĝi estas konektita, kaj la retumilo ankoraŭ turniĝas sur paĝo, kiun ĝi ŝargis antaŭ la interrompo. Rekonekto de VPN restarigas vojon, kaj ĝi ne restarigas la konektan staton, kiun la aplikaĵoj kaj la malproksima flanko amasigis sur la malnova. Temas pri du malsamaj aferoj ripareblaj, kaj konfuzi ilin sendas vin reen al la VPN-agordoj sen kaŭzo.

Unu testo klare apartigas ilin, kaj ĝi daŭras dek sekundojn. Sendu novan peton al la sama celo, dum la malnova pendas.

Kio postvivas rekonekton kaj kio ne

Tunelo estas aro da vojoj, ŝlosiloj kaj adresoj, kaj rekonekto povas restarigi ĉiujn tri dum ĉiu starigita fluo restas morta. La operaciumo tenas ingon malfermita ĉar la aplikaĵo petis tion, kaj la tempolimo de tiu ingo povas esti minutoj aŭ horoj for. Sube, la partnero forgesis la fluon, traduka ero eksvalidiĝis, aŭ la vojo nun iras tra finpunkto, kiu neniam vidis la manpremon. Nenio en la rekonekta sinsekvo trapasas la ingojn de la aplikaĵo kaj riparas ilin.

Iuj klientoj aldonas hokon, kiu forĵetas eksdatajn konektojn ĉe rekonekto, kaj la plej multaj ne. La konduto ĉi tie varias laŭ kliento, platformo kaj versio.

Ankaŭ la malproksima flanko forgesis vin

La fora fino tenas propran staton: TLS-seancon, TCP-regadblokon, kaj eble mapadan eron, kiu ligas vian adreson kaj pordon al la fluo. Traduka aparato laŭ la vojo povas lasi tiun mapadon eksvalidiĝi dum la paŭzo, eĉ kiam la tunelo restarigatas rapide. Post kiam la mapado malaperis, pakaĵoj alvenas por fluo, kiun la servilo jam ne rekonas, kaj la respondo povas esti restarigo, kiun la kliento neniam montras. Aplikaĵoj raportas tion kiel haltiĝon, ne kiel eraron, ĉar ili ankoraŭ atendas ingon, kiu neniam respondos.

Senokupaj tempolimoj ĉe la servila flanko faras la samon laŭ propra horaro, kaj tial seanco povas morti sen iu ajn reta evento. Konekto, kiu estis senokupa pli longe ol la servilo atendas, jam malaperis antaŭ ol vi rimarkas, ke la tunelo moviĝis.

Nova peto estas la testo, kiu apartigas ilin

Sendu novan peton al la sama gastiganto dum la malnova ankoraŭ pendas, kaj observu ambaŭ. Se la nova peto sukcesas, tiam la tunelo, la vojo kaj la nomrezo ĉiuj funkcias, kaj la difekto limiĝas al la eksdata fluo. Se ankaŭ la nova peto fiaskas, vi havas vojan problemon kaj la seanca stato de la aplikaĵo estas falsa spuro.

Konservu iun ajn blokadon de rekta trafiko dum la testo. Peto, kiu sukcesas tra hazarda rezerva vojo, pruvas nenion pri la tunelo.

Konfirmu per nova konekto, ne per la malnova

La subaj komandoj montras la ingojn ankoraŭ malfermitajn, lanĉas unu novan peton kaj kontrolas, ĉu la seanca tabelo ankoraŭ tenas eron por la fluo. Rulu la unuan antaŭ kaj post la rekonekto, por ke la diferenco videblu. Anstataŭigu la gastiganton kaj pordon per via propra servo.

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

Starigita ingo sen moviĝanta trafiko estas la signo, kiun vi serĉu, kaj nova peto redonanta statusan kodon montras, ke la vojo vivas. La konekta tabelo respondas, ĉu io ankoraŭ mapas la fluon, kaj tio estas la parto, kiun la kliento ne povas vidi. La demando al la solvilo kovras la alian duonon de paĝa ŝarĝo, ĉar nomfiasko kaj blokita konekto aspektas idente en retumilo. Kune, tiuj kvar eligoj apartigas eksdatajn seancon de rompita tunelo.

Notu la interrompan tempon, la rekonektan tempon kaj la diferencon inter la malnova kaj la nova peto. Tiu noto transformas vagan plendon en raporton, pri kiu iu povas agi.