DHCP-Server

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 20. April 2007 um 01:16 Uhr durch Staro1 (Diskussion | Beiträge) (revert). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Dieser Artikel wurde zur Löschung vorgeschlagen.

Falls du Autor des Artikels bist, lies dir bitte durch, was ein Löschantrag bedeutet, und entferne diesen Hinweis nicht.

Zur Löschdiskussion.

http://de.wikipedia.org/wiki/Diskussion:Dynamic_Host_Configuration_Protocol --


Der DHCP-Server wird – wie alle Netzwerkdienste – als Hintergrundprozess (Daemon oder Dienst) gestartet und wartet auf UDP-Port 67 auf Client-Anfragen. In seiner Konfigurationsdatei befinden sich Informationen über den zu vergebenden Adresspool sowie zusätzliche Angaben über netzwerkrelevante Parameter wie die Subnetzmaske, die lokale DNS-Domäne oder das zu verwendende Gateway. Außerdem lassen sich auch weitere BOOTP-Server oder der Ort des zu verwendenden Bootimages einstellen.

Betriebsmodi

Es gibt drei verschiedene Betriebsmodi eines DHCP-Servers: Manuelle, automatische und dynamische Zuordnung.

Manuelle Zuordnung

In diesem Modus werden am DHCP-Server die IP-Adressen bestimmten MAC-Adressen fest zugeordnet. Die Adressen werden der MAC-Adresse auf unbestimmte Zeit zugeteilt. Der Nachteil kann darin liegen, dass sich keine zusätzlichen Clients in das Netz einbinden können, da die Adressen fest vergeben sind. Dies kann unter Sicherheitsaspekten erwünscht sein.

Manuelle Zuordnungen werden vor allem dann vorgenommen, wenn der DHCP-Client beispielsweise Server-Dienste zur Verfügung stellt und daher unter einer festen IP-Adresse erreichbar sein soll. Auch Port-Weiterleitungen von einem Router an einen Client benötigen in der Regel eine feste IP-Adresse.

Automatische Zuordnung

Bei der automatischen Zuordnung wird am DHCP-Server ein Bereich von IP-Adressen definiert. Wenn die Adresse aus diesem Bereich einmal einem DHCP-Client zugeordnet wurde, dann gehört sie diesem auf unbestimmte Zeit, denn auch hier wird die zugewiesene IP-Adresse an die MAC-Adresse gebunden. Ist der Adressbereich komplett vergeben, so können sich keine zusätzlichen Clients in das Netz einbinden. Das geht auch dann nicht, wenn die Rechner gar nicht aktiv (eingeschaltet) sind, denn im Cache des DHCP-Servers wird die IP-Adresse gespeichert. Es hilft dann nur ein Löschen des Caches, um die an nicht aktive Rechner vergebenen Adressen verwenden zu können.

Dynamische Zuordnung

Dieses Verfahren gleicht der automatischen Zuordnung, allerdings hat der DHCP-Server hier in seiner Konfigurationsdatei eine Angabe, wie lange eine bestimmte IP-Adresse an einen Client „vermietet“ werden darf, bevor der Client sich erneut beim Server melden und eine „Verlängerung“ beantragen muss. Meldet er sich nicht, wird die Adresse frei und kann an einen anderen (oder auch den gleichen) Rechner neu vergeben werden. Diese vom Administrator bestimmte Zeit heißt Lease-Time (zu deutsch also: „Mietzeit“).

DHCP-Kommandos

  • DHCPDISCOVER: Ein Client ohne IP-Adresse sendet eine Broadcast-Anfrage nach Adress-Angeboten an den/die DHCP-Server im lokalen Netz
  • DHCPOFFER: Der/die DHCP-Server antworten mit entsprechenden Werten auf eine DHCPDISCOVER-Anfrage
  • DHCPREQUEST: Der Client fordert (eine der angebotenen) IP-Adresse(n), weitere Daten sowie Verlängerung der Lease-Zeit von einem der antwortenden DHCP-Server
  • DHCPACK: Bestätigung des DHCP-Servers zu einer DHCPREQUEST-Anforderung
  • DHCPNAK: Ablehnung einer DHCPREQUEST-Anforderung durch den DHCP-Server
  • DHCPDECLINE: Ablehnung durch den Client, da die IP-Adresse schon verwendet wird
  • DHCPRELEASE: Der Client gibt die eigene Konfiguration frei, damit die Parameter wieder für andere Clients zur Verfügung stehen
  • DHCPINFORM: Anfrage eines Clients nach Daten ohne IP-Adresse, z. B. weil der Client eine statische IP-Adresse besitzt

Ablauf der DHCP-Kommunikation

Damit der Client einen DHCP-Server nutzen kann, muss sich dieser im selben Netzwerksegment befinden, da DHCP Broadcasts verwendet und Router keine Broadcasts weiterleiten (Router bilden Broadcast-Domänen). Befindet sich der DHCP-Server in einem anderen Netzwerksegment, so muss ein so genannter DHCP-Relay Agent installiert werden, der die DHCP-Anfragen an den eigentlichen Server weitergibt.

Initiale Adresszuweisung (Lease/Vergabe)

Wenn ein Client erstmalig eine IP-Adresse benötigt, schickt er eine DHCPDISCOVER-Nachricht (mit seiner MAC-Adresse) als Netzwerk-Broadcast an die verfügbaren DHCP-Server (es kann durchaus mehrere davon im gleichen Subnetz geben). Dieser Broadcast hat als Absender-IP-Adresse 0.0.0.0 und als Zieladresse 255.255.255.255, da der Absender noch keine IP-Adresse besitzt und seine Anfrage „an alle“ richtet. Dabei ist der UDP-Quellport 68 und der UDP-Zielport 67. Die DHCP-Server antworten mit DHCPOFFER und machen Vorschläge für eine IP-Adresse. Dies geschieht ebenfalls mit einem Broadcast an die Adresse 255.255.255.255 mit UDP-Quellport 67 und UDP-Zielport 68.

Der Client darf nun unter den eingetroffenen Angeboten (DHCP-Offers) wählen. Wenn er sich für eines entschieden hat (z. B. wegen längster Lease-Zeit oder wegen Ablehnung eines speziellen, evtl. falsch konfigurierten DHCP-Servers, oder einfach für die erste Antwort), kontaktiert er per Broadcast und einem im Paket enthaltenen Serveridentifier den entsprechenden Server mit der Nachricht DHCPREQUEST. Alle eventuellen weiteren DHCP-Server werten dies als Absage für ihre Angebote. Der vom Client ausgewählte Server bestätigt in einer DHCPACK-Nachricht (DHCP-Acknowledged) die IP-Adresse mit den weiteren relevanten Daten, oder er zieht sein Angebot zurück (DHCPNAK, siehe auch sonstiges).

Bevor der Client sein Netzwerkinterface mit der zugewiesenen Adresse konfiguriert, sollte er noch prüfen, ob nicht versehentlich noch ein anderer Rechner die Adresse verwendet. Dies geschieht üblicherweise durch einen ARP-Request mit der soeben zugeteilten IP-Adresse. Antwortet ein anderer Host im Netz auf diesen Request, so wird der Client die vorgeschlagene Adresse mit einer DHCPDECLINE-Nachricht zurückweisen.

DHCP-Refresh (nur bei dynamischer Zuordnung)

Zusammen mit der IP-Adresse erhält der Client in der DHCPACK-Nachricht die Lease-Zeit. Dies ist ein Zeitwert, der angibt, wie lange der Client die zugewiesene IP-Konfiguration verwenden darf; er wird vom Administrator des DHCP-Servers eingestellt. Der Standard sieht vor, dass der Client nach der Hälfte der Lease-Zeit einen erneuten DHCPREQUEST sendet und so bekundet, dass weiteres Interesse an der reservierten IP-Nummer besteht. Dieser DHCPREQUEST wird per Unicast an den Server gesendet, der die IP-Konfiguration vergeben hat. Der Server sollte dann in der Regel ein DHCPACK mit identischen Daten wie vorher, aber einer neuen Lease-Zeit senden. Damit gilt die Adresse als verlängert.

Antwortet der Server nicht, so kann der Client die IP-Konfiguration ohne Einschränkungen weiter verwenden. Er wird jedoch nach Ablauf von 7/8 der Lease-Zeit (87,5 %) versuchen, eine Verlängerung der IP-Konfiguration von irgendeinem DHCP-Server im selben Subnetz zu erhalten. (Ein möglicher Grund dafür ist, dass der ursprüngliche Server abgeschaltet wurde und nun ein neuer Server für die Verwaltung der IP-Adressen zuständig ist.)

Sollte der Client es versäumen, bis zum Ablauf der Lease-Zeit eine Verlängerung zu beantragen, muss er seine Netzwerkkarte dekonfigurieren und wieder bei DHCPDISCOVER mit einer initialen Adresszuweisung beginnen. Sollte der DHCP-Server keine Adressen mehr zur Verfügung haben oder während des Vorganges schon ein anderer Client seine letzte Adresse zugesagt bekommen haben, sendet der Server ein DHCPNAK (DHCP-Not Acknowledged), und der Vorgang der Adressanfrage beginnt erneut.

Sonstiges

Eine negative Bestätigung DHCPNAK kann als Ursache haben, dass der Client versucht, seine ehemalige IP-Adresse zu leasen, die jedoch inzwischen nicht mehr verfügbar ist (Lease abgelaufen und anderweitig vergeben), oder wenn der Client-Computer in ein anderes Subnetz verschoben wurde.

Um die Ausfallwahrscheinlichkeit zu verringern, ist es auch möglich, mehrere DHCP-Server in einem Netz zu platzieren. Dabei sollte allerdings beachtet werden, dass sich die Adressbereiche der einzelnen Server nicht überlappen, da es sonst zu Doppelvergaben von IP-Adressen kommen kann. Dazu gibt es die „authoritative“ (engl. für „maßgebliche“) Einstellung, mit der man einstellen kann, ob ein DHCPNAK auch verschickt werden soll, wenn der DHCP-Server für die vom Client vorgeschlagene Adresse nicht zuständig ist.

Wenn der Client eine negative Bestätigung erhält, wird der DHCP-Lease-Vorgang erneut gestartet.

Ein Client sendet DHCPRELEASE, wenn er eine IP-Adresse vor Ablauf der Lease-Zeit zurückgeben will.

Sollte der Client feststellen, dass die zugewiesene Adresse bereits benutzt wird, so teilt er dies dem Server durch DHCPDECLINE mit, welcher seinerseits den Administrator von dieser potentiellen Fehlkonfiguration unterrichten sollte.

DHCP und DNS

Einige DHCP-Server können mit dem DNS zusammenarbeiten, indem sie IP-Adresse, Rechnernamen und "lease time" an den DNS-Server weiterleiten. Damit ist eine Namensauflösung für Arbeitsstationen auch in Netzen mit DHCP bequem möglich. Dies ist allerdings nicht die Regel. Im Normalfall kommuniziert der Client direkt mit dem DNS-Server. Lediglich bei älteren Windows-Betriebssystemen (älter als Windows 2000) muss diese Aufgabe vom DHCP-Server übernommen werden.

Mögliche Zuweisungen

Standardmäßig kann DHCP dem Client folgende Einstellungen zuweisen:

DHCP für mehrere Subnetze

Der DHCP-Server kann Subnetze bedienen, wenn er über Definitionen für die jeweilige Netzwerkkarte verfügt. Die Auswahl der Definition bestimmt dann die Netzwerkkarte, über welche die Anforderung hereinkommt. Beim Start des DHCP-Servers kann angegeben werden, auf welche Interfaces der Server hört.

Andererseits kann ein DHCP-Server auch über eine Netzwerkkarte mehrere Subnetze bedienen, wenn diese durch einen DHCP-Relay-Agenten verbunden sind, der die DHCP-Befehle weiterreicht.

Sicherheit

DHCP basiert auf UDP. Es ist somit leicht manipulierbar.

Weiterhin wäre es möglich, alle Adressen eines DHCP-Servers zu reservieren, anschließend selbst als DHCP-Server aufzutreten (DHCP-Spoofing) und dann entweder nur falsche Informationen an anfragende Clients weiterzureichen (z. B. immer dieselbe IP-Adresse oder nicht vorhandene Gateways) oder z. B. Gateway- und DNS-IP-Adressen auf andere Rechner umzuleiten, um auch diese Protokolle zu kompromittieren.

Um dieses Problem zu umgehen, wird gelegentlich auch Peg DHCP nach RFC 2322 verwendet.

Weitere Probleme treten bei Verwendung von SSH auf, da sich ein SSH-Client bei jeder Rechnerverbindung den Namen und die IP-Adresse merkt und eine Änderung, wie z. B. eine neue IP-Adresse, als Angriff wertet.