Pourquoi un sous-réseau contourne encore la route par défaut du VPN

Vous basculez le VPN en tunnel complet, la majorité du trafic obéit, puis une adresse répond directement — une imprimante, un NAS, un hôte de rebond en 10.x. La lecture évidente est que le tunnel fuit, alors vous baissez la métrique de la route par défaut et rien ne change. Cette tentative ratée est l’indice : une route par défaut est un recours, pas un verdict. La recherche de route prend le préfixe correspondant le plus long avant même de comparer les métriques, donc un /24 continue de l’emporter sur un /0 quel que soit le nombre que vous accrochez à l’un ou l’autre. Une fois cet ordre clair, la fuite est généralement une route que quelqu’un a installée exprès, ou un préfixe que le client n’a jamais eu l’intention de couvrir.

Ce qu’une route par défaut promet vraiment

0.0.0.0/0 correspond à toute destination IPv4 avec zéro bit de spécificité. Elle existe pour qu’un hôte puisse atteindre tout ce que sa table ne décrit pas mieux. Une route vers 192.168.1.0/24 porte 24 bits correspondants, donc pour 192.168.1.40 elle l’emporte avant que quiconque compare les métriques, la distance administrative ou quoi que le client appelle son champ de priorité. La même règle vaut dans la FIB de Linux, la table de routage de Windows et la pile BSD derrière macOS.

Sur un LAN normal, ce comportement est une fonctionnalité. Le sous-réseau local est directement attaché, l’imprimante continue de fonctionner pendant que le tunnel transporte votre navigation, et rien n’est mal configuré. La question qui vaut la peine n’est pas pourquoi cette adresse passe en direct, mais quel préfixe dans quelle table y correspond, et qui l’y a mis.

Demi-routes par défaut, ou pourquoi l’entrée par défaut peut sembler intacte

L’exemple le plus net est redirect-gateway def1 d’OpenVPN. Au lieu de supprimer votre route par défaut et de la remplacer, il ajoute 0.0.0.0/1 et 128.0.0.0/1. Ensemble, la paire couvre tout IPv4, chaque préfixe est plus long que /0, et les deux battent la route par défaut du routeur tout en la laissant en place. Lancez un listing de routes ensuite et la route par défaut d’origine est toujours là, pointe toujours vers votre passerelle ; elle n’est simplement jamais sélectionnée pour les destinations internet.

Le wg-quick de WireGuard obtient le même résultat par routage par politique. Quand AllowedIPs couvre 0.0.0.0/0, il crée sa propre table, y envoie les paquets marqués et ajoute une règle qui ignore le préfixe de longueur nulle de la table principale. La table principale conserve son entrée par défaut, et les règles décident que la table du tunnel est consultée en premier pour le trafic que l’interface possède.

Les deux conceptions ont besoin d’exactement une route hors du tunnel : une route d’hôte vers l’adresse du serveur VPN lui-même via la passerelle d’origine. Sans elle, le client tenterait de transporter dans le tunnel les paquets qui construisent le tunnel, et la connexion ne s’établirait jamais. Une route non-tunnel dans votre table est donc normale même sur un profil strict de tunnel complet. Les routes qui méritent d’être questionnées sont celles qui couvrent des destinations qui vous importent vraiment.

Les métriques décident des égalités, les préfixes décident des gagnants

Les métriques ne sont comparées qu’entre candidats qui correspondent aussi bien à la destination. Sous Linux, ip route get 10.20.5.9 affiche le gagnant avec sa table, et ip route show table all liste les candidats, y compris les éventuelles demi-routes par défaut et toute table vers laquelle une règle pointe. Sous Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 renvoie la route sélectionnée et l’adresse source, tandis que Get-NetRoute montre la table brute — mais le coût effectif est la métrique de route plus la métrique d’interface, donc un adaptateur lent peut perdre une égalité qu’il semble gagner.

Trois cas couvrent l’essentiel de ce que vous verrez :

• Même destination, /24 contre /0 : le /24 gagne sur la longueur du préfixe, quoi que disent les métriques.
• Même destination, deux /24 avec des métriques différentes : la métrique effective la plus basse gagne.
• Même destination, deux tables, une choisie par une règle de stratégie : la règle choisit d’abord la table, et la comparaison de préfixes a lieu à l’intérieur.

Le troisième cas est celui où finissent la plupart de ces rapports. Une ip rule sous Linux ou un filtre de trafic VPN de Windows peut envoyer le trafic vers une table qui n’a jamais contenu la route par défaut du tunnel, et la table principale paraît parfaite tout le temps.

À qui appartient généralement le contournement

Commencez par le profil, pas par la table. Les configurations split-tunnel et les réglages VPN par application laissent délibérément des préfixes nommés hors du tunnel ; un profil de travail qui protège un sous-réseau privé et laisse la navigation générale passer en direct se comporte comme prévu, et le contourner rompt la politique qu’il devait appliquer. Le guide de routage VPN de Microsoft trace la même frontière entre trafic forcé dans le tunnel et exceptions explicites, ce qui en fait une contre-vérification utile avant de modifier quoi que ce soit.

Cherchez ensuite les restes. Une route qui pointe vers une interface qui n’existe plus, ou vers une adresse de l’ancien réseau, apparaît après le passage de stations d’accueil, d’adaptateurs USB et de ponts de conteneurs. La supprimer une fois n’y met pas fin : les profils de connexion NetworkManager, les fichiers netplan et les routes persistantes de Windows la réinstallent à la prochaine connexion ou au prochain démarrage, alors trouvez le fichier ou le profil qui la possède avant de modifier quoi que ce soit.

Vérifiez ensuite IPv6 séparément. ip -6 route et Get-NetRoute -AddressFamily IPv6 tiennent un état distinct, des routes par défaut distinctes et un comportement client distinct. Un audit limité à IPv4 ne dit rien d’un hôte double pile qui préfère discrètement un chemin IPv6 natif, et cela seul peut faire passer un client pour un split-tunnel.

Confirmez avec le flux de l’application elle-même

Notez la destination que l’application utilise réellement, puis demandez au système le chemin qu’il prendrait depuis l’adresse source à laquelle cette application se lie. ip route get 10.20.5.9 from 192.168.1.40 répond à cela sous Linux ; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus l’adresse locale le fait sous Windows. Comparez le résultat avec ce que le profil affirme. La page d’IP publique d’un navigateur teste une destination sur un protocole et ne dit rien de l’adresse privée qui a lancé la plainte.

Corrigez l’objet le plus étroit qui explique la différence. Si l’exception est approuvée, notez le préfixe et laissez-le ; sinon, retirez la route ou ajoutez une route plus étroite explicite par le tunnel au lieu de baisser la métrique de la route par défaut. Baisser une métrique ne peut pas devancer un préfixe plus long, et modifier la route par défaut alors que deux routes /1 possèdent le chemin internet ne change rien non plus.

Reconnectez ensuite le tunnel et répétez la même requête. Les clients réinstallent les routes à chaque connexion, donc un changement qui ne survit que jusqu’à la poignée de main suivante n’a pas été testé. Si le chemin diverge encore, les suspects restants sont une règle de stratégie, une seconde table ou un filtre côté client — pas la route par défaut.

• Nommez la destination et l’adresse source que l’application utilise réellement.
• Affichez la route gagnante avec ip route get ou Find-NetRoute.
• Vérifiez si une paire /1 ou une table de stratégie possède le chemin internet.
• Listez chaque préfixe plus long que /0 qui correspond à la destination.
• Répétez la vérification IPv6 séparément.
• Remontez la route survivante jusqu’au fichier, au profil ou au filtre qui l’installe.
• Reconnectez et relancez la requête avant de la déclarer corrigée.

Si les sept concordent avec le profil, le tunnel fait exactement ce pour quoi il a été configuré, et la correction appartient au profil plutôt qu’à une métrique.