En bref
Un test de fuite d’IP vérifie si des sites web peuvent voir votre adresse IP publique habituelle, vos requêtes DNS, vos informations WebRTC ou votre trafic IPv6 alors qu’un VPN est connecté. Effectuez d’abord un test de référence, reconnectez le VPN, puis comparez les résultats dans un nouvel onglet avant de conclure qu’un résultat est une vraie fuite.
- Un test VPN réussi affiche l’IP de sortie attendue du VPN, et non l’IP publique visible avant la connexion du VPN.
- Un résolveur DNS situé dans un autre pays n’est pas automatiquement une fuite DNS, car les fournisseurs de VPN peuvent faire passer le DNS par une infrastructure distincte.
- Les adresses privées comme 192.168.x.x et les adresses de lien local en 169.254.0.0/16 ne sont pas des adresses internet routables publiquement.
- Les résultats WebRTC méritent l’attention lorsqu’ils exposent une adresse publique de FAI, et pas simplement une adresse locale ou un nom d’hôte
.local. - Testez à nouveau un VPN après une mise à jour du client, un changement de navigateur, un changement de réseau ou une déconnexion inattendue.
Sommaire
- Comment tester mon VPN pour détecter une fuite d’IP ?
- Que doit afficher un test de fuite d’IP ?
- Pourquoi un test de fuite d’IP peut-il sembler alarmant sans l’être ?
- Comment corriger une fuite d’IP, DNS, WebRTC ou IPv6 ?
- Que faire si mon VPN se déconnecte ?
- Que demande-t-on d’autre sur les fuites d’IP ?
- Que faire après un test de fuite d’IP concluant ?
Comment tester mon VPN pour détecter une fuite d’IP ?
Un test de fuite d’IP fiable compare le même appareil et le même navigateur avant et après la connexion du VPN. Notez d’abord la référence, puis vérifiez la connexion VPN dans un nouvel onglet afin qu’une ancienne page ne fausse pas le résultat.
Commencez sur la connexion que vous utilisez réellement. Si votre préoccupation est le Wi-Fi public, testez sur un Wi-Fi public. Si c’est votre connexion à domicile, testez chez vous. Le résultat obtenu sur un appareil ne prouve pas que chaque téléphone, extension de navigateur, routeur ou application est configuré de la même manière.
- Déconnectez le VPN et fermez les anciens onglets de test. Ouvrez une page de test de fuite et notez l’adresse IPv4 publique, toute adresse IPv6 publique, la localisation approximative affichée et les résolveurs DNS listés.
- Connectez le VPN à un emplacement facilement reconnaissable. Choisissez un pays ou une ville de sortie qui sera facile à identifier dans le nouveau résultat. Attendez que l’application VPN confirme la connexion.
- Ouvrez un nouvel onglet de navigateur. Répétez le test. Un nouvel onglet évite de considérer comme actuel un résultat recueilli avant la connexion du VPN.
- Comparez d’abord les adresses publiques. L’IP publique habituelle attribuée par votre FAI, relevée lors de la référence, ne doit pas apparaître après la connexion du VPN.
- Vérifiez séparément le DNS, WebRTC et l’IPv6. Un changement d’IP publique ne constitue pas à lui seul un test complet. Les requêtes DNS, les données de connexion en temps réel du navigateur et le trafic IPv6 peuvent emprunter des chemins différents.
- Reconnectez-vous et répétez une fois. Déconnectez, reconnectez, puis relancez le test. Si le résultat change, ne supposez pas que le plus propre est le bon.
Un test de fuite d’IP identifie les informations réseau publiques visibles au moment du test, et non tous les risques pour la vie privée sur un appareil. Pour replacer le sujet dans un cadre plus large, consultez comment changer d’adresse IP, expliqué et voyez comment différents outils ne modifient que le navigateur, une application ou tout le trafic de l’appareil.
Un bon test est une comparaison : l’adresse visible avant la connexion du VPN face à celle visible après sa connexion.
Que doit afficher un test de fuite d’IP ?
Un résultat sain affiche normalement l’IP de sortie du VPN à la place de l’IP du FAI relevée lors de la référence. Il doit aussi montrer, pour le DNS et l’IPv6, un comportement conforme à la configuration du VPN ou au fonctionnement documenté de la configuration réseau.
| Résultat du test | Généralement attendu | À examiner de plus près lorsque |
|---|---|---|
| IPv4 publique | Une adresse de sortie du VPN remplace l’adresse du FAI relevée lors de la référence. | L’adresse du FAI de référence reste visible alors que le VPN indique être connecté. |
| IPv6 publique | Une adresse IPv6 acheminée par le VPN apparaît, ou l’IPv6 est indisponible avec la configuration choisie. | Une adresse IPv6 publique associée au réseau habituel apparaît alors que l’IPv4 passe par le VPN. |
| Résolveurs DNS | Les résolveurs correspondent à la documentation du fournisseur de VPN ou à un service DNS configuré délibérément. | Le test identifie systématiquement les serveurs DNS habituels du FAI alors que le VPN devrait gérer le DNS. |
| WebRTC | L’IP publique du VPN, une adresse locale ou un nom d’hôte .local peut apparaître selon le comportement du navigateur. |
Une adresse publique du FAI apparaît dans les données de connexion du navigateur après la connexion du VPN. |
Ne vous fiez pas uniquement aux étiquettes de pays. Une IP de sortie de VPN peut être enregistrée à un endroit alors que son serveur physique ou son infrastructure DNS se trouve ailleurs. La vraie question est de savoir si le test révèle la même adresse publique que celle visible avant la connexion du VPN.
Un test de fuite d’IP ne peut pas non plus dire si une adresse de sortie est partagée avec d’autres utilisateurs du VPN ou attribuée à un seul compte. C’est une décision distincte, liée à la confidentialité et à l’accès, traitée dans les VPN avec IP dédiée, expliqués.
Le résultat clé est simple : l’adresse publique visible par votre FAI, relevée lors de la référence, ne doit pas réapparaître une fois la connexion VPN établie.
Pourquoi un test de fuite d’IP peut-il sembler alarmant sans l’être ?
Toute adresse inconnue n’est pas une fuite publique. Lisez le type d’adresse et l’endroit où elle apparaît avant de modifier vos réglages, car les adresses locales et de lien local n’identifient pas une connexion domestique aux sites web sur l’internet public.
Les adresses locales privées ne sont pas des fuites d’IP publiques. La RFC 1918 réserve 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 aux réseaux privés. Voir une adresse dans l’une de ces plages peut révéler la structure du réseau local à une page ou à une extension, mais ce n’est pas la même chose que d’exposer une adresse publique de FAI sur internet. La RFC 1918 définit ces plages pour les réseaux privés. (datatracker.ietf.org)
Une adresse 169.254 est une adresse de lien local. L’Internet Assigned Numbers Authority classe 169.254.0.0/16 comme plage de lien local, non joignable globalement. Concrètement, 169.254.169.254 n’est pas une adresse publique qu’un site web ordinaire pourrait utiliser pour localiser une connexion internet domestique. Il peut rester utile de chercher pourquoi un appareil a une configuration de lien local, mais ce n’est pas la preuve qu’un VPN a exposé l’IP du FAI. Le registre IANA des adresses IPv4 à usage spécial recense cette plage. (iana.org)
Un nom d’hôte .local n’est pas une adresse publique. Le DNS multicast utilise le domaine .local. pour des noms qui n’ont de sens que sur le lien local. Un résultat de navigateur tel que device-name.local doit donc être interprété autrement qu’une adresse IP numérique publique. La RFC 6762 définit .local. comme domaine de lien local. (datatracker.ietf.org)
WebRTC peut exposer des données de connexion utiles. WebRTC utilise des candidats ICE pour aider à établir des connexions en temps réel, et la documentation des navigateurs avertit que les adresses des candidats peuvent révéler des informations sur la topologie réseau d’un appareil. Une adresse publique de FAI dans ce résultat mérite l’attention ; une adresse privée ou un nom .local appelle à la mise en contexte, pas à la panique. La documentation WebRTC de MDN explique le risque d’exposition. (developer.mozilla.org)
Un résultat suspect n’est une fuite avérée que s’il expose l’adresse publique habituelle ou le chemin DNS habituel du FAI que la connexion VPN devait remplacer.
Comment corriger une fuite d’IP, DNS, WebRTC ou IPv6 ?
Corrigez le chemin qui fuit plutôt que d’appliquer tous les réglages possibles d’un coup. Commencez par le client VPN et la configuration de l’appareil, puis retestez chaque modification avec la même méthode de référence puis de connexion.
- Confirmez que le VPN couvrant tout l’appareil est connecté. Un proxy de navigateur peut modifier l’IP visible par les pages du navigateur pendant que les autres applications continuent d’utiliser la connexion réseau ordinaire. Testez l’outil qui protège le trafic que vous comptez réellement utiliser.
- Passez en revue les règles de tunnel fractionné. Si le tunnel fractionné est activé, un navigateur ou une application exclus peuvent utiliser la connexion normale par conception. Retirez l’application concernée de la liste d’exclusions lorsqu’elle a besoin de la protection du VPN.
- Vérifiez les réglages DNS dans l’application VPN et dans le système d’exploitation. Un résolveur configuré manuellement n’est pas toujours une fuite, mais il doit être voulu et se comporter comme prévu pendant que le VPN est actif. Si le VPN est censé gérer le DNS, supprimez les réglages personnalisés en conflit et reconnectez-vous.
- Vérifiez la gestion de l’IPv6. Si un test affiche une adresse IPv6 publique habituelle à côté d’une IPv4 acheminée par le VPN, vérifiez si le client VPN achemine le trafic IPv6. Ne désactivez pas l’IPv6 à l’aveugle, car cela peut affecter la connectivité sur certains réseaux.
- Mettez à jour l’application VPN et le navigateur. La gestion du réseau et le comportement du navigateur en matière de confidentialité peuvent changer d’une version à l’autre. Retestez après la mise à jour plutôt que de supposer qu’un ancien résultat sain reste valable.
- Testez un autre navigateur sans modifier plusieurs variables à la fois. Cela peut montrer si le problème est propre au navigateur, surtout lorsque l’inquiétude porte sur WebRTC.
Une solution limitée au navigateur ne remplace pas une protection de tout l’appareil lorsque des applications extérieures au navigateur traitent un trafic sensible. Pour une routine plus large de renforcement du navigateur et du réseau, lisez notre guide pour naviguer en toute sécurité.
La correction la plus fiable est celle qui modifie le chemin de trafic précis ayant exposé l’adresse de référence, puis produit le résultat attendu lors d’un nouveau test.
Que faire si mon VPN se déconnecte ?
Considérez une interruption du VPN comme un test à part, car une connexion peut sembler saine tant qu’elle est active et exposer le trafic habituel pendant une coupure. Cessez d’abord toute navigation sensible, reconnectez-vous volontairement, puis comparez le nouveau résultat à la référence d’origine.
Un test d’interruption contrôlée doit être bref. Le VPN étant connecté, mettez les téléchargements en pause et fermez les pages sensibles, déconnectez le VPN et observez si l’appareil retrouve une connectivité ordinaire. Reconnectez-vous immédiatement, ouvrez un nouvel onglet et relancez les vérifications d’IP et de DNS.
Si l’IP publique habituelle devient visible pendant une interruption, ne poursuivez pas les activités qui exigent le VPN tant que la cause n’est pas comprise. Examinez les paramètres de protection de connexion du client VPN, le comportement réseau du système d’exploitation et la documentation d’assistance. Si le comportement persiste, contactez le support en indiquant l’IP de référence, le résultat une fois connecté, l’appareil, le navigateur, le protocole VPN et l’heure exacte du test.
Une connexion active saine est utile, mais une configuration VPN soucieuse de la confidentialité doit aussi se comporter de façon prévisible lors de la reconnexion.
Que demande-t-on d’autre sur les fuites d’IP ?
Que faire quand quelqu’un divulgue votre IP ?
Si quelqu’un expose votre adresse IP publique, déconnectez-vous de tout service où cette adresse crée un risque immédiat, conservez les preuves de menaces ou de harcèlement, et contactez la plateforme concernée ou les autorités locales si nécessaire. Redémarrer un routeur domestique peut changer une adresse dynamique, mais cela ne remplace ni la sécurité des comptes, ni les paramètres de confidentialité, ni un signalement documenté.
À quoi sert l’adresse IP 169.254.169.254 ?
169.254.169.254 appartient à la plage de lien local 169.254.0.0/16, que l’IANA classe comme non joignable globalement. Les adresses de lien local ne sont utilisées que dans le contexte d’un réseau local, et chaque réseau peut y attribuer des services locaux. Voir cette adresse ne prouve pas qu’un VPN a exposé l’adresse publique habituelle de votre FAI.
1.1.1.1 est-elle une IP publique ?
Oui. 1.1.1.1 est une adresse IPv4 joignable publiquement, utilisée par un résolveur DNS public, et non une adresse de réseau privé RFC 1918. Un test de fuite DNS peut l’afficher si l’appareil utilise volontairement ce résolveur. Sa seule présence ne prouve pas une fuite ; l’important est de savoir si le chemin DNS correspond à la configuration voulue.
Quelle est ma vraie adresse IP ?
Dans le cadre d’un test de fuite d’IP, votre vraie adresse IP est l’adresse publique qu’un site web voit lorsque le VPN est déconnecté sur le même réseau. Notez cette adresse de référence avant de tester. Si cette même adresse publique apparaît après la connexion du VPN, la connexion VPN expose peut-être un trafic qui aurait dû être acheminé autrement.
La bonne question n’est pas de savoir si chaque résultat paraît inconnu, mais si l’identité publique d’avant le VPN reste visible une fois que le VPN indique que la connexion a réussi.
Que faire après un test de fuite d’IP concluant ?
Enregistrez la date, l’appareil, le navigateur, le réseau et l’emplacement VPN qui ont produit le résultat sain, puis répétez le test après chaque changement significatif. Si la configuration actuelle ne peut pas offrir le routage de tout l’appareil et le comportement de connexion nécessaires à une navigation privée, un abonnement VPNSecure est une étape suivante pratique pour les appareils pris en charge.
Un résultat sain est un point de contrôle, pas une garantie permanente : répétez le même test chaque fois que l’appareil, le navigateur, le réseau ou la configuration du VPN change.