Pourquoi votre table de routage VPN Windows affiche 0.0.0.0/1 et 128.0.0.0/1

Connectez-vous à un VPN Windows et ouvrez la table de routage, et deux entrées ressortent : 0.0.0.0/1 et 128.0.0.0/1. Ce ne sont pas des fautes de frappe et elles ne remplacent pas la route par défaut. Leur présence dépend d’une option de profil, et la paire est la façon dont un tunnel complet est construit, pas une fonction de tunnel divisé. Lisez l’option, le préfixe et l’interface ensemble avant de changer une seule ligne.

Ce que l’option de passerelle par défaut installe

L’option de profil qui fait tout passer par le tunnel fonctionne en ajoutant ces deux préfixes. Décochez l’option et elles disparaissent, laissant une route qui ne couvre que le sous-réseau remis à l’adaptateur du tunnel. La case contrôle la paire ; elle ne réécrit pas l’unique route par défaut. C’est pourquoi la table après décochage ressemble à une réécriture partielle plutôt qu’à une suppression.

0.0.0.0/1 couvre la moitié basse de l’espace IPv4 et 128.0.0.0/1 la moitié haute, donc ensemble elles couvrent toutes les adresses unicast. Chacune est plus spécifique qu’une route par défaut 0.0.0.0/0, ce qui signifie que la correspondance du préfixe le plus long envoie le trafic ordinaire dans le tunnel tandis que la route physique par défaut reste là où elle était. Conserver cette route par défaut n’est pas cosmétique : les paquets qui encapsulent la charge chiffrée sont adressés à l’adresse publique du serveur et doivent sortir par l’adaptateur physique. Remplacez la route par défaut au lieu de la diviser, et le transport du tunnel lui-même tentera d’entrer dans le tunnel, ce qui est une boucle et non une connexion.

Une 0.0.0.0/0 littérale pointant vers l’adaptateur VPN mérite donc qu’on s’y arrête. Le client natif n’en écrit normalement pas, donc une route manuelle ou la configuration d’un autre client a modifié la table dans votre dos. Trouvez-la avant de déboguer quoi que ce soit en aval.

Le démontage coûte moins cher que de conserver une passerelle

Le démontage est l’argument pratique en faveur de deux entrées plutôt qu’une. Le client possède exactement deux routes pendant la connexion et les supprime à la déconnexion, laissant ce que l’adaptateur physique détient à ce moment-là. Un client qui aurait remplacé l’unique route par défaut devrait se souvenir de la passerelle précédente, et après un changement de bail DHCP il pourrait en restaurer une qui n’existe plus. Deux entrées possédées ne portent pas un tel état.

D’autres clients aboutissent au même dessin. Un profil OpenVPN avec redirect-gateway def1 installe ces deux préfixes au lieu de supprimer la route par défaut, et le client Windows suit le modèle pour la même raison de routage.

C’est aussi pourquoi une table peut ressembler à un tunnel complet quand vous attendiez une division. La paire est la façon dont le tunnel complet est construit, pas la preuve d’une erreur de tunnel divisé. Si le profil est réglé pour utiliser la passerelle distante, tout est routé, quoi qu’une application locale parvienne encore à atteindre.

Le préfixe le plus long gagne avant toute métrique

La longueur du préfixe décide de la recherche avant tout autre champ. La métrique ne départage que les routes de préfixe identique, donc une entrée /1 bat une route par défaut /0 même quand sa métrique est moins bonne. La liaison à l’interface décide de ce qui reste quand deux routes partagent un préfixe et que Windows doit choisir quel adaptateur envoie le paquet.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Une table de tunnel divisé contient la route physique par défaut, les deux demi-routes, la route du sous-réseau du tunnel et tout préfixe de bureau que vous avez ajouté. La route physique par défaut peut se trouver sur une métrique plus basse ou plus haute selon le client et le profil, et tant que la paire /1 existe, cette différence ne change rien. Elle change tout à l’instant où la paire est retirée, et c’est alors qu’une passerelle obsolète ou une mauvaise interface surgit. Lisez toute la table plutôt que la ligne que vous comptiez changer.

Choisissez un seul propriétaire pour le préfixe du bureau

Pour un tunnel divisé, ne nommez que le préfixe qui doit passer par le VPN, et choisissez une seule façon de le posséder. Pointer la route vers l’adresse de tunnel attribuée fonctionne jusqu’à ce que cette adresse change, tandis que la liaison à l’interface survit au changement d’adresse mais casse quand l’index est réattribué après la reconstruction du profil. La cmdlet liée au profil évite les deux problèmes, au prix de la nécessité du profil.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

La cmdlet lie le préfixe au profil nommé, donc la route apparaît avec la connexion et disparaît avec elle, ce que veut un portable géré. Une route persistante survit aux redémarrages et survit au profil qui l’a motivée, et c’est ainsi qu’un VPN retiré laisse des entrées pendant des années. Choisissez une méthode par préfixe et notez le choix, car une route persistante plus une route de profil pour le même préfixe produisent des doublons pénibles à démêler lors du démontage. Quel que soit votre choix, la propriété devrait être visible dans le ticket et pas seulement sur la machine.

La propriété est la question à laquelle cette section répond, pas la syntaxe. Deux propriétaires pour un préfixe est le mode de défaillance qu’il vaut la peine d’éviter.

Vérifiez avec une destination, pas avec un site web

Testez la destination qui doit traverser le tunnel, pas un site web qui annonce une adresse de sortie. Find-NetRoute renvoie la route sélectionnée et l’adresse source, de sorte que vous voyez si le préfixe du bureau ou la route physique par défaut a gagné, puis vous ouvrez le partage lui-même.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Un site d’adresse de sortie est un contrôle faible, car DNS, IPv6 et un proxy de navigateur peuvent chacun envoyer cette requête par un chemin différent. IPv4 et IPv6 ont aussi des réglages séparés dans la même boîte de dialogue, et décocher une case laisse l’autre famille intacte, si bien qu’une machine à double pile peut porter IPv6 par le tunnel tandis qu’IPv4 suit la route divisée. Vérifiez les deux familles avant de qualifier le profil de divisé. Si la route est correcte et que le service échoue encore, la couche restante est le filtrage et non le routage.

Un pare-feu géré par le client peut bloquer le sous-réseau du bureau alors que la table de routage est parfaite. Cette politique appartient à celui qui a déployé le profil, pas à la personne qui modifie les routes.