DHCP

Diese Seite fasst Grundlagen zur dynamischen Konfiguration von Client zusammen. Es gibt bei Microsoft, Wikipedia und anderen Quellen sehr viele sehr gute Beschreibungen zur Funktion, so dass ich mich hier auf Dinge beschränke, die ich sonst nicht so einfach finde.

Was ist DHCP und was nicht !

DHCP steht für "Dynamic Host Configuration Protocol" und beschreibt die Möglichkeiten bestimmte Einstellungen an einen Host vorzugeben. Der Host ist dabei in den meisten Fällen ein Client, der nach der Herstellung einer Netzwerkverbindung über ein DISCOVER-Paket um entsprechende Informationen nachfragt, die von einem DHCP-Server beantwortet werden kann. Die meisten kennen die Funktion des DHCP-Servers nur in der Gestalt, dass der Client so die essentiellen Informationen für die Teilnahme in dem Netzwerk erhält. IP-Adresse, Subnetz-Maske, Default Gateway, DNS-Domäne und DNS-Server sind die allseits bekannten Parameter, die ein Client so bekommt.

Der Administrator bestimmt, wie lange die ausgegeben Werte vom Client verwenden werden dürfen. Damit kann selbst mit DHCP quasi eine statische Konfiguration erreicht werden. Es muss also nicht sein, dass ein Client mit jedem Neustart eine neue IP-Adresse bekommt. Wenn der Client sich seine alte Zuteilung merken kann, dann versucht er beim Start ein "Renew" um die frühere Konfiguration weiter verwenden zu dürfen, eher eine neue Anfrage stellt, die der DHCP-Server aber ebenso mit den gleichen Daten von früher beantworten könnte

Der Client kann im DISCOVER aber noch weitere Informationen mitliefern, z.B. ob es ein Lync Telefon ist, so dass der Server individuelle Antworten (Vendor Specific) liefern kann. So können Informationen zu SIP-Servern, Firmware Updates, Konfigurationsdateien, Syslog-Servern, Zeitservern und auch WPad per DHCP übermittelt werden. DHCP wird sogar von Clients und Servern genutzt, die eine statische IP-Adresse eingetragen haben. DHCP ist eben nicht nur eine IP-Vergabestelle.

DHCP ist weit mehr. Allerdings steigen auch die Anforderungen an die Verfügbarkeit, wenn Sie per DHCP mehr und mehr Einstellungen vornehmen. Eine Unterbrechung des DHCP-Service stellt ein Risiko dar, wenn Dienste davon abhängig sind.

DHCP Client in Aktion

Die normale Funktion eines DHCP-Clients ist auf verschiedenen Seiten schon zur genüge dokumentiert. Ich beschränke mich hier auf Informationen, die ich eher zufällig bezüglich des Windows Clients gefunden habe und nicht vergessen will:

In diesem Blog-Beitrag ist beschrieben, wie der DHCP-Client in welchen Abständen per Default die Anfragen stellt und wiederholt. Mir ist es nämlich schon mehrfach passiert, dass mein Client zuerst eine APIPA-Adresse (169.254.x.x) bekommt hat um etwas später dann noch noch eine "richtige" Adresse zu erhalten.

Sekunden seit Start

0

5

12

27

59

334

609

884

1159

und so weiter
Timeout in Sek für Antwort

5

7

15

32

275

275

275

275

275

 

Wenn ihr Netzwerkadapter also "gefühlt" einen LINK hat aber die Verbindung, warum auch immer noch nicht durchgängig ist und das erste oder gar das zweite Paket noch nicht zugestellt wird, dann sind schnell mal 12 Sekunden vergangen, bis das dritte Paket ankommt. Nervig wird es aber, wenn ihr DHCP-Server länger als 59 Sekunden "unerreichbar" ist. Dann haben in der zwischen zeit eingeschaltete Client schon die ersten fünf versuche hinter sich und arbeiten vermutlich mit einer APIPA-Adresse. Erst bis zu  4,5 Minuten nach Bereitstellung des DHCP-Service werden solche Clients eine neue IP-Adresse per DISCOVER anfragen.

Diese 275 Sekunden können Sie über eine Einstellung in der Windows Registrierung anpassen, z.B. auf 30 (Sekunden) stellen. Das ist durchaus wichtig für Firmen, die nur genau einen DHCP-Server betreiben, weil Sie immer noch davon überzeugt sind dass zwei Server auf dem gleichen LAN sich nur gegenseitig stören. Das war unter NT4 durchaus möglich, wenn die Adressbereiche nicht abgestimmt waren und ein DHCP-Server den OFFER eines anderen abgelehnt hat.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dhcp\Parameters\Options]
"AutonetRetries"=dword:0000001e

DHCP Debugging

Wenn Sie das Gefühl haben, dass ihr DHCP-Client nicht ganz richtig spurt, dann können Sie sogar ein Debugging einschalten.

REM generellen Trace aktivieren
netsh dhcp client trace enable

REM Trace nur für WLAN aktivieren
netsh trace start scenario=wlan provider=Microsoft-Windows-Dhcp-Client


REM Trace wieder abschalten
netsh trace stop.

Damit legt er DHCP-Client-Dienst eine ETL-Datei an, die Sie z.B. mit dem Microsoft Message Analyzer betrachten können

DHCP über Subnetze

DHCP arbeitet mit "MAC-Broadcasts". Technisch sind diese auf das gleiche VLAN bzw. Netzwerksegment beschränkt und können nicht über Router hinweg funktionieren. Aber die meisten Router haben eine Funktion "BootpForwarder" oder "DHCP-Relay", d.h. sie sehen den Broadcast und heben ihn zu einem konfigurierten Ziel-DHCP-Server. Sie addieren dabei natürlich die Information, aus welchem Subnetz die DHCP-Anfrage angekommen ist. Der DHCP-Server kann so auch Anfragen aus Subnetzen bedienen, in denen er kein eigenes Beinchen hat. Das ist in Firmen sogar der Regelfall, wenn mit mehreren VLANs verschiedene Netzwerksegmente gebildet werden.

DHCP Wild Server

DHCP kennt keine Authentifizierung oder Autorisierung. Jeder Client kann einen DHCP-DISCOVER senden und als Broadcast geht er auch an alle Endgeräte in dem gleichen Subnetz. Damit kann natürlich auch ein "fremder" DHCP-Server, der in diesem LAN gerade aktiv ist, IP-Adressen verteilen. Theoretisch könnte diese Station auf dem gleichen Kabel sogar ein eigenes weiteres Subnetz bereit stellen und sich zugleich als Default-Gateway mitgeben. So würden alle Pakete dieses Clients dann über diese Station laufen. Ein idealer Ausgangpunkt für eine Man in the middle-Attacke.

Damit das in einem LAN nicht so einfach ist, gibt es ein effektives Mittel, welches jeder bessere Switch bereitstellen sollte. Zumindest die Enterprise Switches können erkennen, was ein DHCP-OFFER ist und ein Administrator kann pro Port freischalten, wer so einen OFFER und andere Antwortpakete von DHCP-Servern senden darf.

DHCP und IPv6

Auch in IPv6-Netzwerken kann ein DHCPv6-Server sinnvoll sein. Bei IPv6 besteht die IP-Adresse aus einem Netzwerkanteil (8 byte) und einem Hostteil mit ebenfalls 8 Byte. Eine MAC-Adresse hat nur 6 Bytes und so könnte der Client einfach das erste Paket abwarten um daraus die Netzwerkadresse zu extrahieren und dann mit seiner MAC-Adresse als Hostteil zu arbeiten. Um aber nun nicht weltweit eindeutig zu werden, gehört es mittlerweile zum Standard, dass der Client einfach den Host-Teil zufällig erstellt und eine Konflikterkennung macht. Die Wahrscheinlichkeit, dass zwei Systeme die gleiche IPv6-Adresse nutzen (2 hoch 64 = 18.446.744.073.709.551.616 Adressen) ist doch arg gering. Die Information über Router teilen die Router selbst über entsprechende Router Advertising Pakete mit und auch die Namensauflösung per DNS kann per vordefinierter Multicast-Adresse erfolgen.

Dennoch können sie auch IPv6-Adressen und die Konfiguration per DHCP-Server verteilen. Denn die Information über Proxy Server (Siehe WPad) oder andere "Custom Options" können nicht allein über IPv6 Multicasts abgebildet werden.

Weitere Links