Plan d'adressage, DHCP et résolution de noms sur un réseau contraint

Le contexte

Une infrastructure de lab qui doit cohabiter avec un réseau domestique existant, sur lequel je ne peux pas tout me permettre : la box opérateur reste le routeur et le serveur DHCP, et une coupure du réseau ne concerne pas que moi.

C'est une contrainte que je considère comme réaliste. En entreprise aussi, on hérite d'un existant qu'on ne remplace pas d'un coup.

L'objectif

Faire tenir une dizaine de machines de laboratoire sur un réseau que je ne contrôle qu'à moitié, sans conflit d'adresse, sans casser la résolution de noms du domaine, et sans dépendre d'un équipement que je ne maîtrise pas pour les services critiques.

Les décisions structurantes

Un réseau plat, assumé

Un découpage en VLAN était initialement prévu — segments serveurs, lab, administration — porté par un commutateur administrable.

J'y ai renoncé délibérément. La segmentation aurait ajouté une couche de complexité sur laquelle je n'avais pas assez de pratique pour la défendre sérieusement, et elle n'était nécessaire à aucun des services que je voulais démontrer. Un réseau plat maîtrisé vaut mieux qu'une segmentation approximative.

C'est le type d'arbitrage qui se reproduit en entreprise : la solution la plus élaborée n'est pas toujours celle qui rend le meilleur service.

Un bloc réservé plutôt qu'une réservation par machine

Le réseau utilise 192.168.1.0/24. Le relevé de l'existant a montré que les appareils domestiques occupaient les adresses basses et s'arrêtaient largement avant .200.

J'ai donc réservé le bloc .200 – .219 au lab, et réduit la plage DHCP de la box pour qu'elle s'arrête avant. Deux effets : aucune machine du lab ne peut recevoir une adresse déjà attribuée, et aucun nouvel appareil domestique ne peut se voir attribuer une adresse du lab.

L'alternative — une réservation DHCP par adresse MAC pour chaque machine — aurait fonctionné aussi, mais elle aurait rendu le lab dépendant de la box pour son adressage. Un redémarrage ou un remplacement de box, et toutes les réservations disparaissent.

Une convention de nommage porteuse d'information

L'identifiant de la machine virtuelle correspond au dernier octet de son adresse IP. La VM 106 porte le .206, la VM 104 le .204.

Sur une dizaine de machines, cette règle supprime toute ambiguïté lors des interventions : on ne consulte jamais un tableau pour savoir quelle machine on est en train d'arrêter.

Adresse	Machine	Rôle
.200	pve	Hyperviseur
.201	SRV-AD-01	Contrôleur de domaine, DNS
.202 / .203	PC-CLIENT-01/02	Postes clients
.204	SRV-ZABBIX-01	Supervision
.205	SRV-PBS-01	Sauvegarde
.206	SRV-FICHIER-01	Serveur de fichiers
.207	SRV-FOG-01	Déploiement
.254	Box opérateur	Passerelle, DHCP

Un écart documenté : le serveur de déploiement était initialement prévu en .205, adresse déjà attribuée au serveur de sauvegarde lors d'une révision antérieure du plan. Réaffecté en .207. C'est exactement la raison pour laquelle un plan d'adressage doit être un document unique et daté, pas une suite de décisions successives.

Le DHCP laissé sur la box, avec un complément

Migrer le rôle DHCP vers le contrôleur de domaine était envisagé et aurait été plus « propre ». Je ne l'ai pas fait : le risque de couper le réseau domestique était réel, et le gain pédagogique ne le justifiait pas.

En revanche, le démarrage réseau des postes exigeait de distribuer des options DHCP supplémentaires. La solution retenue est un serveur ProxyDHCP (dnsmasq) : il répond aux demandes de démarrage réseau sans distribuer d'adresses. La box continue son travail d'attribution ; le serveur ajoute seulement l'information « voici où trouver le fichier de démarrage ».

Aucun conflit entre deux serveurs DHCP, aucun risque pour le réseau domestique.

L'analyse de la séquence DHCP

J'ai capturé et analysé l'échange complet au niveau paquet avec Wireshark, pour vérifier ce que je croyais savoir.

La séquence en quatre temps :

Message	Émetteur	Mode	Contenu
Discover	Client	Diffusion	« Y a-t-il un serveur DHCP ? »
Offer	Serveur	Unicast ou diffusion	Une proposition d'adresse
Request	Client	Diffusion	« J'accepte celle-ci »
Ack	Serveur	—	Confirmation et configuration complète

Deux observations que la capture rend évidentes et qu'un schéma théorique ne montre pas.

Le Request est diffusé, pas envoyé au seul serveur choisi. C'est volontaire : il informe les autres serveurs DHCP éventuels que leur offre n'a pas été retenue et qu'ils peuvent libérer l'adresse qu'ils avaient réservée. Sans cela, chaque proposition non retenue immobiliserait une adresse.

L'Ack contient bien plus que l'adresse. Masque de sous-réseau, passerelle par défaut, serveurs DNS, durée du bail. C'est par ce message que le client reçoit toute sa configuration réseau — et c'est la réponse à la question « d'où un poste tient-il son serveur DNS ? ».

Le tout en UDP sur les ports 67 et 68, parce que TCP nécessiterait une connexion établie entre deux adresses connues — impossible quand le client n'a pas encore d'adresse et ignore celle du serveur.

Trois incidents DNS

Le point commun de ces trois incidents : aucun ne produit d'erreur explicite. Ils se manifestent ailleurs, plus tard, sous une forme qui ne pointe pas vers leur cause.

La zone inverse absente

La résolution directe fonctionnait, la résolution inverse non — la zone 1.168.192.in-addr.arpa n'avait jamais été créée à l'installation du service DNS.

Sans elle, tout outil qui interroge une adresse IP pour obtenir un nom renvoie un résultat vide : outils de supervision, journaux, diagnostics. Rien ne casse ; l'information disparaît simplement.

Le fichier de configuration DNS réécrit au démarrage

Sur un serveur Debian configuré en adressage statique, le fichier /etc/resolv.conf était réécrit à chaque démarrage. La résolution fonctionnait après correction manuelle, puis échouait au redémarrage suivant.

La cause : un reliquat de client DHCP installé par dépendance, qui reprenait la main au démarrage alors que l'interface était configurée en statique. Le diagnostic a consisté à vérifier qu'aucune unité systemd correspondante n'était active, puis à confirmer que la configuration statique de l'interface était bien la seule source de vérité.

IPv6, la localisation réseau et le DNS de la box

Le plus instructif, parce qu'il enchaîne deux problèmes liés.

Premier temps. IPv6 avait été désactivé au niveau de la carte réseau sur deux serveurs Windows. Conséquence inattendue : le service de localisation réseau ne parvenait plus à classer le réseau comme « authentifié par le domaine ». Toutes les règles de pare-feu limitées au profil Domaine ne s'appliquaient donc jamais — sans qu'aucune erreur ne soit signalée nulle part.

Second temps. Réactiver IPv6 a résolu la localisation, mais la box distribuait alors son propre serveur DNS en IPv6, prioritaire sur le DNS du domaine. La résolution des noms internes s'est effondrée, provoquant des échecs de jonction au domaine dont le code d'erreur ne mentionne à aucun moment le DNS.

La correction : activer IPv6 au niveau de la pile, désactiver DHCPv6 sur la carte, et vider explicitement les adresses de serveurs DNS IPv6. On garde ce dont le système a besoin pour fonctionner, on supprime ce que la box impose.

Le contrôleur de domaine pointe sur lui-même en 127.0.0.1, conformément à la recommandation pour un environnement à contrôleur unique.

Le résultat

Un plan d'adressage documenté et cohabitant sans conflit avec un réseau domestique actif, un démarrage réseau fonctionnel sans toucher au DHCP existant, une résolution de noms directe et inverse opérationnelle, et trois incidents remontés à leur cause racine.

Ce que j'en retiens

Une infrastructure qui fonctionne n'est pas nécessairement une infrastructure saine. Les trois incidents ci-dessus tournaient depuis des semaines sans rien casser de visible — jusqu'à ce qu'un service ajouté plus tard échoue pour une raison qui semblait sans rapport.

C'est aussi ce qui rend le DNS particulier : il ne tombe presque jamais. Il renvoie simplement une réponse incomplète, et c'est le service en aval qui échoue, avec un message qui ne mentionne pas le DNS.