Einrichtung eines DHCP-Servers

Transkript

1 Einrichtung eines DHCP-Servers Inhalt: DHCP, was ist das? Streng nach Vorschrift: Das Protokoll Stets zu Diensten: Der DHCP-Server Auch ohne Klempner: Installation Ordnung ins Chaos: Konfiguration Ein Wort sagt mehr als 1000 Bilder: Dokumentation Wegweiser im Dschungel: Graphische Konfigurationstools kcmdhc webmin Auf alles gefaßt: Vorbereitung DHCP für Faule Nicht ausgebootet: BOOTP Boot-PROMs Nochmals: DHCP und DNS Durchgeschleust: DHCP-Relay DHCP, was ist das? Dieser Artikel beschreibt, wie man einen DHCP-Server unter Linux installiert und konfiguriert. Genaugenommen gibt es keinen DHCP-Server speziell für Linux, so daß der Artikel fast genauso für UNIX allgemein gilt. Streng nach Vorschrift: Das Protokoll DHCP ist ein Protokoll, mit dem die Netzwerk-Konfiguration eines Rechners (des DHCP- Clients) automatisch durch einen DHCP-Server festgelegt werden kann. Dies funktioniert für IP-Adresse, Gateway, DNS-Server, NetBEUI, WinS und so weiter, für uns ist allerdings nur der IP-Anteil von Interesse. Obwohl man das noch nicht sonderlich betonen muß, beschränken wir uns noch auf IPv4, das aktuell verwendete IP-Protokoll. Eines der bemerkenswerten Features von DHCP ist, daß es dem Client eine IP-Adresse zuweisen kann. Diese Adresse kann so konfiguriert werden, daß ein Client immer die gleiche Adresse bekommt. In großen Netzen kann das aber unpraktikabel sein; es geht auch schief, wenn es wenige Adressen, aber viele Clients gibt, von denen immer nur ein Teil am Laufen ist. Daher kann DHCP vorgegebene Bereiche von Adressen verwalten und dem Client eine freie Adresse aus einem dieser Bereiche zuweisen. Der Client hat dann bei jedem Start eine andere IP-Adresse, doch ist das meist ohne Bedeutung. Die meisten werden dieses Feature von ihrem Internet-Zugang her kennen, wo man auch bei jeder Einwahl eine andere IP- Adresse erhält. Ein weiteres Feature von DHCP ist, daß die vergebene IP-Adresse eine Gültigkeitsdauer hat. Diese kann bei wenigen Stunden liegen, in manchen Netzen auch bei einem Jahr, um möglichst immer dieselbe Adresse an einen Client zu vergeben. Beim Booten holt sich der Client immer eine Adresse vom Server. Ist der Client noch am Laufen, wenn die Gültigkeit abläuft (so etwas soll besonders bei Linux-Clients vorkommen), dann versucht der Client automatisch, sie zu verlängern. Der Benutzer merkt davon nichts.

2 Stets zu Diensten: Der DHCP-Server Vielleicht hast du schon einmal in die Datei /etc/services geschaut. Dort findet man die Zeilen bootpc 68/udp bootpc 68/tcp # bootstrap client Dies sind Einträge für den DHCP-Server, der auf Port 68 lauscht. Diese Zeilen müssen vorhanden sein, wenn man den DHCP-Server einsetzen will. Die Zeilen oberhalb dieser Einträge (Portnummer 67) sind übrigens für das BOOTP-Protokoll, dem Vorläufer von DHCP. DHCP ist ist abwärtskompatibel zu BOOTP, d.h. ein DHCP-Server kann auch BOOTP-Clients versorgen. Es versteht sich fast von selbst, daß ein DHCP-Server eine feste IP- Adresse besitzen sollte, also selbst kein DHCP-Client sein kann. Auch darf es nur einen DHCP-Server pro Subnetz geben, oder ein DHCP-Relay (wird am Schluß besprochen), aber nicht beides. Auch ohne Klempner: Installation Im folgenden beschreibe ich die Installation des DHCP-Servers vom ISC (Internet Software Consortium). Sollte der Server nicht in deiner Distribution enthalten sein oder eine neuere Version erschienen sein, kann der Quellcode vom ISC-Server heruntergeladen werden. Den Quellcode zu übersetzen und installieren ist eine Kleinigkeit. Der bekannte Dreisatz sollte genügen:./configure make make install Ordnung ins Chaos: Konfiguration Die Konfiguration des Servers erfolgt mit der Konfigurationsdatei /etc/dhcpd.conf. Will man eine alternative Konfiguration testen, so kann man das mit dem Aufruf dhcpd -cf Konfigurationsdatei tun. Die Syntax der Konfigurationsdatei ist ähnlich der des DNS-Servers BIND. Das verwundert nicht, da beide Server aus demselben Hause stammen. Ein Wort sagt mehr als 1000 Bilder: Dokumentation Neben den Manual Pages dhcpd(1) und dhcpd.conf(5) gibt es auch ein DHCP-Mini-HOWTO des Linux Documentation Project. Im Grunde genügt das schon. Es gibt natürlich auch Bücher zu dem Thema, ich habe jedoch keines davon verwendet. Wegweiser im Dschungel: Graphische Konfigurationstools

3 Es gibt einige graphische oder auch textbasierte (dhcp-conf) Konfigurationsprogramme für den DHCP- Server. Diese entlasten einen zwar generell von der genauen Kenntnis der Syntax der Konfigurationsdatei, bieten aber darüber hinaus keine Vorteile. Denn es liegt in der Natur des Servers, daß hauptsächlich Daten, für die es keine vorgegebene Auswahl gibt, eingegeben werden müssen. Mit etwas gutem Willen könnten aber alle diese Programme verbessert werden. Zum Beispiel könnte für diverse IP-Adressen eine sinnvolle Vorgabe eingetragen werden. Außerdem hat keines der mir bekannten Programme eine Online-Hilfe. Mindestens 4 Programme beherrschen die kcmdhcp: Hinzufügen eines Eintrags DHCP-Konfiguration: dhcp-conf, webmin, kcmdhcp und linuxconf. Auf dhcp-conf werde ich hier nicht weiter eingehen, da es nicht mehr kann als kcmdhcp und webmin auch. Es ist allerdings ein Konsolen-Programm, was bei Servern, die kein X11 installiert haben, hilfreich sein kann. Von linuxconf hatte ich nur eine ältere Version greifbar, die noch kein DHCP konnte. kcmdhc kcmdhcp ist eine Control-Panel-Anwendung für KDE. Es ist mir nicht bekannt, ob das Programm noch gewartet wird, denn die Homepage existiert nicht mehr. Das Aussehen des Programms ist phantasielos vom DHCP-Manager von Windows abgekupfert und dementsprechend unübersichtlich. Das Programm kann keine DHCP- Konfiguration einlesen, die nicht mit kcmdhcp erstellt wurde. In der Bedienung gibt es noch erhebliche Mängel. So findet keine Plausibilitätsprüfung statt, und eine existierende Konfigurationsdatei wird ohne Rückfrage überschrieben. Dieses Programm ist unbrauchbar. webmin Das Programm webmin gestattet die graphische Konfiguration des DHCP- Servers aus dem Browser heraus. webmin: Hinzufügen eines Rechners Auch Webmin kann nur Konfigurationen lesen, die es selbst erstellt hat. Die Bedienung des Programms ist jedoch einwandfrei, von den oben schon beschriebenen Mängeln abgesehen. Doch am meisten lernt man durch direktes Editieren der Konfigurationsdatei, die wir uns jetzt genauer ansehen.

4 Auf alles gefaßt: Vorbereitung Bevor wir uns ganz auf die Konfigurationsdatei konzentrieren, müssen wir noch etwas erledigen. Dazu kurz etwas zur Funktionsweise von DHCP. Beim Booten sendet der Client einen IP-Broadcast (d.h. eine Nachricht mit der IP-Adresse als Empfänger). Der Server antwortet ebenfalls mit einem Broadcast, denn der Client hat ja zu diesem Zeitpunkt noch keine IP-Adresse, auf der er empfangen könnte. Das hat auf dem Server zwei Konsequenzen:?? Es muß eine Route für die Broadcast-Adresse auf dem Netzwerk-Interface definiert sein, das das DHCP-Protokoll abwickelt. Bei Servern mit mehreren Netzwerkkarten, wie meinem eigenen, kann das auch bedeuten, daß mehrere Broadcast-Routen existieren müssen. Daher definieren wir eine Broadcast-Route: route add eth0 Dies wiederholen wir bei Bedarf für eth1 usw. Nach dem nächsten Booten wäre diese Route aber wieder weg, daher tragen wir den Befehl in die Boot-Skripte ein. Bei SuSE ist die Datei /etc/route.conf der geeignete Platz dafür.?? Wir sollten die Broadcast-Adresse dem Resolver bekannt machen, sonst könnte sich dieser bemüßigt fühlen, bei jedem ankommenden DHCP-Paket den Nameserver zu befragen. Und wenn dieser bei einem Internet-Provider läuft, kann das zu einem automatischen Verbindungsaufbau führen, womit wieder eine Gebühreneinheit zum Kamin hinaus ist. Also editieren wir /etc/hosts und fügen folgende Zeile hinzu: broadcast Ferner müssen wir noch eine leere Datei /etc/dhcpd.leases anlegen, sonst protestiert der DHCP-Daemon, jedenfalls in der bei mir installierten Version: touch /etc/dhcpd.leases DHCP für Faule Nun können wir endlich an die eigentliche Konfiguration gehen. Schauen wir uns einmal folgende minimale Konfigurationsdatei an: # Simple Beispiel-Konfiguration subnet netmask { range ; default-lease-time 86400; max-lease-time ; } Offensichtlich sind Kommentare, die mit # beginnen, ebenso erlaubt wie Leerzeilen. Wir haben hier ein Subnetz mit 256 Adressen (ein Klasse-C-Netz) und setzen voraus, daß der Server nur eine Netzwerkkarte besitzt, denn sonst würde diese Konfiguration nicht genügen.

5 Die Netzwerkadresse des Servers muß natürlich zu den konfigurierten Adressen passen, also z.b. zwischen und liegen. Die Konfigurationsdatei bestimmt, daß der Bereich der Adressen bis dynamisch vergeben wird. Ferner wird jeder Client, der nichts anderes anfordert, eine Adresse mit einer Gültigkeitsdauer von einem Tag (die Zeiten sind in Sekunden angegeben) erhalten. Ein Client kann eine maximale Gültigkeitsdauer von 30 Tagen (max-lease-time ) anfordern. Diese simple Konfiguration genügt bereits! Starten wir den Server, so sehen wir eine Ausgabe ähnlich dieser: Internet Software Consortium DHCPD $Name: V2-BETA-1 $ Copyright 1995, 1996 The Internet Software Consortium. All rights reserved. Listening on Socket/eth0/ Sending on Socket/eth0/ Läßt man einen Client nun DHCP machen, dann findet man im System-Log einen Eintrag ähnlich folgendem: dhcpd: DHCPREQUEST for from 00:f0:98:20:ab:c8 via eth0 dhcpd: DHCPACK on to 00:f0:98:20:ab:c8 via eth0 Wie man sieht, wird die Hardware-Adresse der Anfrage vermerkt. Das ist nützlich, wenn man einen BOOTP-Client hat. BOOTP, wir erwähnten es bereits, ist der Vorläufer von DHCP. Es kennt keine dynamische Adreßvergabe, deshalb ist es notwendig, für jeden BOOTP-Client eine explizite Adresse zu vergeben. Dabei wird der Client durch seine Hardware-Adresse identifiziert, und diese kann man, wenn man sie nicht anderweitig schon kennt, dem System- Log entnehmen. Nicht ausgebootet: BOOTP Einen BOOTP-Client kann man der Konfigurationsdatei mit folgenden Zeilen hinzufügen: group { host laptop { hardware ethernet 00:CE:48:04:4A:C7; fixed-address ; option host-name "laptop"; option domain-name "hjb.home"; option domain-name-servers ; option domain-name-servers ; option routers ; } } Das Schlüsselwort "group" mit den Klammern ist nicht unbedingt notwendig. Es hilft jedoch, Tipparbeit zu vermeiden, da man Definitionen, die mehrere Hosts gemeinsam haben, in der Gruppe definieren kann. Diese gelten dann für alle Hosts in der Gruppe. Fügt man die gleiche Definition bei einem einzelnen Host ein, hat diese Vorrang gegenüber der Gruppendefinition. Dies und alle anderen Details kann man in der Manpage dhcpd(5) nachlesen. Boot-PROMs Ist ein BOOTP-Client mit einem Boot-PROM auf der Netzwerkkarte ausgestattet (bei UNIX- Workstations Standard), dann kann er auch vom Netz booten. In diesem Fall muß der DHCP-

6 Daemon wissen, wie der Bootkernel heißt. Diesen Kernel holt sich der Client dann mit TFTP (Trivial File Transfer Protocol). Dieses muß in diesem Fall auf dem Server auch aktiviert sein, üblicherweise durch Ändern einer Zeile in /etc/inetd.conf: tftp dgram udp wait root /usr/sbin/tcpd in.tftpd Vorsicht, tftp kann ein enormes Sicherheitsrisiko sein, doch der TCP-Daemon tcpd hilft, es ein wenig sicherer zu machen. In unserer DHCP-Konfiguration müßten wir dann noch die folgende Zeile hinzufügen, entweder für den Host oder die ganze Gruppe: filename "vmlinuz.px"; # in /tftpboot Mit diesen Andeutungen soll es genug sein mit dem BOOTP-Protokoll. Nochmals: DHCP und DNS Will man DHCP mit dynamischer Adreßvergabe mit einem DNS-Server kombinieren, hat man es nicht ganz leicht. Denn obwohl beide von derselben Organisation geschrieben, wissen sie nichts voneinander. Das wird sich erst mit Version 3.0 des DHCP-Daemons ändern, die derzeit im Beta-Test ist. Sicher kann man alle IP-Adressen in den zu vergebenden Bereichen statisch ins DNS eintragen. Doch das hat offenbar Nachteile, so daß man sich Mechanismen überlegt hat, bei jeder Adreßvergabe durch den DHCP-Daemon den DNS-Server zu aktualisieren. Mindestens zwei frei erhältliche Perl-Skripte sind zu diesem Zweck geschrieben worden. Sie sind einfach und effektiv. und Beide überwachen die Datei /etc/dhcpd.leases. Jedesmal, wenn der DHCP-Daemon eine Adresse vergibt, hält er es in dieser Datei fest. Die Skripte werten die Änderung aus und nutzen das dynamische Update-Feature von BIND 8, um die DNS-Konfiguration anzupassen. Durchgeschleust: DHCP-Relay DHCP-Anfragen funktionieren normalerweise nur in Subnetzen, an die der DHCP-Server direkt angeschlossen ist. Denn kein Router, der etwas auf sich hält, läßt IP-Broadcasts durch. Will man jedoch nicht in jedem Subnetz einen DHCP-Server installieren, z.b. um die Verwaltung zu zentralisieren, schafft ein DHCP-Relay Abhilfe. Das ist ein kleiner Daemon, in der ISC-Version dhcrelay genannt. Er ist im DHCP-Daemon-Paket enthalten. Er nimmt DHCP-Anfragen an und leitet sie an einen konfigurierbaren DHCP-Server weiter, allerdings nicht als Broadcast, und kann daher den Router überwinden. Die Antwort vom DHCP-Server leitet er an den Client weiter, als sei er selbst der Server.