DHCP - Informatik 4

Rheinisch-Westfälische Technische Hochschule Aachen
Lehrstuhl für Informatik IV
Prof. Dr. rer. nat. Otto Spaniol
Dynamic Host Configuration Protocol
Proseminar: Dynamic Host Configuration
Protocol
WS 2002/2003
Nils Gräf
Matrikelnummer: 232827
Betreuung: Mesut Günes
Lehrstuhl für Informatik IV, RWTH Aachen
DHCP-Proseminar
Inhaltsverzeichnis
1. Einführung .................................................................................................................. 2
1.1
Erklärung der Fachbegriffe .................................................................................. 2
2. BOOTP........................................................................................................................ 4
3. DHCP........................................................................................................................... 5
3.1
Aufbau eines DHCP-Pakets ................................................................................. 6
3.2
Arten der Anfragen............................................................................................... 7
3.3
Ablauf einer Zuordnung....................................................................................... 8
3.4
Leasezeiten........................................................................................................... 9
3.5
DHCP-Relay....................................................................................................... 11
4. Praktisches Beispiel.................................................................................................. 13
4.1
Konfigurationsdatei............................................................................................ 14
4.2
Manuelle Zuordnung.......................................................................................... 15
4.3
Automatische Zuordnung................................................................................... 16
4.4
Dynamische Zuordnung ..................................................................................... 16
5. Zusammenfassung .................................................................................................... 17
6. Quellenangabe .......................................................................................................... 18
1
DHCP-Proseminar
1. Einführung
Diese Ausarbeitung soll dem Leser das Dynamic Host Configuration Protocol näher
bringen. Was ist das DHCP und warum wurde es entwickelt? Diese beiden Fragen sind die
Hauptaspekte, worauf diese Arbeit eingeht. Die Motivation, die hinter diesem Protokoll steht,
ist schnell beschrieben und leicht verständlich. Man stelle sich ein großes
Softwareunternehmen mit mehreren tausend Rechnern vor. Dieses Netzwerk muss
administriert und gut strukturiert sein. In der Zeit vor DHCP musste, sobald etwas
Gravierendes im Netzwerk verändert wurde, zum Beispiel ein neuer Gateway wurde in
Betrieb genommen, ein Administrator an jeden einzelnen Rechner und die Konfiguration
geändert werden. In solch einem großen Unternehmen werden fast täglich neue PC´s in
Betrieb genommen und andere ausgetauscht. Auch hier musste jedes Mal ein Administrator
die Netzwerkeinstellungen konfigurieren. Bei so vielen Rechnern wird logischerweise auch
eine Unmenge von IP-Adressen benötigt. Diese sind aber im Zeitalter von IPv4 knapp. Dieses
Proseminar soll dem Leser verdeutlichen, wie mit DHCP diese Probleme gelöst werden. Dazu
wird erst das Prinzip von BOOTP, dem Vorgänger von DHCP, erläutert, um dann die Vorteile
von DHCP aufzudecken. Anhand von Grafiken wird dann auf den zeitlichen Ablauf einer
DHCP-Anfrage eingegangen und aufgezeigt, aus was ein einzelnes Paket besteht.
Abgerundet wird diese Ausarbeitung dann mit einem Beispiel aus der Praxis. Gezeigt wird
eine lauffähige Konfiguration, wie sie unter SuSE Linux 8.0 an einer Schule zum Einsatz
kommt. Darin werden die drei verschiedenen Vergabemodi verwendet und dazu erklärt,
warum der Administrator den jeweiligen Modus gewählt hat und welche Vorteile sich daraus
für die Administration dieses LANs ergeben. Um diese Ausarbeitung besser verstehen zu
können, steht am Anfang eine Erklärung der Fachbegriffe, die nicht als bekannt vorausgesetzt
werden können.
1.1 Erklärung der Fachbegriffe
Address Resolution Protokoll (ARP)
Das ARP setzt eine logische Netzwerkadresse in eine Hardwareadresse um. In Netzwerken
werden die physikalischen Adressen der Rechner nicht verwendet, sondern es handelt sich um
eine logische Adressierung. In TCP/IP-Netzwerken handelt es sich zum Beispiel um das IPAdresskonzept.
Broadcast
Wenn eine Nachricht an die Broadcast-Adresse gesendet wird, empfängt jeder angeschlossene
Rechner im Netzwerk diese Nachricht.
Domain Name System (DNS)
Alle Rechner in einem TCP/IP-Netz werden über eine eindeutige IP-Adresse identifiziert.
Diese 4 Byte lange Zahl ist kompliziert und anfällig für Tippfehler. Aus diesem Grund wurde
bereits 1984 das Domain Name System (DNS) geschaffen. Es ermöglicht, Hosts über den
zugehörigen Domainnamen, etwa rwth-aachen.de, zu erreichen. Das DNS ist eine verteilte
Datenbank, deren zentrale Komponenten die Nameserver sind.
2
DHCP-Proseminar
Hardwareadresse
Jeder Netzwerkadapter bekommt bei der Herstellung eine 6 Byte lange Adresse (zumeist in
hexadezimal angegeben) eingebrannt. Diese ist aufgrund von Herstellerabsprachen weltweit
einmalig. Jeder Rechner ist also über diese Adresse eindeutig zu identifizieren.
IPv4/IPv6
Der Unterschied dieser beiden Konzepte liegt hauptsächlich in der Länge der IP-Adresse. Im
alten und derzeit noch verwendeten Standard IPv4 hat eine Adresse die Länge von 4 Byte.
Eine Beispieladresse ist zum Beispiel die 192.168.0.5. Aufgrund der relativ geringen Anzahl
von diesen Adressen ist man nun dabei auf IPv6 zu migrieren. Bei IPv6 ist eine Adresse 16
Byte lang.
Network Information System (NIS)
Das Network Information System ist ein Verzeichnisdienst, der die Benutzung bestimmter
Konfigurationsdateien von verschiedenen Rechnern aus ermöglicht. Insbesondere in
Verbindung mit dem Network File System (NFS) wird NIS verwendet, um Benutzern
netzwerkweit dieselbe Umgebung zur Verfügung zu stellen.
Request For Comment (RFC)
Hierbei handelt es sich um eine fortlaufend durchnummerierte Dokumentensammlung, die
unter Verwaltung des Internet Architecture Board (IAB) steht. Die bestehenden Protokolle
werden gemäß ihres Entwicklungsstandes und Einsatzbereiches kategorisiert. Die RFC´s sind
für die Entwicklung und Bewertung von Protokollen im Internet verantwortlich.
Windows Internet Name Service (WINS)
Vergleichbar mit dem Verfahren, das bei DNS verwendet wird, um IP-Adressen in leichter
lesbarere Namen umzusetzen, stellt WINS eine Methode auf Windows-NT basierten
Systemen dafür zur Verfügung. Der Hauptunterschied zwischen WINS und DNS liegt darin,
dass DNS eine hierarchische Anordnung zur Verfügung stellt (die Namen können in einer
baumartigen Struktur angeordnet werden). WINS stellt einen "flachen" Name nsraum zur
Verfügung.
WINS unterscheidet sich vom Standard DNS in drei signifikanten Punkten:
1. WINS ist dynamisch. Wenn ein Microsoft-basierter Computer im Netzwerk
hochgefahren wird, sendet er einen Broadcast an alle physikalisch an diesem Segment
angeschlossenen Systeme. Dies ist ein dynamischer Prozess, bei dem Computer das
Netzwerk betreten und wieder verlassen ohne dass eine Intervention notwendig ist.
Bei DNS werden die IP-Mappings in einer Datenbank gehalten, die jemand
administrieren muss. DNS stellt Anfragen über einen Requestor namens BIND,
während NetBIOS über Broadcasts oder gerichtete Datagramme an den WINS-Server
anfragt.
2. Ein NetBIOS Name kann nicht ohne zusätzliche Software über DNS aufgelöst
werden. Microsofts DNS-Server integriert sich in seinen WINS-Service, der DNS
sagt, dass er WINS als eine Art 'hosts'-Datei behandeln soll.
3. Bei NetBIOS müssen Namen im ganzen Netzwerk eindeutig sein, während bei DNS
mehrfache Namen (sogar in derselben Domäne) zulässig sind.
3
DHCP-Proseminar
2. BOOTP – Bootstrap Protocol
Das Kapitel 2 ist frei nach dem Buch TCP/IP-Grundlagen von Gerhard Lienemann [3]
verfasst. Es ist nur auf die nötigen Bedürfnisse zu dem eigentlichen Thema gekürzt und die
Thematik sprachlich angepasst.
Das BOOTP-Protokoll ist ausschließlich dazu entwickelt worden, um Boot-Vorgänge von
Diskless-Workstations, also von Rechnern ohne Disketten- und Festplattenlaufwerk, zu
realisieren.
Mit BOOTP wird nicht das eigentliche Netzwerk-Booten sondern lediglich die Übernahme
der relevanten Netzwerkdaten (z. B. der eigene n IP-Adresse) bewerkstelligt. Der Ladevorgang
selber wird dann von herkömmlichen Transferprotokollen wie TFTP (Trivial File Transfer
Protocol) übernommen.
Der BOOTP-Client beginnt den Bootvorgang mit einem IP-Broadcast, womit er seine
Hardwareadresse dem Server übermittelt. Derjenige Bootserver, dem diese Adresse „bekannt“
ist, antwortet und schickt ihm seine IP-Adresse, den Namen vom Bootserver und den Namen
des Bootfiles, welches geladen werden soll. Nach dem Ladevorgang des Bootfiles und dem
Booten ist dieser Rechner ein vollwertiges Mitglied des Netzwerkes.
Nach dem RFC 951 [1] kann man die Aktivitäten eines BOOTP-Clients folgendermaßen
charakterisieren:
Wie lautet mein Name?
Die Hardwareadresse ist in einem Netzwerk letztlich für die physikalische Adressierung
verantwortlich. Diese ist in der Regel auf dem ROM der Netzwerkkomponente eingebrannt,
ist im Netzwerk eindeutig und wird durch einen separaten BOOTP-Vorgang vor dem
Bootvorgang ausgelesen.
Wie erreiche ich volle Netzwerkfähigkeit?
Die Frage „Wer kennt mich“ stellt der BOOTP-Client netzwerkweit mit einem BootPRequest. Die bereits ausgelesene Hardwareadresse ist Teil dieses Requests, wodurch der für
diesen Client verantwortliche Server seinen „Kunden“ eindeutig erkennt und ihm einen Reply
sendet. Dieser Reply enthält die eigene IP-Adresse, die IP-Adresse des Servers, den Namen
des Bootfiles und gegebenenfalls auch noch die IP-Adresse eines Routers. Mit dieser BasisKonfiguration lassen sich nun auch ARP-Requests und -Replies bearbeiten, und das TFTProtokoll kann zur Übertragung des Bootfiles verwendet werden.
Wie erhalte ich die erforderliche „Kommunikations-Intelligenz“?
Da nun alle notwendigen Informationen für den „remote“-Bootvorgang vorliegen, kann dieser
über TFTP vorgenommen werden. Während des Ladevorganges erfolgt auch die Übernahme
weiterer Netzwerkinforma tionen. Der Client wird initialisiert, und nach der Etablierung der
Netzwerkverbindungen ist der Client einsatzbereit.
4
DHCP-Proseminar
3. DHCP – Dynamic Host Configuration Protocol
Die Möglichkeiten von BOOTP stießen schnell an ihre Grenzen, und auf Grund der
technischen Entwicklung kamen neue Probleme auf. Ein Netzwerk ist lange nicht mehr so
statisch wie es früher einmal war. Wie oft kommt es vor, dass z.B. auf einer Tagung jemand
mit einem Notebook kommt und sich „mal eben“ in das Intranet einloggen will? Soll dazu
jedes Mal der Administrator gerufen werden, um die richtige Konfiguration des Clients
vorzunehmen? In großen Unternehmen trat mit der Zeit aber auch ein anderes Problem auf.
Die IP-Adressen wurden knapp. Jeder PC hatte seine eigene IP-Adresse, aber nie waren alle
Rechner im Einsatz, und einige IP-Adressen lagen die meiste Zeit brach. Diese beiden
Probleme waren die Hauptmotivation, um BOOTP weiterzuentwickeln. Das Ergebnis ist
DHCP. Alle Funktionen von BOOTP wurden übernommen, dieselben Ports, verwendet und
jeder BOOTP-Client kann mit einem DHCP-Server kommunizieren. DHCP ist nicht nur für
Diskless-Workstations gedacht, sondern soll allgemein die Netzwerkkonfigurationen der
Clients zentralisieren, und damit sind diese viel leichter zu administrieren. Außerdem kann
DHCP die ihm zur Verfügung stehenden IP-Adressen dynamisch vergeben, so dass wirklich
immer nur so viele IP-Adressen vergeben sind wie es aktive PC´s im Netzwerk gibt.
Insgesamt gibt es drei verschiedene Arten wie das Dynamic Host Configuration Protocol
seine Clients bedienen kann. Auf diese Varianten mit ihren Vor- und Nachteilen wird in
Kapitel 4 anhand eines praktischen Beispiels eingegangen. DHCP ist in dem RFC 2131 [4]
festgelegt. Es gibt einige weitere RFC´s, die das Verhalten von diesem Protokoll beschreiben,
wie das RFC 2132 [5]. Ein Weiteres, welches erwähnt werden sollte, ist das RFC 1534 [2],
welches die Interaktion zwischen BOOTP und DHCP beschreibt. Das Dynamic Host
Configuration Protocol ist nur in TCP/IP-Netzwerken implementiert und dafür optimiert. Ein
Einsatz in nicht IP-basierten Netzen, wie zum Beispiel Novell Netware-Netzwerke, ist aber
auch gar nicht sinnvoll, da ja eine der Hauptaufgaben von DHCP das dynamische Verwalten
von eben diesen IP-Adressen ist.
DHCP ist aber wohl auch einer der Hauptgründe, warum IPv6 sich noch bis heute nicht weiter
durchsetzen konnte. Denn die durch das große Wachstum des Internet knapp werdenden
IPv4-Adressen werden nun effektiver verwendet, und ein Umstieg auf ein neues System mit
mehr Adressen ist so nicht mehr ganz so dringend. Stellen Sie sich nur mal vor, es gäbe kein
DHCP und jeder private PC, der mit dem Internet verbunden ist, hätte eine eigene Adresse.
Leicht vorstellbar, dass da die 4 Milliarden möglichen Adressen schnell verbraucht wären.
Dem Internet stehen aber ungefähr nur die Hälfte dieser Adressen zur Verfügung, da aufgrund
von großen Firmen, denen Class A-Netze gehören, einige Adressen vergeben sind, aber
niemals im wirklichen Gebrauch sein werden.
Nach dieser Motivation wird nun die technische Umsetzung dargestellt. Begonnen wird im
nächsten Abschnitt mit dem Aufbau einer einzelnen DHCP-Nachricht.
5
DHCP-Proseminar
3.1 Aufbau eines DHCP-Pakets
In diesem Abschnitt soll der Aufbau eines einzelnen DHCP-Message-Paketes verdeutlicht
werden. Die Zahlen in den Klammern geben die Länge des jeweiligen Feldes in Bytes an.
Fig. 1: Aufbau eines DHCP-Pakets
Erläuterung der einzelnen Felder:
Name
Bytes
Op
Htype
Hlen
Hops
Xid
1
1
1
1
4
Secs
Flags
2
2
Ciaddr
4
Yiaddr
Siaddr
Giaddr
4
4
4
Chaddr
Sname
File
Options
16
64
128
var
Erklärung
Typ der Nachricht
Art der Hardwareadresse
Länge der Hardwareadresse
Anzahl der zu überwindenden Relays
Zufallszahl, die vom Client und vom Server als
Transaktions ID verwendet wird. Diese ID wird vom
Client generiert.
Zeit seit Beginn des Dialogs
Beinhaltet ein Broadcastflag und der restliche Teil
muss noch auf Null gesetzt sein. Dieser Bereich ist
für Erweiterungen reserviert.
Client IP-Adresse, nur gesetzt wenn es sich um eine
Erneuerung handelt z.B. bei einem Reboot
Enthält die vom Server vorgeschlagene IP-Adresse.
Serveradresse, nur in DHCPOFFER und DHCPACK
Enthält gegebenenfalls die IP-Adresse eines DHCPRelays
Die Hardwareadresse des Clients
Optional der Hostname des Servers
Name eines eventuellen Bootfiles
Optionale Parameter
6
DHCP-Proseminar
3.2 Arten der Anfragen
In diesem Abschnitt werden nun die verschiedenen Arten der Nachrichten in einem DHCPDialog zwischen Server und Client vorgestellt. Die Nachrichten sind so genannte UDP-Pakete
und nutzen die Ports 67 und 68. Port 67 wird auch der „DHCP-Server-Port“ genannt und dem
entsprechend Port 68 der „DHCP-Client-Port“. Dies besagt, dass alle Nachrichten vom Server
an den Client auf Port 68 und die Anfragen vom Client zum Server auf Port 67.
DHCPDISCOVER Bei diesem Paket handelt es sich um einen Broadcast des Clients zum
auffinden eines Servers. Als Absender IP-Adresse wird die 0.0.0.0
(wird solange verwendet bis der PC eine IP-Adresse zugewiesen
bekommen hat) und als Empfänger-IP-Adresse die 255.255.255.255
(Broadcast) verwendet.
DHCPOFFER
Dies ist die Serverantwort auf einen DHCPDISCOVER. Darin wird
eine mögliche IP-Adresse angeboten und weitere Paramter, wie z.B. ein
DNS-Server könne n übergeben werden. Auch diese Nachricht hat als
Empfänger IP-Adresse die 255.255.255.255.
DHCPREQUEST
Dieses Paket kann drei verschiedene Verwendungen haben, die aber
sehr stark zusammenhängen:
(a) Bestätigung an einen der Server, dass dieser ausgewählt wurde und
damit gleichzeitig auch die Absage an die anderen Server.
(b) Bestätigung der vorhandenen Daten, zum Beispiel nach einem
Reboot.
(c) Zum Verlängern einer Leasezeit.
DHCPACK
Hierbei handelt es sich wieder um eine Servernachricht, die dieser zum
Bestätigen der Daten eines DHCPREQUEST´s sendet.
DHCPNAK
ist das Gegenstück zum DHCPACK. Hiermit teilt der Server dem
Client mit, dass seine IP-Adresse nicht korrekt ist (z.B. weil der Client
in einem neuen Subnetz ist), oder das seine Leasezeit abgelaufen ist.
DHCPDECLINE
Diese Nachricht ist ähnlich DHCPNAK, jedoch gibt diese Anfrage an,
dass seine IP-Adresse schon verwendet wird.
DHCPRELEASE
Ein solches Paket wird vom Client zum Server geschickt, wenn dieser
sich abmeldet und so seine IP-Adresse wieder freigibt.
DHCPINFORM
Dieses Paket sendet der Client dem Server um eine Konfiguration
abzufragen, wenn er extern schon eine IP-Adresse zugewiesen
bekommen hat.
7
DHCP-Proseminar
3.3 Ablauf einer Zuordnung
Fig. 2: Zeitlicher Ablauf eines DHCP-Dialogs
Der Client sendet zu Beginn eines DHCP-Dialogs ein Signal, das so genannte
„DHCPDISCOVER“. Da er selber keine IP-Adresse besitzt und er auch keine Adresse eines
Servers kennt wird dieses Signal per Broadcast in das lokale Subnetz gesendet. Befinden sich
in diesem Bereich ein oder mehrere DHCP-Server, so antworten alle mit einem
8
DHCP-Proseminar
„DHCPOFFER“ als Antwort. Aufgrund von Redundanz ist es gar nicht so selten, dass es
nicht nur einen DHCP-Server gibt. Dieses DHCPOFFER besagt nur, hier ist ein Server, der
dem anfragenden Client Dienste anbietet. Falls es also mehr als einen Server gibt, erreichen
logischerweise auch mehrere Antworten den Client. Welcher Server nun ausgewählt wird, ist
nicht in der RFC 2131 [4] festgelegt. Es kommt also auf die Implementierung und deren
Auswahlkriterien an. In den meisten Fällen ist es jedoch so, dass nach dem FIFO-Prinzip
vorgegangen wird, also die erste Antwort die den Client erreicht verwendet wird. Daraufhin
sendet der Client einen DHCPREQUEST wiederum per Broadcast in sein Subnetz. Diese
Nachricht enthält die IP-Adresse des ausgewählten Servers. Dieser Server sieht diese Message
als Bestätigung an, alle anderen Server als Absage.
Der Server wiederum bestätigt dies noch mit einem DHCPACK. Damit hat der Client seine
IP-Adresse erhalten, und der Server markiert diese in seiner internen Datenbank als „derzeit
verwendet“. Der Server überträgt noch die restlichen Parameter, wie Gateway oder DNSServer, und der Client braucht nur noch diese Daten in seine Konfiguration eintragen und ist
damit fertig für den Netzwerkbetrieb.
3.4 Leasezeiten
In diesem Abschnitt beschäftigen wir uns mit den Leasezeiten und dem dazu gehörenden
Mechanismus.
Im letzten Abschnitt wurde erläutert, wie ein Client seine Konfiguration erhält. Diese erhält er
aber bei der dynamischen Zuteilung nicht auf unbestimmte Zeit. Es wäre nicht sinnvoll eine
Adresse so lange einem Client zu überlassen bis dieser sich abmeldet und damit die Adresse
wieder freigibt. Wie oft saß man schon vor einem Rechner und es ging nichts mehr? Von
einem Restart bekommt der Server nichts mit, so dass diese IP-Adresse nie mehr freigegeben
würde. Es gibt aber auch Implementierungen von DHCP, die ein Abmelden vom Server gar
nicht beinhalten. Daher hat man sich für den so genannten Leasezeitmechanismus
entschlossen.
Mit der Bestätigung des Servers, also mit dem DHCPACK, übersendet dieser dem Client
auch die Gültigkeitsdauer dieser IP-Adresse. Der Client speichert sich zwei Werte T1 und T2,
in der Regel ist T1 50% und T2 87,5% der Gesamtdauer. Es ist jedoch festgeschrieben, dass
T1 kleiner als T2 und T2 kleiner der Leasezeit sein muss.
Nach Ablauf von T1 beginnt der Client mit dem Versuch seine Leasezeit zu verlängern und
sendet dem Server einen DHCPREQUEST. Daraufhin bekommt dieser vom Server wiederum
einen DHCPACK, welcher eine neue Leasetime beinhaltet. Der Client speichert die neuen
Werte T1 und T2 und der Zyklus beginnt von vorne. Dieser Mechanismus wird beendet,
sobald der Client sich explizit abmeldet oder der Server keine neue Leasezeit schickt. Wenn
aber der Client zwischen T1 und T2 keine neue Leasezeit empfangen hat sendet dieser zwar
auch noch mal einen DHCPREQUEST, diesmal jedoch wieder an alle Server. Der Client
startet eine neue Initialisierungsanfrage und bekommt eine neue IP-Adresse zugeteilt.
9
DHCP-Proseminar
Fig. 3: Ablaufdiagramm zum Verlängern einer Leasezeit
10
DHCP-Proseminar
3.5 DHCP-Relay
Jedes etwas größere Netzwerk wird heutzutage in verschiedene Subnetze aufgeteilt. Dafür
gibt es die verschiedensten Gründe. Manchmal sind es Sicherheitsaspekte, die die
Administratoren, dazu veranlassen ihr Netz in kleinere Netze aufzuspalten. Es können aber
auch ganz einfach unterschiedliche Bedürfnisse für verschiedene Abteilungen in einer Firma
der Grund für Subnetze sein. Um diese Subnetze zu verbinden werden Router eingesetzt. Nur
was passiert wenn man DHCP in einem solchen aufgesplitteten Netzwerk einsetzen will? In
jedem Subnetz einen eigenen DHCP-Server aufzustellen würde den Administrationsaufwand
um ein Vielfaches erhöhe n. Bei Änderungen in den Netzwerkkonfigurationen zum Beispiel
müsste man doch jeden Server umkonfigurieren, welches dem Sinn von DHCP, nämlich die
Konfiguration zentral an einem Ort zu haben, widerspricht.
Die dafür gefundene Lösung soll an dem Beispiel vo n Abbildung Vier erläutert werden.
Fig. 4: Beispiel für DHCP-Relays mit drei verschiedenen Subnetzen
11
DHCP-Proseminar
Das Beispiel demonstriert ein Netzwerk mit drei verschiedenen Subnetzen. In der Realität
entspricht jeder der drei Bereiche einem separaten Raum. Bereiche eins und drei sind zwei
CIP-Pools, die über DHCP verwaltet werden. Es soll auch verdeutlicht werden, dass DHCP
nicht nur auf Computer beschränkt ist. Alle Geräte, die TCP/IP verstehen und eine IP-Adresse
haben, können mit DHCP konfiguriert werden. In diesem Beispiel ist es ein Drucker im
dritten Bereich. Bereich zwei zeigt den Serverraum. Hier ist der DHCP-Server untergebracht.
Damit dieser Server auch Clients in anderen Subnetzen bedienen kann gibt es in jedem dieser
einen sogenannten DHCP-Relay.
Warum braucht man einen DHCP-Relay?
Die Antwort ist schnell gefunden, wenn man sich noch einmal Abschnitt 3.2 ansieht. Hieraus
geht hervor, dass ein Client einen Broadcast in seinem Netz abgibt. Davon würde der DHCPServer nichts mitbekommen, da er ja in einem anderen Netz ist. Man braucht also ein Gerät,
dass einen Broadcast in in das andere Netz weiterleitet. Dies ist in der Regel ein normaler
DHCP-Server, der aber keine eigene Konfiguration besitzt, sondern nur entweder den
nächsten Relay oder die Adresse vom eigentlichen Server kennt. Dieser „Gateway“ ist das
Bindeglied zwischen Server und Client. Er nimmt die Anfrage eines Clients entgegen, gibt
diese weiter und wartet auf die Antwort des Servers, um dann dem Client seine Daten
weitergeben zu können.
Mit diesem Prinzip hat man es doch geschafft, die Konfiguration zentral zu halten und die
Anzahl der wichtigen Server auf das Minimum zu reduzieren, welches aus Kostengründen,
aber nicht in Sachen Ausfallsicherheit, anzustreben ist.
12
DHCP-Proseminar
4. Praktisches Beispiel
Das zuvor erlangte theoretische Wissen soll nun an einem praktischen Beispiel erklärt
werden. Zum Einsatz kommt eine Konfiguration eines Kölner Gymnasiums. Die folgende
Konfigurationsdatei läuft auf einem AMD Athlon XP 1800+ unter SuSE Linux 8.0. Die
Konfigurationsdatei des DHCP-Dämons ist in der Regel unter Linux im Verzeichnis /etc zu
finden und hat den Namen „dhcpd.conf“. Die Beispielkonfiguration zeigt jedoch nur die
manuelle Verteilung, um das Dokument originalgetreu zu belassen. Automatische und
Dynamische Verteilungen werden in den beiden dazugehörigen Abschnitten mit Ausschnitten
relevanter Konfigurationen erklärt. Es ist jedoch zu erwähnen, dass es auch durchaus möglich
ist, verschiedene Vergabemodi gleichzeitig zu verwenden. In der Praxis findet man zum
Beispiel oft den Fall, dass die manuelle Verteilung mit der dynamischen oder der
automatischen kombiniert wird. Drucker zum Beispiel müssen immer dieselbe IP-Adresse
haben, da sonst die Druckertreiber diesen nicht mehr finden würden. Das Chaos wäre
vorprogrammiert. Man kann nun diesen Drucker entweder eine feste IP-Adresse per Hand
geben, oder man nimmt hierfür die manuelle Verteilung. Die Rechner können jedoch
trotzdem dynamisch ihre Daten erhalten. Man mag sich fragen, warum diese Schule
überhaupt DHCP einsetzt, da es sich mit insgesamt ca. 70 Rechnern um ein kleines statisches
Netz handelt. Der Mangel an IP-Adresse war sicher nicht der Grund dafür DHCP einzusetzen,
was man auch schnell an der Konfiguration erkennen kann, da ja das Dynamische des
DHCP´s gar nicht verwendet wird. Die Motivation lag einfach und allein in der
Zentralisierung der Netzwerkkonfigurationen. Jeder, der auch nur mal ein kleines Netz
administriert hat, weiß wie undankbar es ist, an jeden einzelnen Rechner zu müssen, nur um
eine einzige Einstellung zu ändern.
Der folgende Abschnitt zeigt nun die oben erwähnte, lauffähige und kommentierte Beispielkonfiguration.
13
DHCP-Proseminar
4.1 Konfigurationsdatei
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#************************************************
#*
DHCP - Konfigurationsskript
*
#*
*
#*
verwendet auf a027fs01.irmgardis
*
#*
erstellt von Nils Gräf
*
#*
am 17.03.2002
*
#*
letzte Änderung am 11.05.2002
*
#************************************************
# Allgemeine Konfiguration:
ddns-update-style interim;
# Servername
server-identifier a027fs01;
# Leasezeiten
default-lease-time 216000;
max-lease-time 432000;
# Subnetmaske
option subnet-mask 255.255.255.0;
# Broadcastadresse
option broadcast-address 192.168.0.255;
# Gateway
option routers 192.168.0.1;
# DNS
option domain-name "irmgardis";
option domain-name-servers 192.168.0.5;
# WinS
option netbios-name-servers a027fs01.irmgardis;
# Nis Domain
option nis-domain "irmgardis";
authoritative;
log-facility local7;
# Vergabe von festen Adressen an den jeweiligen PC:
subnet 192.168.0.0 netmask 255.255.255.0
{
}
# E03
host e03-ws01
{
hardware ethernet 00:04:75:79:8E:13;
fixed-address 192.168.0.20;
}
# E04
host e04-ws01
{
hardware ethernet 00:50:DA:3C:E7:F5;
fixed-address 192.168.0.21;
}
14
DHCP-Proseminar
Diese Beispie lkonfiguration ist in zwei Teile aufzuspalten. Die Zeilen 1-30 stellen die
allgemeinen Netzwerkinformationen dar, und die Zeilen 31-46 zeigen die Parameter zur
manue llen Vergabe der IP-Adressen. Auf den zweiten Bereich wird im Abschnitt 4.2
eingegangen. Zeilen, die mit einer Raute beginnen, gelten als Kommentar und dienen nur zur
besseren Lesbarkeit der Datei. Mit der folgenden Tabelle wird nun der erste Teil der Datei
erklärt.
Zeile
Bedeutung
1-8
10
11-12
13-15
16-17
18-19
20-21
22-24
Kopf der Konfigurationsdatei
Gibt an, wie der DHCP den DNS updaten soll
Servername
Definition der Leasezeiten
Subnetmask
Broadcastadresse
Angabe des Gateways
DNS - Hier wird der Name der Domain sowie die Adresse des Servers festgelegt.
Es ist darauf zu achten, dass es sich bei diesem Beispiel um denselben PC handelt.
WINS-Server, hier ebenfalls derselbe Rechner, dies ist aber nicht zwingend
notwendig.
Legt den NIS-Domainnamen fest (irmgardis)
Macht diesen Server zu dem DHCP-Hauptserver von diesem Netz
Legt das Log- Level des Sytemlogs (syslog) fest
25-26
27-28
29
30
Diese Werte stellen Default-Werte dar, welche, falls dies aus irgendwelchen Gründen
notwendig ist, überschrieben werden können. Ein möglicher Grund wäre zum Beispiel, das
ein PC über eine extra Leitung mit dem Internet verbunden werden soll und daher dieser
einen anderen Gateway zugewiesen bekommen muss.
4.2 Manuelle Zuordnung
Der zweite Teil dieser Beispielkonfiguration zeigt nun, wie man DHCP dazu nutzt einem
Client immer dieselbe IP-Adresse zukommen zu lassen. Die Schule verwendet nur diesen
Vergabemodus. Dieser ist praktisch, wenn man eine feste Anzahl an Rechnern hat und die
Zahl der Rechner sich auf einem relativ geringen Niveau liegt. Die Anzahl der Rechner sollte
aus mehreren Gründen nicht so hoch liegen, da man immer die Hardwareadresse bestimmen
und in die Konfiguration eingeben muss; man schaue sich dazu zum Beispiel mal die Zeilen
36 – 40 an. Hier wird einem einzelnen Rechner, nämlich dem Client „e03-ws01“ die IPAdresse 192.168.0.20 zugewiesen. DHCP erkennt den dazugehörigen Rechner an der
Hardwareadresse, die in Zeile 39 angegeben ist.
15
DHCP-Proseminar
4.3 Automatische Zuordnung
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.199;
}
Die Automatische Zuordnung ist eine Zuteilung ohne zeitliche Beschränkung. Der Rechner
erhält einmalig eine IP-Adresse und behält diese auf unbegrenzte Zeit. In diesem Beispiel ist
der zur Verfügung stehende Pool von Adressen von 192.168.0.100 bis 192.168.0.199. Eine
solche Zuteilung ist zum Beispiel sinnvoll, wenn es einen großen Pool von Rechnern gibt, die
jeweilige IP-Adresse im Prinzip egal ist und es nur darauf ankommt, dass die IP-Adressen
nicht mehrfach vergeben werden. Im Gegensatz zu der manuellen Zuordnung, die nur für
kleine Netzwerke oder Subnetze sinnvoll ist, ist diese in mittelgroßen Netzwerken sinnvoll.
Solange es nicht mehr Rechner gibt als IP-Adressen zur Verfügung stehen, ist diese Zuteilung
die bequemste, da man die Log-Dateien nachvollziehen kann.
4.4 Dynamische Zuordnung
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.199;
default-lease-time 21600;
max-lease-time 43200;
}
Diese Zuteilung ist das eigentliche Herz von DHCP. Die spärlich vorhandenen IP-Adressen
werden effizient ausgenutzt. Die IP-Adressen werden spätestens nach Ablauf der Leasezeit
neu vergeben. Es sind immer nur so viele IP-Adressen vergeben, wie Rechner in Gebrauch
sind. So ist es möglich auf einen relativ kleinen IP-Bereich viele Rechner zu verwenden. Das
beste Beispiel dafür sind wohl die Internetprovider. Nie sind alle Kunden gleichzeitig online,
so dass es viel zu teuer wäre, für jeden eine feste IP-Adresse zu besitzen. Der größte Nachteil
liegt wohl genau in diesem Detail. Man weiß nie, welche IP-Adresse gerade ein Client hat,
welches das Konfigurieren einer Firewall unter Umständen unmöglich machen kann. Bei dem
oben gezeigten Beispiel werden die IP-Adressen von 192.168.0.100 bis 192.168.0.199
vergeben. Die normale Leasezeit wird hier mit 21600 Sekunden, also 6 Stunden angegeben,
die Maximale ist mit 43200 genau doppelt so groß.
16
DHCP-Proseminar
5. Zusammenfassung
Das Dynamic Host Configuration Protocol ist die optimale Lösung für die Probleme, welche
die Motivation zur Entwicklung von diesem Protokoll darstellten. Eine effiziente Verwaltung
der zur Verfügung stehenden IP-Adressen wurde mit den drei verschiedenen Vergabemodi
realisiert. Die Fernkonfiguration der Clients im Netzwerkbereich wurde ebenfalls realisiert,
wie man im Kapitel 4.1 sehen kann. Auf der anderen Seite werden aber auch Nachteile
deutlich und aufgedeckt.. Nach einer kurzen Einführung in das Thema beschäftigt sich das
zweite Kapitel mit dem Vorgänger von DHCP, dem Bootstrap Protocol (kurz BOOTP). Im
dritten Kapitel, dem eigentlichen Proseminar, wird erst auf die Entwicklung von BOOTP zu
DHCP und deren Motivation eingegangen. Weiterhin werden mögliche Einsatzgebiete
vorgestellt. Die Problematik mit dem verzögerten Vorstoß von IPv6 aufgrund der Vorzüge
von DHCP wird am Ende der Einführung in das dritte Kapitel vorgestellt. Danach wird
anhand eines Schemas ein DHCP-UDP-Paket erklärt und veranschaulicht. Nachdem der Leser
erfahren hat wie ein einzelnes Paket aussieht, werden die einzelnen Arten der Anfragen
erläutert. Abschnitt 3.3 zeigt den Ablauf eines Dialoges zwischen einem Client und dem
Server dargestellt. Der Leasezeitmechanismus ist Bestandteil des folgenden Abschnittes.
Danach folgt die Erklärung von DHCP-Relay in 3.5 anhand eines Beispiels. Dieses Beispiel
wird in Kapitel 4 dann fortgeführt und anhand einer Konfigurationsdatei erklärt. Auf die
Vorzüge und die Arbeitsweisen der drei Vergabemodi wird abschließend genauso
eingegangen wie auf deren verschiedene Einsatzmöglichkeiten.
Damit wird die Darstellung von diesem wichtigen Internetprotokoll abgerundet. Arbeitsweise
und Prinzipien wurden dargestellt, sowie auf die Geschichte eingegangen.
17
DHCP-Proseminar
6. Quellenangabe
BOOTP:
[1]
[2]
[3]
Bill Croft, John Gilmore, RFC 951 – “Bootstrap Protocol (BOOTP)”, September
1985, http://www.freesoft.org/CIE/RFC/951/
R. Droms,RFC 1534 – “Interoperation Between DHCP and BOOTP ”,Oktober 1993,
ftp://ftp.isi.edu/in-notes/rfc1534.txt
Gerhard Lienemann, „TCP/IP-Grundlagen“, 1996, ISBN: 3-88229-070-6
DHCP:
[4]
[5]
[6]
[7]
[8]
[9]
[10]
R. Droms, RFC 2131 – „Dynamic Host Configuration Protocol“, März 1997,
ftp://ftp.isi.edu/in-notes/rfc2131.txt
S. Alexander, R. Droms, RFC 2132 – „DHCP Options and BOOTP Vendor
Extensions “, März 1997, ftp://ftp.isi.edu/in- notes/rfc2132.txt
http://www.dhcp.org
Uni Marburg, 22.04.2002, http://www.uni- marburg.de/hrz/komm/dhcp.html
Thomas Eicker, 21.04.2001, http://www.kleines-lexikon.de/w/d/dhcp.shtml
AWi Aktuelles Wissen Verlagsgesellschaft mbH,
http://www.lanline.de/lexikon/lex/dhcp.htm
SONIK GmbH, http://www.sonik.ag/knowledgebase/d/dhcp.htm
Praktisches Beispiel:
[11]
[12]
[13]
Red Hat, Inc. , Red Hat Linux 7.2 Handbuch, 2001, http://www.tuchemnitz.de/linux/Dokumentation/redhat-7.2/RH-DOCS/de/rhl-cg-de-7.2/dhcp.html
SuSE AG, SuSE Linux 8.0 Handbuch, 2002
Linux Manpages
18