Le dhcp port expliqué : ports 67 et 68 dans les réseaux informatiques
Dans n’importe quel réseau informatique qui grandit un peu, les machines ont besoin d’une adresse IP pour parler entre elles. Configurer ça à la main sur chaque poste, c’est vite ingérable. Du coup on laisse faire le protocole DHCP, et derrière toute cette automatisation il y a deux ports UDP très précis qu’on appelle souvent le dhcp port : le 67 et le 68.
Le truc c’est que si ces ports sont mal compris ou bloqués quelque part, tout le mécanisme tombe. J’ai vu des pannes réseau entières causées par un simple oubli de règle sur le port 67 d’un serveur. En fait, c’est un de ces détails techniques qui paraissent anodins… jusqu’au jour où plus aucune machine n’arrive à prendre une IP.
Le rôle du DHCP dans la gestion quotidienne des réseaux
Le Dynamic Host Configuration Protocol permet à un serveur central de distribuer automatiquement des adresses IP, des masques de sous-réseau, des passerelles par défaut et des serveurs DNS aux clients qui en font la demande. Fini les saisies manuelles et les erreurs de frappe. Surtout quand ton parc compte des dizaines ou des centaines de machines, ou quand les gens branchent et débranchent du matériel en permanence.
DHCP est une évolution directe du vieux BOOTP des années 80. Il garde la même logique de base mais ajoute la notion de bail temporaire et une vraie automatisation. La RFC 2131, publiée en 1997, a fixé les règles du jeu, et elles n’ont pas bougé depuis. Le protocole reste d’ailleurs toujours aussi largement utilisé aujourd’hui.
Le serveur peut aussi attribuer une IP fixe à une adresse MAC précise via une réservation. C’est pratique pour les imprimantes ou les serveurs qui doivent toujours avoir la même adresse sans pour autant passer en IP statique manuelle sur la machine elle-même.
Les ports DHCP en détail : 67 pour le serveur, 68 pour le client
Le serveur DHCP écoute en continu sur le port UDP 67. C’est son point d’entrée officiel pour toutes les requêtes. De l’autre côté, chaque client utilise le port UDP 68 pour envoyer ses messages et recevoir les réponses du serveur.
Ces numéros ne sont pas tombés du ciel. Ils viennent tout droit du protocole BOOTP et ont été enregistrés auprès de l’IANA sous les noms bootps (67) et bootpc (68). L’avantage, c’est que ça évite les conflits avec d’autres applications qui tourneraient sur la même machine. Le client envoie toujours depuis son port 68 vers le port 67 du serveur. Le serveur répond depuis son port 67 vers le port 68 du client. Cette symétrie est importante à retenir quand on écrit des règles réseau.
Comment circulent concrètement les messages sur le dhcp port
Tout commence quand un client arrive sur le réseau ou veut renouveler son bail. Il envoie un DHCP Discover en broadcast depuis son port 68 vers n’importe quel serveur qui traîne sur le sous-réseau, en visant le port 67.
Les serveurs qui reçoivent ce message préparent une offre avec une adresse IP disponible et tous les paramètres associés. Ils renvoient un DHCP Offer en utilisant le port 67 en source et le port 68 en destination.
Le client choisit généralement la première offre qui arrive et envoie un DHCP Request en broadcast pour prévenir les autres serveurs qu’ils peuvent oublier cette adresse. Toujours via le port 68 vers le 67.
Enfin, le serveur sélectionné confirme l’attribution avec un DHCP Ack. Le client a maintenant son IP, la durée de son bail et le reste de la configuration. Si le serveur ne peut pas donner l’adresse demandée, il renvoie un DHCP NAK à la place.
Et si aucun serveur ne répond du tout ? Le client tombe en mode dégradé et s’auto-attribue une adresse dans la plage APIPA 169.254.0.0/16. C’est mieux que rien, mais clairement pas ce qu’on veut dans un réseau sérieux.
Gérer le dhcp port dans vos règles de pare-feu
Quand un pare-feu se trouve entre les clients et le serveur DHCP, il faut autoriser le trafic UDP dans les deux sens sur les ports 67 et 68. Les clients envoient leurs requêtes du port 68 vers le 67 du serveur. Les réponses repartent du 67 vers le 68 des clients.
Sur la plupart des firewalls stateful, ouvrir la première direction suffit souvent, mais il vaut mieux être explicite pour éviter les mauvaises surprises. Sur Windows Firewall, sur OPNsense, pfSense ou n’importe quelle appliance pro, on crée généralement deux règles simples. Oublier l’une des deux et tes machines ne récupèrent plus d’IP au démarrage.
Dans les environnements virtualisés ou cloud, pense aussi aux security groups. Le dhcp port y est parfois bloqué par défaut selon la configuration choisie. Et sur les gros réseaux, vérifie que les agents relais (ip helper-address sur Cisco par exemple) peuvent bien traverser les firewalls intermédiaires.
Les agents relais et les réseaux étendus
Sur un réseau avec plusieurs VLANs ou des sites distants, le broadcast DHCP ne traverse pas les routeurs. C’est là qu’on déploie des agents relais DHCP. L’agent capte les requêtes sur le port 67, les forwarde en unicast vers le serveur central (qui peut être à l’autre bout du réseau), et renvoie les réponses aux clients. Les ports restent exactement les mêmes, seul le mode de transport change.
C’est une solution propre pour centraliser son serveur DHCP et simplifier l’administration. Un seul serveur peut servir plusieurs sous-réseaux sans qu’on ait besoin d’en installer un partout.
Les risques de sécurité autour des ports 67 et 68
Ouvrir le dhcp port, c’est indispensable, mais il faut le faire avec un minimum de protection. Un serveur DHCP rogue branché par erreur ou par malveillance peut distribuer des adresses avec un DNS faux ou une passerelle vers un attaquant. Résultat : tout le trafic des utilisateurs peut être redirigé ou intercepté.
Pour limiter le risque, on active le DHCP snooping sur les switches. Cette fonctionnalité marque certains ports comme « non fiables » et bloque les offres DHCP qui en proviennent. Seuls les ports où se trouve vraiment le serveur légitime sont autorisés à répondre. On peut ensuite coupler ça avec Dynamic ARP Inspection pour encore plus de robustesse.
Honnêtement, dans un réseau d’entreprise un peu sérieux, je ne déploie jamais un service DHCP sans au moins activer le snooping. Les ports 67 et 68 sont des points d’entrée trop critiques pour les laisser sans surveillance.
Tester et dépanner les problèmes liés au dhcp port
Si tes clients n’obtiennent plus d’IP, commence par les logs du serveur. Sur Linux avec isc-dhcp-server, regarde syslog ou le fichier dédié au démon. Sur Windows Server, l’Observateur d’événements fait le job.
Côté client, « ipconfig /all » sous Windows ou « ip addr show » sous Linux te montre tout de suite si l’adresse est bien là ou si c’est une APIPA. Pour forcer un renouvellement, rien de plus simple : ipconfig /release puis ipconfig /renew sur Windows, ou sudo dhclient -r suivi de sudo dhclient sur Linux.
Pour vérifier qui écoute sur les ports, utilise ss -tuln | grep -E '67|68' ou l’ancien netstat. Si le serveur n’écoute pas sur 67, c’est généralement que le service n’est pas démarré ou qu’une autre application a pris le port (ça arrive rarement, mais ça arrive).
La plupart du temps, quand on creuse un problème de dhcp port, on tombe sur un pare-feu mal configuré, un switch qui bloque les broadcasts, ou un bail expiré qui n’a pas pu être renouvelé. Avec un peu de méthode, on retrouve vite le coupable.
Au quotidien, bien maîtriser ces deux ports, c’est s’assurer que les machines s’intègrent au réseau sans intervention manuelle et que l’infrastructure reste fluide même quand elle grossit. C’est un petit détail technique, mais il fait vraiment toute la différence dans la gestion des réseaux informatiques.
