Comment les clients DHCP savent-ils lequel des multiples 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 à quel sous-réseau ils appartiennent, évidemment.

Ensuite, de nouveaux clients sont branchés. Ils ne savent rien du sous-réseau dans lequel ils sont censés se trouver et envoient leur DHCPDISCOVER à la diffusion Ethernet 255.255.255.255, donc il va 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?

networking dhcp

— Michael Niemand
source

Comparez cette question et ses réponses.

— Kamil Maciorowski

Voici une autre question connexe .

— kasperd

"la diffusion ethernet 255.255.255.255" - C'est l'adresse de diffusion IP pour le réseau local, pas une adresse Ethernet. Les messages DHCP DISCOVER initiaux sont également très susceptibles d'utiliser l'adresse de diffusion Ethernet ff: ff: ff: ff: ff: ff, mais ce ne sont vraiment pas la même chose.

— ilkkachu

Réponses:

Réponse la plus simple - premier arrivé, premier servi.

Si vous aviez plusieurs VLAN et que 10.10.10.0/24 était sur un VLAN différent de 10.10.20.0/24 - la diffusion ne traverserait pas de VLAN.

Si le serveur DHCP se trouvait sur un VLAN distinct pour les clients, un iphelper sur l'interface de routage entre les vlans dirigerait la diffusion vers l'emplacement correct.

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 sert 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!"
Demande 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, certains serveurs DNS / WINS, un serveur de temps et toutes les autres choses configurées pour votre portée"

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 cessera «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 remarque - il existe en fait une série bien connue d'attaques DoS (Denial of Service) qui abusent de ce droit. Un attaquant branche un appareil qui répond et envoie des paquets DHCPOFFER, puis n'envoie pas DHCPACK lorsqu'il lui est demandé ... maintes et maintes fois. Il existe également une autre attaque DoS où les "faux" serveurs DHCP proposent des adresses qui ne peuvent pas être acheminées ou qui entrent en conflit avec d'autres adresses IP, elles sont détectées pour perturber les réseaux.

— Fazer87
source

Et donc la réponse courte à "Mais comment puis-je exécuter plusieurs sous-réseaux sur un seul segment de couche 2?" est " Vous ne le faites pas. " (Oui, il existe des moyens, mais ce n'est pas quelque chose que vous devriez généralement faire. Un domaine de couche 2 = un sous-réseau.)

— user1686

Merci les gars, qui ont vraiment cliqué avec moi. Je me suis toujours demandé comment cela serait possible, mais ce n'est tout simplement pas le cas. Donc, le point à retenir est le suivant: avoir un routeur / couche 3 basculer entre les sous-réseaux ou les segments avec VLAN, ai-je raison?

— Michael Niemand

En général, oui, vous avez besoin de VLAN ou d'une segmentation physique. Le partage d'un domaine L2 ne serait réalisable que si vos deux serveurs DHCP étaient limités à la gestion de clients "connus" (par exemple par une liste de "baux statiques" avec des adresses MAC autorisées).

— user1686

Je pense que vous pouvez donner à chaque serveur DHCP une liste blanche d'adresses MAC et contrôler quel client obtient une adresse de quel serveur de cette façon.

— Darren

@grawity, vous pouvez facilement exécuter plusieurs sous-réseaux IP sur le même segment de couche 2, si les sous-réseaux sont égaux, et peu vous importe quel client obtient une adresse à partir de quel sous-réseau. Vous avez juste un serveur DHCP qui donne des adresses des deux blocs et un routeur qui agit comme une passerelle pour les deux blocs (avec une adresse dans chacun). Terminé. Dire simplement «vous n'avez pas» est tout à fait faux.

— ilkkachu

La réponse existante de @ Fazer87 est globalement correcte dans la pratique et je recommande de voter en amont 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 sur la base du "premier arrivé, premier servi". Cependant, il n'est pas nécessaire d'adopter cette approche.

La 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.

Donc, si le deuxième serveur DHCP offrait une réservation d'adresse IP plus longue, ou offrait un serveur de temps où l'autre ne le faisait pas, 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 l'offre qui n'a pas été soumise à plusieurs sauts sur différents appareils (rediffusions BOOTP), c'est donc un bon protocole à suivre si vous n'avez aucune raison de vous en soucier.

J'étais sur un projet où un appareil personnalisé préférerait un DHCPOffer qui incluait un serveur TFTP où le firmware mis à jour pouvait être trouvé.

— Pensée étrange
source

... ou si un serveur proposait une adresse que le client avait déjà utilisée auparavant et voulait conserver

— ilkkachu

@ilkkachu: Oui, en théorie, mais il existe de meilleurs mécanismes pour cela (à la fois renouveler une réservation avant son expiration avec l'ancien serveur DHCP, ou envoyer une découverte DHCP demandant l'ancienne adresse IP), il est donc peu probable qu'il soit utile dans la pratique.

— Oddthinking