Comment les clients DHCP savent-ils lequel des nombreux DHCPOFFERS accepter?
Imaginez que nous ayons un réseau comme sur la photo. Six hôtes sur un réseau de couche 2, pas de VLAN. Le réseau est censé être segmenté en deux sous-réseaux, avec un serveur DHCP chacun. Les serveurs DHCP ont des adresses IP fixes, ils savent donc évidemment à quel sous-réseau ils appartiennent.
Ensuite, les nouveaux clients sont branchés. Ils ne savent rien du sous-réseau dans lequel ils sont censés être et envoient leur DHCPDISCOVER au Ethernet broadcast 255.255.255.255, de sorte qu'il passe aux deux serveurs DHCP. Les deux serveurs répondent avec une offre. Maintenant, voici ma question: Comment le client sait-il quel DHCPOFFER il est censé accepter?
Réponse la plus simple - premier arrivé, premier servi.
Si vous aviez plusieurs VLAN et que 10.10.10.0/24 se trouvait sur un VLAN au 10.10.20.0/24 différent, la diffusion ne croiserait pas les VLAN.
Si le serveur DHCP se trouvait sur un VLAN séparé des clients, un iphelper situé sur l'interface de routage entre les vlans dirigerait la diffusion vers le bon emplacement.
Dans votre scénario où vous avez 2 réseaux distincts dans le même VLAN (ou son absence) desservant différents sous-réseaux - c'est une course.
DHCP se désactive en utilisant les transactions suivantes:
- Découverte DHCP (DHCPDISCOVER) - Diffusion client - "Existe-t-il un serveur DHCP?"
- Offre DHCP (DHCPOFFER) - Serveur à client - "Ouais, je suis là et disponible!"
- Requête DHCP (DHCPREQUEST) - Client à serveur "Génial, puis-je avoir une adresse s'il vous plaît?"
- Accusé de réception DHCP (DHCPACK) - Serveur à client "Bien sûr, voici une adresse IP, un masque, une passerelle, des serveurs DNS/WINS, un serveur de temps et tous les autres éléments configurés pour votre étendue"
Tout cela se produit sur les ports UDP 67 pour le serveur et 68 pour le client.
Dès que l'étape 2 est atteinte - le client cesse d'écouter les réponses des autres serveurs DHCP - il est heureux de traiter avec le premier serveur pour lui accorder une certaine attention.
En passant, une série d'attaques par déni de service (DoS) (déni de service) bien connues abusent de ce droit. Un attaquant connecte un périphérique qui répond et envoie des paquets DHCPOFFER mais n'envoie pas DHCPACK à la demande ... maintes et maintes fois. Il existe également une autre attaque DoS où de "faux" serveurs DHCP offrent des adresses qui ne peuvent pas être routées ou qui sont en conflit avec d'autres adresses IP qu'il est demandé de déranger avec des réseaux.
Le réponse existante de @ Fazer87 est globalement correct et je recommande de voter et de l'accepter. Cette réponse explore un détail mineur un peu plus précisément.
Les deux serveurs DHCP peuvent répondre avec un message DHCPOffer.
Un client DHCP peut les accepter selon le principe du "premier arrivé, premier servi". Cependant, il n’est pas nécessaire d’adopter cette approche.
RFC2131 spécifie:
Le client reçoit un ou plusieurs messages DHCPOFFER d'un ou plusieurs serveurs. Le client peut choisir d'attendre plusieurs réponses. Le client choisit un serveur à partir duquel demander des paramètres de configuration, en fonction des paramètres de configuration proposés dans les messages DHCPOFFER.
Ainsi, si le deuxième serveur DHCP offrait une réservation d'adresse IP plus longue, ou offrait un serveur de temps contrairement à l'autre, ou avait peut-être un champ personnalisé que le client avait été programmé pour préférer, il pourrait accepter la deuxième offre.
En règle générale, une approche "premier arrivé, premier servi" vous permettra d'obtenir une offre qui n'a pas été testée plusieurs fois (réémission de BOOTP), donc c'est un bon protocole à suivre si vous n'avez aucune raison de vous en soucier.
J'étais sur un projet où un périphérique personnalisé préfèrerait un DHCPOffer incluant un serveur TFTP sur lequel un micrologiciel mis à jour pourrait être trouvé.