Cette page compare deux signaux qui devraient correspondre lorsqu'un VPN fait ce que vous attendez de lui : l'adresse IPv4 vue par mon gestionnaire HTTPS sur /api/ip et les points de terminaison publics serveur réflexif (srflx) que votre navigateur détecte en effectuant une recherche rapide ICE WebRTC auprès du pool public STUN de Google (généralement stun.l.google.com:19302). J'ai ajouté cette double vérification après qu'un ami utilisant un VPN grand public bien connu a vu s'afficher Londres sur tous les sites du type "quelle est mon IP", tout en continuant à divulguer son ASN d'origine dans un appel vidéo parce que les paquets UDP vers STUN sortaient du tunnel alors que le trafic HTTPS TCP y restait. Ci-dessous, j'explique comment cela se produit, à quoi ressemble un résultat correct et pourquoi aucun onglet de navigateur ne peut remplacer complètement un outil de test DNS natif.
Ce que cet outil vérifie (et ce qu'il ne peut pas prouver)
La ligne Référence HTTP reflète l'adresse client que Cloudflare transmet à mon serveur d'origine (via CF-Connecting-IP ou équivalent). C'est l'adresse que les systèmes de comptabilité, les scores de fraude et la plupart des sites web observent pour les chargements de pages ordinaires sur TLS. La liste WebRTC srflx regroupe les adresses IPv4 extraites des candidats ICE dont le type est srflx, ce qui signifie que le serveur STUN a vu votre paquet UDP arriver de ce point de terminaison public. Lorsque les deux chemins utilisent la même sortie VPN, les adresses doivent concorder au sein de la même famille de versions IP.
Il s'agit d'une heuristique, pas d'une certification. Les logiciels malveillants, les règles de tunnel fractionné (split-tunneling) qui ne répertorient que certains exécutables, les portail captifs ou les fuites exclusivement IPv6 en dehors du tunnel peuvent tous produire des cas particuliers ambigus. L'interface les qualifie alors d'inconclusifs plutôt que de succès ou d'échec binaire. Prenez ce résultat comme une piste : en cas d'incohérence, reproduisez le test avec les outils natifs de votre fournisseur VPN et effectuez une capture de paquets avant de lui signaler un bug.
Comment les fuites WebRTC diffèrent des chargements de pages normaux
La négociation WebRTC s'appuie sur l'algorithme ICE (Interactive Connectivity Establishment) défini dans la RFC 8445. Une partie de la procédure ICE consiste à envoyer des requêtes de liaison STUN définies dans la RFC 5389 afin que les points de terminaison découvrent leurs adresses réflexives à travers le NAT. Les navigateurs transmettent également des noms d'hôte mDNS pour protéger la vie privée sur les réseaux locaux ; lorsque ceux-ci sont actifs, vous pouvez voir des noms opaques du type .local jusqu'à l'arrivée des candidats srflx. Si votre VPN achemine le trafic web TCP dans le tunnel mais laisse l'UDP repasser par le fournisseur d'accès à cause d'une règle de pare-feu manquante, srflx peut exposer l'adresse de votre FAI alors que l'HTTPS affiche toujours le VPN. C'est le schéma classique de fuite WebRTC contre lequel mettent en garde les guides de confidentialité.
Les navigateurs modernes continuent de renforcer les réglages par défaut (interfaces muettes, obligation d'action utilisateur pour l'accès caméra, restriction des candidats d'hôte), mais ICE a toujours besoin de données réflexives pour fonctionner. La solution consiste rarement à "désactiver WebRTC globalement" ; il convient plutôt d'acheminer l'UDP par la même interface que le TCP ou d'utiliser un client VPN installant un pilote de noyau qui capture tous los protocoles IP.
Fuites DNS : pourquoi le navigateur ne peut pas tout voir
Une fuite DNS signifie que les requêtes de résolution de noms de domaine passent par un résolveur qui n'est pas celui prévu par votre VPN (généralement celui de votre FAI), alors que le trafic chiffré sort toujours par l'IP du VPN. Une détection complète utilise souvent des sous-domaines uniques pour qu'un serveur faisant autorité puisse journaliser quel résolveur a posé la question. Le JavaScript classique de même origine ne peut pas énumérer chaque socket du système d'exploitation ou chaque configuration locale ; c'est pourquoi ce site vous redirige vers Quel est mon DNS ? pour des requêtes DoH intentionnelles, et vers des testeurs de fuites natifs pour des réponses absolues.
L'IPv6 augmente les risques : si votre VPN ne tunnelise que l'IPv4 mais que votre OS préfère l'IPv6 pour certaines destinations, les requêtes AAAA et les connexions TCP suivantes peuvent contourner entièrement le tunnel. La correction consiste généralement à "activer l'IPv6 dans le VPN" ou à "bloquer l'IPv6 côté client jusqu'à ce que le fournisseur propose des sorties double pile", plutôt que de modifier des options au hasard dans le navigateur.
À quoi ressemble un résultat correct
L'adresse IP HTTPS et chaque adresse IPv4 srflx doivent correspondre à la plage de sortie annoncée par votre fournisseur VPN. Les réponses DNS (lorsque vous les testez délibérément) doivent provenir des résolveurs de votre fournisseur, et non de ceux de votre FAI. Le WebRTC ne doit afficher aucun srflx dans le délai imparti (NAT strict) ou afficher un srflx identique à l'IP du VPN. Toute divergence mérite une capture d'écran pour le support : indiquez l'horodatage, la ville sélectionnée et si le tunnel fractionné est activé pour les "applications de travail".
Des correctifs qui survivent à un redémarrage
Commencez par le client VPN : activez le bouton d'arrêt d'urgence (kill switch), désactivez le tunnel fractionné pour le navigateur de test et activez le verrouillage DNS du fournisseur s'il est disponible. Sur Firefox, les utilisateurs avancés vérifient dans about:config des clés comme media.peerconnection.ice.default_address_only, mais suivez de préférence les consignes de l'éditeur car les clés exactes varient selon les versions. Sous Windows, vérifiez que la métrique de l'adaptateur virtuel du VPN est inférieure à celle de l'adaptateur Wi-Fi pour que les routes par défaut s'appliquent en priorité.
Exemple de diagnostic Firefox (lecture seule ; ne modifiez que les valeurs que vous comprenez) :
about:webrtc
about:networking#dnsLa première page résume les sessions actives ; la seconde répertorie les entrées du cache DNS visibles par le navigateur, lo qui est utile pour diagnostiquer un portail captif ou des enregistrements SRV obsolètes.
Arguments de vente vs ce que vous pouvez réellement vérifier
La promesse "sans journaux" (no logs) n'est pas vérifiable de l'extérieur ; c'est un engagement juridique et opérationnel. La juridiction compte car les procédures judiciaires dépendent du siège social de l'entreprise. Les serveurs fonctionnant uniquement sur RAM limitent les traces physiques mais ne modifient pas la logique de routage. Ce que vous pouvez vérifier chez vous, c'est l'intégrité du routage (cette page), le choix des résolveurs (outil DNS), la prise en charge de l'IPv6 et l'efficacité du kill switch en coupant brutalement le processus VPN. Effectuez ces tests périodiquement de la même manière que vous vérifiez vos détecteurs de fumée.
Comparatif des types de fuites
| Type de fuite | Ce qui est exposé | Cause fréquente | Correctif pratique |
|---|---|---|---|
| WebRTC / ICE srflx | IP publique IPv4/IPv6 hors VPN | Flux UDP non acheminés dans le tunnel ; pare-feu auxiliaire inactif | Pilote noyau VPN ; désactivation du tunnel fractionné ; mise à jour client |
| DNS | Noms de domaine visibles par le résolveur du FAI | L'OS continue d'utiliser le DNS attribué par DHCP ; le DNS du VPN n'est pas prioritaire | Verrouillage DNS ; forcer DoT/DoH sur l'interface du VPN uniquement |
| IPv6 | Le flux IPv6 natif contourne le tunnel uniquement IPv4 | Le tunnel ne gère pas la v6 ; l'OS préfère les résolutions AAAA | Activer une sortie double pile ; ou désactiver l'IPv6 dans l'OS en attendant |
| Corrélation de trafic | Métadonnées de temps et de volume | Surveillance passive globale aux deux extrémités du VPN | Réseau Tor ou réseaux de routage en oignon à plus forte latence ; accepter l'impact sur le débit |
| Défaillance du Kill-switch | Trafic en clair lors des reconnexions | Crash du client ; transition veille/réveil ; règles de routage personnalisées | Mettre en place des règles de blocage au niveau de l'OS ; tester avec ping pendant la reconconnexion |
Foire aux questions (FAQ)
Qu'est-ce qu'une fuite WebRTC ?
C'est le cas où le protocole WebRTC ICE révèle une adresse IP publique ou un chemin UDP qui ne correspond pas à l'adresse utilisée par votre trafic HTTPS chiffré. Les candidats srflx proviennent directement du serveur STUN ; si celui-ci voit votre FAI alors que le site web voit votre VPN, votre navigateur effectue un routage fractionné involontaire au niveau du protocole.
Comment savoir si mon VPN fonctionne vraiment ?
Effectuez trois vérifications distinctes : l'IP HTTPS (ce site), la comparaison srflx (cette page) et un test DNS de résolveur (notre outil DNS ou le panneau de votre fournisseur). Si les trois concordent sur le VPN, vous avez la confirmation que la route par défaut a changé. Si l'un diverge, examinez les journaux avant de supposer que le VPN est en panne.
Pourquoi mon VPN génère-t-il des fuites DNS ?
Parce que les systèmes d'exploitation résolvent les noms avant ou en parallèle de l'activation du tunnel, et certains VPN n'enregistrent des routes que pour l'IPv4. Les serveurs DNS fournis par DHCP restent actifs dans systemd-resolved, NetworkManager ou les métriques réseau de Windows à moins que le VPN ne pousse de nouveaux résolveurs et n'augmente sa priorité.
Dois-je désactiver l'IPv6 pour mon VPN ?
La désactivation de l'IPv6 doit être une mesure temporaire de diagnostic, pas un choix durable. La bonne méthode est d'utiliser un VPN gérant l'IPv6 de bout en bout ou une configuration système bloquant le AAAA tant que le double pile n'est pas opérationnel. Désactiver l'IPv6 globalement peut bloquer des sites web modernes et compliquer les analyses.
Les VPN gratuits fuient-ils plus que les VPN payants ?
Le prix n'est pas le facteur déterminant, c'est l'implémentation technique qui compte. Certaines offres gratuites sont des versions allégées d'infrastructures payantes avec des profils de sécurité identiques ; d'autres se rémunèrent en collectant et vendant vos requêtes DNS, ce qui est pire qu'une simple fuite de route. Analyse le modèle de menace : un VPN de navigateur gratuit qui ne fait office de proxy que pour les onglets ne protégera jamais l'ensemble de votre système.
Outils connexes
Votre identité de base sans WebRTC : Quelle est mon IP ?. L'ASN et le fournisseur de réseau : Quel est mon FAI ?. Analyse du comportement du résolveur : Quel est mon DNS ?. Pour mesurer le RTT vers ce point d'accès après avoir changé de serveur : Quelle est ma latence ?.
Sources citées ci-dessus
- RFC 5389: Session Traversal Utilities for NAT (STUN)
- RFC 8445: Interactive Connectivity Establishment (ICE)
- W3C WebRTC: Spécification de l'API navigateur
- RFC 4787: Network Address Translation behavioral requirements