VPN je pao usred stranice: izlaze li pozadinski zahtjevi i dalje?

Kartica i dalje prikazuje nadzornu ploču od prije nego što je tunel umro. Brojevi stanja se zamrzavaju, mali spinner se nastavlja vrtjeti, a adresna traka još nosi aplikaciju koju ste otvorili prije sat vremena. Niste ništa dirali nakon prekida, a ipak stranica možda još pokušava doći do svog servera po vlastitom rasporedu. To je dio koji ljudi propuštaju: stranica koja je samo vidljiva i stranica koja još šalje zahtjeve izvana izgledaju isto, a samo jedna od njih pojavljuje se u mrežnom dnevniku.

Posao koji stranica započne bez vas

Četiri mehanizma drže učitan dokument zauzetim. Ponavljajući tajmer može ponovno pokretati poziv stanja svakih nekoliko sekundi. Fetch se može aktivirati kada kartica ponovno postane vidljiva nakon što se vratite na nju. Živi kanal izgrađen na WebSocketu ili događajima koje šalje server može pokušati ponovno spajanje po vlastitom rasporedu odustajanja. Servisni radnik koji je stranica registrirala može se probuditi za sinhronizaciju u redu čekanja čak i kada nema kartice pred vama.

Nijedan od njih ne traži klik i nijedan ne ponovno učitava dokument. Adresna traka, položaj pomicanja i prikazane vrijednosti ostaju tamo gdje su bili. Mijenja se samo mrežna strana: svaki novi pokušaj je svježa odluka donesena u trenutku kada počinje.

Ta razlika je važna jer se vidljiva stranica pohranjuje lokalno. Već naslikani pikseli ne govore ništa o tome je li sljedeći zahtjev uspio. Zamrznuti grafikon sa spinnerom uobičajen je izgled stranice čiji zahtjevi sada ne uspijevaju. Čitanje ekrana govori vam što je server rekao prije nekoliko minuta, a ne što preglednik radi sada.

Zašto ranije učitavanje stranice ne drži rutu

Ništa u učitavanju stranice ne veže dokument za tunel. Usmjeravanje se rješava po paketu, u vrijeme slanja, iz tablice koja postoji kada paket izlazi. Kada tunelsko sučelje nestane, to pretraživanje više ne odgovara tunelskoj ruti. Ili propada na fizički adapter ili ne nalazi ništa, ovisno o tome što je klijent ostavio za sobom.

Ponavljajući povratni pozivi obični su zakazani zadaci. Odjeljak standarda HTML o tajmerima opisuje kako se stavljaju u red i interval tretira kao minimalno kašnjenje, a ne kao obećanje točnog ritma, pa pozadinska kartica može anketirati mnogo rjeđe nego što njezin kod traži. Manje pokušaja nije isto što i nikakvi pokušaji, a vraćanje kartice u prvi plan uobičajen je trenutak za njihov izljev.

Gdje politika kvara završava

Klijentski blok procjenjuje se kada se pokuša veza, a ne kada je stranica dohvaćena. Ako je običan pristup još dopušten, ponovni pokušaj može izaći preko fizičke veze otvoreno. Ako politika zadržava taj promet dok se tunel ne vrati, pokušaj ne uspijeva u trenutku spajanja i stranica prikazuje grešku koju može ponoviti nekoliko sekundi kasnije.

Dva detalja odlučuju koji ćete od toga dobiti. Prvi je opseg primjene koji klijent podržava: blok za cijeli uređaj, blok ograničen na tunelski adapter ili skup pravila s izuzecima. Drugi je pada li odredište unutar izuzetka koji ste ranije dodali za lokalni pisač, captive portal ili uslugu strujanja.

Šifriranje na razini aplikacije ne mijenja ništa od ovoga. HTTPS štiti bajtove između preglednika i servera; ne govori ništa o tome koje sučelje ih nosi. Stranica može biti savršeno šifrirana i ipak izaći pogrešnim putem, a upravo to uski blok dopušta.

Kontrolirana provjera s jednokratnom stranicom

Upotrijebite host koji kontrolirate i stranicu koja ne radi ništa osim što ga poziva, tako da u igri nema stvarnih podataka. Iz terminala uzmite uzorak puta prije i poslije prekida:

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

Pokrenite to s uključenim tunelom, zatim isključite tunel i pokrenite ponovno. Odgovor s javne adrese dok je tunel isključen govori vam da je izravni put otvoren. Istek vremena ili odbijena veza govori vam da politika drži. Ponovite još jednom nakon što se klijent ponovno spoji, kako biste vidjeli da se tunelski put vraća, umjesto da pretpostavljate da jest.

U pregledniku mrežna ploča razdvaja dva pitanja. Filtrirajte na Fetch/XHR, zatim pročitajte stupac inicijatora: unos koji je pokrenuo tajmer ili skripta, bez zabilježene navigacije prije njega, pozadinski je pokušaj, a ne ponovno učitavanje. Usporedite njegovo vrijeme početka s trenutkom kada je tunel pao. Ako je unos još na čekanju dok tunela nema, zahtjev čeka put koji više ne postoji.

Dokazi na strani servera jači su od svega što preglednik prikazuje. Dnevnik zahtjeva s vremenskom oznakom i izvornom adresom dokazuje da je paket stigao. Unosi u pregledniku mogu nositi kolačiće, tokene i pune URL-ove, zato zadržite samo polja koja vaše pitanje treba i redigirajte ostalo prije nego što ih zalijepite bilo gdje.

Što učiniti s odgovorom

Ako pozadinski pokušaji nastavljaju uspijevati dok je tunel isključen, blok je uži nego što ste pretpostavili, a tu prazninu vrijedi zatvoriti prije nego što klijentu povjerite osjetljiv rad. Ako ne uspijevaju, politika radi svoj posao i zamrznuta je stranica kozmetička. U svakom slučaju, zatvaranje jedne kartice nije kontrola na razini uređaja: druge kartice, drugi preglednici i druge aplikacije svaki planiraju svoj posao.

Sljedeći koraci vrijedni poduzimanja: navedite koje ste izuzetke dodali i zašto, potvrdite blokira li klijent samo promet u tunelskom opsegu ili sav promet, i promatrajte jedan pozadinski zahtjev od početka do kraja s otvorenim dnevnikom servera. Ta tri odgovora pokrivaju većinu onoga što izvještaj „VPN je pao i nešto je još povezano” zapravo sadrži.