Howto DHCP

Das DHCP (Dynamic Host Configuration Protocol) ist eine "Erweiterung und Ergänzung" des BOOTP (Bootstrap Protocol), welches aber auch die Abwärtskompatibilität zu diesem garantiert (RFC 2131, 1534). Es ermöglicht mit Hilfe eines entsprechenden Servers die dynamische Zuweisung einer IP-Adresse und weiterer Konfigurationsparameter an Computer in einem Netzwerk (z.B. Internet oder LAN).
Neben den klassischen Parametern, wie Hostname, IP-Adresse, Netzmaske und Gateway, zählt dazu die Verwendung einer Reihe von weiteren IP-Variablen: X-Display- , Time-, Swap-, NIS-Server und die Unterstützung von Vendor-Code-Identifiern, welche ihren Einsatz im Bereich PXE (Preboot Execution Environment) und Diskless Boot finden. Darüber hinaus können in einem Stringfeld z.B. die Konfiguration von Grafikkarte und Monitor incl. Mausanschluss übermittelt werden. Ein weiteres Feld nimmt Kommandozeilen auf, die an die Datei boot.local angehängt und ausgeführt werden. So lassen sich die Audiokomponenten konfigurieren oder zusätzliche Gerätetreiber laden.

Durch DHCP ist die Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne weitere Konfiguration möglich. Ohne DHCP ist ein relativ aufwendiges Setup nötig, das neben der IP-Adresse die Eingabe weiterer Parameter wie Netzmaske, Gateway usw. verlangt. DHCP kann aber diese Parameter beim Starten eines neuen Rechners automatisch vergeben. DHCP wurde ursprünglich entwickelt um die Netzwerkadministration in großen Netzwerken mit häufig wechselnden Topologien und vielen wechselnden Usern zu vereinfachen.

Beim Start des Clients fragt dieser über einen Broadcast im gesamten Netzwerk nach (s)einer IP-Adresse. Als Antwort auf seinen Broadcast erhält er folgende Informationen:

• IP-Adresse
  
• Lease-Time
  
• Default-Route
  
• Netzmaske
  
• DNS-Server-Adressen
  
• WINS-Server
  
• Broadcast-Adresse
  
• IP-Varialen
  
• weitere Parameter

Von den obengenannten Parametern ist aber nur die Konfiguration und Übermittlung der IP-Adresse und der Lease-Time, so etwas wie die Haltbarkeit der IP-Adresse, zwingend notwendig. Alle anderen Parameter sind optional.

Die DHCP-Adressvergabe

Die Broadcast Anfrage vom Client zum Server folgt folgendem Muster, welches auch in Abbildung 1 dargestellt ist. Die Verständigung zwischen dem Client und dem Server läuft mittels UPD (Unreliable Datagram Protocol). Wobei der Server auf Port 67 und der Client auf Port 68 kommuniziert.

Beim Booten des Client fragt dieser mit einer DHCPDISCOVER-Nachricht via Broadcast nach seiner Config. Zu diesem Zeitpunkt besitzt er noch keine IP-Adresse sondern nur die MAC (Media Access Control)-Adresse seines Netzwerkinterfaces. Das Broadcastpaket welches gesendet wird, bekommt die Quelladresse 0.0.0.0 und wird an die Zieladresse 255.255.255.255 gesendet.

Auf diese Anfrage antwortet nun der DHCP-Server mit einer DHCPOFFER-Nachricht. Das Antwortpaket hat schon als Zieladresse die IP, welche der Client in Zukunft besitzen soll. Da die MAC-Adresse in der Anfrage vom Client mitgesendet wurde, kann auf diese Weise die DHCPOFFER-Nachricht nun ihr Ziel finden. Wenn der DHCP Broadcast durch eine Firewall mit Paketfilter geleitet werden soll, müssen verschiedene Filter festgelegt werden, welche bei Anfragen von IP 0.0.0.0 auf Port 67 bzw. in der Rückrichtig für alle IP‘s auf Port 68 einen ungehinderten Verkehr erlauben.

Der Client erhält nun vom DHCP-Server ein sogenanntes Angebot, er entscheidet nun, ob es für ihn korrekt ist. Wenn dies zutrifft, sendet er eine DHCPREQUEST-Nachricht, um dem Server mitzuteilen, das er diese Konfiguration nutzen will. Der DHCP-Server bestätigt dieses und sendet eine DHCPACK-Nachricht - mit absenden dieses DHCPACK besitzt der Client nun seine IP-Adresse.

Wenn diese Prozedur fehlschlägt, weil der Client z.B. heraus findet, dass die IP-Adresse doppelt vergeben ist, sendet er eine DHCPDECLINE-Nachricht an der Server, und die gesamte Vergabeprozedur beginnt nun von vorne. Im Falle einer DHCPDECLINE-Nachricht, sperrt der Server die Adresse für die interne Vergabe.

Zusammen mit seiner IP-Adresse erhält der Client in der DHCPACK-Nachricht auch eine Lease-Time mitgeteilt, welche ihm sagt, wie lange die IP-Adresse für ihn reserviert ist. Der RFC Standart sieht vor, das der Client nach der Hälfte der Lease-Time einen erneuten DHCPREQUEST sendet und so dem Server mitteilt, dass er weiterhin die für ihn reservierte IP-Adresse behalten will. Nach Erhalt dieser Nachricht sendet der Server eine identische DHCPACK-Nachricht an den Client zurück, in der die neue Lease-Time mitgeteilt wird. Nun ist die IP-Adresse verlängert und der DCHP-Refresh ist komplett. Wenn der Client es versäumt eine Verlängerung zu beantragen, muss das Netzwerkinterface dekonfiguriert werden und der DHCP-Request startet erneut mit einer DHCPDISCOVER-Nachricht.


Abbildung 1: DHCP-Adressvergabe in einem Netzwerk

Jetzt kommen wir an den Punkt, an der der Client herunterfährt. Zu diesem Zeitpunkt sendet er eine DHCPRELEASE-Nachricht an den Server, um die Adresse wieder freizugeben. Nun besitzt der Client aber auch die Möglichkeit, seine zuletzt zugewiesene IP-Adresse über den Reboot hinweg zu "merken". Dies kann zum Beispiel der Fall sein, wenn die Lease-Time, noch nicht abgelaufen ist, oder dem Client eine feste IP-Adresse zugeteilt wurde.
Dann entfallen die Initialisierungsschritte und der Client schickt direkt eine DHCPREQUEST-Nachricht an den Server. Dieser bestätigt entweder die Anfrage oder sendet eine DHCPNAK-Nachricht um dem Client mitzuteilen, seine gespeicherten Konfigurationen zu löschen, und die Anfrage komplett von vorne zu beginnen.

DHCP unter Linux

Fast alle Linux-Distributionen erlauben es, das System auch als DHCP-Client zu nutzen. Von Distribution zu Distribution kann es kleine Abweichungen von der Prozedur geben aber der generelle Ablauf ist immer gleich.
Es wird zum Beispiel das Programm dhclient, oder ein artverwandtes Programm, welches die gleiche Funktion besitzt, benötigt. Dieses Programm sendet die DHCP-Anfragen an den DHCP-Server und kommuniziert auch mit diesem. Nun läuft der Client die in Abbildung 1 beschriebene Prozedur ab, und die notwendigen Informationen (IP-Adresse, Netzmaske, Route, DNS-Server usw.) werden an den Client übermittelt. Die hierzu nötigen Konfigurationsschritte und Anpassungen (z.B. ifconfig und resolv.conf) werden automatisch durchgeführt.

DHCP unter Windows

Auch unter Windows gestaltet sich die Nutzung von DHCP ähnlich einfach wie unter Linux-Distributionen. Bei der normalen Grundinstallation von Windows 2000 / XP ist die Netzwerkumgebung schon so vorkonfiguriert, das der Client alle Informationen von einem DHCP-Server bezieht. Wenn kein DHCP-Server vorhanden ist, muss die dann manuell angepasst werden.


Abbildung 2: Nutzung des DHCP Dienstes unter Windows

DHCP Dienst auf einem Hardware Router

Heutzutage bieten die meisten Hardware Router einen DHCP Dienst. In Abbildung 3 wird die Einrichtig dieses Diensten am Beispiel des D-Link 604+ Hardware Routers gezeigt.


Abbildung 3: Einrichten des DHCP Diensten auf einem Hardware Router

Zuerst muss unter dem Menupunkt DHCP der Radio-Button (enable) aktivert werden. Nun werden noch Starting- und Ending IP festgelegt. Diese beiden IP-Adressen legen den Adresspool fest aus dem die IP-Adressen vom DHCP-Server vergeben werden. Als letztes noch die Lease-Time gesetzt. Wie auch bei dem Linux DHCP Deamon gibt es bei vielen Hardware Routern die Möglichkeit, bestimmten Rechnern feste IP Adressen zuzuweisen. Hierzu muss der Rechnername, die MAC-Adresse und die IP Adresse, die der Rechner später haben soll, gesetzt werden. Somit ist die Konfiguration einen Hardware Routers schon fertig.

Grundlagen und Installation eines DHCP Servers unter Linux

Das System muss in der Lage sein, mit RAW-Sockets zu arbeiten, das heißt, dass vollständige Pakete aus einem geöffneten Socket gelesen werden können. Diese Pakete enthalten den vollständigen DHCP-Request eines Clients.

Falls diese Option nicht aktiviert ist, muss man dies noch vorher im Kernel einstellen. Um diese Option zu aktivieren muss man make menuconfig bzw. make xconfig ausführen und unter "Network Options" den Switch Packet Socket einschalten. Somit ist der Server vorbereitet für die Installation des DHCP-Deamon.

Die aktuelle Version des DHCP Deamon des ISC (Internet Software Consortium), das auch für Programme wie, BIND und INN verantwortlich ist, gibt es unter:

http://www.isc.org/index.pl?/sw/dhcp

Nach dem Herunterladen und Entpacken der Software geht man folgendermaßen vor:

$ ./configure

Durch die Befehlsfolge

$ make 
$ su -
Password:
# make install

wird der Deamon kompiliert und installiert. Weiterhin wird ein Relay Agent (dieser dient dazu DHCP-Requests für Linux Router weiterzuleiten) und Omshell, ein Tool das dazu dient, Datenbanken des DHCP-Deamon anzusehen zu editieren bzw. zu manipulieren.

Nun muss man noch einige Regeln am Server festlegen, damit der Server auf Anfragen der Clients auf der IP 255.255.255.255 antwortet.

# route add -host 255.255.255.255 dev eth0

Wenn das fehlschlägt sollte man folgende Zeile in die /etc/hosts eintragen:

255.255.255.255 all-ones

und dann folgendes eingeben.

# route add 255.255.255.255 dev eth0

Ausserdem müssen noch einige Verzeichnisse und eine Datei angelegt werden.

# mkdir /var/state
# mkdir /var/state/dhcp
# touch /var/state/dhcp/dhcpd.leases

Die Konfiguration

Damit der DHCP-Deamon korrekt funktioniert, muss auch die Config angepasst werden. Die Konfigurationsdatei des Deamon ist /etc/dhcpd.conf. Sie ist hierarchisch aufgebaut. Zuerst werden allgemein gültige globale Parameter festgelegt, welche für alle Clients im Netz gelten, z.B. Domainname und Gateway.

Als nächstes Stehen die Subnetze in der Hierarchie. Hier dürfen ebenfalls Parameter für die Clients festgelegt werden, welche in diesem Subnetz liegen. Jedes Subnetz kann zum Beispiel einen eigenen Default-Router haben. Die Parameter innerhalb des Subnetzes überschreiben die global definierten Parameter. Bei solchen Subnetzen ist es wichtig, das der DHCP-Deamon nur auf Anfragen aus dem Subnetz antwortet, welche in der dhcpd.conf stehen. Wenn ein Subnetz nicht definiert ist, wird diese Anfrage einfach ignoriert.

Die nächste Hierarchiestufe ist der Pool. Er wird innerhalb eines Subnetzes angelegt. In diesem Pool können auch Bereiche angelegt werden, somit können auch mehrere Pools in einem Subnetz existieren. Dies ist zum Beispiel für räumlich getrennte Rechner bestimmt, welche aber noch im gleichen Subnetz legen liegen sollen.

Als letzte Stufe in der Hierarchie gibt es die Host-Stufe. In dieser Stufe können einzelne Rechner konfiguriert werden, wenn zum Beispiel ein Rechner immer die gleiche IP bekommen soll. Dies widerspricht zwar dem Grundsatz von DHCP aber manchmal ist es nötig, wenn z.B. Zugriffsregeln auf dem Server (Paketfilter oder TCP-Wrapper Regeln) für eine bestimmte IP festgelegt sind.

Das "group" Statement hilft dabei, neben der Unterteilung nach Subnetzen, Konfigurationsblöcke mit gleichen Parametern zusammenzufassen. So muss nicht für jeden Host die gesamte Palette wiederholt werden.

Die vergebene Adressen werden in der Datei /var/state/dhcp/dhcp.leases gespeichert.

Listing 1: Beispiel für eine Config

server-identifier dhcp.planet-rcs.lan 
filename "/nfsroot/bootimg";
option domain-name "planet-rcs.lan"; 
option domain-name-servers 192.168.1.2, 81.3.25.43; 
option routers 192.168.1.5; 

default-lease-time 43200; 
max-lease-time 86400; 
log-facility local7; 
ddns-update-style ad-hoc; 

subnet 192.168.1.0 netmask 255.255.255.0 { 
range 192.168.1.50 192.168.1.200; 
range dynamic-bootp 192.168.1.210 192.168.1.250; 
option broadcast-address 192.168.1.255; 
} 

group {

option routers 192.168.1.6; 
option x-server-defs "de IMPS/2 psaux 96 100 1024x768 svga 16";
option bootlocal-script "modprobe -qa agpgart";

host lamont { 
hardware ethernet 08:00:69:07:ab:fe; 
option host-name"lamont"; 
fixed-address 192.168.1.10; 
} 

host waschbaer { 
hardware ethernet 08:00:07:26:c0:a5; 
option host-name"waschbaer"; 
fixed-address 192.168.1.11; 
} 

}

• IP-Adresse
  
• Lease-Time
  
• Default-Route
  
• Netzmaske
  
• DNS-Server-Adressen
  
• WINS-Server
  
• Broadcast-Adresse
  
• IP-Varialen
  
• weitere Parameter

Mit dhcpd -d (-d = debug) kann man testen, ob der DHCP-Server richtig läuft und ob eventuell ein paar Fehler in der Konfiguration sind.

Hier noch das Start-Stop-Script welches in liegt /etc/init.d/dhcpd

Download des Start/Stop Scriptes

"start" dient zum Starten, "stop" logischerweise zum Stoppen und "refresh" löscht die Leases-Datei. Wenn der Server automatisch beim Booten starten soll, müssen noch die Links in den Runleveln gesetzt werden:

# cd /etc/rc0.d
# ln -s ../init.d/dhcpd K21dhcpd
# cd ../rc1.d
# ln -s ../init.d/dhcpd K21dhcpd
# cd ../rc2.d
# ln -s ../init.d/dhcpd S91dhcpd
# cd ../rc6.d
# ln -s ../init.d/dhcpd K21dhcpd

Nun kann man den DHCP-Deamon starten, und den Dienst nutzen. Falls man zusätzlich noch einen Bind Nameserver zu laufen hat, kann man sich im folgenden Abschnitt noch darüber informieren, wie man diese beiden Programme zusammen zum laufen bringt, um auch die Namesauflösung bei dynamischen IP‘s sicher zu stellen.

DHCP Server hält den DNS aktuell

Für DNS sind Rechner mit fester IP-Adresse der Standart, die Zuordnung von Name und IP ist hier denkbar einfach. Aber bei dem Einsatz von DHCP-Servern und dynamischen IP‘s gestaltet sich die Zuordnung komplizierter und die manuelle Anpassung der DNS-Konfiguration würde einen Administrator zum Wahnsinn treiben.

Um die dynamisch vergebenen IP Adressen mit ihren Hostnamen durch den für die aktuelle Domain zuständigen Nameserver aufzulösen, besitzt der DHCP-Server die Möglichkeit, dem Bind Nameserver "Updates" zu schicken. Um eine gewisse Sicherheit zu garantieren sollte dies mit Hilfe eines DNS-Schlüssels passieren, welcher in der Datei named.conf für die Access Control List genutzt wird. Die Authentifizierung verläuft also nach dem "shared key" Prinzip. In der dhcpd.conf müssen die Zeilen aus Listing 2 in dem allgemeinen Bereich eingefügt werden.

Zuerst muss aber ein dnssec-key generiert werden. Das Programm dnssec-keygen - es gehört zu Bind, kann solche Key‘s erzeugen. Dies geschieht folgendermaßen.

# cd /etc
# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP

Man sollte nun zwei Dateien erhalten, die mit Kdhcp_updater anfangen (das Ende das Dateinamens wird per Zufall bestimmt):

# ls -l Kdhcp_updater*

-rw-------   1 root     root           54 Jun  4 15:09 Kdhcp_updater.+147+56428.key
-rw-------   1 root     root           81 Jun  4 15:09 Kdhcp_updater.+147+56428.private

Uns interessiert nur die Datei mit der Endung private. Darin ist der Schlüssel enthalten. Dieser sollte aber kein "\" enthalten, also dies mit cat, oder einen Editor seiner Wahl überprüfen. Im Zweifelsfall die beiden Dateien löschen und noch mal einen Schlüssel erstellen:

# cat Kdhcp_updater.xxxxxxxxxx.private

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: gh0FSO+nOmhjYjdfz2Ealq=2

Nun kann man den Key in der dhcpd.conf nutzen.

Listing 2: dhcpd.conf für den Update des Nameserver

server-identifier dhcp.planet-rcs.lan
option domain-name "planet-rcs.lan";
option domain-name-servers 192.168.1.2, 81.3.25.43;
option routers 192.168.1.5;

default-lease-time 43200;
max-lease-time 86400;
log-facility local7;
ddns-update-style ad-hoc;

key DHCP {
 algorithm HMAC-MD5.SIG-ALG.REG.INT;
 secret gh0FSO+nOmhjYjdfz2Ealq=2;
};


zone planet-rcs.lan {
 primary 192.168.1.2;
 key DHCP;
}

zone 1.168.192.in-addr.arpa. {
 primary 192.168.1.2;
 key DHCP;
}

authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.50 192.168.1.200;
  range dynamic-bootp 192.168.1.210 192.168.1.250;
 option broadcast-address 192.168.1.255;
}

group {
 option routers 192.168.1.6;
 option x-server-defs "de IMPS/2 psaux 96 100 1024x768 svga 16"; 
 option bootlocal-script "modprobe -qa agpgart"; 

host lamont {
 hardware ethernet 08:00:69:07:ab:fe;
 option host-name"lamont";   
 fixed-address 192.168.1.10;
}

host waschbaer { 
hardware ethernet 08:00:07:26:c0:a5; 
option host-name"waschbaer"; 
fixed-address 192.168.1.11; 
} 

}

Für die zu aktualisierenden Forward- und Reverse-Zonen müssen nun Einträge definiert werden, wer der Nameserver ist, wer die Updates empfangen soll und welcher Schlüssel verwendet werden soll. Die Authentifizierung dieser Updates basiert auf der Tatsache, das beide Seiten den Schlüssel kennen (shared key Prinzip).

Nun muss nur noch die Forward Zone für die Updates eingetragen werden, dies geschieht mit der Option ddns-domainname "planet-rcs.lan". Die Reverse-Einträge erfolgen automatisch, wenn für die Reverse-Zonen des Netzes ein Eintrag vorhanden ist.

Um dem DHCP-Deamon zu erlauben, das er Updates gestatten soll, müssen die gleichen Key‘s in der named.conf und der dhcpd.conf vorhanden sein. Die Definition der Zonen "planet-rcs.lan" und der Reverse Zonen sind in Listing 3 beschrieben.

Listing 3: Definition der Reverse-Zonen in der named.conf

key DHCP {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret gh0FSO+nOmhjYjdfz2Ealq=2;
};

zone "planet-rcs.lan" {
 type master;
 file "named.planet-rcs";
allow-update {key DHCP;};
};

zone "1.168.192.in-addr.arpa" {
 type master;
 file "named.192.168.1";
 allow-update {key DHCP;};
};

Somit ist die Konfiguration komplett. Der DHCP- und DNS-Server sind nun in der Lage miteinander zu kommunizieren und Up-to-Date zu bleiben. Updates bleiben laufend wirksam, neue Einträge werden hinzugefügt und abgelaufene Leases werden aus der Zone entfernt. Die Zuweisung der Adresse geschieht nach dem in Abbildung 4 abgebildeten Muster.


Abbildung 4: DHCP-Adressvergabe und DNS-Server Syncronisation

Nun sollten wir auch testen ob beide Programme zusammen laufen. Es empfiehlt sich, ein tail -f /var/log/messages/daemon.log (je nach Distribution auch wo anders) mitlaufen zu lassen um eventuelle Fehler zu finden.

Ausblick auf die Zukunft - DHCPv6

IPv6 sollte DHCP als eigenständiges Protokoll ursprünglich überflüssig machen, da viele DHCP-Funktionen serienmäßig in IPv6 enthalten sind. IPv6-fähige Rechner können aus der Layer 2 MAC-Adresse eines Netzwerkinterfaces und dem Präfix fe80::/64 eine Link-lokale IPv6 Adresse errechnen, unter der er dann im lokalen Netzwerk erreichbar ist. Durch eine Anfrage an eine bestimmte Multicast Gruppe kann der Client nach den erreichbaren Routern suchen, und diese dann auch als Gateway nutzen. Bis zu diesem Punkt funktioniert die statuslose Autokonfiguration sehr zuverlässig, aber falls der Client noch einen DNS-Server benötigt, schlägt die Autokonfiguration fehl, da in der zur Zeit gültigen IPv6 RFC-Fassung keine automatische Suche nach DNS-Servern vorgesehen ist.

Es gibt zwar einige unabhängige Lösungsansätze, z.B. durch den Einsatz mehrerer Multicast-Gruppen an denen die DNS-Server im lokalen Netzwerk lauschen. Für diese Lösungen gibt es aber zurzeit noch keinen einheitlichen Standart. Falls die automatische Netzwerkkonfiguration nicht vom lokalen IPv6-Stack des jeweiligen Betriebssystems durchgeführt werden soll, gibt es seit Juli 2003 das DHCPv6 Protokoll, welches in RFC 3315 definiert wurde. Das Protokoll bietet die gleiche Funktionalität wie sein Vorgänger DHCPv4, einziger großer Unterschied sind die Kommunikationsports. Anders als bei seinem Vorgänger läuft die Kommunikation auf UDP Port 546 bei Clients und 547 bei Servern.