El VPN ha caigut a mig camí: encara surten les peticions de fons?
Una pàgina deixada oberta continua fent consultes, reconnectant-se i sincronitzant-se després que el túnel mori. Mireu quins intents encara surten i com demostrar-ho.
La pestanya encara mostra el tauler de control d’abans que morís el túnel. Els números d’estat es congelen, un petit indicador continua girant i la barra d’adreces encara porta l’aplicació que vau obrir fa una hora. No heu tocat res després de la caiguda, i tot i així la pàgina pot estar intentant arribar al seu servidor segons el seu propi calendari. Aquesta és la part que la gent passa per alt: una pàgina que només és visible i una pàgina que encara envia peticions es veuen iguals des de fora, i només una d’elles apareix en un registre de xarxa.
Feina que una pàgina comença sense tu
Quatre mecanismes mantenen ocupat un document carregat. Un temporitzador repetitiu pot tornar a executar una crida d’estat cada pocs segons. Un fetch es pot disparar quan la pestanya torna a ser visible després que hi torneu. Un canal en directe construït sobre WebSocket o esdeveniments enviats pel servidor pot intentar una reconnexió segons el seu propi calendari de retrocés. Un service worker registrat pel lloc pot despertar-se per a una sincronització en cua fins i tot quan no hi ha cap pestanya davant teu.
Cap d’aquests necessita un clic, i cap d’ells recarrega el document. La barra d’adreces, la posició de desplaçament i els valors representats es queden on eren. El que canvia és només el costat de xarxa: cada nou intent és una decisió nova presa en el moment que comença.
Aquesta distinció importa perquè la pàgina visible s’emmagatzema localment. Els píxels ja pintats no diuen res sobre si la petició següent ha tingut èxit. Un gràfic congelat amb un indicador és l’aspecte habitual d’una pàgina les peticions de la qual ara fallen. Llegir la pantalla et diu què va dir el servidor fa minuts, no què fa el navegador ara.
Per què la càrrega anterior de la pàgina no manté cap ruta
Res de la càrrega de la pàgina no lliga el document al túnel. L’encaminament es resol per paquet, en el moment d’enviar, a partir de la taula que existeix quan el paquet surt. Quan la interfície del túnel desapareix, aquesta cerca ja no coincideix amb la ruta del túnel. O bé cau a l’adaptador físic o no troba res, segons què hagi deixat enrere el client.
Les crides de retorn repetides són tasques programades ordinàries. La secció de temporitzadors de l’estàndard HTML descriu com es posen en cua i tracta l’interval com un retard mínim més que com una promesa de cadència exacta, de manera que una pestanya en segon pla pot consultar molt menys sovint del que demana el seu codi. Menys intents no és el mateix que cap intent, i portar una pestanya al davant és un moment habitual per a una allau d’ells.
On recau la política de fallada
El bloc del client s’avalua quan s’intenta una connexió, no quan es va obtenir la pàgina. Si l’accés ordinari encara està permès, el reintent pot sortir per l’enllaç físic en clar. Si la política reté aquest trànsit fins que el túnel torni, l’intent falla en el moment de connectar i la pàgina mostra un error que pot reintentar uns segons després.
Dos detalls decideixen quin d’aquests obtindràs. El primer és l’abast d’aplicació que admet el client: un bloc per a tot el dispositiu, un bloc limitat a l’adaptador del túnel o un conjunt de regles amb exclusions. El segon és si la destinació cau dins d’una exclusió que vau afegir abans per a una impressora local, un portal captiu o un servei de streaming.
El xifratge a nivell d’aplicació no canvia res d’això. HTTPS protegeix els bytes entre el navegador i el servidor; no diu res sobre quina interfície els transporta. Una pàgina pot estar perfectament xifrada i encara sortir pel camí equivocat, i això és exactament el que permet un bloc estret.
Una comprovació controlada amb una pàgina d’un sol ús
Feu servir un amfitrió que controleu i una pàgina que no faci res més que cridar-lo, perquè no hi hagi cap dada real en joc. Des d’un terminal, mostreu el camí abans i després de la caiguda:
curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/pingExecuteu-ho amb el túnel aixecat, després abaixeu el túnel i executeu-ho de nou. Una resposta des d’una adreça pública mentre el túnel està abaixat us diu que el camí directe és obert. Un temps d’espera esgotat o una connexió rebutjada us diu que la política aguanta. Repetiu-ho un cop més després que el client es reconecti, perquè pugueu veure tornar el camí del túnel en lloc de suposar-ho.
Al navegador, el tauler Xarxa separa les dues preguntes. Filtreu a Fetch/XHR i després llegiu la columna d’iniciador: una entrada iniciada per un temporitzador o un script, sense cap navegació registrada abans, és un intent de fons i no una recàrrega. Compareu la seva hora d’inici amb el moment en què va caure el túnel. Si l’entrada encara està pendent quan el túnel ja no hi és, la petició espera un camí que ja no existeix.
L’evidència del costat del servidor és més forta que qualsevol cosa que mostri el navegador. Un registre de peticions amb una marca de temps i una adreça d’origen demostra que el paquet va arribar. Les entrades del navegador poden portar galetes, testimonis i URL completes, així que conserveu només els camps que la vostra pregunta necessita i redacteu la resta abans d’enganxar-los enlloc.
Què fer amb la resposta
Si els intents de fons continuen tenint èxit mentre el túnel està abaixat, el bloc és més estret del que suposàveu, i val la pena tancar aquesta escletxa abans de confiar el client per a feina sensible. Si fallen, la política fa la seva feina i la pàgina congelada és cosmètica. En qualsevol cas, tancar una pestanya no és un control per a tot el dispositiu: altres pestanyes, altres navegadors i altres aplicacions programen cadascun la seva pròpia feina.
Passos següents que val la pena fer: llisteu quines exclusions heu afegit i per què, confirmeu si el client bloqueja només el trànsit d’abast del túnel o tot el trànsit, i observeu una petició de fons de principi a fi amb el registre del servidor obert. Aquestes tres respostes cobreixen la major part del que conté realment un informe de «el VPN ha caigut i alguna cosa encara està connectada».