VPN se je znova povezal, a seja aplikacije še vedno spodleti

Predor se vrne, odjemalec sporoči povezavo, brskalnik pa se še vedno vrti na strani, ki jo je nalagal pred prekinitvijo. Ponovna povezava VPN obnovi pot in ne obnovi stanja povezave, ki so ga aplikacije in oddaljena stran nabrale na stari. To sta dve različni stvari za popravilo in njuno mešanje vas brez razloga pošlje nazaj v nastavitve VPN.

En test ju čisto loči in traja deset sekund. Pošljite novo zahtevo na isti cilj, medtem ko stara visi.

Kaj ponovna povezava preživi in kaj ne

Predor je nabor poti, ključev in naslovov, ponovna povezava pa lahko obnovi vse tri, medtem ko vsak vzpostavljen tok ostane mrtev. Operacijski sistem drži vtičnico odprto, ker je aplikacija to zahtevala, in časovna omejitev te vtičnice je lahko minute ali ure stran. Pod tem je partner pozabil tok, vnos prevajanja je potekel, ali pot zdaj poteka skozi končno točko, ki ni nikoli videla rokovanja. Nič v zaporedju ponovne povezave ne prehaja vtičnic aplikacije in jih ne popravlja.

Nekateri odjemalci dodajo kavelj, ki pri ponovni povezavi zavrže zastarele povezave, večina pa ne. Vedenje se tu razlikuje glede na odjemalca, platformo in različico.

Tudi oddaljena stran vas je pozabila

Oddaljeni konec hrani svoje stanje: sejo TLS, krmilni blok TCP in morda vnos preslikave, ki veže vaš naslov in vrata na tok. Naprava za prevajanje na poti lahko pusti tej preslikavi, da poteče med vrzeljo, tudi ko se predor hitro vzpostavi. Ko preslikava izgine, prihajajo paketi za tok, ki ga strežnik ne prepozna več, odgovor pa je lahko reset, ki ga odjemalec nikoli ne pokaže. Aplikacije to sporočajo kot zastoj in ne kot napako, ker še vedno čakajo na vtičnico, ki ne bo nikoli odgovorila.

Časovne omejitve nedejavnosti na strani strežnika delajo isto po svojem urniku, zato lahko seja umre brez kakršnega koli omrežnega dogodka. Povezava, ki je bila nedejavna dlje, kot strežnik pričakuje, je že izginila, preden opazite, da se je predor premaknil.

Nova zahteva je test, ki ju loči

Pošljite novo zahtevo na isti gostitelj, medtem ko stara še visi, in opazujte obe. Če nova zahteva uspe, predor, pot in razreševanje imen delujejo, napaka pa je omejena na zastareli tok. Če tudi nova zahteva spodleti, imate težavo s potjo in stanje seje aplikacije je napačna sled.

Med testom pustite vsako blokado neposrednega prometa na mestu. Zahteva, ki uspe po naključni rezervni poti, o predoru ničesar ne dokaže.

Potrdite z novo povezavo, ne s staro

Spodnji ukazi pokažejo še odprte vtičnice, začnejo eno novo zahtevo in preverijo, ali tabela sej še drži vnos za tok. Zaženite prvega pred ponovno povezavo in po njej, da bo razlika vidna. Zamenjajte gostitelja in vrata s svojo storitvijo.

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

Vzpostavljena vtičnica brez prometa, ki se premika, je podpis, ki ga iščete, nova zahteva, ki vrne kodo stanja, pa pokaže, da je pot živa. Tabela povezav odgovori, ali kaj še preslika tok, in to je del, ki ga odjemalec ne more videti. Poizvedba pri razreševalniku pokriva drugo polovico nalaganja strani, ker sta neuspeh imena in zataknjena povezava v brskalniku videti enako. Skupaj ti štirje izhodi ločijo zastarelo sejo od pokvarjenega predora.

Zapišite čas prekinitve, čas ponovne povezave in razliko med staro in novo zahtevo. Ta zapis spremeni nejasno pritožbo v poročilo, s katerim lahko kdo dela.