Explication du test de fuite VPN — WebRTC vs DNS vs IP (ce que les pages Web peuvent voir)

Une fuite VPN est frustrante car elle va à l'encontre de l'attente selon laquelle tout le trafic sort magiquement ailleurs sous une seule adresse IP. En pratique, les fuites se divisent en trois catégories dont les analystes parlent constamment : la visibilité de l'IP sur les transports HTTP, les chemins UDP exposés via WebRTC ICE, et les requêtes DNS qui contournent le résolveur du tunnel. Savoir ce que les pages ordinaires peuvent diagnostiquer vous aide à cibler vos efforts — le JavaScript du navigateur excelle avec les signaux HTTPS et ICE, mais peine avec les tests DNS faisant autorité.

Votre navigateur affiche régulièrement l'adresse que les serveurs voient lors des requêtes connectées en TLS. Cette donnée — parfois complétée par des en-têtes de CDN — constitue le cœur des widgets génériques « quelle est mon IP ? ».

Ce que WebRTC collecte et pourquoi srflx est important

Les connexions entre pairs (peer connections) négocient les chemins de médias ou de données à l'aide de l'Interactive Connectivity Establishment (ICE). Chaque candidat est une route potentielle : adresses de l'hôte local ou privées (host), résultats réflexifs de NAT symétrique issus de l'interaction avec STUN (srflx), relais via TURN (relay), et chemins visibles par les pairs appris (prflx).

Les lignes srflx sont importantes pour la recherche de fuites car leur construction envoie des sondes UDP à une infrastructure STUN coopérative. Les valeurs IP réflexives doivent correspondre au point de terminaison public que votre NAT en amont (ou tunnel) expose pour l'UDP sortant — pas nécessairement identique à l'adresse visible par TCP de HTTPS, en particulier lorsque les routeurs traitent les protocoles différemment — mais des divergences importantes méritent d'être examinées.

Les navigateurs modernes exposent progressivement des enveloppes de candidats typées ; les chaînes SDP restent l'alternative de compatibilité (marqueur typ srflx plus IPv4 intégrée). Les fragments SDP contenant de l'IPv6 peuvent être plus difficiles à identifier sans une analyse approfondie ; combinez la comparaison automatique avec les suites de tests de fuite des fournisseurs lorsque l'ambiguïté de l'IPv6 est importante.

Heuristique de comparaison pratique

Exécutez une courte collecte ICE en parallèle avec la référence HTTPS :

Fuites DNS — le fossé d'infrastructure

Historiquement, les fuites DNS signifiaient que « le résolveur de mon FAI continuait à interroger les serveurs faisant autorité pour les noms d'hôte du tunnel ». Prouver l'identité du résolveur nécessite des étiquettes uniques déléguées sous des domaines de mesure — ce que des pages passives ne peuvent pas inventer par magie sans la coopération des opérateurs DNS.

Des conseils responsables restent importants : insistez sur les options de verrouillage DNS / résolveur exclusif du VPN, sécurisez les flux sortants 53/tcp/udp sur le pare-feu, auditez les options DHCP, examinez les configurations de systemd-resolved (Linux), et évitez les exclusions de split-tunneling qui laissent accidentellement Slack ou les mises à jour du navigateur en clair.

Les outils basés uniquement sur le navigateur peuvent néanmoins vous enseigner les requêtes DNS-over-HTTPS contrôlées afin que vous compariez consciemment les réponses visibles du résolveur — par exemple en utilisant notre page complémentaire Quel est mon DNS après avoir configuré délibérément le DoH. Ce flux pédagogique est indépendant de la certification exhaustive des fuites.

Pourquoi les kill switches complètent les sondes JavaScript

Les kill switches du système d'exploitation coupent la sortie hors VPN lorsque les tunnels tombent — fermant ainsi les fenêtres opportunistes par lesquelles le DNS ou des paquets UDP égarés s'échappent. Les scripts ne peuvent pas modifier les tables de routage de l'hôte ; associer des vérifications automatisées de l'interface graphique à des outils de test natifs du fournisseur reste la meilleure pratique en matière de modélisation des menaces — et pas seulement le confort du consommateur.

Extrait de code : structure ICE minimale (pédagogique)

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});
pc.createDataChannel("probe");
pc.onicecandidate = (evt) => {
  const cand = evt.candidate;
  if (!cand) return;
  console.log(cand.type, cand.candidate ?? cand.address);
};
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Le code de production ajoute des minuteries délimitées, des solutions de repli SDP en l'absence d'adresse (address), des verrous de concurrence, des textes de confidentialité concis et un langage nuancé (« signal possible » plutôt qu'une réussite/échec binaire).

Quand une coche verte ment encore

Le NAT symétrique ne produit parfois aucun srflx en quelques secondes, même si votre VPN est fonctionnel — l'absence de données ICE est non concluante et ne constitue pas une preuve de sécurité. Les entreprises peuvent utiliser des serveurs mandataires (proxies) pour le trafic HTTPS tout en ignorant l'UDP, ce qui fausse les comparaisons à moins de contrôler la politique réseau. Les chemins IPv6 peuvent différer de l'IPv4 ; si votre client VPN ne gère qu'un seul protocole, vous devez inspecter les deux explicitement.

Les exclusions de tunnel divisé (jeux, visioconférences, IP SaaS d'entreprise) sont volontairement acheminées en dehors du tunnel — qualifier cela d'« échec » est un contresens. Les utilisateurs doivent corréler les résultats du navigateur avec le tableau de bord du VPN, les journaux du pare-feu ou les captures de paquets lorsque les enjeux sont importants (journalisme, questions juridiques, accès à distance réglementé).

Les outils de pistage (fingerprinters) recoupent les indices IP avec des signaux non liés — WebGL, polices de caractères, audio — de sorte que la simple sécurisation de WebRTC ne supprime pas le risque de suivi. Combinaison de vérifications de fuites avec des guides de sécurisation du navigateur et des habitudes de l'ère HTTPS Everywhere (désormais largement activées par défaut).

Ouvrez Quel est mon VPN / Ai-je une fuite ? pour une comparaison immédiate HTTPS vs WebRTC sur ce domaine, consultez Quelle est mon IP / Quel est mon FAI / Quelle est ma latence / Test de vitesse Internet pour le contexte réseau, et utilisez Quel est mon DNS si vous souhaitez effectuer des requêtes de résolveur en direct — sachant que l'identification du DNS nécessite toujours les outils natifs de votre VPN pour une preuve faisant autorité.