La VPN non ha fatto trapelare il tuo vecchio IP: lo ha fatto un valore memorizzato

Vedere il tuo vecchio indirizzo pubblico nel rapporto di un servizio dopo l'attivazione della VPN non è, di per sé, prova di una fuga. La connessione attiva può usare l'uscita del tunnel mentre l'app invia un valore che ha appreso prima che il tunnel esistesse. Sono due prove diverse, e solo una descrive il pacchetto attuale. L'altra è un valore sopravvissuto alla riconnessione perché nulla sul percorso di rete ne è proprietario.

Le due spiegazioni dietro un indirizzo

La sequenza che le persone immaginano è un pacchetto che lascia l'interfaccia fisica mentre la VPN è presumibilmente attiva. La sequenza che spesso spiega il rapporto è più corta e più noiosa: un'app ha appreso un indirizzo prima e lo conserva ancora. Mettere gli eventi in ordine separa le due.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

Niente in quell'ordine richiede una connessione attiva dal primo indirizzo. Il valore memorizzato viaggia dentro il messaggio, mentre l'intestazione porta l'uscita scelta dal percorso attuale. Un servizio che registra entrambi i campi li mostrerà affiancati e sembrerà contraddittorio.

È una spiegazione possibile, non un'accusa contro un client specifico. La reputazione non è una prova: un codice che puoi leggere, un marchio di cui ti fidi o un'uscita diversa non dicono nulla su ciò che un programma ha conservato o inviato.

La memoria dell'app sopravvive alla riconnessione

Collegare una VPN cambia il percorso che prende una nuova connessione. Lascia intatto lo stato dell'app e non può ritirare informazioni che un servizio remoto ha già memorizzato. Un programma può inviare un identificatore di account, una posizione salvata, un nome di dispositivo o un altro valore ottenuto prima, e la crittografia protegge quel carico in transito senza rimuoverne nulla. La riconnessione è un evento di rete; il valore conservato è un evento dell'app.

La distinzione conta perché i due vivono in luoghi diversi. Lo stato dell'app appartiene al programma e sopravvive ai riavvii, mentre il percorso appartiene al sistema operativo e viene ricostruito a ogni connessione. Pulire l'uno non ha effetto sull'altro.

Un servizio può anche conservare un valore che gli hai consegnato mesi fa, e in quel caso nessun cambiamento locale lo rimuoverà. È conservazione, e sta interamente fuori dal tunnel.

Leggi prima l'intestazione di origine, poi il carico

Inizia stabilendo dove è apparso l'indirizzo. Il registro delle connessioni di un server descrive l'origine attiva, mentre un campo del messaggio, un profilo dell'account o una schermata diagnostica locale possono descrivere un valore inviato o memorizzato molto prima. Quelle osservazioni rispondono a domande diverse.

Confronta anche gli orari. Se il vecchio indirizzo appare in un campo precedente alla connessione VPN, la spiegazione del carico è più forte. Se il server registra una connessione diretta dal vecchio indirizzo mentre il tunnel è attivo, è una questione di routing e richiede un'altra indagine. Ordinare prima i tipi di osservazione impedisce che un indirizzo venga allungato fino a diventare prova di tre eventi.

Tienili separati nelle tue note: origine della connessione, campo del messaggio, schermata dell'account, diagnostica locale. Un indirizzo scritto in quattro punti resta un indirizzo.

La conservazione è una fase diversa dal trasporto

Le linee guida sulla privacy di RFC 6973 trattano raccolta, uso, divulgazione e conservazione come fasi distinte, e avvertono che gli identificatori riutilizzati rendono facile la correlazione. Un nuovo percorso di rete cambia la fase di trasporto e nulla più. I registri che il destinatario già possiede non vengono toccati, e nemmeno qualsiasi profilo che abbia memorizzato il valore all'ingresso. Per questo una riconnessione può sembrare un fallimento mentre il trasporto si comporta correttamente.

Nessun filtro di pacchetti può cancellare un valore dai registri di un destinatario, e riconnettersi non pulirà la cronologia memorizzata di ogni programma. Sono problemi del proprietario dei dati, non del tunnel, e richiedono un altro tipo di soluzione. Chiedi al servizio cosa conserva e per quanto tempo prima di chiedere alla rete di nasconderlo.

Cosa controllare prima di accusare il tunnel

Esamina la raccolta documentata dell'app e i controlli dell'account, e decidi quali campi può inviare, per quanto tempo il servizio li conserva e se l'account può cancellarli o correggerli. Poi esegui il test che separa le spiegazioni: un account nuovo o un profilo applicativo pulito. Se il vecchio valore scompare, erano coinvolti conservazione o stato in cache. Se sopravvive a un profilo pulito, esamina il campo reale della richiesta prima di concludere che la VPN abbia fallito.

Se esiste davvero una connessione diretta, trattala come un rilievo sul percorso di rete. Indaga su routing, tunnel diviso e politica del client secondo i loro termini, e non mescolare quel risultato con un valore del carico che è semplicemente sopravvissuto alla riconnessione. I due guasti sembrano uguali in uno screenshot e si comportano in modo del tutto diverso in una cattura.