VPN fall midt på sida: går bakgrunnsførespurnader framleis ut?

Fana viser framleis dashbordet frå før tunnelen døydde. Statusnummer frys, ein liten snurr held fram med å snurre, og adresselinja ber framleis appen du opna for ein time sidan. Du rørte ingenting etter brotet, men sida kan framleis prøve å nå serveren sin etter sin eigen tidsplan. Det er dette folk overser: ei side som berre er synleg, og ei side som framleis sender førespurnader, ser like ut utanfrå, og berre éi av dei dukkar opp i ein nettverkslogg.

Arbeid ei side startar utan deg

Fire mekanismar held eit lasta dokument oppteke. Ein gjentakande timer kan køyre eit statuskall på nytt kvart par sekund. Ein fetch kan utløysast når fana blir synleg igjen etter at du byter tilbake til henne. Ein levande kanal bygd på WebSocket eller hendingar serveren sender, kan prøve ei ny tilkopling etter sin eigen backoff-plan. Ein service worker som nettstaden har registrert, kan vakne for ein synkronisering i kø sjølv når ingen fane står framfor deg.

Ingen av dei treng eit klikk, og ingen av dei lastar dokumentet på nytt. Adresselinja, rulleposisjonen og dei viste verdiane blir alle ståande der dei var. Det er berre nettverkssida som endrar seg: kvart nytt forsøk er eit ferskt vedtak teke i det augneblikket det startar.

Den skilnaden betyr noko fordi den synlege sida er lagra lokalt. Pikslar som alt er teikna, seier ingenting om kor vidt neste førespurnad lukkast. Eit frose diagram med ein snurr er det vanlege utsjåandet til ei side der førespurnadene no feilar. Å lese skjermen fortel deg kva serveren sa for nokre minutt sidan, ikkje kva nettlesaren gjer no.

Kvifor den tidlegare sideinnlastinga ikkje held ei rute

Ingenting i sideinnlastinga bind dokumentet til tunnelen. Ruting blir avgjord per pakke, ved sendetidspunktet, frå tabellen som finst når pakka forlèt maskinen. Når tunnelgrensesnittet forsvinn, svarar ikkje det oppslaget lenger til tunnelruta. Det fell anten gjennom til den fysiske adapteren eller finn ingenting, avhengig av kva klienten lét etter seg.

Gjentakande tilbakekallingar er vanlege planlagde oppgåver. Timer-avsnittet i HTML-standarden skildrar korleis dei blir sette i kø og handsamar intervallet som ei minimumsforseinking i staden for eit løfte om nøyaktig kadens, slik at ei bakgrunnsfane kan polle langt sjeldnare enn koden ber om. Færre forsøk er ikkje det same som ingen forsøk, og å bringe ei fane tilbake i framgrunnen er eit vanleg augneblink for ein byge av dei.

Kvar feilpolitikken landar

Blokkeringa til klienten blir vurdert når ei tilkopling blir prøvd, ikkje då sida vart henta. Viss vanleg tilgang framleis er tillaten, kan nytt forsøk gå ut over den fysiske lenka i klartekst. Viss politikken held trafikken tilbake til tunnelen kjem tilbake, feilar forsøket i tilkoplingsaugneblinken, og sida viser ein feil ho kan prøve igjen nokre sekund seinare.

To detaljar avgjer kva av desse du får. Den første er handhevinga klienten støttar: blokkering for heile eininga, blokkering avgrensa til tunneladapteren, eller eit regelsett med unntak. Den andre er om målet fell innanfor eit unntak du la til tidlegare for ein lokal skrivar, ein captive portal eller ein strøymeteneste.

Kryptering på applikasjonsnivå endrar ingenting av dette. HTTPS verner byta mellom nettlesar og server; det seier ingenting om kva grensesnitt som ber dei. Ei side kan vere perfekt kryptert og likevel gå ut feil veg, og det er nettopp det ei smal blokkering tillèt.

Ein kontrollert sjekk med ei eingongsside

Bruk ein vert du kontrollerer og ei side som ikkje gjer anna enn å kalle på han, slik at ingen verkelege data er i spel. Frå ein terminal, ta ei prøve av vegen før og etter brotet:

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

Køyr det med tunnelen oppe, ta deretter tunnelen ned og køyr det igjen. Eit svar frå ei offentleg adresse medan tunnelen er nede, fortel deg at den direkte vegen er open. Eit tidsavbrot eller ei avvist tilkopling fortel deg at politikken held. Gjenta ein gong til etter at klienten har kopia til på nytt, slik at du ser tunnelruta kome tilbake i staden for å gå ut frå det.

I nettlesaren skil Nettverk-panelet dei to spørsmåla. Filtrer til Fetch/XHR, og les deretter initiativtakar-kolonnen: ei oppføring starta av ein timer eller eit skript, utan navigasjon registrert før henne, er eit bakgrunnsforsøk og ikkje ei omlasting. Samanlikn starttida med augneblinken tunnelen fall. Viss oppføringa framleis ventar når tunnelen er borte, ventar førespurnaden på ein veg som ikkje finst lenger.

Bevis på serveren er sterkare enn alt nettlesaren viser. Ein førespurnadslogg med tidsstempel og kjeldeadresse provar at pakka kom fram. Nettlesaroppføringar kan bere informasjonskapslar, token og fulle URL-ar, så hald berre att dei felta spørsmålet ditt treng og sladd resten før du limer dei inn nokon stad.

Kva du bør gjere med svaret

Viss bakgrunnsforsøk held fram med å lukkast medan tunnelen er nede, er blokkeringa smalare enn du antok, og det gapet er verdt å tette før du overlèt kjenslevart arbeid til klienten. Viss dei feilar, gjer politikken jobben sin, og den frosne sida er kosmetisk. Uansett er det å lukke éi fane ikkje ein kontroll for heile eininga: andre faner, andre nettlesarar og andre applikasjonar planlegg kvar sine eigne oppgåver.

Neste steg som er verdt å ta: list opp kva unntak du har lagt til og kvifor, stadfest om klienten berre blokkerer tunnelomfatta trafikk eller all trafikk, og følg éin bakgrunnsførespurnad frå start til slutt med serverloggen open. Dei tre svara dekkjer det meste av det ein rapport om «VPN fall og noko er framleis tilkopla» eigentleg inneheld.