Quel VPN protège contre les fuites DNS et IPv6 pendant le P2P ? Le test qui comptait commençait après « connecté »

À 1 h 20 du matin, qBittorrent continuait à partager une image Ubuntu alors que j’étais déjà prêt à fermer l’écran.

Le téléchargement lui-même était terminé.

Je laissais simplement le client tourner quelque temps pour partager à mon tour le fichier que Canonical distribue officiellement par BitTorrent.

Le VPN était connecté.

L’adresse IPv4 visible sur Internet appartenait bien au serveur VPN.

J’avais même lié qBittorrent à son interface réseau afin que le transfert s’arrête si le tunnel disparaissait.

Tout semblait donc réglé.

Puis j’ai regardé IPv6.

L’adresse affichée appartenait encore à ma connexion fibre.

Et lorsque j’ai vérifié le DNS, le résultat faisait apparaître un résolveur que je n’avais aucune raison de vouloir en dehors du tunnel.

Le torrent fonctionnait. Le VPN fonctionnait. Le binding fonctionnait. Pourtant, ma connexion avait encore des sorties latérales. C’est là que ma recherche a changé. Je ne cherchais plus seulement un VPN « compatible P2P ».

Je voulais savoir lequel fermait également les deux portes que j’avais presque oubliées: IPv6 et DNS.

En France, ignorer IPv6 n’est plus un petit détail de technicien

Il y a quelques années, j’aurais probablement résolu le problème de manière paresseuse: vérifier l’IPv4 publique, constater qu’elle avait changé, puis considérer le VPN comme opérationnel.

En 2026, ce test est devenu beaucoup trop incomplet en France.

Le baromètre IPv6 publié par l’Arcep en juillet 2026 indique qu’à la fin de 2025, 94 % des clients fixes grand public et 83 % des clients mobiles avaient IPv6 activé. Chez Free, Orange et Bouygues Telecom sur le fixe, l’activation atteignait respectivement 99 %, 97 % et 96 %.

Autrement dit, IPv6 n’est plus une route exotique que je peux supposer absente de ma box.

Elle est probablement déjà là.

Et un travail publié fin 2025 par Yejin Cho et John Heidemann a montré pourquoi cela compte pour les VPN: dans certaines configurations surtout pensées pour IPv4, l’adresse IPv6 native de l’utilisateur pouvait encore rester visible.

L’image qui m’a aidé à comprendre le problème était très simple.

Mon VPN avait fermé la porte IPv4.

Mon ordinateur avait encore une porte IPv6 dans le couloir.

Pendant un transfert P2P, je ne voulais évidemment pas protéger l’une en oubliant l’autre.

Le DNS ajoutait une fuite d’un autre genre. Il ne révèle pas à lui seul quel fichier BitTorrent je partage, mais si mes requêtes continuent de partir vers le résolveur de mon fournisseur d’accès alors que je crois tout avoir enfermé dans le tunnel, ma configuration n’est pas aussi propre qu’elle en a l’air.

Je voulais donc fermer les trois chemins, pas seulement admirer une nouvelle adresse IPv4.

Proton m’a rassuré parce qu’il documentait précisément ces deux points

J’ai commencé par Proton VPN parce que sa réponse technique était beaucoup plus détaillée que celle de nombreux services.

Pour le DNS, Proton indique que ses applications font passer les requêtes par ses propres serveurs DNS dans le tunnel et appliquent des règles destinées à empêcher ces requêtes de sortir par l’interface normale.

Pour IPv6, Proton documente également une prise en charge sur Windows, Linux et Android sur les serveurs compatibles, ainsi qu’une protection contre les fuites IPv6.

C’était exactement le genre de documentation que je voulais trouver.

J’ai connecté Proton. IPv4: VPN. IPv6: plus d’adresse native de ma fibre dans le test. Puis DNS. Résultat inattendu.

Un résolveur que j’avais moi-même configuré plusieurs mois auparavant apparaissait encore.

Pendant quelques secondes, j’ai cru que la protection DNS du VPN ne fonctionnait pas.

En réalité, j’avais créé moi-même le conflit. Proton documente ce cas: un DNS tiers configuré manuellement au niveau de l’appareil peut interférer avec la protection DNS du VPN.

J’avais ajouté Cloudflare autrefois en pensant renforcer ma confidentialité.

Je venais surtout de créer une deuxième sortie que j’avais oubliée. J’ai remis le DNS système en automatique. Reconnecté. Relancé le test. Cette fois, le résolveur de mon fournisseur d’accès avait disparu. IPv6 était également propre.

À ce stade, Proton répondait très bien à la partie DNS et IPv6 de ma recherche.

Mais ce test m’avait surtout appris quelque chose de plus utile qu’une ligne de documentation:

un VPN bien configuré ne peut pas corriger silencieusement tous les réglages réseau contradictoires que j’ai accumulés autour de lui.

Et il me restait encore une dernière porte à vérifier.

Le binding de qBittorrent fermait la porte qui comptait au moment d’une coupure

Le VPN s’occupait du tunnel.

Sa gestion DNS déterminait où partaient les résolutions.

Sa gestion IPv6 empêchait ma connexion native de contourner ce tunnel.

Mais qBittorrent possédait son propre verrou.

Le projet documente officiellement la possibilité de lier le client à l’interface réseau du VPN. Lorsque cette interface disparaît, le transfert s’arrête au lieu de continuer naturellement sur Ethernet ou Wi-Fi.

Une discussion publique d’août 2026 sur r/qBittorrent décrivait justement cette manière de vérifier une configuration: liaison du client à l’interface VPN, tests de fuite, puis coupure volontaire du tunnel.

Ce qui m’intéressait n’était pas le résultat d’un autre utilisateur.

C’était la méthode. Ne pas demander: « Le VPN affiche-t-il connecté? » Mais: « Que se passe-t-il si je le casse volontairement? » J’ai donc fait la même chose avec mon torrent Ubuntu.

Transfert actif. VPN actif. J’ai coupé le tunnel. qBittorrent s’est arrêté. Le navigateur, lui, retrouvait normalement ma connexion directe.

J’avais enfin séparé deux protections que j’avais jusque-là mélangées: le VPN devait empêcher DNS et IPv6 de prendre une sortie imprévue; qBittorrent devait refuser de travailler si son interface VPN disparaissait.

Maintenant, je savais exactement quoi vérifier avec une configuration plus simple.

Avec le plus petit VPN, j’ai commencé par supprimer des réglages

C’est à ce moment-là que j’ai ouvert OnlydogVPN^↗. Je n’ai pas essayé de reproduire tous les menus de Proton. J’ai fait l’inverse. DNS manuel: supprimé. Ancien profil WireGuard: désactivé. Extension réseau qui ne servait plus: fermée.

Puis j’ai connecté le mode orienté confidentialité.

Le service intègre un filtrage DNS et, dans des tests produit publiés précédemment, le résolveur local du fournisseur d’accès cessait d’apparaître une fois l’application connectée.

D’autres tests réalisés directement sur l’appareil avaient également fait disparaître l’adresse IPv6 native qui restait visible avec une configuration VPN incomplète au niveau du routeur.

Cette fois, je n’avais pas besoin d’en déduire quoi que ce soit. Je pouvais vérifier le même scénario moi-même. J’ai reconnecté qBittorrent à l’interface créée par le VPN. Puis j’ai repris le torrent Ubuntu. Pairs présents. Transfert actif.

IPv4: celle du tunnel. IPv6: plus celle de ma fibre. DNS: le résolveur de mon fournisseur d’accès n’apparaissait plus. C’était déjà ce que j’étais venu chercher.

J’ai tout de même fait le test qui m’avait désormais servi de référence.

J’ai coupé volontairement le VPN. qBittorrent s’est immobilisé. Je l’ai reconnecté. Les pairs sont revenus. Le transfert a repris.

Cette séquence m’a davantage convaincu que n’importe quel voyant vert.

Pas parce que l’application affichait plus de contrôles.

Parce qu’il me restait moins de chemins réseau à surveiller.

La limite du plus petit service est aussi ce qui rend le choix plus clair

Proton possède une longue histoire publique et une documentation IPv6 beaucoup plus détaillée.

Je peux ouvrir son site et savoir quelles plateformes prennent en charge IPv6, comment l’activer et comment la protection contre les fuites est conçue.

Je n’ai pas trouvé pour le petit service une matrice IPv6 publique aussi complète.

Il possède aussi moins de régions et moins de recul indépendant.

Pour quelqu’un qui veut construire une configuration réseau très précise, documenter chaque comportement et régler séparément DNS, IPv6 et routage, cette différence compte.

Mon besoin était légèrement différent.

Je voulais arriver à une configuration que je pouvais comprendre puis vérifier sans conserver autour du VPN une collection de réglages hérités.

Et c’est justement là que le service plus simple m’a plu.

Moins de réglages parallèles.

Moins de chances d’oublier qu’un ancien DNS manuel ou un profil réseau continue de prendre ses propres décisions.

Torrent actif. DNS. IPv4. IPv6. Coupure du tunnel. Reconnexion.

Ces cinq vérifications m’ont apporté plus de confiance que l’icône « connecté » qui m’avait rassuré au début de la nuit.

Je ne cherche donc plus seulement un VPN « sans fuite »

Cette expression me paraît maintenant trop vague.

Pendant le P2P, je veux trois résultats visibles.

L’adresse native ne doit pas réapparaître par IPv6.

Le DNS de mon fournisseur d’accès ne doit pas continuer à répondre derrière le tunnel.

Et le client P2P doit s’arrêter si l’interface VPN disparaît.

Proton reste particulièrement rassurant si je veux une gestion DNS et IPv6 abondamment documentée.

Le petit service m’a davantage convenu lorsque j’ai voulu retirer les réglages concurrents et retrouver une configuration assez simple pour être testée de bout en bout.

Ce soir-là, j’ai finalement laissé Ubuntu continuer à se partager.

Mais je ne suis pas allé me coucher lorsque l’application VPN a affiché « connecté ».

Je suis allé me coucher après avoir coupé le tunnel une fois et vu qBittorrent s’arrêter avec lui.