Test de fuite VPN : IP, WebRTC, IPv6 et DNS

Ce que signifie un VPN « qui fonctionne »

Une fuite survient quand du trafic contourne les règles de routage ou de confidentialité prévues pour le VPN. Une application ou une destination volontairement exclue n’indique pas forcément un défaut. Avant d’interpréter le test, précisez quels navigateurs, applications, versions IP et requêtes DNS doivent passer par le tunnel. Ce test n’examine pas tout l’appareil et ne vérifie pas le fonctionnement du coupe-circuit.

La plupart des fuites ne sont pas des pannes spectaculaires. Elles viennent généralement d’un trafic que l’application VPN n’a jamais été configurée pour transporter, comme l’IPv6, ou de fonctions du navigateur qui ouvrent leurs propres connexions. Une vérification complète examine quatre chemins distincts :

• Votre IP publique en IPv4 – l’adresse que voient la plupart des sites web.
• Votre IP publique en IPv6 – une seconde adresse dont disposent aussi de nombreuses connexions.
• WebRTC – la fonction du navigateur utilisée pour les appels vidéo, capable de découvrir des adresses par elle-même.
• DNS – les requêtes qui traduisent des noms comme example.com en adresses.

Faire le test en moins de deux minutes

Il vous suffit d’IPNixa dans votre navigateur et de votre application VPN. Effectuez les vérifications dans cet ordre pour que la comparaison avant/après ait un sens.

1. VPN désactivé, ouvrez la vérification VPN d’IPNixa et sélectionnez « Enregistrer la connexion actuelle ». Notez les adresses IPv4 et IPv6 confirmées ainsi que le réseau. La comparaison enregistrée reste dans cet onglet pendant 30 minutes maximum.
2. Connectez votre VPN et attendez que l’application indique qu’il est connecté.
3. Sélectionnez « Vérifier à nouveau et comparer ». Comparez chaque version IP confirmée, le pays et le réseau avec la connexion enregistrée.
4. Lisez les observations WebRTC et IPv6. Une adresse publique supplémentaire ou un pays différent mérite un examen ; un pays identique ne suffit pas à exclure une fuite.
5. Utilisez la page dédiée à la détection VPN pour examiner les signaux VPN, proxy, Tor et hébergement. Une classification décrit une adresse observée, pas la sécurité de votre tunnel.
6. Terminez par un test de fuite DNS proposé par votre fournisseur VPN ou par un service de test DNS dédié.

Comment lire chaque résultat

Ce tableau vous aide à décider si une ligne est correcte, mérite un second examen ou nécessite une correction.

Pourquoi l’IPv6 exige une vérification distincte

De nombreuses connexions fixes et mobiles sont en double pile (dual-stack) : elles disposent à la fois d’une adresse IPv4 et d’une adresse IPv6. Certaines applications VPN ne font passer que l’IPv4 par le tunnel. Votre navigateur continue de joindre les sites compatibles double pile en IPv6, souvent en priorité, et ces sites voient l’adresse IPv6 de votre fournisseur d’accès – ce qui révèle votre fournisseur et une localisation approximative.

IPNixa vérifie l’IPv4 et l’IPv6 séparément. Un pays de sortie différent invite à vérifier le routage ou la géolocalisation ; avec un VPN situé dans le même pays, il faut tout de même comparer les adresses. Un test qui échoue ne prouve pas que l’IPv6 est bloqué de manière sûre. Vérifiez les paramètres de routage IPv6 ou de protection contre les fuites de votre application VPN.

Les fuites WebRTC dans votre navigateur

WebRTC permet aux navigateurs de passer des appels et de partager de la vidéo directement entre personnes. Pour trouver un chemin direct, le navigateur demande à un serveur STUN quelle adresse publique il semble avoir. Si cette requête passe en dehors du VPN, elle peut révéler une adresse que le site web n’a jamais vue via le trafic web habituel.

Les navigateurs modernes masquent par défaut les adresses du réseau local ; la vraie question est donc de savoir si une adresse publique autre que celle du VPN apparaît. La vérification d’IPNixa collecte les candidats WebRTC via le serveur STUN public de Cloudflare et les compare aux adresses confirmées sur le web. Si une autre adresse publique apparaît, activez la protection WebRTC de votre VPN ou utilisez un paramètre ou une extension du navigateur qui limite WebRTC au VPN.

« Observé » signifie qu’une adresse ou un autre signal a été vu. « Comparé » signifie que des valeurs ont été confrontées les unes aux autres, et non que la protection du VPN a été certifiée. « Non confirmé » couvre les résultats sans adresse publique, les délais dépassés et les échecs d’exécution ; « Non pris en charge » signifie que le navigateur n’expose aucune API WebRTC. Un test terminé sans adresse publique peut s’expliquer par les protections de confidentialité du navigateur ou par un point d’accès STUN bloqué.

Pourquoi un test de fuite DNS exige un service distinct

Avant que votre navigateur puisse charger un site, un résolveur DNS traduit son nom en adresse. Si ces requêtes partent vers le résolveur de votre fournisseur d’accès au lieu de celui du VPN, votre fournisseur peut toujours voir quels sites vous consultez, même si les pages elles-mêmes passent par le tunnel.

Une page web ne peut pas savoir quel résolveur a répondu à vos requêtes. Un véritable test de fuite DNS fait résoudre par votre appareil des noms uniques et aléatoires, puis observe quels résolveurs les demandent à un serveur DNS faisant autorité. Cela exige une infrastructure DNS dédiée : cette vérification indique donc le DNS comme « Non testé » au lieu de deviner. Utilisez la page de test de fuite de votre fournisseur VPN ou un service dédié aux fuites DNS, et activez la protection contre les fuites DNS de l’application.

Quand « VPN détecté » est une erreur

Sur sa page de détection VPN, IPNixa présente les indices tirés du nom de réseau, de l’ASN et de WARP séparément des classifications facultatives fournies par des prestataires. VPN, proxy, Tor et hébergement sont des signaux distincts. Une adresse d’hébergement ne prouve pas à elle seule qu’un VPN est utilisé, et un VPN non répertorié peut recevoir une classification négative ou inconnue. Lisez la source et l’IP exacte de la requête affichées avec le résultat.

Relais privé iCloud protège surtout Safari ; la couverture de Cloudflare WARP dépend du mode. Le mode DNS uniquement chiffre DNS sans tunnel pour le reste du trafic. N’attribuez pas une couverture identique aux labels relais ou WARP : vérifiez mode et application testée.