Aucune route ne répare un pool VPN qui chevauche votre LAN

L’application annonce un tunnel sain, et pourtant la moitié des destinations dont vous avez besoin ne répondent jamais. Le réflexe est d’ajouter une route ou de baisser une métrique, et ce réflexe est justement le mythe à tuer en premier. Quand le LAN du client et le pool du tunnel revendiquent le même préfixe, la table de routage tient deux faits incompatibles, et ni une route par défaut ni une métrique ne les résout. La réparation est une décision d’adressage, et aucune édition de route ne la remplace.

Pourquoi une route supplémentaire ne peut pas scinder un préfixe

Une route ne peut pas séparer deux revendications sur un même préfixe, c’est pourquoi le geste sensé est d’arrêter de chercher la bonne ligne de route. La pile ne placera pas un préfixe identique devant la route connectée, et une entrée plus spécifique capture bien l’adresse, mais rend l’hôte local qui la possède injoignable. Ce qui ressemble à un problème de routage est une collision d’adressage, et les deux réparations changent des adresses plutôt que des routes. Testez l’affirmation sur votre propre machine avant de l’accepter.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Interrogez le système sur une seule adresse et notez quelle interface il nomme. Linux, macOS et Windows répondent chacun par une recherche en lecture seule qui indique l’interface choisie et le saut suivant sans rien transmettre. Quand la réponse désigne l’adaptateur physique alors que le tunnel est actif, le noyau traite l’adresse comme locale au lien et non comme une adresse que le tunnel pourrait porter.

Placez le préfixe accordé par le fournisseur à côté de celui que sert le routeur domestique et comparez-les comme des chaînes. La correspondance exacte est le cas évident, et un pool plus large du fournisseur qui contient le sous-réseau domestique échoue de la même façon tout en étant plus facile à manquer. Deux préfixes qui se ressemblent seulement ne sont pas une collision, alors notez les deux avant de changer quoi que ce soit.

Lisez le pool que le client a réellement reçu

Lisez ce que le client a reçu, pas la page marketing du fournisseur. Montez la verbosité du journal d’un client OpenVPN et les routes poussées par le serveur y apparaîtront, révélant les préfixes du tunnel ; ailleurs le pool apparaît dans les détails de connexion ou sur l’adaptateur lui-même. Demandez au fournisseur la liste complète des plages privées qu’il utilise, car un seul /24 aujourd’hui peut en faire deux demain. Éviter les blocs RFC 1918 courants n’est pas la même chose qu’éviter l’allocation qui vous a réellement été donnée.

Un pool peut aussi se réduire ou se déplacer entre régions, la liste a donc besoin d’une date et d’un responsable. Traitez toute réponse du fournisseur plus ancienne que votre dernier changement de plan comme une conjecture, pas comme un fait. Redemandez avant de vous engager sur une plage, et gardez la réponse avec les notes réseau pour que la personne suivante hérite de la preuve.

La renumérotation est la réparation que vous pouvez faire

Si le serveur VPN n’est pas à vous pour le changer, déplacer le LAN domestique est la seule réparation disponible, et c’est la situation habituelle avec un fournisseur commercial. Choisissez une plage hors du pool du fournisseur et hors des plages dont vous pourriez avoir besoin plus tard, et vérifiez-la contre chaque autre site que vous atteignez par un tunnel. Attendez-vous à une courte coupure et à une traîne plus longue d’appareils oubliés : celui qui garde encore l’ancienne adresse semble fonctionner jusqu’à ce qu’il ait besoin de la passerelle.

1. D’abord l’inventaire : l’adresse du routeur lui-même, la plage DHCP, les réservations, les redirections de port et tout appareil dont l’adresse a été saisie à la main.
2. Changez ensuite le préfixe LAN du routeur et la plage DHCP ensemble dans une fenêtre de maintenance, et renouvelez les baux filaires avant les sans-fil.
3. Corrigez ensuite les adresses statiques : imprimantes, stockage réseau, tout ce qui a une passerelle codée en dur.
4. Enfin, reconnectez le client VPN et confirmez que l’adresse du tunnel n’entre plus en collision avec le LAN.

Parcourez les adresses dans cet ordre plutôt que toutes à la fois, et gardez l’ancienne plage documentée un moment pour qu’un appareil obsolète soit reconnaissable plutôt que mystérieux. Un appareil qui ne renouvelle jamais s’annonce en n’atteignant pas la passerelle, ce qui est un indice bien meilleur qu’un appel au support. Si le routeur distribue des baux de plus d’un jour, raccourcissez-les pendant la durée de la fenêtre.

Ce qu’un alias peut faire et ne peut pas faire

Quand le serveur est à vous, traduire les adresses sur le client peut exposer le préfixe distant dans une plage locale libre, si bien que le même hôte répond à une seconde adresse. L’OpenVPN communautaire le fait avec client-nat, et cette directive est propre à ce client, absente des clients commerciaux et mobiles auxquels on la compare d’ordinaire. Le montage exige une route qui corresponde à la traduction, une plage libre pour l’alias et un serveur prêt à répondre à l’adresse non traduite du client. Rien de tout cela n’aide quand le client appartient à un fournisseur géré que vous ne pouvez pas configurer.

Une fois le changement en place, atteignez un hôte local et un hôte distant d’abord par adresse puis par nom, en notant la route que le système choisit chaque fois. Un nom peut encore se résoudre dans l’ancienne plage, aussi les adresses et les noms méritent des vérifications indépendantes. Redémarrez un client et un appareil côté serveur si l’un des deux est resté allumé pendant le changement, car les entrées de voisinage en cache survivent à l’édition.

Écrivez les préfixes retenus là où les gens regardent vraiment : les notes réseau, le champ de commentaire du routeur, la page d’accueil. Quelqu’un choisira de nouveau 192.168.1.0/24, et la collision reviendra avec lui.