VPN-ul a căzut la mijlocul paginii: cererile din fundal mai ies?

Fila arată încă tabloul de bord de dinainte de moartea tunelului. Numerele de stare îngheață, un mic indicator continuă să se rotească, iar bara de adrese poartă încă aplicația pe care ați deschis-o acum o oră. Nu ați atins nimic după cădere, și totuși pagina poate încerca în continuare să ajungă la serverul ei după propriul calendar. Asta este partea pe care oamenii o ratează: o pagină doar vizibilă și o pagină care încă trimite cereri arată la fel din exterior, și doar una dintre ele apare într-un jurnal de rețea.

Muncă pe care o pagină o începe fără tine

Patru mecanisme țin un document încărcat ocupat. Un cronometru repetitiv poate rula din nou un apel de stare la fiecare câteva secunde. Un fetch poate porni când fila devine din nou vizibilă după ce reveniți la ea. Un canal live construit pe WebSocket sau pe evenimente trimise de server poate încerca o reconectare după propriul calendar de retragere. Un service worker înregistrat de site poate să se trezească pentru o sincronizare în coadă chiar și când nu există nicio filă în fața voastră.

Niciunul dintre ele nu are nevoie de un clic și niciunul nu reîncarcă documentul. Bara de adrese, poziția de derulare și valorile afișate rămân toate acolo unde erau. Se schimbă doar partea de rețea: fiecare încercare nouă este o decizie proaspătă luată în momentul în care începe.

Această distincție contează pentru că pagina vizibilă este stocată local. Pixelii deja desenați nu spun nimic despre dacă următoarea cerere a reușit. Un grafic înghețat cu un indicator este aspectul obișnuit al unei pagini ale cărei cereri acum eșuează. Citirea ecranului vă spune ce a spus serverul acum câteva minute, nu ce face browserul acum.

De ce încărcarea anterioară a paginii nu ține o rută

Nimic din încărcarea paginii nu leagă documentul de tunel. Rutarea este rezolvată per pachet, în momentul trimiterii, din tabelul care există când pachetul pleacă. Când interfața tunelului dispare, acea căutare nu mai corespunde rutei tunelului. Fie cade pe adaptorul fizic, fie nu găsește nimic, în funcție de ce a lăsat în urmă clientul.

Apelurile inverse repetate sunt sarcini programate obișnuite. Secțiunea despre cronometre a standardului HTML descrie cum sunt puse în coadă și tratează intervalul ca o întârziere minimă, nu ca o promisiune a unei cadențe exacte, așa că o filă din fundal poate interoga mult mai rar decât cere codul ei. Mai puține încercări nu este același lucru cu nicio încercare, iar aducerea unei file în prim-plan este un moment obișnuit pentru o rafală a acestora.

Unde aterizează politica de eșec

Blocarea clientului este evaluată când se încearcă o conexiune, nu când pagina a fost adusă. Dacă accesul obișnuit este încă permis, reîncercarea poate ieși prin legătura fizică în clar. Dacă politica reține acel trafic până când tunelul revine, încercarea eșuează în momentul conectării și pagina afișează o eroare pe care o poate reîncerca câteva secunde mai târziu.

Două detalii decid care dintre acestea vă iese. Primul este domeniul de aplicare pe care clientul îl acceptă: o blocare pentru întregul dispozitiv, o blocare limitată la adaptorul tunelului sau un set de reguli cu excepții. Al doilea este dacă destinația se află într-o excepție adăugată anterior pentru o imprimantă locală, un portal captiv sau un serviciu de streaming.

Criptarea la nivel de aplicație nu schimbă nimic din toate acestea. HTTPS protejează octeții dintre browser și server; nu spune nimic despre ce interfață îi transportă. O pagină poate fi perfect criptată și totuși să iasă pe calea greșită, iar exact asta permite o blocare îngustă.

O verificare controlată cu o pagină de unică folosință

Folosiți un host pe care îl controlați și o pagină care nu face nimic altceva decât să îl apeleze, ca să nu fie date reale în joc. Dintr-un terminal, luați o mostră a căii înainte și după cădere:

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

Rulați-o cu tunelul ridicat, apoi coborâți tunelul și rulați-o din nou. Un răspuns de la o adresă publică în timp ce tunelul este coborât vă spune că calea directă este deschisă. Un timeout sau o conexiune refuzată vă spune că politica ține. Repetați încă o dată după ce clientul se reconectează, ca să vedeți calea tunelului revenind în loc să presupuneți că a revenit.

În browser, panoul Rețea separă cele două întrebări. Filtrați la Fetch/XHR, apoi citiți coloana inițiatorului: o intrare pornită de un cronometru sau un script, fără navigare înregistrată înaintea ei, este o încercare din fundal și nu o reîncărcare. Comparați ora de început cu momentul în care a căzut tunelul. Dacă intrarea este încă în așteptare când tunelul a dispărut, cererea așteaptă o cale care nu mai există.

Dovezile de pe partea serverului sunt mai puternice decât orice arată browserul. Un jurnal de cereri cu marcă de timp și adresă sursă dovedește că pachetul a ajuns. Intrările din browser pot purta cookie-uri, tokenuri și URL-uri complete, așa că păstrați doar câmpurile de care are nevoie întrebarea voastră și redactați restul înainte de a le lipi oriunde.

Ce să faceți cu răspunsul

Dacă încercările din fundal continuă să reușească în timp ce tunelul este coborât, blocarea este mai îngustă decât ați presupus, iar acel gol merită închis înainte de a încredința clientului o muncă sensibilă. Dacă eșuează, politica își face treaba, iar pagina înghețată este doar cosmetică. În orice caz, închiderea unei file nu este un control la nivel de dispozitiv: alte file, alte browsere și alte aplicații își programează fiecare propria muncă.

Pași următori care merită făcuți: enumerați ce excepții ați adăugat și de ce, confirmați dacă clientul blochează doar traficul din domeniul tunelului sau tot traficul, și urmăriți o cerere din fundal de la început până la sfârșit cu jurnalul serverului deschis. Acele trei răspunsuri acoperă cea mai mare parte din ce conține de fapt un raport de tipul „VPN-ul a căzut și ceva este încă conectat”.