Deux clients VPN, une table de routage : qui remporte la route par défaut

On croirait deux clients VPN qui se disputent la même socket, et la correction évidente serait d’en désinstaller un. En pratique, ils touchent rarement la même socket. Chaque connexion réécrit la table de routage du système d’exploitation, et un profil de tunnel complet revendique la route par défaut. Celui qui s’est connecté en dernier l’emporte généralement, et c’est pourquoi le symptôme semble se déplacer d’un client à l’autre.

Le conflit vit dans la table de routage

Un adaptateur virtuel plus une route par défaut, voilà comment un tunnel complet capture le trafic. Quand le second client installe sa propre route par défaut, l’entrée plus ancienne est remplacée ou rétrogradée par la métrique, et chaque destination passe désormais par le tunnel le plus récent. Le premier client reste connecté et affiche toujours une icône verte : l’interface est active alors que le chemin a disparu. C’est cette séparation entre l’état de connexion et l’état de routage qui rend le comportement déroutant.

Les clients sont les éditeurs d’une table partagée. Savoir quelle modification est survenue en dernier explique presque tous les symptômes.

Lisez quel tunnel possède le chemin actuel

Vérifiez la décision réelle au lieu de faire confiance au client qui se déclare connecté. Demandez au système quelle interface porterait une destination précise.

ip route get 10.20.0.5
route print -4

La première commande nomme l’interface et l’adresse source pour une destination, et c’est exactement la question qui vous intéresse. Le vidage des routes montre sous Windows les entrées par défaut concurrentes et leurs métriques, vous voyez donc laquelle gagne actuellement. Lancez la recherche pour un hôte de chaque réseau distant, car une destination peut être correcte alors que l’autre réseau est injoignable. Si la réponse nomme le mauvais tunnel, se reconnecter n’aidera pas ; la politique de routage doit changer.

Empêchez le second client de tout revendiquer

Un client devrait posséder la route par défaut, et l’autre ne devrait porter que ses propres préfixes. OpenVPN les clients peuvent refuser ce que le serveur pousse.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignore chaque route poussée, tandis que pull-filter ignore "redirect-gateway" ne supprime que la directive de route par défaut et conserve le DNS et les autres options poussés. Choisissez entre les deux selon la part de configuration du serveur que vous voulez encore, puis ajoutez les préfixes précis dont le second réseau a besoin. Gardez le DNS en tête, car un résolveur poussé par un tunnel qui ne porte pas les requêtes ne renvoie rien. Testez un hôte connu dans chaque réseau et confirmez l’adresse source que voit le côté distant.

Les sous-réseaux qui se chevauchent ne se contournent pas

Quand les deux réseaux publient le même préfixe, le noyau détient une entrée pour deux endroits différents et doit choisir. Une route d’hôte ne peut pas inventer la distinction manquante, et un ajustement de métrique non plus. Renumérotez un côté, ou faites traduire la plage distante par son administrateur pour que les préfixes diffèrent. Vérifiez les sous-réseaux réels avant d’accuser les clients, car la valeur par défaut 192.168.1.0/24 d’un routeur domestique entre en collision avec une plage de bureau plus souvent qu’on ne l’attend. Notez les deux plages dans le ticket pour que la prochaine modification ne recrée pas le chevauchement.

Séparez aussi deux objectifs : atteindre les deux réseaux est un problème de routage, tandis qu’enchaîner des tunnels pour la confidentialité est une autre conception, avec un opérateur de plus sur le chemin. N’utilisez pas l’un pour résoudre l’autre.