Accueil/Kill switch et fuites DNS

Kill switch et fuites DNS : les détails qui déterminent la protection réelle

Un VPN peut chiffrer parfaitement l'essentiel de son trafic et laisser malgré tout filtrer des informations sensibles par des voies annexes. C'est le paradoxe qu'il faut comprendre pour évaluer sérieusement un service qui affiche un chiffrement robuste : la solidité du tunnel principal ne garantit strictement rien sur l'étanchéité des chemins secondaires que son trafic continue d'emprunter en parallèle.

Ce qu'un kill switch fait exactement

Un tunnel VPN peut se rompre pour des raisons banales : changement de réseau Wi-Fi, mise en veille de l'appareil, instabilité momentanée de la connexion. Sans protection additionnelle, le système d'exploitation bascule alors automatiquement vers la connexion Internet directe, non chiffrée, souvent sans notification visible pour l'utilisateur qui continue de naviguer en pensant être protégé.

Le kill switch surveille en permanence l'état du tunnel VPN et coupe immédiatement l'accès réseau de l'appareil dès qu'une rupture est détectée, jusqu'au rétablissement de la connexion chiffrée. Cette coupure est délibérément brutale : mieux vaut une interruption temporaire de la connectivité qu'une fuite silencieuse de trafic non protégé pendant une reconnexion.

Les deux niveaux de kill switch, une nuance rarement expliquée

Un kill switch au niveau système coupe l'intégralité de la connexion Internet de l'appareil dès que le VPN se déconnecte, sans distinction entre applications. Un kill switch au niveau applicatif, plus fin, permet de ne bloquer que certaines applications désignées tout en laissant les autres continuer à fonctionner sans protection — utile pour ne pas interrompre un appel en cours, au prix d'une protection partielle pour tout ce qui n'est pas explicitement couvert par la règle.

Les fuites DNS, une brèche indépendante du chiffrement

Chaque fois qu'un appareil accède à un nom de domaine, il interroge au préalable un serveur DNS pour obtenir l'adresse IP correspondante. Sur une configuration réseau standard, cette requête part vers le serveur DNS fourni par le fournisseur d'accès local. Un VPN bien configuré redirige également ces requêtes DNS à travers le tunnel chiffré, vers son propre serveur DNS ou un serveur tiers de confiance.

Une fuite DNS survient lorsque cette redirection échoue silencieusement : le trafic applicatif principal continue de transiter par le tunnel chiffré, mais les requêtes DNS empruntent encore le chemin non protégé vers le serveur du fournisseur d'accès local. Le contenu des échanges reste invisible, mais la liste des domaines consultés devient reconstituable par quiconque observe ce trafic DNS résiduel — une fuite d'autant plus insidieuse qu'elle n'affecte pas la navigation de façon perceptible.

Le cas particulier de l'IPv6

De nombreux VPN, historiquement conçus autour du protocole IPv4, ne prennent pas systématiquement en charge le trafic IPv6 dans leur tunnel chiffré. Sur un appareil ou un réseau où l'IPv6 est actif, ce trafic peut alors emprunter une route directe, hors du tunnel VPN, sans que l'utilisateur en soit averti. Cette fuite fonctionne selon un mécanisme identique à la fuite DNS : le tunnel IPv4 reste parfaitement chiffré, pendant qu'une portion distincte du trafic contourne entièrement la protection.

Deux solutions coexistent chez les fournisseurs qui traitent sérieusement ce risque : bloquer intégralement le trafic IPv6 au niveau du pare-feu de l'application VPN, ou l'acheminer correctement à travers le tunnel au même titre que l'IPv4. La pire situation reste celle, encore fréquente, où le fournisseur ne fait ni l'un ni l'autre et laisse le trafic IPv6 filtrer sans aucun traitement, souvent parce que la prise en charge de l'IPv6 a simplement été négligée lors du développement initial de l'application plutôt que sciemment écartée.

Le split tunneling, une complexité supplémentaire à maîtriser

Le split tunneling (tunnellisation fractionnée) permet de choisir quelles applications passent par le tunnel VPN et lesquelles accèdent directement à Internet. Cette fonctionnalité répond à un besoin réel — accéder à un service local incompatible avec un VPN tout en gardant le reste du trafic protégé — mais elle introduit par construction une exception délibérée à la protection, distincte des fuites accidentelles décrites plus haut.

Le risque ne vient pas de la fonctionnalité elle-même, correctement documentée et utilisée intentionnellement, mais d'une configuration mal comprise : une règle de split tunneling trop large, ou un oubli de désactivation après un usage ponctuel, peut laisser hors du tunnel un trafic que l'utilisateur croyait protégé. Vérifier régulièrement la liste des applications exclues du tunnel, plutôt que de configurer cette règle une fois puis de l'oublier, évite ce glissement progressif.

Ce que révèle la documentation technique d'un fournisseur

La façon dont un fournisseur documente ces mécanismes en dit long sur son sérieux. Une documentation qui détaille précisément le comportement du kill switch selon les systèmes d'exploitation, explique la gestion de l'IPv6 sans l'éluder, et fournit une méthode reproductible pour tester l'absence de fuite, traite ces sujets comme des caractéristiques techniques à part entière plutôt que comme des cases à cocher sur une page de comparatif commercial.

À l'inverse, une page produit qui se contente de mentionner « kill switch intégré » sans aucun détail sur son fonctionnement précis, ou qui reste silencieuse sur la question de l'IPv6, ne permet pas de distinguer une implémentation robuste d'une fonctionnalité ajoutée a minima pour cocher une ligne dans un tableau comparatif. Ce silence documentaire constitue en lui-même une information, même s'il ne prouve rien de définitif sur la qualité réelle du produit.

Détecter soi-même ces défaillances

La vérification ne demande pas de compétence technique avancée. Un test de fuite DNS accessible en ligne affiche la liste des serveurs DNS effectivement contactés pendant une session avec le VPN actif ; la présence d'un serveur appartenant au fournisseur d'accès local plutôt qu'au VPN confirme la fuite. Le même principe s'applique à l'adresse IP affichée, à comparer entre une navigation sans VPN et une navigation VPN activé — une différence d'adresse confirme que le tunnel fonctionne, une adresse identique dans les deux cas signale un problème à corriger immédiatement.

Tester le kill switch exige une manipulation volontaire : couper la connexion Wi-Fi ou débrancher le câble réseau pendant que le VPN est actif, puis observer si l'accès Internet reste bloqué. Un test simple, mais que peu d'utilisateurs effectuent avant d'en avoir réellement besoin — ce qui revient à découvrir l'absence de protection au moment précis où elle aurait été utile.

Ce que ces défaillances ont en commun

Kill switch absent, fuite DNS et fuite IPv6 partagent une même caractéristique : ils n'affectent en rien la fluidité perçue de la navigation. Un utilisateur peut naviguer pendant des mois avec l'une de ces défaillances active sans jamais s'en rendre compte, précisément parce que rien dans l'expérience visible ne signale le problème. C'est cette invisibilité qui justifie une vérification active plutôt qu'une confiance fondée sur la seule absence de symptôme apparent, et qui explique pourquoi ces trois points méritent un contrôle systématique après chaque changement de fournisseur ou de configuration, pas seulement au moment de la souscription initiale.