DHCP : éviter les conflits d’IP avant qu’ils n’arrivent

Tu vois le moment où « plus rien ne marche » sur le réseau, alors que la veille tout allait bien. Les postes ont du Wi-Fi. Le switch est OK. Le serveur répond au ping. Et pourtant, impossible d’ouvrir un partage, l’ERP rame, l’imprimante réseau disparaît puis revient. Souvent, quand c’est instable comme ça, je pense à un truc bête mais violent : le conflit d’adresse IP.

Et oui, DHCP est là pour éviter ça. Enfin… DHCP bien configuré, bien surveillé, et avec des habitudes propres. Sinon, DHCP peut aussi devenir la source du chaos. Dans cet article, on va voir comment prévenir les conflits d’IP avant qu’ils n’arrivent, en mode terrain, comme on aime bien au BTS SIO2 SISR Tech Lab. Pas juste la théorie. Les petites pratiques qui font que, le jour où tu es en stage ou en alternance, tu ne te fais pas piéger.

Pourquoi un conflit d’IP fait aussi mal

Un conflit d’IP, c’est deux machines qui pensent avoir la même adresse. Résultat : ARP qui part en vrille, paquets qui arrivent « au mauvais endroit », sessions SMB qui sautent, RDP qui se coupe, et tu te retrouves à diagnostiquer un problème qui ressemble à un bug applicatif alors que non, c’est juste une collision.

Les symptômes typiques :

• message Windows « Conflit d’adresse IP détecté » (parfois)
• pertes de connectivité aléatoires
• imprimante qui imprime une fois sur deux
• téléphone IP qui se ré-enregistre en boucle
• machine qui répond au ping… mais ce n’est pas la bonne (celle-là est sournoise)

Et ce qui rend le truc pénible, c’est que ça peut être intermittent. Parce que l’un des deux équipements n’est pas toujours allumé. Donc tu crois avoir « résolu », puis ça revient trois jours après.

Petit rappel DHCP (mais juste ce qu’il faut)

DHCP, c’est le service qui attribue automatiquement :

• une adresse IP
• un masque
• une passerelle
• des DNS
• et parfois des options spécifiques (VoIP, PXE, etc.)

Le déroulé classique c’est DORA :

• Discover
• Offer
• Request
• Acknowledge

Le serveur loue l’IP avec un bail (lease). Quand le bail expire, le client renouvelle.

Et là, déjà, tu as un premier levier anti conflit : si ton serveur DHCP est l’unique source d’attribution, et qu’il a une base de baux cohérente, les collisions deviennent rares. Le problème, c’est que dans la vraie vie, il y a toujours « un truc » qui sort du cadre.

Les vraies causes des conflits d’IP (celles qu’on rencontre vraiment)

1. Une IP statique posée au hasard dans la plage DHCP

Classique absolu. Quelqu’un configure une caméra, une imprimante, un petit NAS… et met 192.168.1.50 « parce que c’est joli ». Sauf que DHCP distribue aussi cette plage, et un jour il attribue .50 à un PC.

Résultat : conflit.

2. Deux serveurs DHCP sur le même VLAN (sans le vouloir)

Le cas du routeur 4G branché vite fait « juste pour tester ». Ou la box Internet laissée en mode routeur. Ou un Windows Server avec DHCP installé dans un coin de lab, connecté au réseau prod par erreur.

Ça distribue des IP différentes, des passerelles différentes, parfois des DNS publics. Et les postes partent en sucette.

3. Une restauration de VM ou un clone mal préparé

Tu clones une VM qui a une IP statique. Ou pire, tu clones une VM DHCP mais avec un bail conservé et des identifiants réseau identiques dans certains contextes.

En lab, ça passe. En prod, ça peut faire mal.

4. Un équipement qui se croit plus malin que tout le monde

Certaines imprimantes ou IoT ont des modes « auto IP » (APIPA, fallback, etc.), ou des comportements hybrides : elles essayent DHCP, puis basculent en statique, puis reviennent.

Et toi tu vois juste un équipement qui change d’identité toutes les semaines.

5. Des baux trop longs dans un environnement mouvant

Dans une salle de cours, un parc de laptops, un atelier, un environnement avec beaucoup de mouvements, des baux DHCP de 8 jours ou 30 jours, ça augmente le risque que le serveur « pense » qu’une IP est encore utilisée alors que non. Ce n’est pas directement un conflit, mais ça favorise les bricolages, les exceptions, et donc les conflits.

La règle numéro 1 : séparer proprement statique et dynamique

Si tu ne fais qu’une chose après avoir lu cet article, fais ça.

Stratégie simple et efficace

• Plage statique (réservée aux équipements configurés à la main) : par exemple 192.168.10.1 à 192.168.10.49
• Plage DHCP dynamique : 192.168.10.50 à 192.168.10.200
• Plage « réservations DHCP » (optionnel) : tu peux les mettre dans la zone statique, ou au début de la dynamique, mais documente

L’idée : ne jamais avoir une IP statique qui tombe « par hasard » dans le pool.

Et documente. Même un tableau moche dans un wiki interne vaut mieux que rien. Sur le BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), on insiste souvent sur ce point : la doc réseau, ce n’est pas du luxe, c’est du temps gagné.

Utiliser les réservations DHCP (plutôt que des IP statiques)

Une réservation DHCP, c’est l’adresse IP fixée côté serveur, associée à une adresse MAC. Avantages :

• tu gardes la configuration centralisée
• tu évites les collisions dans le pool
• tu peux changer DNS, gateway, options sans te connecter à l’équipement
• tu peux tracer qui a quoi

Idéal pour :

• imprimantes
• bornes Wi-Fi
• téléphones IP
• caméras
• postes « fixes » en salle info
• serveurs… parfois (selon politique)

Attention quand même

• si l’équipement change de carte réseau, la MAC change, la réservation saute
• certaines équipes préfèrent du statique « dur » sur les serveurs. OK, mais alors hors pool, et proprement documenté

Détecter et éliminer les serveurs DHCP pirates

Côté Windows (simple et rapide)

Sur un poste client, fais :

powershell ipconfig /all

Regarde :

• « Serveur DHCP »
• « Serveurs DNS »
• « Passerelle par défaut »

Si tu vois l’IP d’une box, d’un routeur inconnu, ou d’un équipement non prévu, tu as une piste.

Tu peux aussi faire :

powershell ipconfig /release ipconfig /renew

Et observer ce qui répond.

Côté réseau

• Sur des switches managés, active DHCP snooping si possible.
• Bloque les ports « accès » pour qu’ils ne puissent pas émettre des réponses DHCP serveur.

DHCP snooping, c’est vraiment une arme anti chaos. Ça empêche un poste ou une box branchée au hasard de jouer au serveur DHCP.

Bien régler les baux DHCP (et arrêter les valeurs par défaut au hasard)

La durée de bail, ce n’est pas « au feeling », c’est lié à l’usage.

Quelques repères pratiques :

• environnement stable (bureaux fixes) : 3 à 7 jours, parfois plus
• environnement très mobile (invités, Wi-Fi, BYOD) : quelques heures à 1 jour
• réseau d’atelier ou salle de cours : 1 jour, souvent confortable

Trop long, tu gardes des baux inutiles, tu compliques le ménage. Trop court, tu génères plus de renouvellements, ce qui peut être un souci si ton infra est fragile, ou si tu as des liens lents. En LAN classique, ce n’est pas dramatique, mais autant rester cohérent.

Ajouter des exclusions DHCP (et savoir pourquoi)

Sur un serveur DHCP, tu peux définir des exclusions dans une étendue. Exemple : ton pool est .50 à .200, mais tu exclues .150 à .160 parce que c’est une plage temporaire dédiée à un lab.

Ça évite que DHCP distribue une IP que tu veux garder pour autre chose.

Mais… et c’est important… les exclusions ne remplacent pas un plan d’adressage clair. Elles servent à gérer des exceptions, pas à colmater un réseau mal organisé.

Surveiller les conflits avant les utilisateurs (logs, alertes, habitudes)

Sur Windows Server DHCP

Regarde :

• l’observateur d’événements (Event Viewer)
• les logs DHCP (souvent dans C:\Windows\System32\dhcp\)

Tu peux repérer des erreurs du style « adresse déjà utilisée », ou des refus d’attribution.

Sur le terrain : ping et ARP

Quand tu suspectes un conflit, fais simple :

1. Ping l’IP suspecte
2. Regarde l’ARP :

Sous Windows :

powershell arp -a

Sous Linux :

bash ip neigh

Si l’adresse MAC associée à l’IP change, ou si elle ne correspond pas à l’équipement attendu, tu tiens quelque chose.

Astuce bête : débranche l’équipement que tu suspectes, et reping. Si ça répond toujours, ce n’est pas lui. Si ça ne répond plus, c’était peut-être lui. Oui, c’est un peu bourrin. Mais en support, parfois, on n’a pas mieux sous la main.

Gérer le multi VLAN : un DHCP par scope, et relay propre

Dans un réseau segmenté, tu as souvent :

• un VLAN utilisateurs
• un VLAN serveurs
• un VLAN VoIP
• un VLAN caméras
• un VLAN invités

Et chaque VLAN a son sous-réseau.

Deux options :

1. un serveur DHCP avec plusieurs scopes (étendues), et des IP helper (DHCP relay) sur les routeurs L3
2. un DHCP local par segment (rare en PME, plus courant dans des architectures spécifiques)

Le point anti conflit ici : s’assurer que chaque VLAN pointe vers le bon serveur, avec la bonne étendue. Sinon tu distribues des IP d’un autre réseau, et tu te retrouves avec des clients « hors sous-réseau », et des collisions logiques.

Cas particulier : IP fixes sur les serveurs, bonne ou mauvaise idée

En entreprise, beaucoup préfèrent IP statique sur :

• DC
• DNS
• hyperviseurs
• NAS
• routeurs, firewalls
• imprimantes critiques

Ce n’est pas forcément mauvais.

Mais il faut être carré :

• hors plage DHCP
• dans une plage « infra » dédiée, idéalement dans un VLAN infra
• documenté
• avec contrôle de doublons (scan IP régulier, supervision)

Et si tu veux être malin : utiliser des réservations DHCP même pour certains serveurs, ça se fait, mais il faut que ton DHCP soit hautement disponible, sinon tu te tires une balle dans le pied au redémarrage.

Techniques pro pour réduire le risque (sans rendre le réseau compliqué)

1. DHCP snooping + dynamic ARP inspection (DAI)

• DHCP snooping crée une table de correspondance IP/MAC
• DAI bloque les ARP incohérents

En gros, ça limite les conflits et certains types d’attaques (ARP spoofing). C’est très « campus network », mais même en PME ça peut sauver la vie.

2. Supervision des plages DHCP

Avec un outil de supervision, tu peux :

• suivre le taux d’occupation d’un scope
• alerter quand il reste peu d’adresses
• détecter des pics anormaux (tempête de clients, rogue device, etc.)

Même une supervision simple (Zabbix, Centreon, LibreNMS) peut suffire.

3. Scans réguliers (inventaire IP)

Un scan nmap sur un sous-réseau, une fois par semaine, ça met en évidence :

• des nouveaux équipements
• des doublons suspects
• des services non attendus (comme un DHCP)

Oui, c’est un peu « admin qui fait sa ronde ». Mais ça marche.

Mini check-list anti conflit d’IP (à coller dans ton cahier de lab)

• définir un plan d’adressage avec une plage statique et une plage DHCP
• mettre les équipements fixes en réservation DHCP (ou statique hors pool)
• vérifier qu’il n’y a qu’un seul serveur DHCP par VLAN (sauf architecture prévue)
• régler la durée de bail selon l’usage
• activer DHCP snooping (si switch compatible)
• surveiller les logs DHCP et les alertes
• documenter les IP critiques
• scanner régulièrement le réseau (inventaire)

Un petit lab simple à faire (et à refaire) pour t’entraîner

Tu peux reproduire ça en VM et en réseau virtuel (VirtualBox, VMware, Proxmox) :

1. Un serveur Windows avec le rôle DHCP
2. Deux clients Windows
3. Une imprimante simulée (ou une VM Linux)
4. Une IP statique volontairement mise dans la plage DHCP

Objectif : provoquer le conflit, observer les symptômes, puis corriger en :

• déplaçant la statique hors pool
• ou en créant une réservation DHCP

Note ce que tu vois dans :

• ipconfig /all
• les logs DHCP
• arp -a

Si tu veux d’autres labs du même style, garde un œil sur le BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/). L’idée du site, c’est exactement ça : des situations réelles, reproductibles, qui te préparent au support et à l’admin réseau.

Conclusion : DHCP ne fait pas tout, mais il peut éviter 90 % des drames

Éviter les conflits d’IP, ce n’est pas magique. C’est surtout de l’hygiène :

Un plan d’adressage clair. Des réservations. Une plage DHCP bien délimitée. Pas de box branchée en douce. Un peu de surveillance.

Et quand ça dérape quand même, parce que ça arrivera un jour, tu as une méthode : identifier qui répond sur l’IP, vérifier ARP, vérifier le serveur DHCP, et éliminer la source.

Ce n’est pas le sujet le plus glamour des réseaux. Mais c’est typiquement le genre de détail qui fait la différence entre « technicien qui subit » et « admin qui maîtrise ».

Questions fréquemment posées

Qu'est-ce qu'un conflit d'adresse IP et pourquoi est-il problématique sur un réseau ?

Un conflit d'adresse IP survient lorsque deux machines sur le même réseau se voient attribuer la même adresse IP. Cela provoque des dysfonctionnements comme des sessions SMB interrompues, des imprimantes réseau instables, ou encore des pertes de connectivité aléatoires. Le protocole ARP est perturbé, ce qui fait que les paquets arrivent au mauvais destinataire, rendant le diagnostic parfois complexe.

Comment fonctionne le DHCP pour prévenir les conflits d'adresses IP ?

Le DHCP (Dynamic Host Configuration Protocol) attribue automatiquement une adresse IP unique à chaque appareil sur le réseau via un processus appelé DORA (Discover, Offer, Request, Acknowledge). Il loue une adresse IP pour une durée déterminée appelée bail. Si le serveur DHCP est bien configuré et surveillé, il évite efficacement les conflits en maintenant une base de baux cohérente.

Quelles sont les causes fréquentes des conflits d'IP dans un environnement professionnel ?

Les causes typiques incluent : 1) L'attribution manuelle d'une IP statique dans la plage DHCP sans coordination ; 2) La présence de deux serveurs DHCP sur le même VLAN sans synchronisation ; 3) La restauration ou clonage de machines virtuelles avec des configurations réseau identiques ; 4) Des équipements IoT ou imprimantes qui alternent entre modes DHCP et statique ; 5) Des baux DHCP trop longs dans des environnements dynamiques favorisant l'utilisation prolongée d'adresses non libérées.

Comment détecter un conflit d'adresse IP sur son réseau ?

Les signes classiques sont : un message Windows indiquant un conflit d'adresse IP détecté, une connectivité intermittente ou aléatoire, une imprimante réseau qui ne répond pas systématiquement, un téléphone IP qui se ré-enregistre en boucle, ou encore une machine répondant au ping mais n'étant pas celle attendue. Ces symptômes peuvent être intermittents si l'un des appareils concernés n'est pas toujours allumé.

Quelles bonnes pratiques adopter pour éviter les conflits d'IP lors de la gestion du DHCP ?

Il est essentiel de configurer correctement la plage DHCP en excluant les adresses utilisées en statique, éviter la présence simultanée de plusieurs serveurs DHCP non coordonnés sur le même VLAN, gérer soigneusement les clones ou restaurations de VMs pour éviter les duplications d'adresses, surveiller les comportements spécifiques des équipements hybrides (statique/DHCP), et adapter la durée des baux DHCP selon la dynamique du parc pour éviter l'épuisement ou l'inutilisation prolongée d'adresses.

Pourquoi un conflit d'IP peut-il être intermittent et difficile à résoudre ?

Parce que souvent l'un des deux équipements ayant la même adresse IP n'est pas constamment allumé. Ainsi, le conflit peut apparaître puis disparaître selon la disponibilité des appareils. Cela donne l'impression que le problème est résolu alors qu'il peut réapparaître plus tard, rendant le diagnostic plus complexe et nécessitant une surveillance attentive.