Adresse VPN contre bail DHCP du LAN : qui attribue l’IP du tunnel ?

Connectez le client et regardez la carte réseau plutôt que l’icône Wi-Fi. Une adresse comme 10.80.0.14 peut se trouver sur un tunnel alors qu’aucun serveur DHCP du LAN du bureau n’a jamais enregistré ce bail. Le processus qui a choisi le numéro décide où commence le diagnostic.

Côté client, tout se ressemble : une adresse IPv4, un masque, parfois une passerelle par défaut. La différence n’apparaît que lorsqu’on demande qui répond de cette adresse et qui en tient un registre.

Lire l’adresse du tunnel depuis le client

Windows montre la distinction si l’on lit tout le bloc et non la première ligne. ipconfig /all imprime une description de carte, une adresse physique et une ligne DHCP. Une carte d’accès distant PPP ou IKEv2 signale normalement DHCP comme désactivé, parce que la connexion a négocié son adresse pendant l’appel au lieu de la louer à un serveur du LAN. Une carte de tunnel avec DHCP activé est inhabituelle et mérite une enquête à part.

Linux répartit la même information entre deux outils. ip -4 addr show dev tun0 donne l’adresse et la longueur du préfixe. nmcli -f IP4 connection show work révèle si la valeur vient du profil de connexion, d’un échange DHCP sur le lien ou d’une configuration poussée. WireGuard est le cas le plus net, puisque wg-quick applique la ligne Address du fichier de configuration quand l’interface apparaît et qu’aucun pair n’attribue quoi que ce soit à la connexion.

Le préfixe dit aussi quelque chose. Un /32, ou un masque de 255.255.255.255, signifie que la passerelle compte router vers une seule adresse d’hôte, alors qu’un masque plus large suggère un sous-réseau sur le lien quelque part derrière le tunnel.

Ce que transporte la charge de configuration IKEv2

IKEv2 dispose d’un mécanisme dédié à cette tâche. La charge de configuration décrite dans RFC 7296, section 3.15.1 transporte des attributs tels que INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS et leurs équivalents IPv6. Le client envoie un attribut de longueur nulle lorsqu’il n’a pas de préférence, et le répondeur renvoie la valeur qu’il veut voir utiliser. Cet échange circule dans IKE_AUTH, déjà chiffré, si bien qu’aucune diffusion DHCP ne traverse jamais le tunnel.

Deux conséquences en découlent. Premièrement, l’adresse est choisie par le répondeur ou par tout backend d’autorisation qu’il consulte, ce qui explique pourquoi un pool peut vivre sur la passerelle, dans une réponse RADIUS ou dans un mappage de fournisseur d’identité. Deuxièmement, l’attribut DNS est distinct de l’attribut d’adresse. Recevoir 10.80.0.14 ne dit rien du résolveur qui est revenu, ni même s’il en est revenu un.

L’attribut de masque réseau est facultatif en pratique. Beaucoup de déploiements ne renvoient qu’une adresse et laissent le client installer une route d’hôte, ce qui explique qu’un même pool puisse ressembler à un /32 sur un client et à un /24 sur un autre.

Là où une étendue DHCP du LAN et un pool VPN se heurtent

Le trouble commence quand les deux attributaires visent la même plage. Un serveur DHCP pour 10.20.30.0/24 ne sait rien d’un pool VPN configuré pour 10.20.30.128/25, donc rien ne l’empêche de louer 10.20.30.140 à une imprimante pendant que la passerelle remet la même adresse à un client distant. Le heurt reste silencieux des jours durant, puis se manifeste par un doublon intermittent.

Une conception routée de site à site évite le heurt par construction. Un hôte de l’agence garde l’adresse que son serveur DHCP local lui a donnée. Les interfaces de tunnel des deux passerelles portent leurs propres adresses de lien, et la table de routage décide du trajet des paquets. Les adresses des clients d’accès distant forment une troisième catégorie et ne doivent pas être mélangées aux adresses de lien de la passerelle.

Ponter le tunnel sur le LAN supprime cette séparation. Si la conception a réellement besoin d’un seul domaine de diffusion, le point de terminaison VPN doit participer aux mêmes décisions d’attribution que le serveur DHCP, via un relais ou une source faisant autorité partagée, au lieu d’émettre des adresses de son côté.

Prouver quel processus possède l’adresse

Prouvez la propriété avant de modifier une étendue. Sur le client, relevez l’adresse et le préfixe. Sur le LAN, cherchez dans la base des baux. Sur la passerelle, listez les pools qu’elle est configurée à distribuer. Une adresse trouvée dans le fichier des baux appartient à un serveur DHCP, ce qui signifie que le tunnel est ponté ou relayé ; une adresse trouvée seulement dans le pool de la passerelle appartient au point de terminaison du tunnel.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Notez quatre choses une fois la réponse claire : quel composant attribue l’adresse du client, quelle plage lui est réservée, comment le trafic de retour atteint cette plage et quelles ressources l’acceptent. Ces quatre entrées transforment une ligne de carte virtuelle en fait opérationnel.

Répétez le contrôle pour l’attribut DNS tant que vous y êtes. Un pool qui distribue des adresses sans résolveur laisse le client sur son DNS local, ce qui est une panne différente d’un pool qui distribue une adresse que le LAN utilise déjà.