La VPN no va filtrar la teva IP antiga: ho va fer un valor recordat

Veure la teva adreça pública antiga a l'informe d'un servei després que la VPN arrenqui no és, per si sol, prova d'una fuita. La connexió activa pot estar utilitzant l'eixida del túnel mentre l'aplicació envia un valor que va aprendre abans que el túnel existís. Són dues proves diferents, i només una descriu el paquet actual. L'altra és un valor que va sobreviure a la reconnexió perquè res al camí de la xarxa en té la propietat.

Les dues explicacions darrere d'una adreça

La seqüència que la gent imagina és un paquet que surt de la interfície física mentre la VPN suposadament està activa. La seqüència que sovint explica l'informe és més curta i més avorrida: una aplicació va aprendre una adreça abans i encara la reté. Ordenar els esdeveniments separa les dues.

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

Res en aquest ordre no exigeix una connexió activa des de la primera adreça. El valor recordat viatja dins del missatge, mentre la capçalera porta l'eixida que ha triat la ruta actual. Un servei que registra tots dos camps els mostrarà costat a costat i semblarà contradictori.

Aquesta és una explicació possible, no una acusació contra cap client concret. La reputació no és una prova: un codi que pots llegir, una marca que confies o una eixida diferent no diuen res sobre què va guardar o enviar un programa.

La memòria de l'aplicació sobreviu a la reconnexió

Connectar una VPN canvia la ruta que pren una connexió nova. Deixa l'estat de l'aplicació en pau i no pot retirar informació que un servei remot ja ha emmagatzemat. Un programa pot enviar un identificador de compte, una ubicació desada, un nom de dispositiu o un altre valor que va obtenir abans, i el xifratge protegeix aquesta càrrega en trànsit sense treure'n res. La reconnexió és un esdeveniment de xarxa; el valor retingut és un esdeveniment de l'aplicació.

La distinció importa perquè tots dos viuen en llocs diferents. L'estat de l'aplicació pertany al programa i sobreviu als reinicis, mentre que la ruta pertany al sistema operatiu i es reconstrueix a cada connexió. Netejar-ne un no té cap efecte sobre l'altre.

Un servei també pot guardar un valor que li vas lliurar fa mesos, i en aquest cas cap canvi local no el traurà. Això és retenció, i queda completament fora del túnel.

Llegeix la capçalera d'origen i després la càrrega

Comença per determinar on va aparèixer l'adreça. El registre de connexions d'un servidor descriu l'origen actiu, mentre que un camp de missatge, un perfil de compte o una pantalla de diagnòstic local poden descriure un valor enviat o desat molt abans. Aquestes observacions responen preguntes diferents.

Compara també els temps. Si l'adreça antiga apareix en un camp anterior a la connexió VPN, l'explicació de la càrrega és més forta. Si el servidor registra una connexió directa des de l'adreça antiga mentre el túnel està actiu, això és una qüestió d'encaminament i necessita una altra investigació. Ordenar primer els tipus d'observació evita que una adreça s'estiri fins a ser prova de tres esdeveniments.

Mantén-los separats a les notes: origen de la connexió, camp del missatge, pantalla del compte, diagnòstic local. Una adreça escrita en quatre llocs continua sent una adreça.

La retenció és una etapa diferent del transport

La guia de privacitat de RFC 6973 tracta la recollida, l'ús, la divulgació i la retenció com a etapes diferents, i adverteix que els identificadors reutilitzats fan fàcil la correlació. Un camí de xarxa nou canvia l'etapa de transport i res més. Els registres que el destinatari ja té no es toquen, i tampoc cap perfil que hagi desat el valor d'entrada. És per això que una reconnexió pot semblar un fracàs mentre el transport funciona correctament.

Cap filtre de paquets no pot esborrar un valor dels registres d'un destinatari, i reconnectar-se no netejarà l'historial desat de cada programa. Són problemes del propietari de les dades, no del túnel, i necessiten un altre tipus de solució. Pregunta al servei què guarda i durant quant de temps abans de demanar a la xarxa que ho amagui.

Què cal comprovar abans de culpar el túnel

Revisa la recollida documentada de l'aplicació i els controls del compte, i decideix quins camps pot enviar, quant de temps els guarda el servei i si el compte els pot esborrar o corregir. Després fes la prova que separa les explicacions: un compte nou o un perfil d'aplicació net. Si el valor antic desapareix, hi havia retenció o estat en memòria cau. Si sobreviu a un perfil net, examina el camp real de la sol·licitud abans de concloure que la VPN va fallar.

Si realment hi ha una connexió directa, tracta-la com una troballa del camí de xarxa. Investiga l'encaminament, el túnel dividit i la política del client amb els seus propis termes, i no barregis aquest resultat amb un valor de càrrega que simplement va sobreviure a la reconnexió. Les dues fallades s'assemblen en una captura de pantalla i es comporten de manera molt diferent en una captura de trànsit.