La page consacrée au principe général du kill switch VPN mentionne que ce mécanisme peut échouer silencieusement à cause de deux angles morts précis : les fuites DNS et le trafic IPv6. Ces deux mécanismes méritent une explication détaillée, parce qu'ils illustrent une vérité plus générale : un kill switch surveille ce qu'on lui a demandé de surveiller, rien de plus, et ce périmètre est souvent plus étroit que ce que l'utilisateur imagine.
Chaque fois qu'un appareil doit accéder à un site web, il doit d'abord traduire le nom de domaine saisi en adresse IP, via une requête DNS envoyée à un résolveur. Sur une connexion sans VPN, cette requête part vers le résolveur configuré par le fournisseur d'accès à Internet ou par le routeur local. Lorsqu'un VPN fonctionne correctement, il doit rediriger ces requêtes DNS à travers son propre tunnel, vers ses propres résolveurs, au même titre que le reste du trafic.
Le problème survient quand le système d'exploitation continue d'envoyer certaines requêtes DNS au résolveur habituel, en dehors du tunnel, indépendamment du fait que le trafic applicatif principal soit bien chiffré et acheminé par le VPN. Cela peut se produire parce que le système interroge plusieurs résolveurs en parallèle pour accélérer la résolution, parce que la configuration réseau du routeur reste prioritaire pour ce type de requête spécifique, ou parce que le logiciel VPN ne force pas explicitement le routage DNS au niveau système.
Un kill switch, dans son fonctionnement le plus courant, surveille l'état du tunnel et la route du trafic principal. Il ne surveille pas nécessairement, de façon indépendante, le chemin emprunté par les requêtes DNS. Un tunnel peut donc être parfaitement actif, le kill switch n'ayant même pas de raison de se déclencher, alors qu'une fuite DNS parallèle expose en continu la liste des domaines consultés à votre fournisseur d'accès.
La majorité des VPN grand public ont été conçus historiquement pour chiffrer et acheminer le trafic IPv4. Un nombre croissant de fournisseurs d'accès à Internet proposent désormais une connectivité IPv6 en parallèle de l'IPv4, et la plupart des systèmes d'exploitation appliquent un mécanisme de préférence qui privilégie l'IPv6 lorsque les deux protocoles sont disponibles pour une même destination.
Si un client VPN ne gère que le trafic IPv4, sans bloquer ni acheminer explicitement le trafic IPv6, alors toute requête pouvant emprunter une route IPv6 native sortira directement par la connexion du fournisseur d'accès, en dehors du tunnel chiffré, alors même que l'application VPN affiche un statut « connecté » et fonctionnel. Ce type de fuite ne provoque aucun dysfonctionnement visible : la navigation continue normalement, simplement sans la protection attendue sur cette portion du trafic.
Le lien avec le kill switch est direct : un kill switch qui ne surveille que la route IPv4 par défaut n'a, par définition, rien à détecter du côté IPv6. Il peut fonctionner parfaitement pour son périmètre déclaré tout en laissant un canal de fuite entier hors de son champ de vision.
Ce qui rend ces deux mécanismes particulièrement problématiques, c'est qu'ils ne déclenchent aucune alerte visible dans l'interface utilisateur. Aucun message d'erreur, aucune icône rouge, aucune notification ne signale qu'une requête DNS ou qu'un paquet IPv6 vient de contourner le tunnel. L'utilisateur voit un statut « connecté », un kill switch « activé », et n'a aucune raison de suspecter quoi que ce soit tant qu'il n'a pas procédé à une vérification technique active.
Cette invisibilité explique pourquoi ces deux fuites sont si souvent absentes des discussions grand public autour des VPN, alors qu'elles sont bien documentées dans la littérature technique sur le sujet. Un comparatif qui se contente de vérifier la présence d'un kill switch, sans vérifier son comportement face à ces deux cas précis, laisse une partie significative du risque réel hors du champ de son évaluation.
Sur le plan du DNS, la garantie attendue est que les requêtes de résolution soient 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, y compris pendant les phases de reconnexion. Sur le plan de l'IPv6, deux approches sont techniquement acceptables : soit le trafic IPv6 est pris en charge et tunnelisé au même titre que l'IPv4, soit il est intégralement bloqué au niveau système tant que le VPN est actif. Ce qui n'est pas acceptable, c'est l'absence de toute mention claire sur ce point dans la documentation technique du fournisseur — cette absence constitue en elle-même un signal d'alerte, puisqu'elle laisse supposer que la question n'a simplement pas été traitée.
La vérification de ces deux points fait partie intégrante du protocole de test détaillé sur notre page tester un kill switch VPN : protocole de vérification étape par étape, qui explique comment observer concrètement le comportement du résolveur DNS et du trafic IPv6 pendant une coupure simulée du tunnel.
Contrairement au test du kill switch, qui nécessite de simuler une panne, la vérification des fuites DNS et IPv6 peut et doit aussi être effectuée pendant que le VPN fonctionne normalement, tunnel actif. Il suffit de comparer le résolveur DNS affiché par un test en ligne dédié avec celui annoncé par le fournisseur VPN : s'ils ne correspondent pas, une fuite existe indépendamment de tout scénario de coupure. De la même manière, vérifier si une adresse IPv6 publique est détectable pendant que le VPN est actif, alors que le fournisseur ne propose officiellement qu'une couverture IPv4, révèle une fuite structurelle et permanente, pas seulement un risque ponctuel lors d'une déconnexion.
Cette distinction compte : une fuite qui existe en permanence, tunnel actif ou non, est arithmétiquement plus grave qu'une fuite qui ne survient que pendant une fenêtre de reconnexion de quelques secondes. Les deux méritent d'être corrigées, mais la première devrait suffire à elle seule à écarter un fournisseur, sans même avoir besoin de tester son comportement en cas de coupure.
Installer un VPN directement sur un routeur domestique, plutôt que sur chaque appareil individuellement, complique encore la question. Un routeur mal configuré peut continuer à utiliser son propre résolveur DNS pour certains appareils du réseau local pendant que d'autres passent correctement par le tunnel, créant une situation hétérogène difficile à diagnostiquer sans tester chaque appareil séparément. De la même manière, si le routeur ne désactive pas explicitement l'annonce IPv6 sur le réseau local, certains appareils connectés peuvent continuer à obtenir une adresse IPv6 routable directement via le fournisseur d'accès, en dehors de toute logique de tunnel VPN, quel que soit le kill switch configuré sur le routeur lui-même.
Il est tentant de considérer qu'un bon kill switch règle automatiquement la question des fuites, ou inversement qu'une protection anti-fuite rend le kill switch superflu. Les deux mécanismes répondent en réalité à des questions différentes. Le kill switch répond à la question : que se passe-t-il quand le tunnel tombe complètement ? La protection anti-fuite répond à la question : est-ce que la totalité du trafic passe bien par le tunnel quand celui-ci est actif ? Un service peut exceller sur l'un des deux points et être défaillant sur l'autre. Évaluer un VPN sur un seul de ces deux axes, comme le fait la majorité des comparatifs grand public, laisse forcément un angle mort dans l'appréciation globale de sa fiabilité.