Fuite DNS dans un VPN : comment vérifier et résoudre

Vous avez activé le VPN, mais le fournisseur voit quand même que vous accédez à YouTube ou Instagram. Cela semble être de la paranoïa — jusqu'à ce que vous vérifiiez. La fuite DNS est l'une des raisons les plus courantes pour lesquelles un VPN protège moins bien qu'il n'y paraît. Si vous rencontrez des problèmes de stabilité avec des sites bloqués ou si vous voulez simplement vous assurer de votre sécurité —Fuite DNS VPN : solution cette problème existe, et elle est plus simple que vous ne le pensez.

Qu'est-ce qu'une fuite DNS et pourquoi est-elle dangereuse en Russie

DNS est le carnet d'adresses d'Internet. Lorsque vous tapez instagram.com, votre appareil demande d'abord au serveur DNS : « quelle est l'adresse IP de ce domaine ? ». Ce n'est qu'ensuite que la connexion s'établit. Le problème est que le VPN chiffre la connexion elle-même, mais la requête DNS peut passer à côté du tunnel — directement vers le serveur de votre fournisseur.

Conclusion : le contenu est chiffré, mais le fait que vous ayez accédé au domaine telegram.org ou youtube.com ne l'est pas.

Comment fonctionnent les requêtes DNS avec un VPN activé

Idéalement, cela devrait fonctionner ainsi : appareil → tunnel VPN chiffré → serveur DNS du fournisseur VPN → site. La requête passe par le tunnel, le fournisseur en Russie ne voit qu'un flux chiffré vers l'adresse IP du serveur VPN et rien de plus.

Mais si quelque chose ne va pas — le système d'exploitation envoie la requête DNS directement, avant que le tunnel n'ait le temps de l'intercepter. Ou parallèlement au tunnel. C'est ce qu'on appelle une fuite.

Pourquoi le DPI et le fournisseur voient les domaines même à travers un VPN

Les fournisseurs russes utilisent activement le DPI (Deep Packet Inspection) — une technologie d'inspection approfondie des paquets. Les TSPU, que Roskomnadzor a obligés à installer chez les fournisseurs, analysent le trafic précisément au niveau des requêtes DNS, entre autres.

Si votre requête DNS est envoyée en clair au serveur du fournisseur, le système DPI voit le domaine. Ensuite, il y a blocage ou throttling, ce fameux ralentissement de YouTube, qui pousse beaucoup de gens à utiliser un VPN. Cela crée un cercle vicieux : vous avez un VPN, mais le ralentissement persiste.

Quels sont les risques d'une fuite DNS lors du contournement des blocages du RKN

Le fournisseur obtient une liste de domaines auxquels vous accédez. Cela suffit pour appliquer un blocage même avec un VPN actif. Le trafic lui-même est chiffré — ils ne savent pas ce que vous regardiez sur YouTube, mais ils savent que vous y êtes allé, et peuvent ralentir ou bloquer la connexion au niveau de la réponse DNS.

Pour ceux qui utilisent un VPN précisément pour contourner les blocages d'Instagram, Facebook, TikTok, Twitter/X ou Telegram — la fuite DNS annule pratiquement la protection.

Comment vérifier une fuite DNS en une minute

La vérification prend littéralement une minute. Activez le VPN, ouvrez votre navigateur et suivez les instructions ci-dessous. Aucune connaissance spéciale n'est nécessaire.

Test sur dnsleaktest.com et browserleaks.com

Le moyen le plus simple est de se rendre surdnsleaktest.com avec une connexion VPN active. Le site montre quels serveurs DNS traitent vos requêtes en ce moment. Cela fonctionne de la même manière surbrowserleaks.com/dns — il y a un peu plus de détails sur la configuration du navigateur.

Une autre option est —ipleak.net. Il affiche immédiatement l'adresse IP, DNS et WebRTC sur une seule page, ce qui est pratique pour un contrôle rapide et complet.

Quelle est la différence entre le test Standard et le test Étendu

Sur dnsleaktest.com, il y a deux boutons : Test standard et Test étendu. Le test standard effectue environ 6 requêtes, le test étendu — 36. La différence est importante : lors du test standard, certaines fuites ne se manifestent pas, car le système d'exploitation a le temps de mettre en cache les requêtes ou le répartiteur les envoie accidentellement par le tunnel.

Lancez toujours le test étendu. Cela prend environ 20 secondes, mais le résultat est fiable.

Comment lire le résultat : quels IP et pays devraient être présents

Après le test, vous verrez une liste de serveurs DNS avec des adresses IP et des géolocalisations. Si vous vous êtes connecté à un serveur VPN en Allemagne — la liste devrait contenir des serveurs DNS allemands ou neutres de votre fournisseur VPN.

Si la liste contient une adresse IP russe ou un serveur avec le nom de votre fournisseur (par exemple, dns.mts.ru ou quelque chose de similaire en géolocalisation) — vous avez une fuite. C'est une confirmation directe que les requêtes DNS passent à côté du tunnel.

Vérification supplémentaire pour une fuite WebRTC

WebRTC est une histoire à part. Les navigateurs comme Chrome et Firefox l'utilisent pour les appels vidéo, et il peut révéler votre véritable IP même avec un VPN actif. Vous pouvez vérifier cela surbrowserleaks.com/webrtc.

Si vous voyez votre véritable IP russe à côté de l'IP VPN — il faut désactiver WebRTC dans le navigateur. Dans Firefox, cela se fait via about:config → media.peerconnection.enabled → false. Dans Chrome, il est plus simple d'installer l'extension uBlock Origin avec l'option de blocage de WebRTC activée.

Comment résoudre les fuites DNS sur différents appareils

Il n'y a pas de solution universelle — chaque plateforme a ses spécificités. Ci-dessous, les étapes concrètes pour chaque appareil.

Windows : paramètres de l'adaptateur et option Bloquer les DNS externes

Sous Windows, le problème est souvent lié au fait que le système continue d'envoyer des requêtes DNS via l'adaptateur réseau physique en parallèle avec le VPN. Il y a deux solutions.

Première — si vous avez un client OpenVPN, ajoutez dans la configuration la ligneblock-outside-dns. Cela bloque les DNS en dehors du tunnel au niveau de la Windows Filtering Platform. Cela fonctionne de manière fiable, testé.

Deuxième — entrer manuellement les DNS dans les paramètres de l'adaptateur VPN : Panneau de configuration → Connexions réseau → adaptateur VPN → Propriétés → IPv4 → entrer les DNS du fournisseur VPN (généralement indiqué dans la documentation). En même temps, dans les paramètres des autres adaptateurs (Wi-Fi, Ethernet), retirez le DNS automatique pour que le système ne s'y réfère pas en cas de panne du tunnel.

Kill switch — obligatoire. La plupart des clients VPN normaux (Mullvad, ProtonVPN, NvoVPN) l'ont dans les paramètres. Sans cela, en cas de brève interruption du VPN, le système passe immédiatement à une connexion directe, et les DNS vont chez le fournisseur.

Android : DNS privé et comportement des différentes applications VPN

Android 9+ a ajouté une fonction système DNS privé (DNS-over-TLS). Cela semble être une protection — mais c'est justement cela qui cause souvent des fuites. Le DNS privé fonctionne au niveau système et peut contourner le tunnel VPN.

Vérifiez : Paramètres → Réseau → Avancé → DNS privé. Si "Automatique" est sélectionné ou si une adresse tierce est indiquée — c'est une fuite potentielle avec le VPN actif. Lors de l'utilisation d'une application VPN avec son propre résolveur DNS (comme la plupart des clients normaux), il est préférable de passer le DNS privé en mode "Désactivé" ou "Off".

De plus : certaines applications Android comme Psiphon ou de simples clients proxy ne proxifient que le trafic HTTP, mais pas le DNS. Le résultat — une fuite classique. Utilisez un client VPN complet avec le mode "Tout le trafic".

iPhone/iOS : particularités des profils et iCloud Private Relay

Sur iOS, le VPN est généralement configuré via des profils (.mobileconfig) ou via des clients intégrés. La plupart des applications VPN décentes sur iOS gèrent le DNS correctement — elles le tunnelisent via leur serveur.

Mais il y a un détail :iCloud Private Relay. Si vous avez un abonnement iCloud+, Private Relay peut être activé, et il traitera le DNS indépendamment du VPN. Lorsqu'ils fonctionnent simultanément, les résultats du test DNS deviennent imprévisibles — vous voyez soit les serveurs Apple, soit les serveurs VPN.

Solution : lors de l'utilisation d'un VPN, désactivez iCloud Private Relay. Paramètres → [votre identifiant Apple] → iCloud → Private Relay → désactiver. Ils résolvent des tâches similaires, mais s'entravent mutuellement.

macOS : configuration manuelle des DNS et vérification

Sous macOS, les DNS sont configurés séparément pour chaque interface réseau. Si le VPN crée une interface virtuelle (utun0 et similaires), il faut s'assurer que le DNS système pour le Wi-Fi et l'Ethernet ne le remplace pas.

Préférences système → Réseau → sélectionner Wi-Fi → Avancé → DNS. Si des serveurs du fournisseur y sont indiqués — remplacez-les par les DNS de votre service VPN ou laissez-les temporairement vides avec le VPN actif. Après les modifications, redémarrez le VPN et refaites le test sur dnsleaktest.com.

Routeur et Smart TV/Apple TV : DNS au niveau réseau

Smart TV, Apple TV, PlayStation, Xbox — ils n'ont pas leurs propres clients VPN. Vous ne pouvez pas installer d'application sur un téléviseur Samsung. Le seul moyen de protéger ces appareils est de configurer le VPN et le DNS au niveau du routeur.

Sur les routeurs avec des firmwares OpenWRT, DD-WRT ou Keenetic (populaire en Russie), vous pouvez installer un client VPN directement sur le routeur et indiquer les DNS du fournisseur VPN dans les paramètres du serveur DHCP. Ainsi, tous les appareils du réseau, y compris les téléviseurs et les consoles, utilisent automatiquement le DNS sécurisé.

Détail important : si vous avez un double NAT (par exemple, routeur du fournisseur + votre routeur) — le DNS configuré sur le routeur du fournisseur peut écraser vos paramètres. Assurez-vous que votre routeur fonctionne en mode routeur et non en pont, et qu'il distribue le DHCP aux appareils du réseau.

Dépendance de la fuite au protocole : WireGuard, OpenVPN, IKEv2, VLESS

Le protocole a son importance — et tous ne traitent pas le DNS de la même manière. Analysons honnêtement, sans marketing.

Pourquoi WireGuard et OpenVPN se comportent différemment

OpenVPN avec une configuration correcte (paramètreblock-outside-dns sous Windows, option redirect-gateway def1 dans la configuration) tunnelise tout le trafic y compris le DNS. C'est une option éprouvée, cela fonctionne de manière prévisible.

WireGuard est légèrement différent en architecture — il ne prend pas en charge block-outside-dns nativement. Mais la plupart des clients WireGuard (Mullvad App, WireGuard officiel pour Windows) mettent en œuvre cette protection au niveau de l'application. Dans la configuration de WireGuard, il y a le paramètreDNS = dans la section [Interface] — s'il est spécifié, le client utilise le DNS indiqué et bloque le système. S'il n'est pas spécifié — la fuite est presque garantie.

IKEv2 tunnelise normalement le DNS lors de l'utilisation de clients natifs sur Windows et iOS. Sur Android, c'est un peu plus compliqué — cela dépend de l'implémentation.

Shadowsocks et VLESS/XRay : DNS en dehors du tunnel principal

C'est là que la plupart des articles se taisent. Shadowsocks et VLESS/XRay sont des protocoles proxy, pas de véritables VPN. Ils contournent très bien le DPI et les blocages de la Roskomnadzor, surtout en combinaison avec l'obfuscation. Mais par défaut, ils proxient le trafic des applications (TCP/UDP), et les requêtes DNS passent directement par le résolveur système.

Si vous utilisez des clients comme v2rayN, Nekobox ou sing-box avec VLESS/XRay — vous devez configurer les règles DNS séparément. Dans sing-box, cela se fait dans la section dns de la config : vous indiquez le serveur (par exemple, 1.1.1.1 via proxy) et les règles de routage DNS. Sans cela — fuite classique, même si tout le trafic HTTP passe par le proxy.

Amnezia et obfuscation : quel impact dans le contexte DNS

AmneziaVPN et d'autres outils d'obfuscation (obfs4, Cloak, GoodbyeDPI) cachent la signature du trafic VPN au DPI. Cela aide à contourner le blocage du protocole VPN lui-même, mais ne résout pas le problème de la fuite DNS.

Amnezia est construit sur WireGuard ou OpenVPN — donc tout ce qui a été dit sur ces protocoles s'applique ici aussi. L'obfuscation fonctionne au niveau de transport, le DNS est une couche séparée. Si le protocole de base est correctement configuré, le DNS passera par le tunnel. Sinon — il passera à côté, et l'obfuscation n'aidera en rien.

Que choisir si la protection contre les fuites est importante

Pour une protection maximale du DNS — des protocoles VPN classiques avec un client correctement configuré. WireGuard avec un DNS spécifié dans la config ou OpenVPN avec block-outside-dns — les deux fonctionnent bien. Certains services, y compris NvoVPN, fournissent leur propre DNS à l'intérieur du tunnel, ce qui élimine la nécessité de le configurer manuellement.

Si vous utilisez VLESS/XRay — n'oubliez pas de configurer le routage DNS dans sing-box ou v2ray. Ce n'est pas compliqué, mais cela nécessite une étape supplémentaire dans la config.

Ce qui NE fonctionne PAS et erreurs fréquentes

Au fil des ans, plusieurs mythes persistants se sont accumulés. Voici ce qui ne fonctionne vraiment pas — et pourquoi.

Changer le DNS en 8.8.8.8 ne ferme pas la fuite

C'est sans doute le conseil le plus répandu sur Internet. « Spécifiez le DNS Google 8.8.8.8 ou Cloudflare 1.1.1.1 — et il n'y aura pas de fuite ». C'est faux.

Changer le serveur DNS ne change que à qui votre requête est envoyée. Mais si la requête sort du tunnel — elle passe quand même par le réseau du fournisseur en clair, et le DPI la voit. Vous avez simplement changé le destinataire de dns.provider.ru à 8.8.8.8, mais le chemin passe toujours par le fournisseur. Ce n'est pas une solution.

Extensions de navigateur au lieu de VPN système

Les extensions comme « VPN pour Chrome » ou « Proxy pour Firefox » ne protègent que le trafic du navigateur lui-même. Les requêtes DNS système, les requêtes d'autres applications, les messageries — tout cela passe à côté. L'extension donne un faux sentiment de protection.

Il en va de même pour les bloqueurs WebRTC — ils ne ferment qu'une fuite spécifique dans le navigateur, mais n'affectent en rien le DNS système.

Kill switch désactivé et interruptions de connexion

Le kill switch n'est pas une fonctionnalité optionnelle. C'est un élément de protection critique. Lors d'une brève interruption du VPN (changement de réseau, signal Wi-Fi instable, changement d'IP), le système d'exploitation bascule immédiatement vers une connexion directe. La requête DNS est envoyée au fournisseur — tout, la fuite est enregistrée.

L'interruption peut durer 2-3 secondes. Suffisant pour que la requête DNS pour le site ouvert soit envoyée directement. Si votre client a un kill switch — activez-le. Si le client ne fournit pas de kill switch — cherchez un autre. Voilà à quoi ressemble la fuite DNS VPN : solution au niveau des paramètres.

Et une autre situation sous-estimée : un filtre DNS d'entreprise ou un contrôle parental configuré sur l'appareil. Ces outils redéfinissent souvent le DNS système et fonctionnent indépendamment du VPN. Si un profil MDM ou une application de contrôle parental avec son propre DNS est installé sur l'appareil — il interceptera les requêtes indépendamment des paramètres VPN.

Si vous avez compris les paramètres, lancé le test étendu et vérifié que les serveurs DNS appartiennent à votre fournisseur VPN, et non à un opérateur russe — la fuite DNS VPN : solution trouvée et le problème est résolu. Vérifiez cela périodiquement, surtout après la mise à jour des applications ou du système.