it-swarm.com.de

Woher wissen DHCP-Clients, welche von mehreren DHCPOFFERS akzeptiert werden sollen?

Stellen Sie sich vor, wir haben ein Netzwerk wie auf dem Bild. Sechs Hosts in einem Layer 2-Netzwerk, keine VLANs. Das Netzwerk soll in zwei Subnetze mit jeweils einem DHCP-Server unterteilt werden. Die DHCP-Server haben feste IP-Adressen, sodass sie offensichtlich wissen, zu welchem ​​Subnetz sie gehören.

Dann werden neue Clients angeschlossen. Sie wissen nichts über das Subnetz, in dem sie sich befinden sollen, und senden ihren DHCPDISCOVER an Ethernet broadcast 255.255.255.255, sodass er an beide DHCP-Server gesendet wird. Beide Server antworten mit einem Angebot. Hier ist meine Frage: Woher weiß der Client, welches DHCPOFFER er akzeptieren soll?

 DHCP situation

16
Michael Niemand

Einfachste Antwort - Wer zuerst kommt, mahlt zuerst.

Wenn Sie mehrere VLANs hatten und 10.10.10.0/24 sich in einem anderen VLAN als 10.10.20.0/24 befand, wurde die Übertragung nicht über VLANs übertragen.

Wenn sich der DHCP-Server in einem separaten VLAN zu den Clients befand, leitete ein Iphelper auf der Routing-Schnittstelle zwischen vlans die Übertragung an den richtigen Ort.

In Ihrem Szenario, in dem Sie zwei separate Netzwerke innerhalb desselben VLAN (oder eines fehlenden) haben, die unterschiedliche Subnetze bedienen, ist dies eine Rasse.

DHCP wird mit den folgenden Transaktionen ausgeführt:

  1. DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Gibt es einen DHCP-Server?"
  2. DHCP-Angebot (DHCPOFFER) - Server an Client - "Ja, ich bin hier und verfügbar!"
  3. DHCP Request (DHCPREQUEST) - Client an Server "Super, kann ich bitte eine Adresse haben?"
  4. DHCP-Bestätigung (DHCPACK) - Server an Client "Sicher, hier sind eine IP, eine Maske, ein Gateway, einige DNS/WINS-Server, ein Zeitserver und alle anderen für Ihren Bereich konfigurierten Informationen."

All dies geschieht auf den UDP-Ports 67 für den Server und 68 für den Client.

Sobald Schritt 2 erreicht ist, hört der Client auf, die Antworten anderer DHCP-Server zu "lauschen". Er freut sich, wenn er sich mit dem ersten Server befasst, der ihm etwas Aufmerksamkeit schenkt.

Als Randnotiz - es gibt tatsächlich eine bekannte Reihe von DoS-Angriffen (Denial of Service), die dieses Recht missbrauchen. Ein Angreifer steckt ein Gerät ein, das antwortet und DHCPOFFER-Pakete sendet und dann DHCPACK nicht sendet, wenn er gefragt wird ... immer und immer und immer wieder. Es gibt auch eine andere DoS-Attacke, bei der "gefälschte" DHCP-Server Adressen anbieten, die nicht geroutet werden können oder die mit anderen IP-Adressen in Konflikt stehen, die es schnüffelt, um mit Netzwerken in Konflikt zu kommen.

26
Fazer87

Die vorhandene Antwort von @ Fazer87 ist in der Praxis im Großen und Ganzen richtig, und ich empfehle, sie zu bestätigen und zu akzeptieren. Diese Antwort untersucht ein kleines Detail etwas genauer.


Beide DHCP-Server antworten möglicherweise mit einer DHCPOffer-Nachricht.

Ein DHCP-Client akzeptiert sie möglicherweise nach dem Prinzip "Wer zuerst kommt, mahlt zuerst". Es ist jedoch nicht erforderlich, diesen Ansatz zu wählen.

RFC2131 gibt an:

Der Client empfängt eine oder mehrere DHCPOFFER-Nachrichten von einem oder mehreren Servern. Der Client kann sich dafür entscheiden, auf mehrere Antworten zu warten. Der Client wählt einen Server aus, von dem Konfigurationsparameter angefordert werden sollen, basierend auf den Konfigurationsparametern, die in den DHCPOFFER-Nachrichten angeboten werden.

Wenn also der zweite DHCP-Server eine längere IP-Adressreservierung anbietet oder einen Zeitserver anbietet, auf dem der andere keine IP-Adresse hat, oder möglicherweise ein benutzerdefiniertes Feld hat, für das der Client die bevorzugte Einstellung festgelegt hat, akzeptiert er möglicherweise das zweite Angebot.

In der Regel erhalten Sie bei einem "Wer zuerst kommt, mahlt zuerst" -Ansatz das Angebot, das noch nicht über mehrere Geräte hinweg durchlaufen wurde (BOOTP-Rebroadcasts). Es ist daher ein gutes Protokoll, das Sie befolgen sollten, wenn Sie keinen Grund haben, sich darum zu kümmern.

Ich war an einem Projekt beteiligt, bei dem ein benutzerdefiniertes Gerät ein DHCPOffer bevorzugen würde, das einen TFTP-Server enthält, auf dem aktualisierte Firmware gefunden werden kann.

9
Oddthinking