VPN falt midt på siden: går bakgrunnsforespørsler fortsatt ut?

Fanene viser fortsatt dashbordet fra før tunnelen døde. Statusnumre fryser, en liten spinner fortsetter å snurre, og adressefeltet bærer fortsatt appen du åpnet for en time siden. Du rørte ingenting etter bruddet, men siden kan fortsatt prøve å nå serveren sin etter sin egen tidsplan. Det er dette folk overser: en side som bare er synlig, og en side som fortsatt sender forespørsler, ser like ut utenfra, og bare én av dem dukker opp i en nettverkslogg.

Arbeid en side starter uten deg

Fire mekanismer holder et lastet dokument opptatt. En gjentakende timer kan kjøre et statuskall på nytt hvert par sekunder. En fetch kan utløses når fanen blir synlig igjen etter at du bytter tilbake til den. En levende kanal bygget på WebSocket eller server-sendte hendelser kan forsøke en ny tilkobling etter sin egen backoff-plan. En service worker som nettstedet har registrert, kan våkne for en synkronisering i kø selv når ingen fane står foran deg.

Ingen av dem trenger et klikk, og ingen av dem laster dokumentet på nytt. Adressefeltet, rulleposisjonen og de viste verdiene blir alle stående der de var. Det er bare nettverkssiden som endres: hvert nytt forsøk er en fersk beslutning tatt i det øyeblikket det starter.

Den forskjellen betyr noe fordi den synlige siden er lagret lokalt. Piksler som allerede er tegnet, sier ingenting om hvorvidt neste forespørsel lyktes. Et frosset diagram med en spinner er det vanlige utseendet til en side der forespørslene nå feiler. Å lese skjermen forteller deg hva serveren sa for noen minutter siden, ikke hva nettleseren gjør nå.

Hvorfor den tidligere sideinnlastingen ikke holder en rute

Ingenting i sideinnlastingen binder dokumentet til tunnelen. Ruting avgjøres per pakke, ved sendetidspunktet, fra tabellen som finnes når pakken forlater maskinen. Når tunnelgrensesnittet forsvinner, samsvarer ikke det oppslaget lenger med tunnelruten. Det faller enten gjennom til den fysiske adapteren eller finner ingenting, avhengig av hva klienten etterlot.

Gjentakende tilbakeringinger er vanlige planlagte oppgaver. Timer-avsnittet i HTML-standarden beskriver hvordan de legges i kø og behandler intervallet som en minimumsforsinkelse i stedet for et løfte om nøyaktig kadens, slik at en bakgrunnsfane kan polle langt sjeldnere enn koden ber om. Færre forsøk er ikke det samme som ingen forsøk, og å bringe en fane tilbake i forgrunnen er et vanlig øyeblikk for en byge av dem.

Hvor feilpolitikken lander

Klientens blokkering vurderes når en tilkobling forsøkes, ikke da siden ble hentet. Hvis vanlig tilgang fortsatt er tillatt, kan nytt forsøk gå ut over den fysiske lenken i klartekst. Hvis politikken holder trafikken tilbake til tunnelen kommer tilbake, feiler forsøket i tilkoblingsøyeblikket, og siden viser en feil den kan prøve igjen noen sekunder senere.

To detaljer avgjør hvilken av disse du får. Den første er håndhevelsesomfanget klienten støtter: en blokkering for hele enheten, en blokkering begrenset til tunneladapteren, eller et regelsett med unntak. Den andre er om målet faller innenfor et unntak du la til tidligere for en lokal skriver, en captive portal eller en strømmetjeneste.

Kryptering på applikasjonsnivå endrer ingenting av dette. HTTPS beskytter bytene mellom nettleser og server; det sier ingenting om hvilket grensesnitt som bærer dem. En side kan være perfekt kryptert og likevel gå ut feil vei, og det er nettopp det en smal blokkering tillater.

En kontrollert sjekk med en engangsside

Bruk en vert du kontrollerer og en side som ikke gjør annet enn å kalle den, slik at ingen virkelige data er i spill. Fra en terminal, ta en prøve av veien før og etter bruddet:

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

Kjør det med tunnelen oppe, ta deretter tunnelen ned og kjør det igjen. Et svar fra en offentlig adresse mens tunnelen er nede, forteller deg at den direkte veien er åpen. En tidsavbrudd eller en avvist tilkobling forteller deg at politikken holder. Gjenta én gang til etter at klienten har koblet til på nytt, slik at du ser tunnelruten komme tilbake i stedet for å anta at den gjorde det.

I nettleseren skiller Nettverk-panelet de to spørsmålene. Filtrer til Fetch/XHR, og les deretter initiativtaker-kolonnen: en oppføring startet av en timer eller et skript, uten navigasjon registrert før den, er et bakgrunnsforsøk og ikke en omlasting. Sammenlign starttiden med øyeblikket tunnelen falt. Hvis oppføringen fortsatt er ventende når tunnelen er borte, venter forespørselen på en vei som ikke lenger finnes.

Bevis på serveren er sterkere enn alt nettleseren viser. En forespørselslogg med tidsstempel og kildeadresse beviser at pakken kom fram. Netleseroppføringer kan bære informasjonskapsler, tokens og fulle URL-er, så behold bare feltene spørsmålet ditt trenger og sladd resten før du limer dem inn noe sted.

Hva du bør gjøre med svaret

Hvis bakgrunnsforsøk fortsetter å lykkes mens tunnelen er nede, er blokkeringen smalere enn du antok, og det gapet er verdt å tette før du overlater sensitivt arbeid til klienten. Hvis de feiler, gjør politikken jobben sin, og den frosne siden er kosmetisk. Uansett er det å lukke én fane ikke en enhetsdekkende kontroll: andre faner, andre nettlesere og andre applikasjoner planlegger hver sine egne oppgaver.

Neste steg som er verdt å ta: list opp hvilke unntak du har lagt til og hvorfor, bekreft om klienten bare blokkerer tunnelomfattet trafikk eller all trafikk, og følg én bakgrunnsforespørsel fra start til slutt med serverloggen åpen. De tre svarene dekker det meste av det en rapport om «VPN falt og noe er fortsatt tilkoblet» egentlig inneholder.