VPN faldt midt på siden: går baggrundsanmodninger stadig ud?

Fanen viser stadig kontrolpanelet fra før tunnelen døde. Statusnumre fryser, en lille spinner drejer videre, og adresselinjen bærer stadig den app, du åbnede for en time siden. Du rørte ikke noget efter afbrydelsen, og alligevel kan siden stadig forsøge at nå sin server efter sin egen tidsplan. Det er den del, folk overser: en side, der blot er synlig, og en side, der stadig sender anmodninger, ser ens ud udefra, og kun én af dem optræder i en netværkslog.

Arbejde en side starter uden dig

Fire mekanismer holder et indlæst dokument beskæftiget. En gentaget timer kan køre et statuskald igen hver få sekunder. Et fetch kan udløses, når fanen bliver synlig igen, efter du skifter tilbage til den. En live-kanal bygget på WebSocket eller server-sendte hændelser kan forsøge en genoprettelse efter sin egen backoff-plan. En service worker, som webstedet har registreret, kan vågne for en synkronisering i kø, selv når ingen fane er foran dig.

Ingen af dem kræver et klik, og ingen af dem genindlæser dokumentet. Adresselinjen, rullepositionen og de viste værdier bliver alle, hvor de var. Det eneste, der ændrer sig, er netværkssiden: hvert nyt forsøg er en frisk beslutning, truffet i det øjeblik det begynder.

Den forskel betyder noget, fordi den synlige side er gemt lokalt. Pixel, der allerede er malet, siger intet om, hvorvidt den næste anmodning lykkedes. Et frosset diagram med en spinner er det sædvanlige udseende af en side, hvis anmodninger nu fejler. At læse skærmen fortæller dig, hvad serveren sagde for minutter siden, ikke hvad browseren laver nu.

Hvorfor den tidligere sideindlæsning ikke holder en rute

Intet i sideindlæsningen binder dokumentet til tunnelen. Routing afgøres pr. pakke, på afsendelsestidspunktet, ud fra den tabel, der findes, når pakken forlader. Når tunnelgrænsefladen forsvinder, matcher det opslag ikke længere tunnelruten. Det falder enten igennem til den fysiske adapter eller finder intet, afhængigt af hvad klienten efterlod.

Gentagne callbacks er almindelige planlagte opgaver. Timerafsnittet i HTML-standarden beskriver, hvordan de sættes i kø, og behandler intervallet som en minimumsforsinkelse snarere end et løfte om præcis kadence, så en baggrundsfane kan polle langt sjældnere, end dens kode beder om. Færre forsøg er ikke det samme som ingen forsøg, og at bringe en fane tilbage til forgrunden er et almindeligt øjeblik for en byge af dem.

Hvor fejlpolitikken lander

Klientens blokering vurderes, når en forbindelse forsøges, ikke da siden blev hentet. Hvis almindelig adgang stadig er tilladt, kan gentagelsen gå ud over det fysiske link i klartekst. Hvis politikken holder trafikken tilbage, indtil tunnelen vender tilbage, fejler forsøget på forbindelsestidspunktet, og siden viser en fejl, den kan gentage få sekunder senere.

To detaljer afgør, hvilken af dem du får. Den første er det håndhævelsesomfang, klienten understøtter: en blokering for hele enheden, en blokering begrænset til tunneladapteren eller et regelsæt med undtagelser. Den anden er, om destinationen falder inden for en undtagelse, du tidligere har tilføjet for en lokal printer, en captive portal eller en streamingtjeneste.

Kryptering på applikationsniveau ændrer intet af dette. HTTPS beskytter byte mellem browser og server; det siger intet om, hvilken grænseflade der bærer dem. En side kan være perfekt krypteret og stadig gå ud ad den forkerte vej, og det er præcis, hvad en smal blokering tillader.

En kontrolleret test med en engangsside

Brug en vært, du kontrollerer, og en side, der ikke gør andet end at kalde den, så ingen rigtige data er i spil. Fra en terminal tager du en prøve på vejen før og efter afbrydelsen:

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

Kør det med tunnelen oppe, bring derefter tunnelen ned, og kør det igen. Et svar fra en offentlig adresse, mens tunnelen er nede, fortæller dig, at den direkte vej er åben. En timeout eller en afvist forbindelse fortæller dig, at politikken holder. Gentag endnu en gang, efter klienten har genoprettet forbindelsen, så du kan se tunnelruten komme tilbage i stedet for at antage, at den gjorde.

I browseren adskiller Netværkspanelet de to spørgsmål. Filtrer til Fetch/XHR, og læs derefter initiativkolonnen: en post startet af en timer eller et script, uden navigation registreret før den, er et baggrundsforsøg snarere end en genindlæsning. Sammenlign dens starttid med det øjeblik, tunnelen faldt. Hvis posten stadig er afventende, når tunnelen er væk, venter anmodningen på en vej, der ikke længere findes.

Bevis på serversiden er stærkere end alt, hvad browseren viser. En anmodningslog med et tidsstempel og en kildeadresse beviser, at pakken ankom. Browserposter kan bære cookies, tokens og fulde URL'er, så behold kun de felter, dit spørgsmål har brug for, og rediger resten, før du indsætter dem nogen steder.

Hvad du skal gøre med svaret

Hvis baggrundsforsøg fortsat lykkes, mens tunnelen er nede, er blokeringen smallere, end du antog, og det hul er værd at lukke, før du betror klienten følsomt arbejde. Hvis de fejler, gør politikken sit arbejde, og den frosne side er kosmetisk. Uanset hvad er lukning af én fane ikke en enhedsdækkende kontrol: andre faner, andre browsere og andre applikationer planlægger hver deres eget arbejde.

Næste skridt, der er værd at tage: list hvilke undtagelser du har tilføjet og hvorfor, bekræft, om klienten kun blokerer tunnelomfattet trafik eller al trafik, og følg én baggrundsanmodning fra start til slut med serverloggen åben. De tre svar dækker det meste af, hvad en rapport om »VPN'en faldt, og noget er stadig forbundet« egentlig indeholder.