Fuites DNS, WebRTC et IPv6 : pourquoi un VPN actif peut quand même révéler votre IP réelle
Un VPN actif ne signifie pas systématiquement une protection totale. L'icône verte de l'application, le statut "connecté" affiché à l'écran : rien de tout cela ne garantit que l'intégralité de votre trafic passe réellement par le tunnel chiffré. Trois mécanismes système précis peuvent laisser filtrer des informations en dehors de ce tunnel, sans qu'aucune alerte ne s'affiche : les fuites DNS, les fuites WebRTC et les fuites IPv6. Comprendre comment ils fonctionnent est la seule façon de vérifier, plutôt que de simplement espérer, qu'un VPN fait réellement ce qu'il prétend faire.
Chaque fois que vous saisissez une adresse dans un navigateur, votre appareil doit d'abord traduire ce nom de domaine en adresse IP via une requête DNS. Sur une connexion sans VPN, cette requête part vers le résolveur DNS configuré par votre fournisseur d'accès à Internet ou votre routeur. Lorsqu'un VPN est correctement configuré, il doit rediriger ces requêtes DNS à travers son propre tunnel, vers ses propres résolveurs.
Le problème survient lorsque le système d'exploitation continue d'envoyer certaines requêtes DNS au résolveur habituel, en dehors du tunnel, alors même que le reste du trafic est bien chiffré. Cela peut se produire pour plusieurs raisons techniques : une configuration réseau qui conserve les serveurs DNS du routeur en priorité, un système d'exploitation qui interroge plusieurs résolveurs en parallèle pour accélérer la navigation, ou une application VPN qui ne force pas explicitement le routage DNS au niveau du système.
La conséquence est directe : même si le contenu de vos échanges reste chiffré, votre fournisseur d'accès à Internet peut voir la liste des noms de domaine que vous consultez. Pour un observateur situé à ce niveau du réseau, cela revient à connaître les sites que vous visitez, minute par minute, malgré la présence apparente d'un VPN.
WebRTC (Web Real-Time Communication) est une technologie intégrée par défaut dans la plupart des navigateurs modernes, conçue pour permettre des communications audio, vidéo et de partage de données en temps réel directement entre deux navigateurs, sans passer par un serveur intermédiaire. Elle est utilisée par de nombreux services de visioconférence et de chat en ligne.
Pour établir cette connexion directe entre deux machines, WebRTC utilise un mécanisme appelé ICE (Interactive Connectivity Establishment), qui collecte plusieurs "candidats" d'adresses réseau : l'adresse locale de l'appareil, mais aussi son adresse IP publique, obtenue via des serveurs STUN. Le problème est que cette collecte d'adresses se fait au niveau du navigateur, indépendamment du tunnel VPN. Un site web malveillant, ou simplement un script de suivi publicitaire, peut déclencher cette négociation ICE en arrière-plan et récupérer votre adresse IP publique réelle, même si votre trafic HTTP classique passe bien par le VPN.
Cette fuite est particulièrement insidieuse car elle ne dépend pas de la qualité du chiffrement du VPN ni de sa politique de journalisation : elle contourne entièrement le VPN au niveau applicatif, dans le navigateur. Un VPN peut être irréprochable sur le plan du chiffrement et de l'absence de journaux, et laisser malgré tout fuiter l'IP réelle par ce canal si aucune protection spécifique n'est mise en place.
La majorité des VPN grand public ont été conçus historiquement pour chiffrer le trafic IPv4. Or, un nombre croissant de fournisseurs d'accès à Internet proposent désormais une connectivité IPv6 en parallèle, et la plupart des systèmes d'exploitation appliquent un mécanisme de préférence, souvent appelé "Happy Eyeballs", qui privilégie IPv6 lorsque les deux protocoles sont disponibles.
Si un VPN ne tunnelise que le trafic IPv4, sans bloquer ni acheminer explicitement l'IPv6, alors toute requête pouvant emprunter une route IPv6 native sortira directement par la connexion de votre fournisseur d'accès, en clair, en dehors du tunnel chiffré. L'utilisateur voit son VPN connecté et actif, alors qu'une partie significative de son trafic réseau ne passe jamais par lui.
Ce type de fuite est d'autant plus difficile à repérer qu'il ne provoque aucun dysfonctionnement visible : la navigation continue de fonctionner normalement, puisque le trafic IPv6 non tunnelisé atteint sa destination sans problème, simplement sans la protection attendue.
Il n'est pas nécessaire de dépendre uniquement des promesses commerciales d'un fournisseur pour évaluer ce risque. Une méthodologie de vérification simple, réalisable par n'importe quel utilisateur, repose sur une comparaison avant/après connexion :
Adresse IP publique : relevez votre adresse IP publique et le résolveur DNS utilisé avant d'activer le VPN, puis à nouveau une fois connecté. L'adresse IP doit changer et correspondre à celle du serveur VPN choisi ; le résolveur DNS affiché doit correspondre à celui du fournisseur VPN, jamais à celui de votre fournisseur d'accès habituel.
Test en navigation privée avec et sans WebRTC : en désactivant temporairement WebRTC dans les paramètres avancés du navigateur (ou en testant sur un navigateur qui le bloque par défaut), comparez si une adresse IP différente de celle du VPN apparaît lorsqu'un site tente une négociation ICE. Une différence indique une fuite.
Contrôle IPv6 : désactivez temporairement IPv6 au niveau du système d'exploitation et vérifiez si votre navigation change de comportement. Si la connexion fonctionnait déjà sans IPv6 activé pendant que le VPN était censé tout tunneliser, cela suggère que du trafic IPv6 non protégé transitait auparavant en parallèle du tunnel.
Ces trois vérifications doivent idéalement être répétées régulièrement, et pas uniquement au moment de la souscription : une mise à jour du système d'exploitation, un changement de routeur ou une mise à jour de l'application VPN peuvent modifier ce comportement sans avertissement.
Face à ces trois mécanismes, un fournisseur VPN rigoureux doit apporter des réponses techniques précises, et non de simples déclarations marketing :
DNS propre au tunnel : les requêtes DNS doivent être forcées à transiter exclusivement par les résolveurs du fournisseur VPN, via l'interface réseau virtuelle créée par le tunnel, sans possibilité de retour vers le résolveur du routeur ou du fournisseur d'accès.
Protection WebRTC explicite : soit au niveau de l'application VPN elle-même, soit via un blocage recommandé au niveau du navigateur, la négociation ICE ne doit jamais pouvoir révéler une adresse IP différente de celle attribuée par le VPN.
Gestion explicite de l'IPv6 : deux approches sont acceptables sur le plan technique, soit le tunnel IPv6 est pris en charge au même titre que l'IPv4, soit le trafic IPv6 est intégralement bloqué au niveau système tant que le VPN est actif. L'absence de toute mention sur ce point dans la documentation technique d'un fournisseur est en elle-même un signal d'alerte.
Kill switch comme filet de sécurité : au-delà de la prévention de ces trois fuites précises, un kill switch fiable reste la dernière ligne de défense en cas de coupure inattendue du tunnel, en bloquant tout trafic tant que la connexion VPN n'est pas rétablie.
Ces éléments techniques ont aussi un lien direct avec la question de la juridiction du fournisseur VPN : un résolveur DNS opéré par le VPN lui-même, plutôt que délégué à un tiers, n'a de sens en matière de confidentialité que si le pays d'hébergement de ce résolveur applique un cadre légal cohérent avec l'absence de conservation des journaux.
La conclusion pratique de ces trois mécanismes est simple : la confiance accordée à un VPN ne doit jamais reposer uniquement sur son statut affiché "connecté". Les fuites DNS, WebRTC et IPv6 partagent un point commun troublant : elles sont chacune invisibles pour l'utilisateur tant qu'il ne procède pas à une vérification active. Un VPN qui fonctionne parfaitement pendant des mois peut se retrouver, après une simple mise à jour système, exposé à l'une de ces trois fuites sans qu'aucun indicateur ne change dans l'interface de l'application.
Intégrer ces vérifications à une routine régulière, plutôt qu'à un test unique réalisé au moment de l'installation, est ce qui distingue une utilisation réellement sécurisée d'une simple impression de sécurité.