VPN atkal pieslēdzās, bet lietotnes sesija joprojām neizdodas

Tunelis atgriežas, klients ziņo par pieslēgšanos, un pārlūks joprojām griežas lapā, ko tas ielādēja pirms pārrāvuma. VPN atkārtota pieslēgšanās atjauno ceļu un neatjauno to savienojuma stāvokli, ko lietotnes un attālā puse sakrāja vecajā. Tie ir divi dažādi labojamie, un to sajaukšana bez iemesla aizsūta jūs atpakaļ uz VPN iestatījumiem.

Viens tests tos tīri atdala, un tam vajag desmit sekundes. Nosūtiet jaunu pieprasījumu uz to pašu galamērķi, kamēr vecais karājas.

Kas pārdzīvo atkārtotu pieslēgšanos un kas ne

Tunelis ir maršrutu, atslēgu un adrešu kopa, un atkārtota pieslēgšanās var atjaunot visas trīs, kamēr katrs izveidotais plūdums paliek miris. Operētājsistēma tur ligzdu atvērtu tāpēc, ka lietotne to lūdza, un tās ligzdas noilgums var būt minūtes vai stundas tālu. Zem tā partneris ir aizmirsis plūdumu, tulkošanas ieraksts ir beidzies, vai ceļš tagad iet caur galapunktu, kas nekad nav redzējis rokas spiedienu. Nekas atkārtotas pieslēgšanās secībā neizstaigā lietotnes ligzdas un nelabo tās.

Daži klienti pievieno āķi, kas atkārtotas pieslēgšanās laikā izmet novecojušus savienojumus, un vairums nepievieno. Uzvedība šeit atšķiras atkarībā no klienta, platformas un versijas.

Attālā puse aizmirsa arī jūs

Tālais gals tur savu stāvokli: TLS sesiju, TCP vadības bloku un varbūt kartēšanas ierakstu, kas piesaista jūsu adresi un portu plūdumam. Tulkošanas ierīce ceļā var ļaut šim kartējumam beigties pārrāvuma laikā, pat ja tunelis ātri atjaunojas. Kad kartējums pazūd, pienāk paketes plūdumam, ko serveris vairs neatpazīst, un atbilde var būt reset, ko klients nekad neparāda. Lietotnes to ziņo kā apstāšanos, nevis kļūdu, jo tās joprojām gaida ligzdu, kas nekad neatbildēs.

Servera puses dīkstāves noilgumi dara to pašu pēc sava grafika, tāpēc sesija var nomirt bez neviena tīkla notikuma. Savienojums, kas bija dīkstāvē ilgāk, nekā serveris gaida, jau ir pazudis, pirms pamanāt, ka tunelis ir pārvietojies.

Jauns pieprasījums ir tests, kas tos atdala

Nosūtiet jaunu pieprasījumu uz to pašu resursdatoru, kamēr vecais vēl karājas, un vērojiet abus. Ja jaunais pieprasījums izdodas, tad tunelis, maršruts un vārdu izšķiršana darbojas, un kļūme aprobežojas ar novecojušo plūdumu. Ja arī jaunais pieprasījums neizdodas, jums ir ceļa problēma un lietotnes sesijas stāvoklis ir nepareiza pēda.

Testa laikā atstājiet vietā jebkuru tiešās plūsmas bloķēšanu. Pieprasījums, kas izdodas pa nejaušu rezerves ceļu, par tuneli neko nepierāda.

Apstipriniet ar jaunu savienojumu, nevis veco

Tālāk dotās komandas parāda vēl atvērtās ligzdas, sāk vienu jaunu pieprasījumu un pārbauda, vai sesiju tabulā vēl ir ieraksts plūdumam. Palaidiet pirmo pirms atkārtotas pieslēgšanās un pēc tās, lai starpība būtu redzama. Aizstājiet resursdatoru un portu ar savu pakalpojumu.

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

Izveidota ligzda, kurā nekustas plūsma, ir tā pazīme, kas jāmeklē, un jauns pieprasījums, kas atgriež statusa kodu, rāda, ka ceļš ir dzīvs. Savienojumu tabula atbild, vai kaut kas vēl kartē plūdumu, un tā ir daļa, ko klients nevar redzēt. Vaicājums atrisinātājam nosedz otru lapas ielādes pusi, jo vārda kļūme un iestrēdzis savienojums pārlūkā izskatās vienādi. Kopā šie četri izvadi atdala novecojušu sesiju no salauzta tuneļa.

Pierakstiet pārrāvuma laiku, atkārtotas pieslēgšanās laiku un starpību starp veco un jauno pieprasījumu. Šis pieraksts pārvērš neskaidru sūdzību ziņojumā, ar ko kāds var rīkoties.