VPN je padel sredi strani: ali pozadinske zahteve še vedno odhajajo?

Zavihek še vedno prikazuje nadzorno ploščo od prej, preden je tunel umrl. Številke stanja zamrznejo, majhen kazalnik se še vrti, naslovna vrstica pa še vedno nosi aplikacijo, ki ste jo odprli pred uro. Po prekinitvi se niste ničesar dotaknili, pa vendar lahko stran še vedno poskuša doseči svoj strežnik po lastnem urniku. To je del, ki ga ljudje zgrešijo: stran, ki je le vidna, in stran, ki še vedno pošilja zahteve, sta od zunaj videti enako, in le ena od njiju se pojavi v omrežnem dnevniku.

Delo, ki ga stran začne brez vas

Štirje mehanizmi držijo naložen dokument zaposlen. Ponavljajoči se časovnik lahko znova zažene klic stanja vsakih nekaj sekund. Fetch se lahko sproži, ko zavihek po vrnitvi znova postane viden. Živ kanal, zgrajen na WebSocketu ali dogodkih, ki jih pošilja strežnik, lahko poskusi ponovno povezavo po lastnem urniku umikanja. Servisni delavec, ki ga je registriralo spletišče, se lahko zbudi za sinhronizacijo v čakalni vrsti, tudi ko pred vami ni nobenega zavihka.

Nobena od teh ne potrebuje klika in nobena znova ne naloži dokumenta. Naslovna vrstica, položaj drsenja in prikazane vrednosti ostanejo tam, kjer so bile. Spremeni se le omrežna stran: vsak nov poskus je sveža odločitev, sprejeta v trenutku, ko se začne.

Ta razlika je pomembna, ker je vidna stran shranjena lokalno. Že narisane slikovne pike ne povedo ničesar o tem, ali je naslednja zahteva uspela. Zamrznjen grafikon s kazalnikom je običajen videz strani, katere zahteve zdaj ne uspevajo. Branje zaslona vam pove, kaj je strežnik rekel pred nekaj minutami, ne pa, kaj brskalnik počne zdaj.

Zakaj prejšnje nalaganje strani ne drži poti

Nič v nalaganju strani ne veže dokumenta na tunel. Usmerjanje se rešuje za vsak paket v trenutku pošiljanja iz tabele, ki obstaja, ko paket odide. Ko vmesnik tunela izgine, to iskanje ne ustreza več poti tunela. Bodisi pade na fizični adapter bodisi ne najde ničesar, odvisno od tega, kaj je odjemalec pustil za seboj.

Ponavljajoči se povratni klici so običajne načrtovane naloge. Razdelek o časovnikih standarda HTML opisuje, kako se postavijo v čakalno vrsto, in interval obravnava kot najmanjšo zamudo, ne kot obljubo natančnega ritma, zato lahko zavihek v ozadju sprašuje veliko redkeje, kot zahteva njegova koda. Manj poskusov ni isto kot noben poskus, in vrnitev zavihka v ospredje je pogost trenutek za njihov izbruh.

Kam pristane politika napake

Blokada odjemalca se oceni, ko se poskusi povezava, ne ko je bila stran pridobljena. Če je običajen dostop še dovoljen, lahko ponovni poskus odide prek fizične povezave nekodirano. Če politika zadrži ta promet, dokler se tunel ne vrne, poskus spodleti v trenutku povezave in stran prikaže napako, ki jo lahko poskusi znova nekaj sekund pozneje.

Dve podrobnosti odločata, katero od tega dobite. Prva je obseg izvajanja, ki ga odjemalec podpira: blokada cele naprave, blokada omejena na adapter tunela ali nabor pravil z izjemami. Druga je, ali cilj pade v izjemo, ki ste jo prej dodali za lokalni tiskalnik, ujeti portal ali storitev pretakanja.

Šifriranje na ravni aplikacije tega ne spremeni. HTTPS ščiti bajte med brskalnikom in strežnikom; ne pove ničesar o tem, kateri vmesnik jih prenaša. Stran je lahko popolnoma šifrirana in vseeno odide po napačni poti, in prav to ozka blokada dovoljuje.

Nadzorovana preveritev z enkratno stranjo

Uporabite gostitelja, ki ga nadzorujete, in stran, ki ne počne ničesar drugega, kot da ga kliče, da v igri ne bo resničnih podatkov. V terminalu vzemite vzorec poti pred prekinitvijo in po njej:

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

Zaženite to z dvignjenim tunelom, nato spustite tunel in zaženite znova. Odgovor z javnega naslova, ko je tunel spuščen, vam pove, da je neposredna pot odprta. Prekoračitev časa ali zavrnjena povezava vam pove, da politika drži. Ponovite še enkrat, potem ko se odjemalec znova poveže, da vidite vrnitev poti tunela, namesto da bi to predvidevali.

V brskalniku plošča Omrežje ločuje obe vprašanji. Filtrirajte na Fetch/XHR, nato preberite stolpec začetnika: vnos, ki ga je zagnal časovnik ali skript, brez zabeležene navigacije pred njim, je poskus v ozadju in ne ponovno nalaganje. Primerjajte njegov začetni čas s trenutkom, ko je tunel padel. Če je vnos še vedno v teku, ko tunela ni več, zahteva čaka na pot, ki ne obstaja več.

Dokazi na strani strežnika so močnejši od vsega, kar prikaže brskalnik. Dnevnik zahtev s časovnim žigom in izvornim naslovom dokazuje, da je paket prispel. Vnosi brskalnika lahko nosijo piškotke, žetone in polne URL-je, zato obdržite le polja, ki jih vaše vprašanje potrebuje, in preostanek prekrijte, preden jih kam prilepite.

Kaj storiti z odgovorom

Če poskusi v ozadju še naprej uspevajo, medtem ko je tunel spuščen, je blokada ožja, kot ste domnevali, in to vrzel je vredno zapreti, preden odjemalcu zaupate občutljivo delo. Če spodletijo, politika opravlja svoje delo in zamrznjena stran je kozmetična. Kakor koli, zaprtje enega zavihka ni nadzor za celotno napravo: drugi zavihki, drugi brskalniki in druge aplikacije vsak načrtujejo svoje delo.

Naslednji koraki, ki se jih splača lotiti: naštejte, katere izjeme ste dodali in zakaj, potrdite, ali odjemalec blokira samo promet v obsegu tunela ali ves promet, in opazujte eno pozadinsko zahtevo od začetka do konca z odprtim dnevnikom strežnika. Ti trije odgovori pokrivajo večino tega, kar poročilo „VPN je padel in nekaj je še vedno povezano“ v resnici vsebuje.