VPN foel midden op 'e side wei: gean eftergrûnsoanfragen noch út?

It ljepblêd lit noch it dashboard sjen fan foar't de tunnel dea gie. Statusnûmers befrieze, in lyts draaitsje bliuwt draaien, en de adresbalke draacht noch de app dy't jo in oere lyn iepenen. Jo hawwe nei de útfal neat oanrekke, en dochs kin de side noch besykje om har server te berikken neffens har eigen skema. Dat is it diel dat minsken misse: in side dy't allinnich sichtber is en in side dy't noch oanfragen stjoert, sjogge der fan bûten itselde út, en mar ien fan beide ferskynt yn in netwurkloch.

Wurk dat in side sûnder jo begjint

Fjouwer meganismen hâlde in laden dokumint dwaande. In werheljende timer kin alle pear sekonden in statusoprop opnij útfiere. In fetch kin ôfgean as it ljepblêd wer sichtber wurdt neidat jo der werom geane. In libbene kanaal boud op WebSocket of troch de server stjoerde barrens kin neffens syn eigen weromlûkingskema in ferbining opnij besykje. In service worker dy't troch de side registrearre is, kin wekker wurde foar in yn 'e wachtrige sette syngronisaasje, sels as der gjin ljepblêd foar jo is.

Net ien fan dy hat in klik nedich, en net ien fan harren werlaadt it dokumint. De adresbalke, de skrolposysje en de werjûne wearden bliuwe allegear wêr't se wiene. Wat feroaret is allinnich de netwurkkant: elke nije poging is in fars beslút dat nommen wurdt op it stuit dat it begjint.

Dat ûnderskie is fan belang om't de sichtbere side lokaal opslein is. Piksels dy't al skildere binne, sizze neat oer oft it folgjende oanfraach slagge is. In beferzen grafyk mei in draaitsje is de gewoane foarm fan in side waans oanfragen no mislearje. It skerm lêze fertelt jo wat de server minuten lyn sei, net wat de browser no docht.

Wêrom't de eardere side-lading gjin rûte hâldt

Neat yn 'e side-lading bynt it dokumint oan 'e tunnel. Routing wurdt per pakket oplost, op it stuit fan ferstjoeren, út 'e tabel dy't bestiet as it pakket fuortgiet. As de tunnelinterface ferdwynt, past dy syktocht net mear by de tunnelrûte. It falt óf troch nei de fysike adapter óf fynt hielendal neat, ôfhinklik fan wat de klient efterlitten hat.

Werheljende callbacks binne gewoane plande taken. De timer-seksje fan 'e HTML-standert beskriuwt hoe't se yn 'e wachtrige set wurde en behannelet it ynterval as in minimale fertraging yn stee fan in belofte fan krekte kadâns, dat in eftergrûnljepblêd kin folle minder faak pollje as syn koade freget. Minder pogingen is net itselde as gjin pogingen, en in ljepblêd wer nei foaren bringe is in gewoan momint foar in útbarsting fan harren.

Wêr't it falbelied lânet

De blokkade fan 'e klient wurdt beoardiele as in ferbining besocht wurdt, net doe't de side ophelle waard. As gewoane tagong noch tastien is, kin de werpoging oer de fysike keppeling iepen út gean. As it belied dat ferkear tsjinhâldt oant de tunnel weromkomt, mislearret de poging op it ferbiningsmomint en lit de side in flater sjen dy't it pear sekonden letter wer besykje kin.

Twa details beslisse hokker fan dy't jo krije. It earste is it hanthaveningsoanbod dat de klient stipet: in blokkade foar it hiele apparaat, in blokkade beheind ta de tunneladapter, of in regelset mei útsûnderingen. It twadde is oft it bestimming yn in útsûndering falt dy't jo earder tafoege hawwe foar in lokale printer, in captive portal of in streamingstsjinst.

Fersifering op applikaasjenivo feroaret hjir neat oan. HTTPS beskermet de bytes tusken browser en server; it seit neat oer hokker interface se draacht. In side kin perfekt fersifere wêze en dochs fia de ferkearde paad fuortgean, en dat is krekt wat in smelle blokkade tastean lit.

In kontrolearre kontrôle mei in weismyt-side

Brûk in host dy't jo kontrolearje en in side dy't neat oars docht as dy oanroppe, sadat gjin echte gegevens yn it spul binne. Nim fan in terminal it paad foar en nei de útfal:

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

Fier it út mei de tunnel omheech, bring dan de tunnel del en fier it wer út. In antwurd fan in iepenbier adres wylst de tunnel del is, fertelt jo dat it direkte paad iepen is. In tiidferrin of in wegere ferbining fertelt jo dat it belied hâldt. Werhelje it noch ien kear neidat de klient wer ferbûn is, sadat jo it tunnelpaad weromkomme sjogge ynstee fan it oan te nimmen.

Yn 'e browser skiedt it Netwurk-paniel de twa fragen. Filterje op Fetch/XHR, lês dan de kolom fan 'e inisjator: in ynfier start troch in timer of in skript, sûnder navigaasje dy't derfoar registrearre is, is in eftergrûnpoging yn stee fan in werlading. Fergelykje syn starttiid mei it momint dat de tunnel foel. As de ynfier noch yn behanneling is as de tunnel fuort is, wachtet it oanfraach op in paad dat net mear bestiet.

Bewiis oan 'e serverkant is sterker as alles wat de browser lit sjen. In oanfraachloch mei in tiidstempel en in boarneadres bewiist dat it pakket oankaam. Browser-ynfierren kinne cookies, tokens en folsleine URL's drage, dus hâld allinnich de fjilden oer dy't jo fraach nedich hat en ferbergje de rest foardat jo se earne plakke.

Wat te dwaan mei it antwurd

As eftergrûnpogingen trochgean te slagjen wylst de tunnel del is, is de blokkade smeller as jo oannommen hiene, en dat gat is de muoite wurdich te sluten foardat jo de klient foar gefoelich wurk fertrouwe. As se mislearje, docht it belied syn wurk en is de beferzen side kosmetysk. Hoe dan ek, it sluten fan ien ljepblêd is gjin apparaatbrede kontrôle: oare ljepblêden, oare browsers en oare applikaasjes plenje elk har eigen wurk.

Folgjende stappen dy't de muoite wurdich binne: lis op hokker útsûnderingen jo tafoege hawwe en wêrom, befêstigje oft de klient allinnich tunnel-begrepen ferkear of al it ferkear blokkearret, en folgje ien eftergrûnoanfraach fan begjin oant ein mei it serverloch iepen. Dy trije antwurden dekke it measte fan wat in rapport fan „de VPN foel en der is noch wat ferbûn" eins befettet.