VPN val midde op die bladsy weg: gaan agtergrondversoeke steeds uit?

Die oortjie wys steeds die paneelbord van voor die tonnel dood is. Statusgetalle vries, ’n klein draaikringetjie bly draai, en die adresbalk dra steeds die toepassing wat jy ’n uur gelede oopgemaak het. Jy het niks ná die onderbreking aangeraak nie, tog probeer die bladsy dalk steeds op sy eie skedule sy bediener bereik. Dit is die deel wat mense miskyk: ’n bladsy wat bloot sigbaar is en ’n bladsy wat steeds versoeke stuur, lyk van buite identies, en net een van hulle verskyn in ’n netwerklog.

Werk wat ’n bladsy sonder jou begin

Vier meganismes hou ’n gelaaide dokument besig. ’n Herhalende tydhouer kan elke paar sekondes ’n statusoproep weer laat loop. ’n Fetch kan afvuur wanneer die oortjie weer sigbaar word nadat jy teruggeskakel het. ’n Lewendige kanaal wat op WebSocket of bedienergestuurde gebeurtenisse gebou is, kan volgens sy eie terugskakelingskedule ’n herverbinding probeer. ’n Dienswerker wat deur die werf geregistreer is, kan wakker word vir ’n tougestelde sinchronisasie, selfs wanneer geen oortjie voor jou is nie.

Nie een van dié het ’n klik nodig nie, en nie een van hulle herlaai die dokument nie. Die adresbalk, die rolposisie en die weergegewe waardes bly almal waar hulle was. Wat verander, is net die netwerkkant: elke nuwe poging is ’n vars besluit wat geneem word op die oomblik dat dit begin.

Daardie onderskeid maak saak, want die sigbare bladsy word plaaslik gestoor. Prente wat reeds geskilder is, sê niks oor of die volgende versoek geslaag het nie. ’n Bevrore grafiek met ’n draaikringetjie is die gewone voorkoms van ’n bladsy wie se versoeke nou misluk. Om die skerm te lees, vertel jou wat die bediener minute gelede gesê het, nie wat die blaaier nou doen nie.

Waarom die vroeëre bladsylading nie ’n roete hou nie

Niks in die bladsylading bind die dokument aan die tonnel nie. Roetering word per pakkie opgelos, op die oomblik van stuur, uit die tabel wat bestaan wanneer die pakkie vertrek. Wanneer die tonnelkoppelvlak verdwyn, pas daardie soektog nie meer by die tonnelroete nie. Dit val óf deur na die fisiese adapter óf vind glad niks, afhangend van wat die kliënt agtergelaat het.

Herhalende terugroepe is gewone geskeduleerde take. Die tydhouer-afdeling van die HTML-standaard beskryf hoe hulle in die tou geplaas word en behandel die interval as ’n minimum vertraging eerder as ’n belofte van presiese kadens, so ’n agtergrondoortjie kan baie minder dikwels peil as wat sy kode vra. Minder pogings is nie dieselfde as geen pogings nie, en om ’n oortjie terug na die voorgrond te bring is ’n algemene oomblik vir ’n uitbarsting daarvan.

Waar die foutbeleid beland

Die kliënt se blok word geëvalueer wanneer ’n verbinding probeer word, nie wanneer die bladsy gelaai is nie. As gewone toegang steeds toegelaat word, kan die herpoging oor die fisiese skakel in die oopte uitgaan. As die beleid daardie verkeer vashou totdat die tonnel terugkeer, misluk die poging by verbindingstyd en wys die bladsy ’n fout wat dit ’n paar sekondes later weer kan probeer.

Twee besonderhede bepaal watter een van dié jy kry. Die eerste is die handhawingsomvang wat die kliënt ondersteun: ’n blok vir die hele toestel, ’n blok beperk tot die tonneladapter, of ’n reëlstel met uitsonderings. Die tweede is of die bestemming binne ’n uitsondering val wat jy vroeër bygevoeg het vir ’n plaaslike drukker, ’n captive portal of ’n stromingsdiens.

Toepassingsvlak-versleuteling verander niks hiervan nie. HTTPS beskerm die grepe tussen blaaier en bediener; dit sê niks oor watter koppelvlak hulle dra nie. ’n Bladsy kan perfek versleutel wees en steeds deur die verkeerde pad uitgaan, en dit is presies wat ’n smal blok toelaat.

’n Beheerde kontrole met ’n weggooibladsy

Gebruik ’n gasheer wat jy beheer en ’n bladsy wat niks anders doen as om dit te roep nie, sodat geen werklike data in die spel is nie. Vanaf ’n terminaal, neem ’n monster van die pad voor en ná die onderbreking:

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

Begin dit met die tonnel op, bring dan die tonnel af en begin dit weer. ’n Antwoord vanaf ’n publieke adres terwyl die tonnel af is, sê vir jou die direkte pad is oop. ’n Tydverstrekking of ’n geweierde verbinding sê vir jou die beleid hou vas. Herhaal nog een keer nadat die kliënt weer verbind het, sodat jy kan sien die tonnelpad kom terug eerder as om te aanvaar dit het.

In die blaaier skei die Netwerk-paneel die twee vrae. Filtreer na Fetch/XHR, lees dan die inisieerder-kolom: ’n inskrywing wat deur ’n tydhouer of ’n skrip begin is, met geen navigasie wat daarvoor aangeteken is nie, is ’n agtergrondpoging eerder as ’n herlaai. Vergelyk sy begintyd met die oomblik toe die tonnel geval het. As die inskrywing nog hang wanneer die tonnel weg is, wag die versoek op ’n pad wat nie meer bestaan nie.

Bedienerkant-bewyse is sterker as enigiets wat die blaaier wys. ’n Versoeklog met ’n tydstempel en ’n bronadres bewys die pakkie het aangekom. Blaaierinskrywings kan koekies, tekens en volle URL's dra, so hou net die velde wat jou vraag nodig het en redigeer die res voordat jy dit enige plek plak.

Wat om met die antwoord te doen

As agtergrondpogings aanhou slaag terwyl die tonnel af is, is die blok smaller as wat jy aangeneem het, en daardie gaping is die moeite werd om te sluit voordat jy die kliënt vir sensitiewe werk vertrou. As hulle misluk, doen die beleid sy werk en is die bevrore bladsy kosmeties. In elk geval, om een oortjie toe te maak is nie ’n toestelwye beheer nie: ander oortjies, ander blaaiers en ander toepassings skeduleer elkeen hul eie werk.

Volgende stappe wat die moeite werd is: lys watter uitsonderings jy bygevoeg het en waarom, bevestig of die kliënt net tonnel-gerigte verkeer of alle verkeer blokkeer, en kyk een agtergrondversoek van begin tot end met die bedienerlog oop. Daardie drie antwoorde dek die meeste van wat ’n verslag van „die VPN het geval en iets het steeds gekonnekteer” werklik bevat.