Test de fuite WebRTC : lire les IP exposées

Ce que fait réellement le test WebRTC

WebRTC permet les appels et les connexions de données dans le navigateur. Lors de l’établissement de la connexion, ICE collecte des adresses candidates ; un service STUN peut aider à découvrir l’adresse visible depuis Internet. Ce chemin peut différer d’une requête web ordinaire : c’est pourquoi il est utile de l’examiner en parallèle de votre IP publique.

IPNixa contacte le service STUN public de Cloudflare et compare les candidats publics avec les observations IPv4 et IPv6 de ce test. Les candidats hôtes privés et mDNS ne sont pas comptés comme exposition publique. Les candidats IPv6 situés dans un /64 déjà observé sont considérés comme appartenant au même réseau : la comparaison porte donc sur des réseaux publics supplémentaires, et non sur chaque adresse dont l’écriture diffère.

Comment faire un test de fuite WebRTC

Gardez active la configuration VPN que vous comptez utiliser et testez le navigateur que vous utilisez réellement. IPNixa ne demande pas l’accès à la caméra ni au micro pour ce test.

1. Ouvrez le test VPN et attendez que les observations IPv4 et IPv6 publiques se stabilisent.
2. Consultez la ligne « Exposition WebRTC ». Ce test s’exécute à chaque vérification de connexion et attend jusqu’à trois secondes la collecte des candidats.
3. Si une adresse supplémentaire apparaît, vérifiez les paramètres WebRTC de votre VPN et de votre navigateur. Une adresse supplémentaire ne suffit pas à établir une fuite VPN.
4. Si le résultat est Non confirmé, réessayez après avoir vérifié les restrictions du navigateur et la connectivité. Pour interpréter un résultat manquant, tenez compte des paramètres de confidentialité que vous avez volontairement activés.

Lire l’état avant l’adresse

L’aboutissement et la comparaison répondent à des questions différentes. La collecte des candidats peut se terminer sans exposer d’adresse publique, ou s’arrêter tôt après n’avoir exposé qu’une partie de la liste.

Exemple pas à pas avec une adresse supplémentaire

Prenons un exemple : après la connexion à un VPN, HTTP confirme 198.51.100.24, tandis que WebRTC observe aussi 203.0.113.42. Ces deux adresses sont réservées à la documentation. Si vous aviez enregistré 203.0.113.42 avant de connecter le VPN, la réapparition de cette adresse justifie d’examiner le chemin WebRTC. Si vous n’avez pas enregistré de connexion de référence directe, l’outil ne peut pas établir que l’adresse supplémentaire appartient à votre connexion domestique.

Regardez d’abord si la collecte s’est terminée. Une adresse supplémentaire reste une observation utile quand la collecte dépasse le délai, mais la liste peut être incomplète. Vérifiez ensuite les exclusions de navigateur et les recommandations WebRTC de votre VPN, répétez le même test et comparez les résultats. Si vous contactez le support, indiquez le libellé d’état et l’heure du test, ainsi que le schéma d’adresses observé. Évitez de tirer d’un candidat supplémentaire une conclusion sur votre localisation ou votre identité : IPNixa n’en déduit ni une localisation cachée de votre domicile ni un verdict sur votre fournisseur VPN.

Pourquoi l’absence d’adresse publique n’est pas concluante

Un navigateur peut n’exposer que des candidats locaux, masquer les détails d’adresse ou ne pas réussir à joindre le service STUN. Ces cas peuvent être cohérents avec des réglages de confidentialité, mais ils ne disent rien de ce qui se passerait dans un autre navigateur, lors d’un autre appel ou dans une autre application.

Pour aller plus loin, répétez le test dans les mêmes conditions réseau et examinez la comparaison IPv4/IPv6 complète. Les fuites DNS nécessitent un service de test distinct, doté de son propre serveur DNS faisant autorité. La classification du fournisseur VPN et l’exposition de l’empreinte du navigateur répondent elles aussi à d’autres questions.