Pourquoi une réservation DHCP n’est pas une IP fixe pour votre serveur VPN
Une réservation correspond à un identifiant de client, pas à une machine, et elle ne rend jamais votre IP publique fixe. Ce qui déplace réellement l’adresse d’un serveur VPN domestique.
J’ai déplacé un boîtier VPN domestique du Wi-Fi vers l’Ethernet et son adresse « permanente » a changé le soir même. Rien sur le routeur n’était cassé. La réservation correspondait à l’adaptateur sans fil, et cet adaptateur n’était plus sur le chemin.
La même idée fausse a une seconde moitié. Corriger l’adresse LAN ne fait rien pour l’adresse à laquelle vos amis se connectent, et cela n’a rien à voir avec le pool privé que le VPN remet aux clients. Trois adresses, trois modes de défaillance distincts, et un seul d’entre eux est le travail d’une réservation.
Une réservation correspond à un client, pas à un appareil
En DHCPv4, la réservation est liée à l’adresse matérielle du client ; en DHCPv6, elle est liée à un DUID que le client est censé conserver. Le champ hostname est une étiquette pour les humains. Ce que le routeur compare réellement, c’est l’identifiant qui arrive dans la requête.
Lisez l’entrée comme une condition : quand cet identifiant demande, donnez-lui cette adresse. Les renouvellements gardent le même bail tant que la correspondance tient, et un redémarrage demande simplement à nouveau. Quand l’identifiant change, la requête rate la réservation et le client prend ce que le pool dynamique propose. Pas d’erreur, pas d’avertissement, juste une autre adresse.
OpenWrt montre la forme clairement. Un bloc config host dans /etc/config/dhcp lie un nom, une MAC et une adresse, et la documentation des baux statiques explique comment cette entrée interagit avec le pool. D’autres routeurs cachent les mêmes trois champs derrière des libellés différents.
Où la correspondance se casse en silence
Changer de matériel est le cas courant. Changez la carte réseau, ou déplacez la machine entre Ethernet et Wi-Fi, et l’adresse que voit le routeur change avec elle. L’ancienne réservation reste dans la liste, toujours d’apparence correcte.
Une réinstallation est le deuxième cas, et elle mord le plus fort en IPv6. Une installation neuve peut générer un nouveau DUID alors que l’ancien bail IPv4 est encore valide, donc l’adresse v4 survit un moment et l’entrée v6 cesse de s’appliquer sans aucune modification visible.
Le troisième est un identifiant de client épinglé. Plusieurs clients DHCP permettent de définir une chaîne d’identifiant au lieu d’utiliser la MAC. Si une mise à jour ou une réécriture de la configuration abandonne ce réglage, la correspondance disparaît même si la machine n’a pas bougé.
Le quatrième est la duplication : un bloc périmé et un bloc neuf pour le même hôte. Le serveur répond avec la règle qui correspond, souvent l’adresse du pool que vous vouliez éviter. Supprimez l’entrée périmée au lieu d’en ajouter une seconde.
Configuration côté hôte et ce qu’elle coûte
Définir l’adresse sur l’hôte supprime entièrement la question de la correspondance. L’interface monte avec cette adresse que DHCP réponde ou non, et c’est ce que vous voulez d’une machine qui doit rester joignable après un redémarrage du routeur.
Le coût, c’est la propriété. Vous fournissez désormais le préfixe, la passerelle et les résolveurs, et vous devez garder l’adresse hors du pool dynamique vous-même. Sous Ubuntu avec netplan, /etc/netplan/01-vpn.yaml la porte :
network:
version: 2
ethernets:
eth0:
dhcp4: false
addresses: [192.168.50.10/24]
routes:
- to: default
via: 192.168.50.1
nameservers:
addresses: [192.168.50.1]Les utilisateurs de NetworkManager arrivent au même état avec nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, puis nmcli con up "Wired connection 1". Appliquez netplan avec netplan try au premier essai plutôt qu’avec netplan apply ; une passerelle mal tapée sort la machine du réseau et vous laisse chercher une console.
Gardez quand même une réservation correspondante. Elle n’est pas redondante. L’entrée enregistre l’adresse côté routeur et empêche le serveur DHCP de donner cette adresse à un appareil invité si quelqu’un élargit le pool plus tard.
Une adresse LAN stable n’est pas un point de terminaison public
Pointez la redirection de port vers 192.168.50.10 et la règle survit à chaque changement côté LAN. Elle ne vous donne pas une adresse internet stable. Votre IP publique appartient au fournisseur d’accès et peut bouger lors d’une reconnexion ou d’un changement de modem, ce à quoi sert le DNS dynamique.
Derrière un NAT de niveau opérateur, il n’y a aucune IPv4 publique à rediriger, et aucune réservation n’en crée une. Vérifiez d’abord la page WAN du routeur : si l’adresse est dans une plage partagée, la redirection entrante ne peut pas fonctionner, aussi propre soit la réservation.
La troisième adresse est le pool du tunnel, souvent quelque chose comme 10.8.0.0/24. Ces adresses n’existent qu’à l’intérieur du tunnel et n’apparaissent jamais sur le LAN. Les confondre avec l’adresse LAN du serveur, c’est ainsi qu’un port finit redirigé vers un client qui n’est en ligne que tant qu’il est connecté.
Vérifiez le chemin dans l’ordre où il casse
Commencez par le routeur. Comparez l’entrée de la table des baux à la cible de la réservation ; si le serveur a pris une adresse du pool, l’identifiant est faux, et ip link show sur l’hôte vous donne la valeur à comparer.
Puis l’hôte. ip -4 addr show eth0 devrait rapporter l’adresse et le préfixe attendus. Une seconde adresse sur la même interface signifie généralement que DHCP tourne encore à côté de votre configuration statique.
Puis la redirection. Confirmez que la destination est toujours égale à l’adresse que vous venez de vérifier, et confirmez que quelque chose écoute avec ss -lntp. Une redirection vers un port fermé ressemble exactement, de l’extérieur, à une redirection cassée.
Terminez depuis l’extérieur, sur un téléphone avec le Wi-Fi coupé. Ce seul test sépare « l’adresse locale est fausse » de « l’accessibilité publique est cassée », les deux problèmes que cette installation ne cesse de mélanger.
Notez les trois adresses, LAN, publique et pool du tunnel, et précisez quel système possède chacune. Quand une connexion échouera le mois prochain, vous saurez laquelle inspecter au lieu de changer les trois d’un coup.