Il VPN è caduto a metà pagina: le richieste in background escono ancora?

La scheda mostra ancora la dashboard di prima che il tunnel morisse. I numeri di stato si bloccano, un piccolo indicatore continua a girare e la barra degli indirizzi porta ancora l’app aperta un’ora fa. Non avete toccato nulla dopo la caduta, eppure la pagina potrebbe ancora tentare di raggiungere il suo server secondo il proprio calendario. È la parte che le persone trascurano: una pagina semplicemente visibile e una pagina che invia ancora richieste appaiono identiche dall’esterno, e solo una delle due compare in un log di rete.

Il lavoro che una pagina avvia senza di voi

Quattro meccanismi tengono occupato un documento caricato. Un timer ripetuto può rieseguire una chiamata di stato ogni pochi secondi. Un fetch può scattare quando la scheda torna visibile dopo che vi siete riportati su di essa. Un canale live costruito su WebSocket o su eventi inviati dal server può tentare una riconnessione secondo il proprio calendario di backoff. Un service worker registrato dal sito può svegliarsi per una sincronizzazione in coda anche quando nessuna scheda è davanti a voi.

Nessuno di questi richiede un clic, e nessuno ricarica il documento. La barra degli indirizzi, la posizione di scorrimento e i valori visualizzati restano tutti dov’erano. Cambia solo il lato rete: ogni nuovo tentativo è una decisione fresca presa nel momento in cui inizia.

Questa distinzione conta perché la pagina visibile è memorizzata localmente. I pixel già dipinti non dicono nulla sul fatto che la richiesta successiva sia riuscita. Un grafico congelato con un indicatore è l’aspetto abituale di una pagina le cui richieste ora falliscono. Leggere lo schermo vi dice cosa ha detto il server qualche minuto fa, non cosa sta facendo il browser adesso.

Perché il caricamento precedente della pagina non tiene una rotta

Niente nel caricamento della pagina lega il documento al tunnel. L’instradamento viene risolto per pacchetto, al momento dell’invio, dalla tabella che esiste quando il pacchetto parte. Quando l’interfaccia del tunnel scompare, quella ricerca non corrisponde più alla rotta del tunnel. O ricade sull’adattatore fisico o non trova nulla, a seconda di ciò che il client ha lasciato dietro di sé.

Le callback ripetute sono normali attività pianificate. La sezione sui timer dello standard HTML descrive come vengono messe in coda e tratta l’intervallo come un ritardo minimo anziché come la promessa di una cadenza esatta, quindi una scheda in background può interrogare molto meno spesso di quanto chieda il suo codice. Meno tentativi non è la stessa cosa di nessun tentativo, e riportare una scheda in primo piano è un momento comune per una raffica di essi.

Dove atterra la politica di errore

Il blocco del client viene valutato quando si tenta una connessione, non quando la pagina è stata scaricata. Se l’accesso ordinario è ancora consentito, il nuovo tentativo può uscire dal collegamento fisico in chiaro. Se la policy trattiene quel traffico finché il tunnel non torna, il tentativo fallisce al momento della connessione e la pagina mostra un errore che può riprovare qualche secondo dopo.

Due dettagli decidono quale dei due ottenete. Il primo è l’ambito di applicazione supportato dal client: un blocco per l’intero dispositivo, un blocco limitato all’adattatore del tunnel o un insieme di regole con esclusioni. Il secondo è se la destinazione ricade in un’esclusione aggiunta in precedenza per una stampante locale, un portale captive o un servizio di streaming.

La cifratura a livello applicativo non cambia nulla di tutto ciò. HTTPS protegge i byte tra browser e server; non dice nulla su quale interfaccia li trasporti. Una pagina può essere perfettamente cifrata e uscire comunque dalla strada sbagliata, ed è esattamente ciò che un blocco stretto consente.

Un controllo controllato con una pagina usa e getta

Usate un host che controllate e una pagina che non faccia altro che chiamarlo, così nessun dato reale è in gioco. Da un terminale, campionate il percorso prima e dopo la caduta:

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

Eseguitelo con il tunnel attivo, poi abbassate il tunnel e rieseguitelo. Una risposta da un indirizzo pubblico con il tunnel abbassato vi dice che il percorso diretto è aperto. Un timeout o una connessione rifiutata vi dice che la policy tiene. Ripetete ancora una volta dopo che il client si è riconnesso, così vedete tornare il percorso del tunnel invece di darlo per scontato.

Nel browser, il pannello Rete separa le due domande. Filtrate su Fetch/XHR, poi leggete la colonna dell’iniziatore: una voce avviata da un timer o da uno script, senza navigazione registrata prima, è un tentativo in background e non un ricaricamento. Confrontate la sua ora di inizio con il momento in cui il tunnel è caduto. Se la voce è ancora in sospeso quando il tunnel non c’è più, la richiesta attende un percorso che non esiste più.

Le prove lato server sono più forti di qualsiasi cosa mostri il browser. Un log delle richieste con un timestamp e un indirizzo sorgente dimostra che il pacchetto è arrivato. Le voci del browser possono portare cookie, token e URL completi, quindi conservate solo i campi che servono alla vostra domanda e oscurate il resto prima di incollarle ovunque.

Cosa fare con la risposta

Se i tentativi in background continuano a riuscire mentre il tunnel è abbassato, il blocco è più stretto di quanto supponeste, e quel varco merita di essere chiuso prima di affidare al client un lavoro sensibile. Se falliscono, la policy sta facendo il suo lavoro e la pagina congelata è cosmetica. In ogni caso, chiudere una scheda non è un controllo a livello di dispositivo: altre schede, altri browser e altre applicazioni pianificano ciascuno il proprio lavoro.

Passi successivi che vale la pena fare: elencate quali esclusioni avete aggiunto e perché, confermate se il client blocca solo il traffico nell’ambito del tunnel o tutto il traffico, e osservate una richiesta in background dall’inizio alla fine con il log del server aperto. Quelle tre risposte coprono la maggior parte di ciò che contiene davvero un rapporto del tipo «il VPN è caduto e qualcosa è ancora connesso».