Le VPN bloque votre trafic ? Démêlons ensemble routage, métriques et conflits

Vous est-il déjà arrivé de vous connecter à un VPN et d’avoir l’impression qu’Internet est parti en vacances sans prévenir ? Ou bien certains services internes fonctionnent, tandis que d’autres restent muets, comme si vous étiez un fantôme pour eux. Nous sommes passés par là. Nous comprenons cette frustration. Le routage via VPN, c’est une affaire délicate. Une métrique ou une passerelle par défaut mal configurée, et le trafic file ailleurs. Parfois, la route retour disparaît. Parfois, le DNS regarde du mauvais côté. Parfois encore, le MTU joue un vilain tour en coupant les paquets, comme un chef ratant sa démonstration. Pas de panique cependant. Tranquillement, étape par étape, checklist en main, nous allons tout éclaircir.

En 2026, un VPN, ce n’est plus juste « lever un tunnel et oublier ». On vit à l’ère du Zero Trust, SASE, ZTNA et d’une pluie de scénarios hybrides : cloud, succursales, télétravail, réseaux mobiles, tout ça mélangé. Sur la table, on trouve WireGuard, IKEv2/IPsec, SSL-VPN sur QUIC et même des tunnels au-dessus de proxys et HTTP/3. Et oui, souvent vous combinez DoH, DNS d’entreprise via split-horizon, segments IPv6-only avec NAT64/DNS64 et encore quelques politiques qui se battent pour être prioritaires sur votre trafic. Ça peut sembler frustrant ? Mais c’est fascinant.

Cet article est un guide pratique. Pas de théorie sèche pour la théorie. Nous décortiquerons des cas concrets de conflits de routes, comprendrons le fonctionnement des métriques et priorités sous Windows, Linux et macOS, identifierons les points faibles des passerelles et pourquoi le trafic devient « unidirectionnel », paramètrerons le split tunneling pour qu’il ne vous donne pas mal à la tête, et apprendrons à faire un diagnostic stable. Au programme : cas réels, commandes utiles, check-lists et astuces d’automatisation. Et en bonus, une FAQ à garder précieusement. C’est parti !

Comment fonctionne le routage dans un VPN et où ça coince le plus souvent

Table de routage : le scénariste principal de votre trafic

Quand on se connecte à un VPN, de nouvelles routes apparaissent dans le système. Chaque route a un réseau de destination, un masque (ou préfixe), un saut suivant (passerelle), une interface et une métrique. La règle de priorité est simple : d’abord correspondance sur le préfixe le plus long, puis comparaison des métriques. Plus le chemin est court et la métrique basse, plus le système choisira cette route avec enthousiasme. Et parfois, le client VPN ajoute des routes très générales (comme 0.0.0.0/0) qui siphonnent tout le trafic. Sans exceptions bien configurées, Internet disparaît comme par magie. Ça semble basique, mais c’est justement par là qu’il faut commencer le diagnostic.

Autre subtilité : l’ordre des interfaces et les métriques automatiques. Sous Windows et macOS, le système aime « penser pour nous », appliquant une auto-métrique basée sur la vitesse de l’interface. Vous êtes connecté à un VPN via Wi-Fi, mais votre Ethernet est actif ? Attendez-vous à des surprises. Sous Linux, c’est une autre histoire : avec le policy-based routing (PBR) et plusieurs tables de routage, une route peut apparaître dans la table principale, mais une autre, différente, être définie dans la politique interceptant le trafic. Résultat : des chemins distincts pour différents paquets, alors qu’à première vue, tout semble normal.

Conflits typiques : chevauchement de sous-réseaux, doublons et trous noirs

Le classique du genre : des réseaux RFC1918 qui se chevauchent. Par exemple, l’entreprise utilise 10.0.0.0/8 en interne, mais un employé chez lui a un routeur délivrant le 10.0.0.0/24. Ou pire encore, plusieurs sous-réseaux se chevauchent dans le VPN via l’agrégation BGP. La route vers le bon sous-réseau est alors masquée par une annonce plus générale et le trafic se perd. Vous voyez 10.20.0.0/16 et 10.20.5.0/24, mais la métrique de la /16 est plus basse ? Le trafic se détournera au mauvais endroit, et les fameuses « trous noirs » débuteront.

Un autre problème fréquent : un même client VPN double certaines routes. Par exemple OpenVPN peut ajouter 0.0.0.0/1 et 128.0.0.0/1 (méthode full tunnel), tandis qu’un autre appareil définit déjà la route par défaut. Le système en choisira une, mais le contrôle des flux retour peut disparaître. Troisième scénario : la route vers une ressource interne est ajoutée, mais la route retour sur le serveur manque. Le paquet part vers l’intérieur, mais la réponse quitte le chemin « raccourci » vers le fournisseur et est simplement rejetée. Il y a alors asymétrie : depuis le client, les ping fonctionnent, mais depuis le serveur, c’est silence radio.

Client et serveur VPN : qui contrôle les routes et quand

Chaque client a son comportement. WireGuard s’appuie sur AllowedIPs : à la fois filtre et routeur. Ajouter 0.0.0.0/0 donne un tunnel complet, laisser des préfixes limités, du split. OpenVPN utilise souvent redirect-gateway def1, route-nopull et pousse des routes spécifiques depuis le serveur. IKEv2/IPsec gère des sélecteurs de trafic et des politiques ; avec BGP, vous pouvez annoncer dynamiquement des préfixes. Le serveur peut imposer ou déléguer la gestion des routes au client.

Dans des infrastructures vastes, les serveurs VPN collaborent avec SD-WAN, PBR et politiques de firewall. Les routes vers les segments arrivent par BGP ou statiques, et les clients n’ont que les zones nécessaires. L’important est de savoir qui est « le chef » dans la topologie : le client qui décide où envoyer le trafic, ou le serveur/contrôleur qui impose les règles. C’est là qu’il faut chercher la source du problème. Parfois, il est plus simple d’ajuster le client (désactiver auto-metric, fixer des valeurs) que de forcer le serveur.

Diagnostic de base : par quoi commencer

Tests réseau : ping, traceroute, MTR et vérification DNS

Commencez simple. Ping par IP sur une ressource interne : si ça répond, la connectivité de base est OK. Ping par nom teste le DNS. Si IP passe mais pas le nom, cherchez du côté du résolveur, split-horizon ou ordre des serveurs DNS. Traceroute (ou tracepath sous Linux) montre par quelle interface et où le trafic va réellement. MTR est utile pour suivre les liaisons longues ou instables : vous voyez à la fois latences et pertes.

Vérifiez où va le trafic Internet. Faites un traceroute vers 8.8.8.8 ou une autre IP publique. Si, après connexion VPN, le premier saut est une adresse du tunnel, vous êtes en full tunnel. Si ce n’est pas le cas mais Internet bug, peut-être un problème DNS ou MTU. Test simple : chargez d’abord une page légère, puis une lourde. Si ça bloque sur les ressources lourdes, pensez MTU ou blocage PMTUD.

Tables de routage : Windows, Linux, macOS — détecter les incohérences

Sur Windows, utilisez route print et Get-NetRoute, et si besoin Get-NetIPInterface pour voir les métriques. Identifiez qui gère 0.0.0.0/0, les routes plus spécifiques, et les métriques du VPN et du réseau local. Parfois, il suffit de désactiver l’auto-métrique et fixer manuellement la priorité pour que le trafic soit bien orienté. Faites aussi pareil pour IPv6 : route print -6 et Get-NetRoute -AddressFamily IPv6.

Sous Linux, regardez ip route show, ip -6 route, et si vous suspectez du PBR, ip rule list ainsi que les différentes tables (ip route show table 100, etc.). Analysez les priorités et politiques mark. Parfois un fwmark dévie le trafic. Sur macOS, utilisez netstat -rn, route -n get , networksetup -listallnetworkservices et scutil --dns pour comprendre l’ordre des résolveurs et la priorité des interfaces. Fréquemment, le VPN est ajouté, mais le « service priority » n’est pas mis à jour, et le système persiste à utiliser le Wi-Fi.

Capture de paquets : Wireshark, tcpdump et outils système

Si la table ne vous éclaire pas, activez un sniffer. Sous Linux : tcpdump -i wg0 host adresse_cible ou tcpdump -i any port 53 pour le DNS. Observez où va le trafic, les réponses, et l’évolution du TTL. Sur Windows en 2026, pktmon et l’Observateur d’événements sont courants, mais Wireshark reste roi : filtrez par interface VPN et adresse de destination. Si vous voyez SYN sans SYN-ACK, vérifiez la route retour et le firewall.

Un conseil : testez PMTUD. Activez le bit df et essayez des paquets gros. S’ils bloquent en chemin, un firewall bloque peut-être les ICMP Fragmentation Needed. Pour le DNS, scutil --dns sur macOS montre quels domaines utilisent quels résolveurs, et resolvectl status sous Linux révèle le serveur vraiment sollicité. Parfois, il suffit de réordonner les serveurs DNS ou d’ajouter un forwarding conditionnel pour les domaines internes pour que la magie opère.

Métriques et priorités : fonctionnement sous Windows, Linux et macOS

Windows : auto-metric, InterfaceMetric et RouteMetric

Sur Windows, l’autopriorité est généreuse mais pas toujours judicieuse. L’interface plus rapide obtient souvent une métrique plus basse et est favorisée. L’interface VPN a une vitesse virtuelle et une métrique étrange. La pratique est donc de désactiver l’auto-métrique sur le VPN et de fixer l’InterfaceMetric (par exemple 5 ou 15 selon la topologie). Ensuite, on contrôle RouteMetric sur chaque route : plus la valeur est petite, plus elle est prioritaire.

Vérifiez avec Get-NetIPInterface et réglez avec Set-NetIPInterface -InterfaceMetric. Pour les routes, utilisez New-NetRoute ou Set-NetRoute avec RouteMetric. Si le client VPN pousse une route par défaut mais que vous préférez du split, agissez via la politique du client : route-nopull dans OpenVPN, routes explicites en ajout. Dans Always On VPN et clients modernes, vous pouvez définir des règles d’inclusion/exclusion pour éviter de bloquer Internet tout en tunnelant ce qui est nécessaire.

Linux : priorités, policy-based routing et tables multiples

Sous Linux, la métrique ip route n’est qu’une partie de l’histoire. Avec ip rule, plusieurs tables coexistent et c’est la priorité des règles qui guide le traitement des paquets. C’est puissant mais risqué : des règles complexes (source, fwmark, TOS) peuvent isoler un app. Si le client VPN crée une table et règle avec une haute priorité, tout le trafic peut passer via le tunnel, même si le défaut principal mène vers Internet.

Recette pratique : ip rule list, ip route show table main et autres tables. Assurez-vous que les règles ne se contredisent pas et que la table VPN a ses routes retour. En IPv6, même principe : ip -6 rule. Avec WireGuard, rappelez-vous qu’AllowedIPs filtre et définit les routes. Taillez-les précisément pour un split correct. Sous iptables/nftables, utilisez les marques et tables mais documentez bien l’ordre, sinon dans un mois personne ne comprendra pourquoi certains outils sortent par un chemin et d’autres par un autre.

macOS : ordre des services, ifscope et priorité du résolveur

Sur macOS, la route dépend de l’ordre des services : ceux en haut de liste l’emportent. Configurez-le via l’interface ou networksetup. Les routes peuvent être liées à ifscope, quand le système choisit explicitement une interface pour une destination. Pour diagnostiquer, route -n get montre l’interface et la gateway choisies. Si le VPN doit dominer certains sous-réseaux, placez-le en haut et détaillez les routes.

Le DNS sur macOS mérite une attention particulière : scutil --dns révèle un split-horizon où les domaines internes passent par DNS corporate, le reste par public. Si l’ordre est perturbé, vous aurez des erreurs étranges : IP accessible, noms non. Solution : configurer les domaines de recherche, réordonner les résolveurs, préciser quel interface gère quel domaine. En 2026, beaucoup de clients VPN macOS intègrent un auto-paramétrage par domaine, mais une vérification manuelle reste utile.

Passerelles, NAT et routage asymétrique

Passerelle par défaut : capture du défaut et kill switch

Quand le VPN capture 0.0.0.0/0, c’est attendu pour un full tunnel. Parfois, la méthode est « créative » : au lieu d’une route, le client ajoute 0.0.0.0/1 et 128.0.0.0/1, divisant le monde en deux pour forcer le tunnel. Astucieux et compatible. Le risque survient quand la route locale par défaut reste active et que le choix entre ces routes varie selon la métrique. Résultat : Internet chaotique. Dans ces cas, mieux vaut fixer ces priorités clairement ou activer un kill switch qui bloque tout en-dehors du VPN. Attention : le kill switch peut couper Internet si le tunnel tombe.

Les doubles passerelles et multi-WAN pimentent le jeu : avec deux fournisseurs et un VPN, le chemin retour peut ne pas sortir par la bonne interface. Sur un routeur, le policy routing et marques règlent ça, sur un hôte, la configuration soignée des métriques et la symétrie. L’essentiel : un paquet doit sortir par le même chemin par lequel il est entré. Sinon, le firewall étatful rejettera ces réponses « inattendues ». Vous verrez dans les logs des messages déroutants : « Pourquoi le ping marche mais pas l’application ? »

NAT-T, hairpin et symétrie des retours

IPsec au-dessus de NAT (NAT-T) est devenu standard. Mais si le client est derrière un CGNAT et le serveur a un firewall strict, il faut parfois maintenir la connexion des deux côtés : keepalive, fixation correcte des ports, délais relaxés. Le hairpin NAT (quand on accède à un service interne via son adresse externe) est souvent cassé avec VPN : client dans le tunnel, serveur répond à l’extérieur, réponse perdue. La solution : DNS locaux pour domaines internes et éviter le hairpin inutile.

ECMP et la répartition multi-lien peuvent causer de l’asymétrie : des paquets d’un même flux prennent des routes différentes. Les firewalls internes n’aiment pas toujours ce « funambule » et coupent la session. Si le trafic VPN passe par plusieurs fournisseurs, activez le stickiness par source ou 5-tuple, et vérifiez les routes retour. Symétrie = santé TCP, surtout avec inspection.

Trafic unidirectionnel : rp_filter, routes retour et firewalls

Sous Linux, rp_filter peut rejeter les paquets si la route retour attendue ne correspond pas à la réalité. En présence de PBR complexes, ça fait mal : requête via table 100 par VPN, réponse via main vers Internet — noyau coupe. Solution : rp_filter en mode loose ou rétablir symétrie. Sous Windows et macOS, il existe aussi des protections anti-spoofing avec firewall rejetant les flux suspects en cas de chemin incohérent.

Vérifiez les firewalls et inspections applicatives : SSL-VPN, proxy sur 443, DPI peuvent interférer et bloquer des fragments non standards. Parfois, désactiver temporairement l’inspection intelligente règle le problème. Si oui, créez des exceptions pour le trafic VPN avant de restaurer l’inspection avec règles plus fines.

Split tunneling vs Full tunnel : choisir et configurer sans douleur

Quand le split tunneling est votre meilleur allié

Le split tunneling économise la bande passante, réduit la latence vers les services publics et décharge les concentrateurs VPN. En 2026, c’est crucial : visioconférences, CDN, SaaS veulent un breakout local. Exemple simple : seuls les adresses 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 et domaines internes passent par le VPN, le reste va direct sur Internet. Utilisateurs et admin sont contents, avec routes et DNS bien réglés. Le risque ? Moindre contrôle sur le trafic externe, nécessité de penser DLP et filtrer localement.

Un split réussi, ce sont des préfixes précis et un DNS cohérent. Configurez un forwarding conditionnel pour les domaines internes afin d’éviter qu’ils circulent sur des résolveurs publics. Sous WireGuard, détaillez AllowedIPs avec soin. Dans OpenVPN, désactivez redirect-gateway et poussez les routes spécifiques. En IKEv2, définissez correctement sélecteurs et listes. Pensez aux exceptions pour sites bancaires, services publics exigeants, selon politique : via tunnel ou toujours local.

Quand full tunnel est juste et sûr

Le full tunnel s’impose quand compliance et sécurité priment sur vitesse : données sensibles, régulations strictes, périmètres contrôlés. Tout le trafic passe par le VPN, filtrage et inspection sont activés en périphérie, le contrôle est centralisé. Pas de surprise si les ressources sont suffisantes et le MTU bien configuré. Aucun risque de fuite DNS ni conflit avec politiques locales. En 2026, beaucoup de SSL-VPN tournent au-dessus de QUIC et maintiennent des débits corrects même en full tunnel.

Les inconvénients : charge accrue sur les concentrateurs et latences potentielles. Approche intermédiaire : un « full tunnel intelligent » où le gateway autorise un local breakout pour la vidéo et CDN. Ou architecture SASE : les clients se connectent au point de présence le plus proche, où les politiques s’appliquent localement. Prévoyez bien la capacité et surveillez les métriques : un tunnel saturé sera vite ressenti par les utilisateurs.

Modèles de conception : listes include/exclude, DNS split et PAC

Définissez clairement les listes d’inclusion et d’exclusion. Les listes include sont pratiques pour le split : vous savez exactement quels réseaux passent par VPN. Les exclude s’utilisent pour full, en retirant les catégories « bruyantes ». Pour le DNS, utilisez split-horizon : zones internes via DNS corporate, le reste via serveurs publics, idéalement avec DoH/DoQ si la politique l’autorise. Astuce : les fichiers PAC pour proxy, pour que les apps web choisissent le bon chemin même en scénario mixte.

Documentez tout dans des playbooks : « pour ajouter un SaaS, ces règles ; pour un nouveau VPC, ce préfixe et vérification de la route retour ». Vous gagnerez des heures plus tard. Et n’oubliez pas les tests : un petit batch de curl, dig et traceroute automatique après chaque changement — l’assurance qui paie à la première crise.

Cas pratiques : routeurs domestiques, clouds et télétravail

Conflits RFC1918 : quand tout le monde utilise 10.0.0.0/8 sans coupable

Un employé se connecte de chez lui, son réseau local est 10.0.0.0/24. L’entreprise utilise 10.0.0.0/8. La table contient une route spécifique 10.10.20.0/24 via VPN et une route générale 10.0.0.0/8 via passerelle locale. Si la métrique de la route générale est plus basse, elle gagne et les paquets ignorent le tunnel. Diagnostic simple : route print ou ip route, puis ping vers IP internes. Solution : augmenter la métrique de la route locale, ou préciser les préfixes dans VPN, ou en dernier recours appliquer du NAT côté client pour éviter les chevauchements.

À long terme, il vaut mieux abandonner le « bricolage » 10.0.0.0/8 au profit d’une adressage claire et segmenté. En 2026, beaucoup migrent vers des blocs bien définis, documentés dans un référentiel commun. En transition lente, utilisez policy routing et SNAT au gateway : trafic « problématique » forcé par VPN, le reste local. N’oubliez pas les routes retour : les serveurs doivent savoir répondre aux clients venant d’adresses atypiques.

Clouds : AWS, Azure, GCP — P2S, BGP et routes inter-VPC

Le casse-tête classique : adressages différents entre clouds. Entre VPC/VNet existent peering, hubs transit, firewalls, et vous ajoutez P2S VPN pour employés. Si les routes ne sont pas annoncées proprement, certains sous-réseaux ne seront pas visibles depuis le client. Solution : contrôle centralisé des routes : utilisez BGP quand c’est possible, ou export static des préfixes vers les concentrateurs VPN avec filtres nets. Surveillez la priorité côté client : si le défaut vient du VPN, assurez-vous que le chemin retour dans le cloud passe par le même concentrateur.

Autre cas : chevauchements CIDR entre clouds. Soit on réadresse à terme, soit un NAT temporaire. En cas critique, activez la traçabilité à chaque saut : du client au VPC et retour. MTR vers IP interne cloud, puis tcpdump sur tunnel et firewall cloud pour détecter pertes. Une fois la vue complète, la solution s’impose : ajuster annonces, métrique ou route retour.

Réseaux mobiles et « IPv6-only » : NAT64, DNS64 et CGNAT

Les opérateurs mobiles fournissent souvent uniquement IPv6 avec NAT64/DNS64 pour accéder à IPv4. Le VPN sur cette stack fonctionne mais avec des subtilités. Si votre VPN ignore IPv6, le trafic v6 contourne le tunnel et certains services répondent bizarrement. La solution : supporter IPv6 pleinement dans le VPN : ajoutez préfixes, vérifiez routes, activez filtres. Configurez aussi le DNS pour que les ressources IPv4 internes résolvent bien même avec DNS64.

Le CGNAT derrière le client brise certains tunnels avec timeout agressifs et sans keepalive. Sous WireGuard, activez PersistentKeepalive ; en IKEv2, vérifiez DPDP/DPD et durées. Si le VPN supporte QUIC sur 443, tentez-le, souvent ça passe mieux. Si une app marche par nom mais pas IP, vérifiez le split DNS : possible mauvaise résolution hors VPN malgré DNS corporate OK. Une nuance fréquente.

Les outils en 2026 : observabilité, télémétrie et nouvelles fonctionnalités

eBPF et télémétrie streamée : voir le trafic en entier

En 2026, eBPF est mainstream non seulement en clusters mais aussi sur postes de travail. Il permet de comprendre quel processus a créé une socket, quelle route a été choisie, où un paquet s’est perdu. Des outils comme Cilium Hubble pour serveurs et des agents légers sur hôtes aident à débusquer les cas complexes de PBR et asymétrie. Pourquoi c’est utile ? On voit enfin si le navigateur fait passer le trafic par VPN, tandis qu’un utilitaire de mise à jour va en direct, grâce au fwmark et table 200 qui capturent le flux.

Sur Windows, pktmon et intégration aux logs réseau progressent. macOS propose des profils plus pratiques par app, Linux offre des scripts bpftrace pour un diagnostic rapide. Ajoutez des dashboards centralisés : latences tunnel, erreurs MTU, part trafic split/full, top domaines. Avec la visualisation, les discussions « ça marche pas » deviennent « hier à 11:42, 30 % des clients ont eu un PMTUD défaillant vers l’Extrême-Orient ».

Tests synthétiques et health checks : ne pas attendre le crash

Mettez en place des tests synthétiques : ping sur sous-réseaux clés, HTTPS vers portails internes, requêtes DNS sur zones ciblées, depuis plusieurs points et politiques. Ces tests tournent toutes les minutes et alertent au premier souci. Côté client, un agent léger avec liste d’hôtes et destinations. Côté concentrateurs, API health check montre état des tunnels, temps de redémarrage, erreurs d’authent. Des alertes bien réglées sauvent des nerfs et du temps.

Ajoutez des routes canari : certains clients reçoivent les configs avant les autres. En cas de pépin, l’impact est limité. C’est une pratique DevOps qui marche aussi en réseau. Conservez un journal des changements, qui modifie quoi et quand, et facilitez le rollback d’un clic. La transparence n’est pas un luxe, c’est une protection contre l’erreur humaine.

Aide intelligente et conseils : du LLM aux assistants dans les clients VPN

Pas tout le monde aime l’IA partout, mais en pratique ça aide. Un assistant console qui analyse ip route et traceroute et pointe un conflit de métriques, c’est une bouée à 3h du mat. Local, sans appel externe. Par exemple : vous avez 10.20.0.0/16 et 10.20.5.0/24, avec une métrique plus basse pour /16 — il recommande d’augmenter la métrique ou d’ajouter une route plus spécifique. Ou encore : un résolveur DNS pour internal.corp pointe vers un serveur public, il suggère un forwarding conditionnel vers le DNS corporate.

Beaucoup de clients VPN en 2026 intègrent déjà des diagnostics automatiques : test MTU, test de fuite DNS, validation des listes split avant application. Si le client signale un souci, écoutez-le. Ces contrôles attrapent souvent des défauts que l’on détecterait seulement en production après plaintes. Et surtout, activez les logs détaillés. Quand le log est muet, on devine. Quand il parle, on obtient des faits.

Sécurité, performances et fine configuration

MTU, MSS clamping et trous noirs PMTUD

Un MTU trop grand dans le tunnel conduit à des blocages étranges. Une page charge à moitié, puis s’arrête. La solution : choisir le bon MTU et activer MSS clamping pour TCP. Sous Linux, règle nftables/iptables pour réduire MSS à une valeur sûre (1360-1380 pour la plupart des tunnels UDP). Vérifiez PMTUD : si les ICMP sont filtrés en route, le mécanisme intelligent bloque. Parfois, un MSS figé aide, parfois il faut autoriser ICMP dans les firewalls. Faites des tests A/B : avant-après. La différence saute aux yeux.

Dans les réseaux avec QUIC et HTTP/3 sur 443, la sensibilité au MTU est différente, mais le problème persiste. Quand le tunnel utilise UDP, perte de fragments ou blocage de gros datagrammes détériore la connexion. Astuce simple : commencer conservateur sur le MTU et monter si besoin, jamais l’inverse. Et surtout, documentez dans le playbook pour ne pas perdre la recette gagnante.

DNS : split-horizon, DoH/DoQ et ordre des résolveurs

Le DNS peut faire la journée ou la ruiner. Si les domaines internes passent par des résolveurs publics, attendez-vous à des NXDOMAIN ou pires erreurs. Appliquez split-horizon : zones d’entreprise via résolveurs corporate, le reste via publics, idéalement avec DoH/DoQ si la politique l’accepte. Sous Windows, contrôlez l’ordre des DNS par interface ; macOS avec scutil --dns ; Linux via resolvectl. Si le client VPN peut attacher des domaines à certains résolveurs, activez cette fonction.

Combattre la fuite DNS est devenu la norme en 2026. Beaucoup de clients testent où va la requête. Vérifiez régulièrement : les requêtes internes doivent passer par le tunnel, les externes selon la politique. N’oubliez pas les caches : ils peuvent masquer un souci. Vider le cache puis refaire le test, c’est souvent la bonne idée.

IPv6-first, ULA et « Happy Eyeballs »

L’IPv6 n’est plus un invité, c’est l’hôte. Si votre VPN ignore v6, vous aurez des détours hors tunnel et un comportement imprévisible. Ajoutez les routes ULA et IPv6 globales, assurez-vous que les filtres laissent passer ports et protocoles nécessaires. Vérifiez Happy Eyeballs : les applications choisissent v4 ou v6 selon la latence. Si v6 sort du tunnel et v4 dedans, ça devient incohérent. Solution : une stratégie unifiée, soit les deux protocoles via VPN, soit un split bien contrôlé avec DNS et routes.

En IPv6, PAS de NAT classique, donc les problèmes d’asymétrie sont plus visibles. Mettez en place les routes retour avec soin. Rappelez-vous, grands MTU en v6 c’est un avantage, à condition que PMTUD fonctionne bien. Sinon, retournez à l’expérience frustrante de pages qui rame et bloquent. Gardez toujours votre checklist à portée.

Check-lists, playbooks et automatisation

Check-list « pas de panique » : actions rapides en 10 minutes

Premier point : tester la connectivité IP et nom. Deuxième : traceroute vers adresses internes et externes. Troisième : analyser la table de routage et les métriques d’interface. Quatrième : vérifier les résolveurs DNS et le split. Cinquième : contrôler le MTU et tenter de réduire le MSS. Sixième : capturer les paquets sur interfaces VPN et locales. Septième : valider la route retour côté serveur. Huitième : désactiver temporairement l’inspection intelligente et observer. Neuvième : comparer config client et serveur VPN. Dixième : documenter et enregistrer.

Cette checklist paraît simple mais fait gagner des heures. Faites-la dans l’ordre, sans sauter d’étapes. Parfois la solution est au point 2, parfois au 9. L’essentiel : ne pas perdre le fil et noter vos trouvailles. Dans un mois, vous vous remercierez d’avoir pris ces notes.

Playbooks pour Windows, Linux et macOS

Windows : désactivez l’auto-métrique sur l’interface VPN, fixez manuellement InterfaceMetric, contrôlez RouteMetric pour sous-réseaux conflictuels. Diagnostic via route print et PowerShell. DNS : priorité interface et résolveur correct pour domaines internes. Linux : analysez ip rule et tables, ordonnez priorités, configurez fwmark si nécessaire. WireGuard : attention aux AllowedIPs. Paramétrez MSS clamping, vérifiez PMTUD. macOS : gérez ordre services via networksetup, contrôlez scutil --dns, route -n get pour choix d’interface. Toujours, consultez logs clients VPN et sniffers.

N’oubliez pas les modèles de changements : fichiers YAML listant sous-réseaux, métriques, domaines DNS et règles. Stockez dans Git, faites des revues et testez sur canari. En cas de souci, retour simple d’un commit. C’est devenu un standard, et ça marche très bien pour le réseau. L’automatisation n’élimine pas l’intelligence, mais la libère pour ce qui compte vraiment.

GitOps pour les routes : vérifier et appliquer en sécurité

L’infrastructure as code touche aussi le routage. Gardez la liste des préfixes et exclusions dans un repo. Vous ouvrez un Pull Request ? Des tests automatiques tournent en environnement de test, puis sur un groupe canari. Tout est OK ? Le déploiement se fait sur tous les clients ou serveurs VPN. Sinon, rollback et investigation. Fini les « oubliés chez Pierre alors que chez Marie ça marche ». Clair et reproductible.

Ajoutez des validations statiques : validateur CIDR, interdiction des préfixes qui se chevauchent sans validation explicite, contrôle que les nouvelles routes ne coupent pas l’accès internet. Et surtout, un journal « qui a validé quoi ». Vous transformez le chaos en méthode. Et les utilisateurs ne sont plus des bêta-testeurs à leur insu.

FAQ : réponses courtes aux questions fréquentes

Pourquoi Internet disparaît-il après connexion au VPN ?

Le plus souvent, le client VPN capte la route par défaut (full tunnel) mais la route retour vers Internet n’est pas configurée ou est bloquée par un kill switch. Vérifiez la table : présence de 0.0.0.0/0, 0.0.0.0/1, 128.0.0.0/1, leurs métriques. Lancez un traceroute vers une IP publique : si premier saut dans le tunnel, Internet doit passer par là. Sinon, regardez du côté DNS (résolveur pointant sur serveurs internes inaccessibles) ou MTU (paquets gros qui coincent). Test rapide : baissez le MSS, mettez un DNS public temporaire, vérifiez si kill switch est actif, restaurez la symétrie des routes.

Comment résoudre un conflit de sous-réseaux identiques client/entreprise ?

Trois options : 1) réadressage côté entreprise (fiable, mais long), 2) NAT temporaire sur la sous-réseau en conflit au bord du VPN (rapide, mais complexe), 3) policy-based routing avec routes explicites sur préfixes corrects et métrique relevée sur la route générale côté client. Commencez par diagnostiquer : route print ou ip route, identifiez la route prioritaire. Ajoutez des préfixes plus spécifiques dans la config VPN pour l’emporter sur la route générale. Vérifiez routes retour sur serveurs et règles firewall. Et consignez le conflit dans un registre des adresses pour l’éliminer définitivement, pas seulement soigner les symptômes chaque mois.

Que choisir : split tunneling ou full tunnel ?

Pour priorité sécurité et contrôle, prenez full tunnel. Pour performance et économie sur trafic public, privilégiez split. Option intermédiaire : full tunnel avec breakout local au gateway ou approche SASE, où le point le plus proche applique politiques et délivre trafic internet. Ne négligez pas DNS et MTU : un ordre mal configuré en split peut générer « invisibilité » des services internes ou fuites. Idéalement, pilotez sur canaris, mesurez métriques, puis déployez à grande échelle. Choisir à l’aveugle mène souvent à retravailler.

Pourquoi les pings passent mais les sites ne s’ouvrent pas ?

Le ping utilise ICMP, les sites TCP/UDP sur HTTP(S). Si ICMP fonctionne mais TCP bloque, vérifiez MTU et MSS : peut-être que les gros segments sont tronqués en route et que PMTUD est bloqué par filtrage ICMP Fragmentation Needed. Autre piste : DNS. IP accessible, nom non ? Vérifiez via quel résolveur passent les domaines et si les requêtes sortent bien via VPN. Troisième hypothèse : firewall ou inspection SSL bloquant le trafic non attendu (exemple QUIC). Mettez un sniffer : si vous voyez SYN sans SYN-ACK, cherchez la route retour et filtre côté serveur.

Comment prioriser une interface réseau et ses routes ?

Sur Windows, désactivez auto-metric et fixez InterfaceMetric sur l’interface VPN, puis affectez RouteMetric sur les routes importantes. Vérifiez avec Get-NetRoute et route print. Sous Linux, ne regardez pas que ip route, mais aussi ip rule : la priorité des règles peut rediriger le trafic dans une autre table. Sur macOS, configurez l’ordre des services avec networksetup, validez via route -n get. Sur toutes plateformes : métrique plus basse et préfixe plus long gagnent. Documentez tout pour éviter la magie et savoir qui a quoi.

Comment diagnostiquer les problèmes uniquement en IPv6 ?

Assurez-vous d’abord que le VPN supporte IPv6 avec routes adéquates (ex. ULA et préfixes globaux). Lancez ping6/tracepath6 vers une IP v6 interne, inspectez ip -6 route ou route print -6. Regardez le DNS : les enregistrements AAAA doivent se résoudre via le résolveur corporate. Contrôlez le MTU : en v6, le PMTUD est essentiel et bloquer ICMPv6 casse les connexions. Si l’app en v6 sort hors VPN à cause de Happy Eyeballs, ajustez la politique : soit les deux stacks passent par VPN, soit le v6 est désactivé sur certaines routes. Logs client VPN et sniffer fourniront la réponse finale.