A VPN non filtrou o teu IP antigo: fíxoo un valor recordado

Ver o teu antigo enderezo público no informe dun servizo despois de que a VPN arrinque non é, por si só, proba dunha fuga. A conexión activa pode estar usando a saída do túnel mentres a aplicación envía un valor que aprendeu antes de que o túnel existise. Son dúas probas distintas, e só unha describe o paquete actual. A outra é un valor que sobreviviu á reconexión porque nada na ruta de rede é o seu dono.

As dúas explicacións detrás dun enderezo

A secuencia que a xente imaxina é un paquete que sae da interface física mentres a VPN supostamente está activa. A secuencia que a miúdo explica o informe é máis curta e máis aburrida: unha aplicación aprendeu un enderezo antes e aínda o conserva. Ordenar os acontecementos separa as dúas.

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

Nada nesa orde esixe unha conexión activa desde o primeiro enderezo. O valor recordado viaxa dentro da mensaxe, mentres a cabeceira leva a saída que escollese a ruta actual. Un servizo que rexistra ambos os campos mostrarémolos un ao lado do outro e parecerá contraditorio.

Esa é unha explicación posible, non unha acusación contra ningún cliente concreto. A reputación non é unha proba: un código que podes ler, unha marca na que confías ou unha saída distinta non din nada sobre o que un programa gardou ou enviou.

A memoria da aplicación sobrevive á reconexión

Conectar unha VPN cambia a ruta que toma unha conexión nova. Deixa intacto o estado da aplicación e non pode retirar información que un servizo remoto xa almacenou. Un programa pode enviar un identificador de conta, unha localización gardada, un nome de dispositivo ou outro valor que obtivo antes, e o cifrado protexe esa carga en tránsito sen quitar nada dela. A reconexión é un acontecemento de rede; o valor retido é un acontecemento da aplicación.

A distinción importa porque os dous viven en lugares distintos. O estado da aplicación pertence ao programa e sobrevive aos reinicios, mentres que a ruta pertence ao sistema operativo e reconstrúese en cada conexión. Limpar un non ten efecto sobre o outro.

Un servizo tamén pode gardar un valor que lle entregaches hai meses, e nese caso ningún cambio local o eliminará. Iso é retención, e queda por completo fóra do túnel.

Le a cabeceira de orixe e despois a carga

Comeza por determinar onde apareceu o enderezo. O rexistro de conexións dun servidor describe a orixe activa, mentres que un campo de mensaxe, un perfil de conta ou unha pantalla de diagnóstico local poden describir un valor enviado ou gardado moito antes. Esas observacións responden a preguntas distintas.

Compara tamén os tempos. Se o enderezo antigo aparece nun campo anterior á conexión VPN, a explicación da carga é máis forte. Se o servidor rexistra unha conexión directa desde o enderezo antigo mentres o túnel está activo, iso é unha cuestión de enrutamento e necesita outra investigación. Ordenar primeiro os tipos de observación evita que un enderezo se estire ata ser proba de tres acontecementos.

Manténs separados nas túas notas: orixe da conexión, campo da mensaxe, pantalla da conta, diagnóstico local. Un enderezo escrito en catro lugares segue sendo un enderezo.

A retención é unha etapa distinta do transporte

As directrices de privacidade de RFC 6973 tratan a recollida, o uso, a divulgación e a retención como etapas distintas, e advirten de que os identificadores reutilizados facilitan a correlación. Unha ruta de rede nova cambia a etapa de transporte e nada máis. Os rexistros que o destinatario xa ten non se tocan, e tampouco ningún perfil que gardase o valor na entrada. Por iso unha reconexión pode parecer un fracaso mentres o transporte se comporta correctamente.

Ningún filtro de paquetes pode borrar un valor dos rexistros dun destinatario, e reconectar outra vez non limpará o historial gardado de cada programa. Son problemas do propietario dos datos, non do túnel, e necesitan outro tipo de solución. Pregunta ao servizo que garda e durante canto tempo antes de pedir á rede que o oculte.

Que comprobar antes de culpar o túnel

Revisa a recollida documentada da aplicación e os controis da conta, e decide que campos pode enviar, canto tempo os garda o servizo e se a conta pode borralos ou corrixilos. Despois fai a proba que separa as explicacións: unha conta nova ou un perfil de aplicación limpo. Se o valor antigo desaparece, había retención ou estado na caché. Se sobrevive a un perfil limpo, examina o campo real da solicitude antes de concluír que a VPN fallou.

Se realmente hai unha conexión directa, trátaa como un achado da ruta de rede. Investiga o enrutamento, o túnel dividido e a política do cliente cos seus propios termos, e non mestures ese resultado cun valor de carga que simplemente sobreviviu á reconexión. Os dous fallos parécense nunha captura de pantalla e compórtanse de forma moi distinta nunha captura de tráfico.