VPN:et föll mitt på sidan: går bakgrundsförfrågningar fortfarande ut?

Fliken visar fortfarande instrumentpanelen från innan tunneln dog. Statusnummer fryser, en liten snurra fortsätter att snurra, och adressfältet bär fortfarande appen du öppnade för en timme sedan. Du rörde ingenting efter avbrottet, och ändå kan sidan fortfarande försöka nå sin server enligt sitt eget schema. Det är den delen folk missar: en sida som bara är synlig och en sida som fortfarande skickar förfrågningar ser likadana ut utifrån, och bara en av dem dyker upp i en nätverkslogg.

Arbete som en sida startar utan dig

Fyra mekanismer håller ett inläst dokument upptaget. En återkommande timer kan köra ett statusanrop igen varannan sekund. En fetch kan utlösas när fliken blir synlig igen efter att du byter tillbaka till den. En livekanal byggd på WebSocket eller serversända händelser kan försöka återansluta enligt sitt eget backoff-schema. En service worker som webbplatsen registrerat kan vakna för en synkronisering i kön även när ingen flik är framför dig.

Ingen av dem behöver ett klick, och ingen av dem läser in dokumentet igen. Adressfältet, rullningspositionen och de renderade värdena stannar alla där de var. Det är bara nätverkssidan som ändras: varje nytt försök är ett färskt beslut som fattas i det ögonblick det börjar.

Den skillnaden spelar roll eftersom den synliga sidan lagras lokalt. Redan målade pixlar säger ingenting om huruvida nästa förfrågan lyckades. Ett fryst diagram med en snurra är det vanliga utseendet på en sida vars förfrågningar nu misslyckas. Att läsa skärmen berättar vad servern sa för några minuter sedan, inte vad webbläsaren gör nu.

Varför den tidigare sidinläsningen inte håller en rutt

Ingenting i sidinläsningen binder dokumentet till tunneln. Routing löses per paket, vid sändningstillfället, från tabellen som finns när paketet lämnar maskinen. När tunnelgränssnittet försvinner matchar den uppslagningen inte längre tunnelrutten. Det faller antingen igenom till den fysiska adaptern eller hittar ingenting alls, beroende på vad klienten lämnade efter sig.

Återkommande callbacks är vanliga schemalagda uppgifter. Timeravsnittet i HTML-standarden beskriver hur de köas och behandlar intervallet som en minimifördröjning snarare än ett löfte om exakt kadens, så en bakgrundsflik kan polla mycket mer sällan än koden ber om. Färre försök är inte samma sak som inga försök, och att föra en flik tillbaka till förgrunden är ett vanligt ögonblick för en skur av dem.

Var felpolicyn landar

Klientens blockering utvärderas när en anslutning försöks, inte när sidan hämtades. Om vanlig åtkomst fortfarande tillåts kan återförsöket gå ut över den fysiska länken i klartext. Om policyn håller tillbaka trafiken tills tunneln kommer tillbaka misslyckas försöket vid anslutningsögonblicket och sidan visar ett fel som den kan försöka igen några sekunder senare.

Två detaljer avgör vilket av dessa du får. Den första är den tillämpningsomfattning klienten stöder: en blockering för hela enheten, en blockering begränsad till tunneladaptern, eller en regeluppsättning med undantag. Den andra är om målet faller inom ett undantag du lade till tidigare för en lokal skrivare, en captive portal eller en strömningstjänst.

Kryptering på applikationsnivå ändrar inget av detta. HTTPS skyddar byten mellan webbläsare och server; det säger ingenting om vilket gränssnitt som bär dem. En sida kan vara perfekt krypterad och ändå gå ut fel väg, och det är precis vad en snäv blockering tillåter.

En kontrollerad kontroll med en engångssida

Använd en värd du kontrollerar och en sida som inte gör annat än att anropa den, så att inga riktiga data är i spel. Från en terminal, ta ett prov på vägen före och efter avbrottet:

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

Kör det med tunneln uppe, ta sedan ner tunneln och kör det igen. Ett svar från en offentlig adress medan tunneln är nere säger dig att den direkta vägen är öppen. En timeout eller en avvisad anslutning säger dig att policyn håller. Upprepa en gång till efter att klienten återanslutit, så att du ser tunnelvägen komma tillbaka i stället för att anta att den gjorde det.

I webbläsaren skiljer Nätverkspanelen de två frågorna. Filtrera till Fetch/XHR och läs sedan initiativtagarkolumnen: en post som startats av en timer eller ett skript, utan navigering registrerad före den, är ett bakgrundsförsök och inte en omladdning. Jämför dess starttid med ögonblicket då tunneln föll. Om posten fortfarande väntar när tunneln är borta väntar förfrågan på en väg som inte längre finns.

Bevis på serversidan är starkare än allt webbläsaren visar. En förfrågningslogg med tidsstämpel och källadress bevisar att paketet kom fram. Webbläsarposter kan bära kakor, tokens och fullständiga URL:er, så behåll bara de fält din fråga behöver och maska resten innan du klistrar in dem någonstans.

Vad du bör göra med svaret

Om bakgrundsförsök fortsätter att lyckas medan tunneln är nere är blockeringen snävare än du antog, och den luckan är värd att täppa igen innan du anförtror klienten känsligt arbete. Om de misslyckas gör policyn sitt jobb och den frysta sidan är kosmetisk. Hur som helst är att stänga en flik ingen enhetsövergripande kontroll: andra flikar, andra webbläsare och andra program schemalägger var sitt arbete.

Nästa steg som är värda att ta: lista vilka undantag du har lagt till och varför, bekräfta om klienten bara blockerar tunnelomfattad trafik eller all trafik, och följ en bakgrundsförfrågan från början till slut med serverloggen öppen. De tre svaren täcker det mesta av vad en rapport om ”VPN:et föll och något är fortfarande anslutet” egentligen innehåller.