VPN midden op de pagina weggevallen: gaan achtergrondverzoeken nog steeds de deur uit?

Het tabblad toont nog het dashboard van voordat de tunnel stierf. Statuscijfers bevriezen, een klein rondje blijft draaien, en de adresbalk draagt nog de app die u een uur geleden opende. U hebt na de onderbreking niets aangeraakt, en toch probeert de pagina misschien nog steeds volgens haar eigen schema haar server te bereiken. Dat is het deel dat mensen missen: een pagina die alleen zichtbaar is en een pagina die nog verzoeken verstuurt, zien er van buiten hetzelfde uit, en slechts één van beide verschijnt in een netwerklogboek.

Werk dat een pagina zonder u begint

Vier mechanismen houden een geladen document bezig. Een herhalende timer kan elke paar seconden een statusaanroep opnieuw uitvoeren. Een fetch kan afgaan wanneer het tabblad weer zichtbaar wordt nadat u er terug naar toe schakelt. Een live kanaal op basis van WebSocket of door de server verzonden gebeurtenissen kan volgens zijn eigen backoff-schema opnieuw proberen te verbinden. Een door de site geregistreerde service worker kan wakker worden voor een synchronisatie in de wachtrij, zelfs wanneer er geen tabblad voor u staat.

Geen van die heeft een klik nodig, en geen ervan herlaadt het document. De adresbalk, de scrollpositie en de weergegeven waarden blijven allemaal waar ze waren. Wat verandert, is alleen de netwerkkant: elke nieuwe poging is een verse beslissing die op het moment dat ze begint wordt genomen.

Dat onderscheid is belangrijk omdat de zichtbare pagina lokaal is opgeslagen. Al geschilderde pixels zeggen niets over de vraag of het volgende verzoek is geslaagd. Een bevroren grafiek met een rondje is het gewone uiterlijk van een pagina waarvan de verzoeken nu mislukken. Het scherm lezen vertelt u wat de server minuten geleden zei, niet wat de browser nu doet.

Waarom het eerdere laden van de pagina geen route vasthoudt

Niets in het laden van de pagina bindt het document aan de tunnel. Routering wordt per pakket bepaald, op het moment van verzenden, uit de tabel die bestaat wanneer het pakket vertrekt. Wanneer de tunnelinterface verdwijnt, komt die opzoeking niet meer overeen met de tunnelroute. Ze valt ofwel door naar de fysieke adapter of vindt helemaal niets, afhankelijk van wat de client achterliet.

Herhalende callbacks zijn gewone geplande taken. De timersectie van de HTML-standaard beschrijft hoe ze in de wachtrij worden gezet en behandelt het interval als een minimale vertraging in plaats van een belofte van exacte cadans, zodat een achtergrondtabblad veel minder vaak kan pollen dan zijn code vraagt. Minder pogingen is niet hetzelfde als geen pogingen, en een tabblad weer naar de voorgrond brengen is een veelvoorkomend moment voor een uitbarsting ervan.

Waar het foutbeleid landt

De blokkering van de client wordt beoordeeld wanneer een verbinding wordt geprobeerd, niet wanneer de pagina werd opgehaald. Als gewone toegang nog is toegestaan, kan de nieuwe poging via de fysieke verbinding onbeveiligd naar buiten gaan. Als het beleid dat verkeer tegenhoudt tot de tunnel terugkomt, mislukt de poging op het moment van verbinden en toont de pagina een fout die ze enkele seconden later opnieuw kan proberen.

Twee details bepalen welke van die twee u krijgt. Het eerste is de handhavingsomvang die de client ondersteunt: een blokkering voor het hele apparaat, een blokkering beperkt tot de tunneladapter, of een regelset met uitsluitingen. Het tweede is of de bestemming binnen een uitsluiting valt die u eerder toevoegde voor een lokale printer, een captive portal of een streamingdienst.

Versleuteling op toepassingsniveau verandert hier niets aan. HTTPS beschermt de bytes tussen browser en server; het zegt niets over welke interface ze vervoert. Een pagina kan perfect versleuteld zijn en toch via de verkeerde weg naar buiten gaan, en dat is precies wat een smalle blokkering toestaat.

Een gecontroleerde controle met een wegwerppagina

Gebruik een host die u beheert en een pagina die niets anders doet dan die aanroepen, zodat er geen echte gegevens in het spel zijn. Neem vanaf een terminal een monster van het pad voor en na de onderbreking:

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

Voer het uit met de tunnel omhoog, breng dan de tunnel omlaag en voer het opnieuw uit. Een antwoord vanaf een openbaar adres terwijl de tunnel omlaag is, zegt u dat het directe pad open is. Een time-out of een geweigerde verbinding zegt u dat het beleid vasthoudt. Herhaal het nog eens nadat de client opnieuw heeft verbonden, zodat u het tunnelpad ziet terugkomen in plaats van het aan te nemen.

In de browser scheidt het Netwerk-paneel de twee vragen. Filter op Fetch/XHR en lees dan de kolom initiator: een item dat door een timer of een script is gestart, zonder navigatie die ervoor is geregistreerd, is een achtergrondpoging en geen herlaadbeurt. Vergelijk de starttijd met het moment waarop de tunnel wegviel. Als het item nog in behandeling is terwijl de tunnel weg is, wacht het verzoek op een pad dat niet meer bestaat.

Bewijs aan de serverkant is sterker dan alles wat de browser toont. Een verzoeklogboek met een tijdstempel en een bronadres bewijst dat het pakket aankwam. Browseritems kunnen cookies, tokens en volledige URL's bevatten, dus bewaar alleen de velden die uw vraag nodig heeft en redigeer de rest voordat u ze ergens plakt.

Wat u met het antwoord moet doen

Als achtergrondpogingen blijven slagen terwijl de tunnel omlaag is, is de blokkering smaller dan u aannam, en dat gat is het waard om te dichten voordat u de client gevoelig werk toevertrouwt. Als ze mislukken, doet het beleid zijn werk en is de bevroren pagina cosmetisch. Hoe dan ook, het sluiten van één tabblad is geen apparaatbrede controle: andere tabbladen, andere browsers en andere toepassingen plannen elk hun eigen werk.

Volgende stappen die de moeite waard zijn: lijst op welke uitsluitingen u hebt toegevoegd en waarom, bevestig of de client alleen tunnelgebonden verkeer of al het verkeer blokkeert, en volg één achtergrondverzoek van begin tot eind met het serverlogboek open. Die drie antwoorden dekken het grootste deel van wat een rapport „de VPN viel weg en er is nog iets verbonden" werkelijk bevat.