Fuites IPv6 et VPN en 2026 : comment boucher toutes les failles sans perdre en rapidité

Pourquoi les fuites IPv6 mettent à mal votre anonymat justement aujourd’hui

Qu’est-ce que le trafic IPv6 et pourquoi le VPN le laisse parfois filer

IPv6 n’est plus une théorie depuis longtemps. En 2026, son adoption dépasse 44-48 % du trafic mondial, et dans certains pays, les réseaux mobiles fonctionnent déjà en IPv6-only avec NAT64 et DNS64. Sur le papier, c’est parfait, mais il y a un hic : beaucoup de scénarios VPN ont été pensés pour l’IPv4 et ignorent simplement l’IPv6, sauf si vous activez explicitement son support. Résultat, certaines applications continuent de communiquer en IPv6 en dehors du tunnel VPN, comme si vous n’étiez pas protégé. Silence radio, sans erreur apparente. C’est ce qu’on appelle une fuite, pure et simple.

Un exemple simple : vous connectez votre VPN, vous voyez une nouvelle adresse IPv4 du fournisseur VPN, vous vous sentez en sécurité et ouvrez votre navigateur. Le site interroge l’enregistrement AAAA et établit une connexion IPv6 directe via votre fournisseur d’accès. Votre IP d’origine est visible, les cookies restent actifs, vous pensez être protégé. Dans un autre onglet, WebRTC envoie une requête STUN et révèle votre IPv6 global. Sur les graphiques c’est parfait, mais en réalité votre vie privée est compromise. C’est frustrant, n’est-ce pas ?

Les failles se trouvent où : dual-stack, Happy Eyeballs, QUIC et WebRTC

Les sources de fuite sont multiples. En 2026, la pile réseau utilise activement la stratégie Happy Eyeballs : le client teste IPv4 et IPv6 en parallèle et retient la première réponse. Si votre VPN ne protège que l’IPv4, c’est l’IPv6 direct qui l’emporte. Deuxième point : les applications modernes communiquent via HTTP/3 sur QUIC, lui-même au-dessus de l’UDP, et certains clients VPN filtrent mal le trafic sortant UDP vers des adresses ::/0 si les filtres sont superficiels. Dernier ingrédient : WebRTC. Même sans appel vidéo, le navigateur peut effectuer un échange STUN et exposer votre IPv6 réel.

Un détail concerne le DNS. Quand le système ou le navigateur active un DNS chiffré, comme DoH ou DoQ, les requêtes AAAA peuvent passer outre la configuration VPN ou le résolveur système. La réponse DNS indique ensuite une adresse IPv6 au navigateur qui se connecte directement. Ce n’est pas magique, c’est une spécificité des priorités dans le transport. En plus, les applications UWP et PWA utilisent parfois leurs propres piles réseau, qui ne respectent pas totalement les politiques du VPN. Vous pensez tout faire passer dans le tunnel, mais certains paquets se baladent librement.

Les risques des fuites : désanonymisation, géolocalisation, espionnage et simples blocages

Les fuites IPv6 sont problématiques pour plusieurs raisons. D’abord, elles relient instantanément vos actions à l’espace d’adresses de votre provider, soit une géographie, une juridiction et des logs potentielles. Ensuite, les traqueurs et réseaux publicitaires savent utiliser l’IPv6 permanent pour lier sessions et appareils, même avec un IPv4 changeant via VPN. Enfin, les blocages gouvernementaux ou d’entreprise se font parfois en IPv6, et vous vous retrouvez bloqué alors que vous pensiez passer entre les mailles.

Dernier point : la NAT. En IPv4, la NAT vous cache derrière une adresse partagée, mais IPv6 est conçu pour fonctionner sans NAT. Beaucoup de réseaux domestiques reçoivent un préfixe /56 ou /64, chaque machine ayant une adresse routable globale. Oui, il y a des adresses temporaires et des protections RFC, mais si le trafic échappe au VPN, vous exposez un identifiant global. Ce n’est pas la fin du monde, mais une brèche qu’il faut colmater rapidement.

Bloquer ou tunneliser IPv6 : quelle stratégie choisir ?

Deux approches : couper IPv6 ou le faire passer dans le VPN

Deux stratégies majeures pour contrer les fuites. La première, la plus simple, consiste à désactiver complètement l’IPv6 sur les interfaces ou au niveau du noyau, et ne laisser passer que l’IPv4 via le VPN. Fiable, rapide, reproductible. Mais en 2026, certains sites et réseaux mobiles attendent IPv6 et peuvent dégrader l’expérience, d’autant que certaines applications insistent pour utiliser QUIC sur IPv6. La deuxième approche, plus élégante, est d’intégrer un support complet d’IPv6 dans le tunnel. Du coup, vous recevez une adresse IPv6 du fournisseur VPN, routez ::/0 dans le tunnel et appliquez des règles de firewall strictes en externe.

Laquelle choisir ? Si vous voulez minimiser les risques sur desktop sans perdre en fonctionnalités, désactivez temporairement IPv6. Pour une compatibilité maximale, mieux vaut que VPN transporte IPv4 et IPv6. C’est plus complexe, demande un bon support provider, mais vous évitez de galérer à corriger la routage plus tard. Et gardez en tête : les demi-mesures du genre « blocage partiel de préfixes » donnent une fausse impression de sécurité.

Mécaniques techniques : firewall, routage policy et blackhole

En bloquant IPv6 localement, plusieurs mécanismes fiables existent. Le plus basique : couper la pile au niveau système. Ensuite, utiliser un firewall pour dropper tout trafic inet6 sortant sur les interfaces physiques sauf VPN. Enfin, configurer une route par défaut ::/0 vers blackhole, pour que tout paquet IPv6 parte dans un cul-de-sac s’il n’y a pas de tunnel actif. Parfois on combine avec du policy-based routing : les paquets sont marqués et forcés à passer uniquement par l’interface VPN, le reste est rejeté.

Pour tunneliser IPv6, c’est l’inverse. Vous ajoutez la route ::/0 dans l’interface tunnel, récupérez une adresse IPv6 du provider VPN, et interdisez tout inet6 sortant hors cette interface via firewall. Dans WireGuard, on configure AllowedIPs = 0.0.0.0/0, ::/0 et la règle killswitch. En OpenVPN, c’est tun-ipv6 et redirect-gateway ipv6. Important : ne pas oublier le DNS, il doit fournir les enregistrements AAAA et envoyer les requêtes DNS dans le tunnel, sinon une partie du trafic contournera le VPN.

Performances et coûts

Côté vitesse, un bon blocage IPv6 ne coûte quasiment rien, surtout s’il est fait au niveau du noyau ou des tables de routage. Le tunnel IPv6 impose une charge similaire à IPv4, généralement 3-7 % de CPU en plus pour chiffrement et traitement, parfois plus sur vieilles plateformes ARM. En 2026, WireGuard sur desktop et routeurs avec offload est très rapide, donc les discussions sur « perte de vitesse » relèvent souvent plus de l’émotion que de la technique.

Un point à surveiller : le temps d’établissement de connexion. Une mauvaise configuration de Happy Eyeballs peut amener le client à tenter IPv6 hors tunnel, attendre un timeout causé par le firewall, et retarder l’ouverture du site de quelques secondes. Remède simple : router correctement ::/0 dans le tunnel ou vers blackhole, ne pas compter sur une règle de blocage isolée dans une application. Le flux sera soit direct via tunnel, soit bloqué, sans latences.

Windows 10, 11 et 12 : protéger efficacement contre les fuites IPv6

Désactivation rapide d’IPv6 : interface graphique et PowerShell

Sur Windows, deux méthodes. La plus accessible : réseau et internet, modifier les options d’adaptateur, propriétés de l’interface concernée, décocher Internet Protocol Version 6. Ça marche mais ne couvre pas toujours les interfaces tunnel et virtuelles. La méthode plus fiable : utiliser la clé de registre DisabledComponents, mais en 2026 Microsoft recommande la prudence. Plus simple et propre : PowerShell et netsh pour éviter les demi-mesures.

Commandes rapides. PowerShell en admin : Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6. Répétez pour Wi-Fi. Ou globalement : netsh interface ipv6 set teredo disabled, netsh interface ipv6 set privacy state=enabled, ou radicalement : Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name DisabledComponents -Type DWord -Value 0xff. Redémarrez, IPv6 est coupé. Mais ne poussez pas trop : si votre VPN supporte IPv6, mieux vaut gérer routes et firewall.

Filtrage avec Windows Defender Firewall et WFP

Pour ne pas dépendre de simples cases à cocher, ajoutez des règles strictes au firewall. Windows Defender Firewall offre la création de règles sortantes bloquant tout TCP et UDP pour profils Private et Public sur IPv6, sauf sur interface VPN. Pas très intuitif dans l’interface, mais possible avec netsh : netsh advfirewall firewall add rule name="Block IPv6 out" dir=out action=block protocol=any profile=any interfacetype=any remoteip=any localip=any edge=yes. Puis créez une règle autorisant l’interface VPN pour ::/0. Appliquez dans l’ordre : d’abord deny tout, puis allow spécifique au VPN.

Pour un contrôle très précis, utilisez les politiques WFP via clients spécialisés ou GPO. Elles filtrent au niveau des callout drivers, bloquant IPv6 avant la sortie du stack. Avec WireGuard, vérifiez AllowedIPs ::/0 et l’option killswitch activée, bloquant tout hors tunnel. Pour OpenVPN, utilisez block-ipv6 si le provider ne supporte pas IPv6, ou tun-ipv6 et redirect-gateway ipv6 sinon.

DNS et modes Always-on VPN

Souvent négligé, le DNS peut tout faire basculer. Windows 11 dispose de DoH système et certaines versions testent DoQ. Assurez-vous que le DNS chiffré passe par le VPN. Vérifiez le paramètre DNS chiffré dans les réglages réseau, sélectionnez un fournisseur dans la liste ou activez « Automatique via réseau actuel » si le client VPN expose un résolveur. Sinon, les requêtes AAAA passeront hors tunnel, exposant votre IPv6.

Autre habitude importante : Always-on. Sur Windows, activé via options du client VPN ou politiques MDM en entreprise. Toujours mettre kill switch. Sans lui, au reconnect ou veille, le système revient vite au direct IPv6, laissant filer quelques requêtes. Comme oublier une fenêtre ouverte en hiver : la maison est chaude, mais on sent le courant d’air.

macOS et iOS : prudence avec PF et profils

Désactiver IPv6 et choisir l’interface

macOS gère bien le réseau, mais active IPv6 par défaut. La base : networksetup -setv6off Wi-Fi, répétez pour Ethernet. Cela désactive IPv6 sur un service précis sans casser la pile globale. Pour revenir en arrière : -setv6automatic. Sur iOS, pas de bouton direct, le système décide. Pour une garantie béton, préférez tunneliser IPv6 dans l’adaptateur VPN plutôt que tenter un blocage total sur la plateforme mobile.

Si votre provider VPN supporte IPv6, vérifiez que l’interface utun obtient une adresse du pool VPN et la route ::/0. De nombreux clients WireGuard sur macOS et iOS ajoutent depuis 2025 AllowedIPs ::/0 et respectent killswitch. Contrôlez la priorité des services via networksetup -listnetworkserviceorder. Mettez le VPN au-dessus de Wi-Fi et Ethernet pour éviter des comportements inattendus.

PF : règles simples pour drop inet6

Pour un contrôle strict, activez PF. Dans /etc/pf.conf ajoutez : block out on en0 inet6 all et block out on en1 inet6 all, en autorisant pass out on utun0 inet6 from any to any. Chargez les règles proprement : sudo pfctl -f /etc/pf.conf puis sudo pfctl -e. Cela empêche tout trafic IPv6 hors tunnel. Sur desktop, c’est un compromis efficace : pas de casse de la pile, mais une porte verrouillée là où il faut.

Gardez à l’esprit que macOS aime ses services Apple : iCloud Private Relay, Handoff, AirDrop. Private Relay chiffre le trafic via ses mécanismes propres. Pour un contrôle total, désactivez-le, sinon le diagnostic de fuites sera compliqué. Pas parce que ce service est mauvais, mais parce qu’il mélange les canaux. Stabilisez votre VPN avant d’activer ces fonctions supplémentaires, puis refaites vos tests.

DNS et chiffrement : DoH, DoQ et résolveurs

En 2026, Safari et macOS supportent DNS chiffré. Cela signifie que le résolveur peut utiliser DoH ou DoQ directement, si le profil de configuration l’indique. En usage pro ou profils personnalisés, vérifiez les résolveurs assignés au service réseau. Si DoH tourne sur Wi-Fi mais que le client VPN ne l’intercepte pas, les requêtes AAAA passeront hors tunnel.

Règle d’or : le résolveur doit rester dans le tunnel. Soit vous bloquez explicitement toute sortie DNS hors interface VPN, soit vous configurez le client pour qu’il publie un résolveur système utilisé par Safari. Ça paraît fastidieux, mais dès qu’une fuite discrète survient en veille, vous comprenez pourquoi le DNS est crucial.

Linux : sysctl, nftables et WireGuard intelligent

Désactivation globale ou ciblée d’IPv6

Sur Linux, sysctl est la voie directe. Dans /etc/sysctl.d/99-noipv6.conf, mettez net.ipv6.conf.all.disable_ipv6=1 et net.ipv6.conf.default.disable_ipv6=1 puis sysctl -p. Ça désactive IPv6 partout. Pour de la granularité, coupez l’IPv6 sur interfaces physiques uniquement (net.ipv6.conf.eth0.disable_ipv6=1), tout en le gardant actif sur tun0 ou wg0. Ainsi, tunnel actif, sortie nulle. Parfois, le paramètre noyau ipv6.disable=1 dans GRUB est utilisé, mais c’est le marteau pilon, bien pour serveur, peu adapté aux portables.

Pour toucher plus finement, utilisez la route blackhole : ip -6 route add blackhole ::/0 metric 1000. Elle bloque toute sortie IPv6 sauf si un itinéraire tunnel prioritaire existe. Plus élégant qu’une règle firewall isolée, il s’allie bien au policy routing. Avec NetworkManager, gardez les métriques de routes et désactivez les entrées IPv6 automatiques sur interfaces physiques.

nftables : règles solides

nftables permet une fermeture claire et stricte des fuites. Exemple : table inet filter { chain output { type filter hook output priority 0; policy accept; oifname "wg0" accept; ip6 daddr ::/0 drop; } }. La logique est simple : tout est accepté sur wg0, tout IPv6 sortant ailleurs est bloqué. Faites pareil pour input si vous ne voulez pas d’entrants. En tunnel IPv6, inversez la politique : drop par défaut, accept wg0 IPv4 et IPv6, ajoutez inspection stateful conntrack pour laisser passer les paquets retour.

WireGuard reste le roi de la rapidité en 2026. Dans la config client, mettez AllowedIPs = 0.0.0.0/0, ::/0 pour tunnel total. Ajoutez Table = off et PolicyRouting si vous voulez gérer routes à la main. Activez PersistentKeepalive, surtout sur mobiles IPv6-only avec NAT64, pour éviter la mise en veille du tunnel. N’oubliez pas la règle oifname dans nftables : votre kill switch vital. OpenVPN ? Vérifiez tun-ipv6, redirect-gateway ipv6, route-nopull et selective push si le provider configure des routes spécifiques.

DNS : systemd-resolved, resolvconf et proxy DoH

Les distros modernes tournent sur systemd-resolved. Vérifiez que l’interface wg0 enregistre son DNS avec resolvectl dns wg0 10.8.0.1 et que le mode de domaine est correct. Désactivez l’automagie sur interfaces physiques : dans NetworkManager, ignore-auto-dns yes, configurez manuellement le résolveur. Sinon, les requêtes AAAA peuvent sortir vers le DNS du provider, dévoilant votre IPv6 direct.

Pour chiffrer le DNS, installez un proxy local DoH ou DoQ dans le tunnel : cloudflared, dnsproxy, dnscrypt-proxy. Important : le trafic vers les serveurs amont doit transiter par wg0, sinon c’est retour à la case départ. Vérifiez avec curl -6 https://adresse-de-votre-DNS-provider — il doit sortir par wg0, tcpdump -i eth0 ne doit pas montrer de paquets sur ports 853 ou 443 vers des DNS externes.

Android : réseaux IPv6-only et VPN Always-on

VPN toujours actif et tunnel complet

Android vit depuis plusieurs années dans des réseaux IPv6-only des opérateurs. Sans un VPN bien configuré, le trafic sort en IPv6 via NAT64, et vous ne voulez surtout pas de fuites. Activez Always-on VPN et l’option Bloquer les connexions sans VPN. Ce kill switch intégré stoppe tout trafic si le tunnel tombe. Le client WireGuard Android gère AllowedIPs ::/0 et 0.0.0.0/0, faites-en un tunnel complet, pas un split.

Certaines applis utilisent leur propre DNS ou QUIC, vérifiez que le client VPN bloque le LAN local et filtre IPv6. Depuis Android 13 à 15, DNS privé est partout activé. Configurez-le vers une adresse accessible uniquement via tunnel ou laissez Automatique si le VPN annonce un résolveur. Sinon, les requêtes AAAA iront directement aux résolveurs publics via mobile network, cassant toute confidentialité d’un coup.

ADB, OEM et astuces supplémentaires

Dans l’interface Android standard, on ne peut pas couper IPv6. Théoriquement possible via ADB et modifications sysctl sur appareils rootés, par exemple net.ipv6.conf.all.disable_ipv6=1. En 2026 c’est rare : mieux vaut établir un tunnel IPv6 propre et appliquer des règles strictes dans le client. Certains OEM personnalisent le réseau, retardant le trafic avant VPN. D’où l’indispensable Always-on avec blocage sans VPN.

Testez WebRTC sur navigateurs mobiles. Désactivez mDNS et candidats directs si possible, ou utilisez extensions quand soutenu. Ces petits gestes suppriment une source supplémentaire d’adresse IPv6 exposée. Testez aussi bien en Wi-Fi qu’en LTE ou 5G. Fréquemment, tout est net à la maison, mais dès la sortie la fuite éclate sur mobile.

DNS privé et QUIC

Android aime la rapidité et active QUIC partout, en particulier dans les services Google et messageries. Sans vigilance dans firewall ou client VPN sur UDP, les fuites passent inaperçues. Configurez le client pour interdire l’UDP sortant hors tunnel, sauf DNS local dans VPN. Pour DNS privé, donnez un nom de domaine résolu uniquement via tunnel ; cela empêche les sorties non souhaitées. Ce n’est pas simple, mais le gain vaut le coup.

Routeurs : OpenWrt, MikroTik et Ubiquiti

OpenWrt : RA, DHCPv6 et routage policy

Sur OpenWrt, les fuites démarrent souvent via annonces RA et DHCPv6. Si vous ne voulez pas d’IPv6 sortant, désactivez les RA sur LAN, interdisez le préfixe provider et droppez ip6 dans firewall. Simple. Mieux : optez pour un VPN qui prend en charge IPv4 et IPv6, distribue IPv6 aux clients via DHCPv6-PD du pool VPN. Ainsi, les navigateurs savent où aller, Happy Eyeballs joue en votre faveur.

Côté politique : installez une policy-based routing, marquez le trafic LAN et forcez-le uniquement sur interface VPN. Ajoutez blackhole ::/0 dans la table principale pour éliminer tout hors VPN. Sous WireGuard dans OpenWrt, configurez AllowedIPs ::/0 et option route_allowed_ips 1. Laissez des commentaires firewall clairs dans les configs pour ne pas oublier vos raisons un mois plus tard. La doc dans la config c’est votre meilleur allié.

MikroTik RouterOS v7 : réglage fin d’IPv6

MikroTik a sa propre pile IPv6. Avant on supprimait parfois le paquet ipv6, mais en v7 c’est dépassé. Configurez firewall : chain=forward family=ipv6 action=drop excepté interface WireGuard ou IPsec utilisée. Pour routes, positionnez ::/0 vers interface VPN avec métrique haute pour les autres. En mangle, marquez les paquets originates LAN et dirigez-les vers une table policy routing qui ne route que via VPN.

ND et RA : désactivez les annonces LAN si pas d’adressage VPN distribué. Sinon, assurez-vous que le préfixe VPN arrive correctement et s’annonce. C’est souvent suffisant pour oublier le mot « fuite ». Activez fasttrack avec précaution, il peut bypasser certains filtres si WireGuard n’est pas exempté.

Ubiquiti : EdgeRouter et UniFi

Sur EdgeRouter, même logique : firewall IPv6 bloque trafic sortant WAN, autorise tunnel. En tables de routage, ::/0 via interface VPN. Sur UniFi UX, ajoutez règles réseau et clients. Vérifiez comment le contrôleur fournit DNS : parfois il donne des résolveurs externes. Changez pour des adresses internes VPN ou lancez un résolveur local qui va chercher à travers le tunnel.

Testez bien aussi les réseaux Wi-Fi invités. Ils incluent souvent isolation clients et DNS spécifiques évitant vos règles globales. Un clic oublié, et les téléphones invités exposent leur IPv6 hors VPN. Ne laissez pas le hasard gagner.

Tests : comment être sûr qu’il n’y a pas de fuites

Contrôles via navigateur : adresses, WebRTC et modules

Commencez simple. Faites une recherche pour checker l’IP vue par un site : votre IPv4 VPN visible, pas d’IPv6 direct ? Ensuite, ouvrez les outils dev du navigateur, regardez les logs réseaux. Des requêtes AAAA vers un résolveur hors tunnel ? Problème. Testez WebRTC sur pages dédiées : s’il montre un IPv6 global fournisseur, la config est incomplète.

Désactivez l’autoswitch DoH dans le navigateur si pas routé via VPN. Chrome doit pointer Secure DNS vers un résolveur accessible par tunnel. Firefox peut être paramétré pour suivre le système ou utiliser un DNS spécifique. C’est fastidieux, mais en préparant un checklist, vous gagnerez dix minutes à chaque vérification future.

CLI : curl, dig, ping6 et tcpdump

En terminal c’est clair. Lancez curl -4 https://example.test et curl -6 https://example.test. Le premier doit passer par VPN, le second soit aussi, soit échouer si vous bloquez IPv6. dig AAAA domaine : notez qui répond. traceroute -6 adresse contrôle si le chemin sort. tcpdump -i interface ip6 détecte tout trafic IPv6. Trouvé des paquets sur eth0 hors tunnel ? Fuite détectée, ajustez règles et retestez.

Sur Windows, utilisez Test-NetConnection -ComputerName domaine -TraceRoute -InformationLevel Detailed et netsh trace start capture=yes report=no. Sur macOS, nettop -m tcp et logs packet filter. Sur Android sans root, plus difficile, mais comparez résultats IP dans apps de test et stats réseau VPN. Ne cherchez pas la solution miracle, mais une séquence fiable pour un résultat certain.

Automatisation et alertes

Pour une sécurité critique, automatisez. Sous Linux un script toutes les cinq minutes curl -6 vers un hôte de contrôle dans tunnel vérifie la réponse et l’interface. Un autre surveille tcpdump sur interface physique, envoie alerte en messagerie si ip6 détecté. Sur Windows, script PowerShell vérifie routes ::/0 et règles firewall. Pas de science-fict, juste checker les voyants. Ça sauve quand un driver se met à jour sans prévenir.

En entreprise, établissez audits réguliers. Trimestriels : tests sur PC, téléphones, routeurs. Après grosses mises à jour : contrôle rapide. Sur routeurs, captures périodiques des routes et règles. Dans navigateurs, gestion des profils. Ça paraît barbant, mais c’est comme une ceinture de sécurité : gênant au début, salvateur ensuite.

N’oubliez pas la formation utilisateurs. Quelques slides pour reconnaître une IP normale en test, vérifier WebRTC et où signaler un souci. Expliquez que DNS privé sans VPN, c’est pas du privé. Les gens sont malins, faut juste leur filer les bons outils.

Erreurs fréquentes et comment les éviter

IPv6 désactivé globalement, mais services cassés

Couper IPv6 au niveau noyau plante parfois portails d’entreprise, CDN récents et applis mobiles. Pas de surprise. Si possible, évoluez vers un modèle « IPv6 uniquement via VPN ». Compatibilité assurée, fuites évitées. Si coupure globale, gardez sauvegardes configs et plan rollback. Pas de héros la nuit, mieux vaut préparez le jour.

Autre erreur : oublier le routeur. Vous coupez IPv6 sur laptop, mais TV et smartphone diffusent leur adresse globale en Wi-Fi. Tracking toujours effectif. Appliquez une politique unique maison ou bureau. Discipline payante.

Fuites DNS liées à DoH et DoQ

Le navigateur lance DoH vers un résolveur public et votre plan tombe à l’eau. Vérifiez la configuration : DNS sécurisé doit être sous contrôle. Sous Windows et Android, configurez un provider système ou désactivez la contrainte automatique si elle ne passe pas par VPN. Sur macOS, assurez-vous que le profil désigne un résolveur dans VPN. Sinon, déployez un proxy DoH local dans le tunnel.

Autre subtilité : résolveurs multiples. Le système garde parfois plusieurs adresses, apps interrogent différents serveurs. La solution : un point central, un résolveur local systémique qui sort par VPN. Bye le chaos des paramètres disparates.

Problèmes de routes ::/0 dans WireGuard

Parfois, AllowedIPs ::/0 est bien configuré, mais fuite persiste. Vérifiez que le client n’a pas Table = off sans policy routing configurée ensuite. Sinon, routes non appliquées. Deuxième point : priorité métrique. Si interface physique a métrique plus basse, le système part par là. Montez la métrique physique ou abaissez celle de wg0. Et activez les règles nftables droppant IPv6 hors wg0, dernier rempart.

Déjà vu aussi : blackhole ::/0 ajouté dans mauvaise table. La commande passe, mais aucun effet. Apprenez à lire ip -6 rule et ip -6 route show table all. Un coup d’œil suffit, comme lire le tableau de bord : vitesse, tours, essence, on roule.

FAQ : rapide et précis

Faut-il couper totalement IPv6 pour éviter les fuites ?

Pas forcément. La méthode la plus sûre et à jour est de tunneliser IPv6 dans le VPN et interdire son usage hors tunnel. Désactiver totalement reste une solution temporaire si vous devez boucher vite une faille ou si votre VPN ne supporte pas IPv6. Mais en 2026, de plus en plus de services exigent IPv6, alors mieux vaut apprivoiser que combattre.

Si vous craignez la complexité, commencez simple : désactivez IPv6 sur interfaces physiques, testez, puis activez-le dans le tunnel. Quand vous êtes à l’aise, passez à la gestion fine. Une évolution progressive, pas un saut dans l’inconnu.

Comment savoir si mon IPv6 fuit maintenant ?

Deux étapes. Dans navigateur, vérifiez si le site voit votre IPv6 et s’il correspond à l’IP VPN. En terminal, lancez curl -6 vers une ressource fiable, contrôlez la route avec ip -6 route get adresse. Un paquet passant par l’interface physique est une fuite. Lancez tcpdump sur interface physique et attendez un paquet ip6 : preuve irréfutable.

Pensez aussi à WebRTC. Testez candidats sur pages dédiées ou réglages navigateur. Un IPv6 global fournisseur visible ? Configuration incomplète. Corrigez firewall et DNS.

Mon VPN ne supporte pas IPv6. Que faire ?

Trois options. Désactivez IPv6 temporairement sur vos appareils. Configurez un firewall strict qui droppe IPv6 hors tunnel. Et envisagez de changer pour un VPN qui fournit IPv6 dans son tunnel. En 2026, ce n’est plus une option exotique, mais une routine d’hygiène. Vivre sans IPv6 devient compliqué, surtout en mobile et media.

Si changer de VPN n’est pas possible, gardez un checklist clair et une automatisation. Scripts pour capturer IPv6 physique, alertes. Que le système signale dès qu’il détecte une sortie anormale. Un compromis simple mais efficace.

Blocage IPv6 impacte-t-il la vitesse ?

Si vous dropez proprement IPv6 hors tunnel ou le redirigez vers blackhole, l’impact est minime. Les soucis apparaissent quand le client tente IPv6 hors tunnel, les paquets sont dropés, et il attend avant de basculer en IPv4. Ça se règle via routage ::/0 correct dans le tunnel ou blackhole avec métrique adaptée.

Tuneler IPv6 coûte comme IPv4, surtout sur WireGuard. Sur CPUs modernes la différence est souvent statistique. Plus important : stabilité routes et absence de hachures réseau.

Faut-il désactiver DoH et DoQ pour la sécurité ?

Non, pas si vous pouvez les faire passer via VPN. Mieux vaut chiffrer que pas du tout. Le problème ne réside pas dans DoH/DoQ, mais dans leurs sorties sans contrôle. Solution : résolveur hébergé dans le tunnel, et blocage strict de toute résolution hors tunnel. Règle incontournable.

Si vous ne pouvez pas tout paramétrer maintenant, désactivez DoH temporairement dans le navigateur jusqu’à preuve contraire. Puis réactivez-le, vous aurez confidentialité et ordre.

Que faire avec WebRTC si j’en ai besoin tous les jours ?

Désactiver WebRTC totalement n’est pas une option si vous l’utilisez régulièrement. Solution : configurez-le pour ne fournir que des candidats IP dans le tunnel. Avec IPv6 tunnelisé, il utilisera l’adresse VPN, pas votre IPv6 global. Bloquez aussi les candidats locaux directs s’ils n’impactent pas la fonctionnalité.

En entreprise, mettez en place des serveurs TURN accessibles uniquement via VPN, assurez-vous que les clients ne peuvent pas faire de percée UDP hors VPN. Plus strict, mais ça évite fuites et mauvaises surprises.

Pourquoi le split-tunnel est problématique en 2026 ?

Le split-tunnel n’est pas mauvais en soi, il demande juste discipline et surveillance. Quand une moitié du net passe directe et l’autre par VPN, vous avez un puzzle de domaines, protocoles et ports. Ajoutez IPv6, QUIC et DoH, et vous obtenez un système où la fuite est quasi inévitable statistiquement.

Si votre équipe n’est pas prête à gérer les règles et le monitoring continus, mieux vaut tunnel complet avec exceptions listées. C’est moins fun, mais solide. Au final, l’essentiel c’est l’efficacité, pas la poésie des règles.»