VPN prisijungė iš naujo, bet programos sesija vis tiek žlunga
Prisijungimas iš naujo atkuria maršrutus, o ne lizdo būseną. Atidarykite vieną naują užklausą, kol senoji dar kabo, ir žinosite, kuri iš dviejų nepavyko.
Tunelis grįžta, klientas praneša apie prisijungimą, o naršyklė vis dar sukasi puslapyje, kurį įkėlinėjo prieš nutrūkimą. VPN prisijungimas iš naujo atkuria kelią ir neatkuria tos ryšio būsenos, kurią programos ir tolimoji pusė sukaupė senajame. Tai du skirtingi dalykai, kuriuos reikia taisyti, ir jų sumaišymas be priežasties grąžina jus į VPN nustatymus.
Vienas testas juos švariai atskiria, ir jam reikia dešimties sekundžių. Siųskite naują užklausą tam pačiam tikslui, kol senoji kabo.
Kas išgyvena prisijungimą iš naujo, o kas ne
Tunelis yra maršrutų, raktų ir adresų rinkinys, ir prisijungimas iš naujo gali atkurti visus tris, nors kiekvienas užmegztas srautas lieka miręs. Operacinė sistema laiko lizdą atidarytą todėl, kad programa to paprašė, ir to lizdo laikas gali būti po kelių minučių ar valandų. Po tuo partneris pamiršo srautą, vertimo įrašas pasibaigė, arba kelias dabar eina per tašką, kuris niekada nematė rankos paspaudimo. Niekas prisijungimo iš naujo sekoje nepereina programos lizdų ir jų nesutaiso.
Kai kurie klientai prideda kabliuką, kuris prisijungimo metu išmeta pasenusius ryšius, o dauguma ne. Elgsena čia skiriasi priklausomai nuo kliento, platformos ir versijos.
Tolimoji pusė taip pat jus pamiršo
Tolimasis galas laiko savo būseną: TLS sesiją, TCP valdymo bloką ir galbūt susiejimo įrašą, kuris pririša jūsų adresą ir prievadą prie srauto. Vertimo įrenginys kelyje gali leisti tam susiejimui pasibaigti per pertrauką, net kai tunelis atsistato greitai. Kai susiejimas dingsta, ateina paketai srautui, kurio serveris nebepažįsta, ir atsakymas gali būti reset, kurio klientas niekada nerodo. Programos tai praneša kaip sustojimą, o ne kaip klaidą, nes jos vis dar laukia lizdo, kuris niekada neatsakys.
Serverio pusės neveiklumo laikai daro tą patį pagal savo grafiką, todėl sesija gali mirti be jokio tinklo įvykio. Ryšys, kuris buvo neveiklus ilgiau, nei serveris tikisi, jau dingo, kol pastebėsite, kad tunelis pajudėjo.
Nauja užklausa yra testas, kuris juos atskiria
Siųskite naują užklausą tam pačiam pagrindiniam kompiuteriui, kol senoji dar kabo, ir stebėkite abi. Jei nauja užklausa pavyksta, tuomet tunelis, maršrutas ir vardų skyrimas veikia, o gedimas apsiriboja pasenusiu srautu. Jei nauja užklausa taip pat nepavyksta, turite kelio problemą ir programos sesijos būsena yra klaidingas pėdsakas.
Testo metu palikite vietoje bet kokį tiesioginio srauto blokavimą. Užklausa, kuri pavyksta atsitiktiniu atsarginiu keliu, nieko neįrodo apie tunelį.
Patvirtinkite nauju ryšiu, o ne senuoju
Toliau pateiktos komandos rodo vis dar atidarytus lizdus, pradeda vieną naują užklausą ir patikrina, ar sesijų lentelėje dar yra įrašas srautui. Pirmąją paleiskite prieš prisijungimą iš naujo ir po jo, kad skirtumas būtų matomas. Pakeiskite pagrindinį kompiuterį ir prievadą savo paslauga.
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
Užmegztas lizdas, kuriuo nejuda joks srautas, yra tas požymis, kurio reikia ieškoti, o nauja užklausa, grąžinanti būsenos kodą, rodo, kad kelias gyvas. Ryšių lentelė atsako, ar dar kažkas susieja srautą, ir tai yra dalis, kurios klientas negali matyti. Užklausa rezolveriui apima antrąją puslapio įkėlimo pusę, nes vardo gedimas ir įstrigęs ryšys naršyklėje atrodo vienodai. Kartu tie keturi išvedimai atskiria pasenusią sesiją nuo sulaužyto tunelio.
Užrašykite nutrūkimo laiką, prisijungimo iš naujo laiką ir skirtumą tarp senosios ir naujos užklausos. Tas užrašas paverčia neaiškų nusiskundimą ataskaita, kuria kas nors gali remtis.