VPN pārtrūka lapas vidū: vai fona pieprasījumi joprojām iziet?

Cilne joprojām rāda informācijas paneli no laika pirms tuneļa nāves. Statusa skaitļi sasalst, mazs ritenītis turpina griezties, un adreses joslā joprojām ir lietotne, ko atvērāt pirms stundas. Pēc pārrāvuma jūs neko neaiztikāt, tomēr lapa joprojām var mēģināt sasniegt savu serveri pēc sava grafika. Tieši to cilvēki izlaiž: lapa, kas tikai ir redzama, un lapa, kas joprojām sūta pieprasījumus, no ārpuses izskatās vienādi, un tikai viena no tām parādās tīkla žurnālā.

Darbs, ko lapa sāk bez jums

Četri mehānismi uztur ielādētu dokumentu aizņemtu. Atkārtots taimeris var ik pēc dažām sekundēm atkārtoti palaist statusa izsaukumu. Fetch var iedarboties, kad cilne pēc atgriešanās atkal kļūst redzama. Tiešsaistes kanāls, kas veidots uz WebSocket vai servera sūtītiem notikumiem, var mēģināt atkārtoti savienoties pēc sava atkāpšanās grafika. Vietnes reģistrēts service worker var pamosties rindā ievietotai sinhronizācijai pat tad, ja jums priekšā nav nevienas cilnes.

Nevienam no tiem nav nepieciešams klikšķis, un neviens no tiem neielādē dokumentu no jauna. Adreses josla, ritināšanas pozīcija un attēlotās vērtības visas paliek tajās pašās vietās. Mainās tikai tīkla puse: katrs jauns mēģinājums ir svaigs lēmums, kas pieņemts tajā mirklī, kad tas sākas.

Šī atšķirība ir svarīga, jo redzamā lapa tiek glabāta lokāli. Jau uzzīmētie pikseļi neko nepasaka par to, vai nākamais pieprasījums izdevās. Iesaldēta diagramma ar ritenīti ir parastais izskats lapai, kuras pieprasījumi tagad neizdodas. Ekrāna lasīšana pasaka, ko serveris teica pirms dažām minūtēm, nevis to, ko pārlūks dara tagad.

Kāpēc agrākā lapas ielāde netur maršrutu

Nekas lapas ielādē nesaista dokumentu ar tuneli. Maršrutēšana tiek atrisināta katram paketei, sūtīšanas brīdī, no tabulas, kas pastāv, kad pakete iziet. Kad tuneļa saskarne pazūd, šī meklēšana vairs neatbilst tuneļa maršrutam. Tā vai nu nokrīt uz fizisko adapteri, vai atrod neko, atkarībā no tā, ko klients atstāja aiz sevis.

Atkārtoti atzvanījumi ir parasti ieplānoti uzdevumi. HTML standarta taimeru sadaļa apraksta, kā tie tiek ievietoti rindā, un intervālu uzskata par minimālu aizturi, nevis precīza ritma solījumu, tāpēc fona cilne var aptaujāt daudz retāk, nekā prasa tās kods. Mazāk mēģinājumu nav tas pats, kas nekādu mēģinājumu, un cilnes atgriešana priekšplānā ir parasts to uzliesmojuma brīdis.

Kur nolaižas kļūmes politika

Klienta bloķēšana tiek novērtēta tad, kad tiek mēģināts izveidot savienojumu, nevis tad, kad lapa tika iegūta. Ja parastā piekļuve joprojām ir atļauta, atkārtotais mēģinājums var iziet pa fizisko saiti atklāti. Ja politika aiztur šo trafiku, līdz tunelis atgriežas, mēģinājums neizdodas savienošanās brīdī, un lapa parāda kļūdu, ko tā var atkārtot pēc dažām sekundēm.

Divi dati nosaka, kuru no tiem jūs iegūsiet. Pirmais ir piemērošanas tvērums, ko klients atbalsta: bloķēšana visai ierīcei, bloķēšana, kas ierobežota ar tuneļa adapteri, vai noteikumu kopa ar izņēmumiem. Otrais ir tas, vai galamērķis iekrīt izņēmumā, ko iepriekš pievienojāt vietējam printerim, sagūstītajam portālam vai straumēšanas pakalpojumam.

Lietojumprogrammas līmeņa šifrēšana neko no tā nemaina. HTTPS aizsargā baitus starp pārlūku un serveri; tas neko nepasaka par to, kura saskarne tos pārvadā. Lapa var būt lieliski šifrēta un joprojām iziet pa nepareizo ceļu, un tieši to pieļauj šaurs bloķējums.

Kontrolēta pārbaude ar vienreizēju lapu

Izmantojiet jūsu kontrolētu resursdatoru un lapu, kas neko nedara, kā vien to izsauc, lai spēlē nebūtu reālu datu. No termināļa paņemiet ceļa paraugu pirms pārrāvuma un pēc tā:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

Palaidiet to ar ieslēgtu tuneli, tad izslēdziet tuneli un palaidiet vēlreiz. Atbilde no publiskas adreses, kamēr tunelis ir izslēgts, pasaka, ka tiešais ceļš ir atvērts. Taimauta vai atteikta savienojuma gadījumā tā pasaka, ka politika tur. Atkārtojiet vēl vienu reizi pēc tam, kad klients ir atkārtoti pievienojies, lai redzētu tuneļa ceļu atgriežamies, nevis to pieņemtu.

Pārlūkā tīkla panelis atdala abus jautājumus. Filtrējiet uz Fetch/XHR, pēc tam lasiet iniciatora kolonnu: ieraksts, ko sācis taimeris vai skripts, bez pirms tā reģistrētas navigācijas, ir fona mēģinājums, nevis pārlāde. Salīdziniet tā sākuma laiku ar brīdi, kad tunelis pārtrūka. Ja ieraksts joprojām gaida, kad tuneļa vairs nav, pieprasījums gaida ceļu, kas vairs neeksistē.

Servera puses pierādījumi ir spēcīgāki par visu, ko rāda pārlūks. Pieprasījumu žurnāls ar laika zīmogu un avota adresi pierāda, ka pakete ieradās. Pārlūka ieraksti var saturēt sīkfailus, marķierus un pilnus URL, tāpēc paturiet tikai tos laukus, kas nepieciešami jūsu jautājumam, un aizkrāsojiet pārējos, pirms tos kaut kur ielīmējat.

Ko darīt ar atbildi

Ja fona mēģinājumi turpina izdoties, kamēr tunelis ir izslēgts, bloķējums ir šaurāks, nekā jūs domājāt, un šo plaisu ir vērts aizvērt, pirms uzticat klientam jutīgu darbu. Ja tie neizdodas, politika dara savu darbu, un iesaldētā lapa ir tikai kosmētiska. Jebkurā gadījumā vienas cilnes aizvēršana nav visas ierīces kontrole: citas cilnes, citi pārlūki un citas lietotnes katra plāno savu darbu.

Nākamie soļi, ko ir vērts spert: uzskaitiet, kādus izņēmumus un kāpēc pievienojāt, apstipriniet, vai klients bloķē tikai tuneļa tvēruma trafiku vai visu trafiku, un novērojiet vienu fona pieprasījumu no sākuma līdz beigām ar atvērtu servera žurnālu. Šīs trīs atbildes aptver lielāko daļu no tā, ko ziņojums „VPN pārtrūka, un kaut kas joprojām ir savienots“ patiešām satur.