Entspannt ans Netz

Ob im Mittelstandsbetrieb, auf der LAN-Party, in der ambitionierten Wohngemeinschaft oder beim Multimedia-Netz zuhause: Wenn jeder Rechner einzeln für den Gebrauch im Netzwerk konfiguriert wird, macht das viel Arbeit. Sicher kann ein zentraler Systemadministrator auf diese Art und Weise IP-Adresse, Netzwerkmaske, Default-Gateway sowie den Nameserver festlegen, doch sobald mehrere Leute mit unterschiedlichem Kenntnisstand ihre Rechner selbst einrichten sollen, wird es spannend.

Aber auch erfahrene Netzwerkadministratoren stoßen bei der "händischen" Methode mit wachsender Rechneranzahl auf eine Handvoll Probleme. So darf jede IP-Adresse nur einmalig vergeben werden, sonst kommt es zu Kollisionen im Netz. Und selbst wenn eine unverlierbar aufbewahrte und konsequent geführte Liste aller bisher vergebenen IP-Adressen existiert: Möchte man im Netz Umstrukturierungen vornehmen (einen eigenen Nameserver aufsetzen, eine andere Netzwerkmaske verwenden oder gar dem Router nach draußen eine andere IP-Adresse geben) muss jeder vorhandene Rechner von Hand umkonfiguriert werden.

Kommen Gäste mit Notebooks vorbei, sollten diese im Kopf haben, wo und wie die notwendigen Einstellungen vorzunehmen sind. Denn Hand aufs Herz: Wissen Sie, wie unter MacOS 7.6 das Netz konfiguriert wird? Und mögen Sie zugeben, dass Sie es für Windows 98 wissen?

Aus der Misere hilft das Dynamic Host Configuration Protocol (DHCP). Um es nutzen zu können, baut man einen Rechner zum DHCP-Server aus. Fürderhin verwaltet dieser die Netzwerkkonfiguration aller anderen Rechner im Netz. Ergänzend zu den klassischen Parametern können ihm zusätzliche, für dieses Netzwerk spezifische Werte wie ein Timeserver oder der Name eines WINS-Servers mitgegeben werden.

Viele Rechner …

Wie sieht das in der Praxis aus? Denken wir uns ein kleines privates Netzwerk. "Privat" bedeutet in diesem Zusammenhang, dass die dabei verwendeten IP-Adressen aus einem Adresspool stammen, aus dem sich jeder bedienen kann. Damit es keine Konfusionen gibt, dürfen diese Adressen nur in lokalen Netzen (LANs), nicht aber beim Datenverkehr mit dem Internet verwendet werden.

Für ein richtig großes Netzwerk (ein sogenanntes Class-A-Netz) ist der Bereich zwischen 10.0.0.0 und 10.255.255.255 für den allgemeinen Gebrauch im LAN reserviert, ein mittelgroßes "Class-B-Netz" deckt der Bereich 172.16.0.0 bis 172.31.255.255 ab, und wer nur kleine Brötchen backen muss, begnügt sich mit den 65023 möglichen Adressen im Bereich von 192.168.0.0 bis 192.168.255.255.

Für kleine Firmen und WGs reicht ein solches "Class-C-Netz", und da es auf dieser Welt schon genug 192.168.0.0-Netzwerke gibt, bringen wir die eigene Hausnummer 2 ins Spiel und nennen unser Netz 192.168.2.0 (sehr praktisch wenn man sich mal mit den Bewohnern des Nachbarhauses vernetzen möchte).

… und nur ein Server

Der Rechner, der diese IPs vergeben soll, braucht zunächst das DHCP-Serverprogramm. Allzu viele freie Implementierungen gibt es nicht, deswegen greifen wir – wie andere auch – zu dhcpd, dem ISC-DHCP-Server.

Wer den Ehrgeiz hat, das Programm selbst zu übersetzen, lädt die Programmquellen von [1] herunter. Alle anderen installieren das zur Distribution passende Paket, bei Debian mittels

apt-get install dhcp

Nutzer anderer Distributionen finden das passende RPM-Paket in aller Regel auf den Distributions-CDs oder DVDs. Notfalls hilft http://rpmfind.net/ weiter, wenn man nach DHCP sucht.

Nach der Installation findet sich im Verzeichnis /etc/ die Konfigurationsdatei dhcpd.conf. Sie ist gut kommentiert, sodass man die der Phantasie des Programmautors entsprungenen Werte lediglich den eigenen Gegebenheiten anpassen muss. Zuvor sollte man sich jedoch Gedanken machen, wie viele Rechner man in seinem Netz gleichzeitig zu betreiben gedenkt. Auf einer LAN-Party wird dies eine eher große Anzahl sein, eine Wohngemeinschaft dürfte kaum über zehn Rechner hinauskommen.

In unserem Beispiel in Listing 1 gehen wir davon aus, dass sich immer nur maximal 20 Rechner gleichzeitig im Netz befinden. An die darf der dhcpd die IP-Adressen aus dem Bereich (englisch: range) 192.168.2.50 bis 192.168.2.69 vergeben. Darüber hinaus gilt es, mit option domain-name-servers den Nameserver und mit option routers das Gateway ins Internet festzulegen. Wer keinen eigenen Nameserver im LAN betreibt [2], verwendet den vom Internetprovider empfohlenen. Bei einem Zugang per T-Online ist dies 194.25.2.129, bei Arcor unter anderem 145.253.2.11.

default-lease-time 3600;
max-lease-time 14400;
subnet 192.168.2.0 netmask 255.255.255.0 {
        range 192.168.2.50 192.168.2.69;
        option domain-name-servers 194.25.2.129;
        option broadcast-address 192.168.2.255;
        option routers 192.168.2.1;
}

Auffällig sind die geschweiften Klammern, die die Definition für ein Netzwerksegment einfassen. Jede Konfigurationsangabe wird von einem Semikolon abgeschlossen.

Die Freiheit der Konfiguration

Allgemein gesprochen finden sich in der Konfigurationsdatei zwei Arten von Einträgen: solche, die mit dem Wort option beginnen und die anderen. Die "Optionen" (zusammengefasst in Tabelle 2) gibt der dhcpd unverändert an die anfragenden Rechner (Clients genannt) weiter. Ob ein Client mit dem Wert etwas anfangen kann, hängt jedoch von seinem Betriebssystem ab. Unter Umständen lässt ihn der Administrator mit einem extra geschriebenen Skript weiterverarbeiten.

Die anderen Angaben sind für den Serverprozess dhcpd selbst bestimmt – Tabelle 1 fasst sie zusammen.

255=1*2^7+1*2^6+1*2^5+1*2^4+1*2^3+1*2^2+1*2^1+1*2^0

11111111.11111111.11111111.00000000

11000000.10101000.00000010.00000011

11000000.10101000.00000010.00000000

Feste Bindung

Entschließt man sich dazu, im gesamten Netzwerk auf DHCP zu setzen, gibt es einige Rechner die ständig dieselbe IP-Adresse haben sollten. Schließlich möchte niemand erst die aktuelle Adresse eines Gateway- oder Multimediaservers ermitteln müssen, bevor er ihn nutzen kann.

Auch um eine solche, clientabhängige Adressvergabe kümmert sich die /etc/dhcpd.conf. Damit der dhcpd die um eine IP-Adresse bittenden Rechner richtig identifizieren kann, zieht er die eindeutige MAC-Adresse der Netzwerkkarte heran.

Auf PCMCIA-Netzwerkkarten oder Wireless-LAN-USB-Sticks ist sie stets aufgedruckt. Kommt man nicht so leicht an den Aufkleber der Netzwerkkarte, hilft Software dabei, die MAC-Adresse zu ermitteln. Unter unixoiden Betriebssystemen dient dazu der Befehl ifconfig, die Betriebssysteme aus dem Hause Microsoft bringen das Kommandozeilenprogramm ipconfig für diesen Zweck mit. Listing 2 zeigt das Beispiel eines Linux-Rechners, dessen MAC- oder "Hardware"-Adresse 00:02:2D:34:90:85 lautet.

renner@lyra:~$ /sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:02:2D:34:90:85
          inet addr:10.32.130.79  Bcast:10.32.135.255  Mask:255.255.248.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15695 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10988 errors:204 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5201433 (4.9 MiB)  TX bytes:1559490 (1.4 MiB)
          Interrupt:10 Base address:0x100

Aber auch, wer keinen direkten Zugriff auf den fraglichen Rechner hat, muss nicht verzagen – sofern der DHCP-Server ihm bereits auf Zufallsbasis eine Adresse zuordnet. In der Datei /var/lib/dhcp/dhcpd.leases protokolliert dhcpd nämlich, wer für welchen Zeitraum welche IP-Adresse bekommt.

Alternativ kann man einen ping auf das gesamte Netzwerk absetzen, um so eine Reaktion aller erreichbaren Rechner zu provozieren. Anschließend schaut man mit Befehl arp -a nach, welche Rechner und MAC-Adressen bekannt sind (Listing 3). Der einleitende ping ist notwendig, da die arp-Tabelle, die unter anderem die MAC-Adressen aller bekannten Computer im lokalen Netzwerk enthält, nur Rechner kennt, zu denen bereits ein wie auch immer gearteter Netzwerkkontakt bestand.

renner@lyra:~$ ping -c3 192.168.2.0
PING 192.168.2.0 (192.168.2.0): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.2 ms
64 bytes from 192.168.2.52: icmp_seq=0 ttl=64 time=3.5 ms (DUP!)
64 bytes from 192.168.2.53: icmp_seq=0 ttl=64 time=4.2 ms (DUP!)
64 bytes from 192.168.2.62: icmp_seq=0 ttl=64 time=4.7 ms (DUP!)
[…]
renner@lyra:~$ /usr/sbin/arp -a
? (192.168.2.1) at 00:03:E3:00:18:F1 [ether] on eth0
? (192.168.2.52) at 00:30:05:55:02:ED [ether] on eth0
? (192.168.2.53) at 00:0C:6E:1F:32:C4 [ether] on eth0
? (192.168.2.62) at 00:30:05:55:03:7F [ether] on eth0

Welche der vielen MAC-Adressen nun die richtige ist, muss man jedoch raten oder im Ausschlussverfahren ermitteln. In ganz verzwickten Fällen sucht man in einer speziellen Datenbank [3] den zu einer MAC-Adresse gehörenden Netzwerkkartenhersteller (Abbildung 1), um mit diesem Wissen bei der Zuordnung weiterzukommen.

Abbildung 1: MAC-Adresse und Kartenhersteller lassen sich über MAC-Find zuordnen.

Hat man die Hardware-Adresse herausgefunden, lässt sich dhcpds Konfiguration um eine feste IP-Zuordnung zum jeweiligen Rechner ergänzen:

host lyraA  {
  hardware ethernet 00:02:2D:34:90:85;
  fixed-address lyra.mtr.mynet;
}

Verfügt ein Rechner über mehrere Netzwerkkarten (z. B. eine zusätzliche Wireless-LAN-Karte), darf man die MAC-Adressen beider Karten demselben Hostnamen zuordnen, sofern sie nie gleichzeitig zum Einsatz kommen:

host lyraB  {
  hardware ethernet 00:80:C7:C1:3D:76;
  fixed-address lyra.mtr.mynet;
}

Unter Umständen lässt sich das Netzwerkmedium im laufenden Betrieb wechseln, ohne dass bestehende Verbindungen abbrechen! Statt eines Hostnamens, der eine funktionierende Adressauflösung voraussetzt, kann man auch die IP-Adresse angeben.

DHCP für Anspruchsvolle

DHCP kann aber noch mehr! Per DHCP bringt man Diskless Clients, die ihr Betriebssystem aus dem Netzwerk beziehen, den Namen des Bootimages näher. Dieses wird dann mit dem Trivial File Transfer Protocol TFTP, einer abgespeckten FTP-Variante, übers Netz übertragen. Listing 4 zeigt als Beispiel, wie einer SGI-Indy-Workstation der auf ihr zu bootende Linux-Kernel per DHCP bekannt gemacht wird. Solcherart Boot-Prozedere kommt nicht nur in großen Rechner-Clustern, wie sie zur Lösung mathematischer Fragestellungen genutzt werden, zum Einsatz, sondern zum Beispiel auch in den Rechnerpools von Universitäten oder Fortbildungsinstituten.

host indy {
   filename "indy_r4k_tftpboot.img";
   hardware ethernet 08:00:69:08:58:40;
   fixed-address 192.168.2.12;
   server-name "cassiopeia.mtr.mynet";
   option host-name "indy";
   option domain-name "mtr.mynet";
   option domain-name-servers 192.168.2.53;
   option routers 192.168.2.1;
}

Das funktioniert nur, wenn der tftpd-Server in der Datei /etc/inetd.conf eingeschaltet wird. Damit der das angegebene Bootimage (im Beispiel indy_r4k_tftpboot.img) findet, bekommt er beim Aufruf das Verzeichnis mit diesen Dateien (etwa /boot) mit auf den Weg:

tftp  dgram  udp  wait  nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot

Bei Distributionen, die statt des Superservers inetd den moderneren xinetd einsetzen, muss die Datei /etc/xinetd.d/tftp wie in Listing 5 angepasst werden.

# default: off
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /boot
}

Ein einziger DHCP-Server kann sogar unterschiedliche Netzwerksegmente gleichzeitig bedienen. Hierzu legt man mehrere subnet-Sektionen in der Konfiguration an. Die innerhalb der geschweiften Klammern vergebenen Optionen wie Angaben zum Nameserver oder zur NIS-Domäne dürfen sich dabei unterscheiden. In der Praxis wird jedes Netzsegment an eine eigene, im DHCP-Server eingebaute Netzwerkkarte gebunden sein.

Damit der dhcpd Änderungen seiner Konfiguration berücksichtigt, muss er jeweils neu starten. Aber da solche Ergänzungen nur selten notwenig sind, kann man die meiste Zeit ganz entspannt das Gefühl genießen, sich auch bei neu angeschlossenen Rechnern im Netz um nichts kümmern zu müssen.

Die Clientseite

Auch für die Neuankömmlinge selbst gibt es nicht viel zu tun. Statt eine statische IP-Adresse einzutragen, müssen sie nur DHCP einschalten. Je nach Betriebssystem (und gegebenenfalls der Distribution) geschieht das an unterschiedlichen Stellen. Bei Debian erledigt es die Zeile

iface eth0 inet dhcp

in der Datei /etc/network/interfaces, bei anderen Distributionen hilft meist ein grafisches Konfigurationsprogramm weiter, bei Mandrake der in Abbildung 2 gezeigte Wizard.

Abbildung 2: Hier aktivieren Sie den DHCP-Client bei Mandrake.

Unter Windows wird man unter SystemsteuerungNetzwerkverbindungen fündig, beim klassischen MacOS im Apple-Menu unter Control Panel - TCP/IP. MacOS X (Abbildung 3) schaltet DHCP unter System PreferencesInternet & Network zu.

Abbildung 3: Auch MacOS X bietet DHCP-Unterstützung.

Das Angebot der – in aller Regel vorinstallierten – DHCP-Clientprogramme für Linux ist überschaubar. Zum einen gibt es das seiner geringen Größe wegen besonders bei Minidistributionen beliebte pump. Die größeren Alternativen dhcp-client und dhcpcd bieten zusätzliche Funktionen, beispielsweise die Möglichkeit, nach erfolgter IP-Konfiguration eigene Skripte zu starten.

Vorsicht ist bei älteren dhcp-Paketen und dem Kernel 2.6 geboten. Nicht dass diese Kombination nicht funktionierte, doch prüft beim dhcp-client das Skript /sbin/dhclient, um welche Kernelversion es sich handelt. Weil es mit der Kernelversion 2.6 nichts anzufangen weiß, bricht die Verarbeitung ab. Da zumindest aus Sicht des DHCP-Prozesses nur ein Unterschied zwischen 2.0 und späteren Kernelversionen besteht, ändert man das Skript so ab, dass auch 2.6 als gültige Kernelversion erkannt wird:

2.[123456].*)
        exec /sbin/dhclient-2.2.x -q "$@"
        ;;

Einfach eine 6 mehr an der richtigen Stelle, und schon ist man der Probleme ledig.