Le VPN n’a pas fuité votre ancienne IP : une valeur mémorisée l’a fait

Voir votre ancienne adresse publique dans le rapport d’un service après l’activation du VPN n’est pas, en soi, une preuve de fuite. La connexion active peut utiliser la sortie du tunnel pendant que l’application envoie une valeur qu’elle a apprise avant l’existence du tunnel. Ce sont deux preuves différentes, et une seule décrit le paquet actuel. L’autre est une valeur qui a survécu à la reconnexion parce que rien sur le chemin réseau ne la possède.

Les deux explications derrière une adresse

La séquence que les gens imaginent est un paquet qui quitte l’interface physique alors que le VPN est censé être actif. La séquence qui explique souvent le rapport est plus courte et plus banale : une application a appris une adresse plus tôt et la conserve encore. Mettre les événements dans l’ordre sépare les deux.

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

Rien dans cet ordre n’exige une connexion active depuis la première adresse. La valeur mémorisée voyage dans le message, tandis que l’en-tête porte la sortie qu’a choisie la route actuelle. Un service qui journalise les deux champs les affichera côte à côte et semblera contradictoire.

C’est une explication possible, pas une accusation contre un client particulier. La réputation n’est pas une preuve : un code que vous pouvez lire, une marque à laquelle vous faites confiance ou une autre sortie ne disent rien de ce qu’un programme a conservé ou envoyé.

La mémoire de l’application survit à la reconnexion

Connecter un VPN change la route que prend une nouvelle connexion. Il laisse l’état de l’application intact et ne peut pas retirer des informations qu’un service distant a déjà stockées. Un programme peut envoyer un identifiant de compte, un emplacement enregistré, un nom d’appareil ou une autre valeur obtenue plus tôt, et le chiffrement protège cette charge en transit sans rien en retirer. La reconnexion est un événement réseau ; la valeur conservée est un événement de l’application.

La distinction compte parce que les deux vivent à des endroits différents. L’état de l’application appartient au programme et survit aux redémarrages, tandis que la route appartient au système d’exploitation et est reconstruite à chaque connexion. Nettoyer l’un n’a aucun effet sur l’autre.

Un service peut aussi conserver une valeur que vous lui avez remise il y a des mois, et dans ce cas aucun changement local ne l’éliminera. C’est de la conservation, et elle se situe entièrement hors du tunnel.

Lisez l’en-tête source, puis la charge utile

Commencez par déterminer où l’adresse est apparue. Le journal de connexions d’un serveur décrit la source active, tandis qu’un champ de message, un profil de compte ou un affichage de diagnostic local peuvent décrire une valeur soumise ou stockée bien plus tôt. Ces observations répondent à des questions différentes.

Comparez aussi les horaires. Si l’ancienne adresse apparaît dans un champ antérieur à la connexion VPN, l’explication par la charge utile est plus forte. Si le serveur enregistre une connexion directe depuis l’ancienne adresse pendant que le tunnel est actif, c’est une question de routage et elle demande une autre enquête. Trier d’abord les types d’observation empêche une adresse d’être étirée en preuve de trois événements.

Gardez-les séparés dans vos notes : source de connexion, champ de message, affichage du compte, diagnostic local. Une adresse écrite à quatre endroits reste une adresse.

La conservation est une étape différente du transport

Les recommandations de confidentialité de RFC 6973 traitent la collecte, l’usage, la divulgation et la conservation comme des étapes distinctes, et elles avertissent que les identifiants réutilisés rendent la corrélation facile. Un nouveau chemin réseau change l’étape de transport et rien d’autre. Les enregistrements que le destinataire détient déjà ne sont pas touchés, pas plus qu’un profil qui a stocké la valeur à l’entrée. C’est pourquoi une reconnexion peut sembler un échec alors que le transport se comporte correctement.

Aucun filtre de paquets ne peut effacer une valeur des enregistrements d’un destinataire, et se reconnecter n’effacera pas l’historique stocké de chaque programme. Ce sont des problèmes du propriétaire des données, pas du tunnel, et ils demandent un autre type de solution. Demandez au service ce qu’il conserve et pendant combien de temps avant de demander au réseau de le cacher.

Que vérifier avant d’accuser le tunnel

Examinez la collecte documentée de l’application et les contrôles du compte, et décidez quels champs elle peut envoyer, combien de temps le service les conserve et si le compte peut les effacer ou les corriger. Faites ensuite le test qui sépare les explications : un compte neuf ou un profil d’application propre. Si l’ancienne valeur disparaît, une conservation ou un état en cache était en cause. Si elle survit à un profil propre, examinez le champ réel de la requête avant de conclure que le VPN a échoué.

Si une connexion directe existe réellement, traitez-la comme une constatation sur le chemin réseau. Enquêtez sur le routage, le tunnel divisé et la politique du client selon leurs propres termes, et ne mélangez pas ce résultat avec une valeur de charge utile qui a simplement survécu à la reconnexion. Les deux défaillances se ressemblent sur une capture d’écran et se comportent tout autrement dans une capture de trafic.