Votre pool VPN n'est pas la plage DHCP du LAN : pourquoi ça casse

Le raccourci tentant est de donner aux clients VPN des adresses de la même plage que celle qu'utilise le serveur DHCP du bureau, en partant de l'idée que tout n'est de toute façon qu'un seul réseau. Ce n'est pas le cas. Un tunnel routé transporte des paquets unicast entre deux extrémités, tandis que le pool du LAN existe pour répondre aux requêtes de diffusion sur un segment physique. Réutiliser les numéros place deux allocateurs responsables d'un même espace d'adresses et laisse le chemin de retour indéfini.

Deux allocateurs, un espace d'adresses

Le serveur DHCP du LAN sait quelles adresses il a louées et à quelle adresse MAC, et il les défend avec ARP. Le serveur VPN a son propre pool et ne sait rien de ces baux. Aucun des deux n'a tort ; on ne les a jamais présentés l'un à l'autre.

Une adresse du pool du LAN que le serveur VPN attribue peut déjà appartenir à une imprimante. Désormais deux appareils revendiquent une adresse sur le même préfixe, et la table de transfert du commutateur décide lequel répond.

C'est la panne que les gens rencontrent en premier : un client qui se connecte correctement puis atteint la mauvaise machine, ou atteint la bonne par intermittence.

Pourquoi le routeur ne distribue pas d'adresses VPN

La découverte DHCP est une diffusion, et les diffusions s'arrêtent à une frontière routée. À moins que la conception ne ponte le tunnel ou n'exécute un relais DHCP avec l'autorité correspondante, la requête du client n'atteint jamais le serveur du LAN.

Le serveur VPN attribue donc l'adresse lui-même : un pool dans la configuration du serveur, une adresse par pair dans une installation WireGuard, ou une adresse poussée par la couche d'authentification dans un déploiement IKEv2. Ces mécanismes sont indépendants de la base des baux du LAN, et c'est précisément pourquoi ils ont besoin de leur propre plage.

Le même raisonnement explique pourquoi modifier l'étendue DHCP ne répare pas un client VPN qui n'obtient jamais d'adresse. Le client n'interroge pas le serveur du LAN, et aucune édition de l'étendue ne l'y contraindra.

Le chevauchement se manifeste comme un conflit, pas comme un réseau lent

Deux réseaux qui partagent un préfixe sans conception prise en charge sont un problème différent de la double propriété, et on les confond souvent. Si le pool VPN est un préfixe distinct, le chevauchement ne compte que lorsqu'une route envoie le trafic du mauvais côté. Si le pool se trouve dans le préfixe du LAN, le conflit est immédiat et local.

En pratique, vous voyez des réponses ARP provenant du mauvais appareil, des connexions qui se réinitialisent à mi-chemin, et un client dont quelqu'un d'autre revendique sa propre adresse. Rien de tout cela ne ressemble à un problème de routage, c'est pourquoi le correctif est appliqué à la mauvaise couche. Un bail en double est facile à confirmer et pénible à supporter. Il survit aussi aux redémarrages, parce que les deux allocateurs continuent d'insister sur la même adresse.

Le chemin de retour est un problème distinct

Même avec un pool propre et distinct, les hôtes du LAN doivent savoir comment répondre à un client. Leur passerelle par défaut est le routeur, et le routeur a besoin d'une route pour le pool pointant vers le serveur VPN, sauf si la conception traduit plutôt le trafic du client.

Lisez le chemin dans les deux sens avant de changer quoi que ce soit. Sur la passerelle, demandez quelle interface le noyau utiliserait pour une adresse de client ; sur le client, demandez quelle route il utilise pour une adresse du LAN.

Ces commandes montrent la décision de transfert sur la passerelle et les entrées de voisinage qui révèlent un doublon :

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Si la première commande répond avec l'interface du tunnel, la route de retour existe. Si elle répond avec l'interface du LAN, le routeur croit que le client est sur le câble et tentera un ARP pour lui.

Les conceptions pontées existent, mais il faut les choisir

Ponter un tunnel vers le LAN est une conception réelle, utilisée lorsque les clients doivent recevoir des diffusions ou être découverts par des protocoles qui supposent un seul segment. Elle exige que le serveur possède ce comportement de pont et la gestion d'adresses qui l'accompagne.

Ce qui ne fonctionne pas, c'est d'imiter le résultat en copiant des numéros. Un pool partagé sans pont vous donne le conflit sans la découverte, ce qui est le pire des deux arrangements.

Choisissez la couche trois avec un pool distinct, sauf si l'application a vraiment besoin du segment, et documentez le pool pour que le prochain administrateur ne réutilise pas la plage DHCP par souci de propreté.