La VPN no filtró tu IP antigua: lo hizo un valor recordado

Ver tu antigua dirección pública en el informe de un servicio después de que la VPN arranque no es, por sí solo, prueba de una fuga. La conexión activa puede estar usando la salida del túnel mientras la aplicación envía un valor que aprendió antes de que el túnel existiera. Son dos pruebas distintas, y solo una describe el paquete actual. La otra es un valor que sobrevivió a la reconexión porque nada en la ruta de red es su dueño.

Las dos explicaciones detrás de una dirección

La secuencia que la gente imagina es un paquete que sale de la interfaz física mientras la VPN supuestamente está activa. La secuencia que a menudo explica el informe es más corta y aburrida: una aplicación aprendió una dirección antes y todavía la conserva. Ordenar los acontecimientos separa las dos.

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 en ese orden exige una conexión activa desde la primera dirección. El valor recordado viaja dentro del mensaje, mientras la cabecera lleva la salida que haya elegido la ruta actual. Un servicio que registra ambos campos los mostrará uno al lado del otro y parecerá contradictorio.

Esa es una explicación posible, no una acusación contra ningún cliente concreto. La reputación no es una prueba: un código que puedes leer, una marca en la que confías o una salida distinta no dicen nada sobre lo que un programa guardó o envió.

La memoria de la aplicación sobrevive a la reconexión

Conectar una VPN cambia la ruta que toma una conexión nueva. Deja intacto el estado de la aplicación y no puede retirar información que un servicio remoto ya ha almacenado. Un programa puede enviar un identificador de cuenta, una ubicación guardada, un nombre de dispositivo u otro valor que obtuvo antes, y el cifrado protege esa carga en tránsito sin quitar nada de ella. La reconexión es un acontecimiento de red; el valor retenido es un acontecimiento de la aplicación.

La distinción importa porque los dos viven en lugares distintos. El estado de la aplicación pertenece al programa y sobrevive a los reinicios, mientras que la ruta pertenece al sistema operativo y se reconstruye en cada conexión. Limpiar uno no tiene efecto sobre el otro.

Un servicio también puede guardar un valor que le entregaste hace meses, y en ese caso ningún cambio local lo eliminará. Eso es retención, y queda por completo fuera del túnel.

Lee la cabecera de origen y después la carga

Empieza por determinar dónde apareció la dirección. El registro de conexiones de un servidor describe el origen activo, mientras que un campo de mensaje, un perfil de cuenta o una pantalla de diagnóstico local pueden describir un valor enviado o guardado mucho antes. Esas observaciones responden a preguntas distintas.

Compara también los tiempos. Si la dirección antigua aparece en un campo anterior a la conexión VPN, la explicación de la carga es más fuerte. Si el servidor registra una conexión directa desde la dirección antigua mientras el túnel está activo, eso es una cuestión de enrutamiento y necesita otra investigación. Ordenar primero los tipos de observación evita que una dirección se estire hasta ser prueba de tres acontecimientos.

Mantenlos separados en tus notas: origen de la conexión, campo del mensaje, pantalla de la cuenta, diagnóstico local. Una dirección escrita en cuatro lugares sigue siendo una dirección.

La retención es una etapa distinta del transporte

Las directrices de privacidad de RFC 6973 tratan la recogida, el uso, la divulgación y la retención como etapas distintas, y advierten de que los identificadores reutilizados facilitan la correlación. Una ruta de red nueva cambia la etapa de transporte y nada más. Los registros que el receptor ya tiene no se tocan, y tampoco ningún perfil que haya guardado el valor a la entrada. Por eso una reconexión puede parecer un fracaso mientras el transporte se comporta correctamente.

Ningún filtro de paquetes puede borrar un valor de los registros de un receptor, y reconectar otra vez no limpiará el historial guardado de cada programa. Son problemas del propietario de los datos, no del túnel, y necesitan otro tipo de solución. Pregunta al servicio qué guarda y durante cuánto tiempo antes de pedir a la red que lo oculte.

Qué comprobar antes de culpar al túnel

Revisa la recogida documentada de la aplicación y los controles de la cuenta, y decide qué campos puede enviar, cuánto tiempo los guarda el servicio y si la cuenta puede borrarlos o corregirlos. Después haz la prueba que separa las explicaciones: una cuenta nueva o un perfil de aplicación limpio. Si el valor antiguo desaparece, había retención o estado en caché. Si sobrevive a un perfil limpio, examina el campo real de la solicitud antes de concluir que la VPN falló.

Si realmente hay una conexión directa, trátala como un hallazgo de la ruta de red. Investiga el enrutamiento, el túnel dividido y la política del cliente con sus propios términos, y no mezcles ese resultado con un valor de carga que simplemente sobrevivió a la reconexión. Los dos fallos se parecen en una captura de pantalla y se comportan de forma muy distinta en una captura de tráfico.