DHCP-Relay

Was ist ein DHCP-Relay?

Ein DHCP-Relay, auch DHCP-Relay-Agent genannt, ist ein Netzwerkdienst, der DHCP-Nachrichten zwischen Clients und Servern über Subnetzgrenzen hinweg weiterleitet. DHCP (Dynamic Host Configuration Protocol) arbeitet ursprünglich mit Broadcasts, die von Routern nicht weitergeleitet werden. Ein DHCP-Relay fängt die Broadcast-Anfragen der Clients ab, verpackt sie in Unicast-Pakete und sendet sie an einen zentralen DHCP-Server in einem anderen Subnetz. So können wenige DHCP-Server viele Subnetze bedienen, ohne dass in jedem Segment ein eigener Server stehen muss.

Problemstellung: DHCP und Routing

In einem lokalen Netzwerksegment sendet ein Client ohne IP-Adresse einen DHCP-Discover als Broadcast an die Adresse 255.255.255.255. Dieser Broadcast erreicht nur Geräte im gleichen Subnetz. Router lassen Broadcasts grundsätzlich nicht durch, um das Netz nicht mit Verkehr zu überfluten. Steht der DHCP-Server in einem anderen Subnetz, erreicht die Anfrage ihn nicht. Der Client kann keine IP-Adresse beziehen, und der Netzwerkzugang scheitert. Ein DHCP-Relay löst dieses Problem, indem es die Broadcasts auf dem Subnetz abhört und stellvertretend die Kommunikation mit dem entfernten Server führt.

Funktionsweise des DHCP-Relay-Agenten

Der DHCP-Relay-Agent ist typischerweise eine Funktion des Routers oder Layer-3-Switches, der das Subnetz des Clients anbindet. Er lauscht auf dem lokalen Interface auf UDP-Port 67, den die Clients für DHCP-Broadcasts verwenden. Sobald er einen DHCP-Discover oder DHCP-Request empfängt, modifiziert er das Paket und leitet es als Unicast an einen oder mehrere konfigurierte DHCP-Server weiter.

Dazu füllt der Relay-Agent das Feld giaddr (Gateway IP Address) im DHCP-Paket mit der IP-Adresse des eigenen Interfaces, an dem er die Anfrage empfangen hat. Der DHCP-Server identifiziert anhand des giaddr, aus welchem Subnetz die Anfrage stammt, und wählt einen passenden Adresspool. Die Antwort des Servers sendet er als Unicast an die giaddr-Adresse zurück. Der Relay-Agent empfängt die Antwort und leitet sie im lokalen Subnetz als Broadcast oder Unicast an den Client weiter.

Ablauf eines DHCP-Dialogs mit Relay

Der typische DHCP-Vier-Wege-Handshake läuft mit einem Relay-Agenten wie folgt ab:

1. DHCP-Discover: Der Client sendet einen Broadcast auf dem lokalen Subnetz. Der Relay-Agent empfängt das Paket, setzt das giaddr-Feld und leitet es als Unicast an den DHCP-Server weiter.
2. DHCP-Offer: Der Server wählt einen Adresspool basierend auf dem giaddr aus und sendet ein Angebot als Unicast an den Relay-Agenten zurück. Der Relay-Agent stellt das Paket dem Client per Broadcast oder direkt per Unicast zu, abhängig von dessen Flag-Feld.
3. DHCP-Request: Der Client sendet seine verbindliche Anforderung erneut per Broadcast. Der Relay-Agent leitet sie wiederum als Unicast zum Server.
4. DHCP-ACK: Der Server bestätigt die Vergabe und sendet den ACK an den Relay-Agenten. Dieser übermittelt ihn an den Client. Der Client konfiguriert seine Schnittstelle mit der angebotenen IP-Adresse.

Der gesamte Vorgang ist für den Client transparent. Er kommuniziert wie mit einem lokalen Server, der Relay-Agent vermittelt nur.

Technische Details im Paketaufbau

Das DHCP-Protokoll basiert auf BOOTP und verwendet UDP-Port 67 für Server und Port 68 für Clients. Der Relay-Agent modifiziert die DHCP-Nachricht auf dem Weg zum Server, nicht auf dem Rückweg. Neben dem giaddr-Feld kann der Relay-Agent die sogenannte Option 82 (DHCP Relay Agent Information Option) in das Paket einfügen. Option 82 enthält Zusatzinformationen wie die Circuit-ID und die Remote-ID, die den genauen physischen Anschluss des Clients identifizieren. Der DHCP-Server kann diese Informationen für die Adressvergabe, für Accounting oder für die Umsetzung von Sicherheitsrichtlinien auswerten.

Konfiguration auf Cisco-Routern

Auf einem Cisco-Router oder Layer-3-Switch wird der DHCP-Relay-Dienst mit dem Befehl ip helper-address aktiviert. Dieser Befehl wird auf dem Interface konfiguriert, das mit dem Client-Subnetz verbunden ist. Eine typische Konfiguration für ein VLAN-Interface weist zunächst eine IP-Adresse zu und setzt dann die Helfer-Adresse auf die IP des zentralen DHCP-Servers, etwa 10.0.0.10.

Diese Konfiguration leitet DHCP-Anfragen aus dem entsprechenden VLAN an den DHCP-Server weiter. Der Befehl ip helper-address aktiviert das Relay nicht nur für DHCP (UDP 67), sondern standardmäßig auch für weitere Protokolle wie TFTP, DNS und NetBIOS. Soll nur DHCP weitergeleitet werden, müssen die unerwünschten Dienste mit no ip forward-protocol udp global oder pro Port gefiltert werden.

Konfiguration auf anderen Plattformen

Das DHCP-Relay-Prinzip ist herstellerunabhängig, die Kommandos variieren.

• Juniper JunOS: Unter der Hierarchie forwarding-options wird eine Server-Gruppe definiert und mit Interfaces verknüpft. Der Server-Gruppe wird die IP-Adresse des DHCP-Servers zugewiesen, anschließend wird die Gruppe aktiviert und einem Interface wie vlan.100 zugeordnet.
• Linux (dhcrelay): Der ISC DHCP Relay Agent wird mit dhcrelay gestartet. Der Aufruf benennt das Interface zum Client-Netz und die Adresse des DHCP-Servers, etwa dhcrelay -i eth0 10.0.0.10.
• HPE/ArubaOS-Switch: Der Befehl lautet ip helper-address ähnlich wie bei Cisco, oder die Konfiguration erfolgt über dhcp-relay mit Server-IP und Interface.

DHCP-Relay versus DHCP-Proxy

Ein DHCP-Relay ist von einem DHCP-Proxy zu unterscheiden. Der Relay-Agent leitet die DHCP-Nachrichten nahezu transparent weiter. Er verändert nur das giaddr und fügt gegebenenfalls Option 82 ein. Der DHCP-Server kommuniziert direkt mit dem Client, der Relay-Agent handelt nicht eigenständig aus.

Ein DHCP-Proxy hingegen agiert als vollständiger DHCP-Server gegenüber dem Client und als DHCP-Client gegenüber dem tatsächlichen Server. Er verwaltet eigene Lease-Tabellen und kann Adressen lokal zwischenspeichern. DHCP-Relays sind einfacher, ressourcenschonender und weiter verbreitet.

Option 82 und ihre Bedeutung

Option 82 ist ein mächtiges Werkzeug für den Relay-Agenten. Es erlaubt, den physischen Port, das VLAN und die MAC-Adresse des Clients zu übermitteln. Der DHCP-Server kann dies für die Zuweisung fester IP-Adressen pro Port, für die Platzierung in bestimmten Subnetzen oder für Sicherheitsüberprüfungen nutzen. In modernen Netzen ist Option 82 die Basis für die dynamische IP-Vergabe bei Ethernet-Zugangsnetzen (FTTx, DSL) und für das IPoE-Verfahren. Die meisten DHCP-Server, etwa der ISC DHCP-Server oder Microsoft DHCP, verarbeiten Option 82 und können Regeln darauf anwenden.

Praktische Anwendungsszenarien

DHCP-Relays kommen in nahezu jedem Unternehmen mit mehreren VLANs und einem zentralen DHCP-Server zum Einsatz. Statt in jedem VLAN einen eigenen Server oder einen DHCP-Dienst auf dem Layer-3-Switch zu betreiben, genügt eine zentrale Instanz. Das reduziert Verwaltungsaufwand und stellt einheitliche Lease-Richtlinien sicher. In Providernetzen leiten Breitband-Router die DHCP-Anfragen von Endkunden über Option 82 an zentrale Server weiter. Auch in WLAN-Umgebungen mit zentralisiertem Controller vermitteln die Access Points oder der Controller DHCP-Anfragen per Relay an das Kernnetz.

Grenzen und Fehlerquellen

Ein DHCP-Relay kann keine Broadcasts weiterleiten, die nicht vom Relay-Agenten selbst empfangen werden. Der Router muss in jedem Subnetz präsent sein, das DHCP benötigt. Bei falscher Konfiguration der ip helper-address kann es zu Weiterleitungsschleifen kommen, wenn der Router die Antwort des Servers erneut als Broadcast interpretiert und weiterleitet. Viele Systeme verhindern dies durch spezielle Filter. Fehlt die Rückroute vom DHCP-Server zum Relay-Agenten, oder ist eine Firewall dazwischen, scheitert der DHCP-Dialog. Der Server erreicht den Relay-Agenten unter der giaddr-Adresse nicht, und die Antwort verpufft. Auch die Verwendung von Option 82 kann Fehler verursachen, wenn der Server sie nicht versteht und das Angebot verwirft. Eine konsistente Konfiguration von Relay-Agent und Server ist daher unerlässlich.

Best Practices

Die DHCP-Relay-Funktion sollte auf allen Layer-3-Interfaces aktiviert sein, an denen sich DHCP-Clients befinden. Die Zielserveradresse sollte redundant ausgelegt sein, indem mehrere IP-Adressen per ip helper-address konfiguriert werden. Option 82 sollte nur dann eingefügt werden, wenn der Server sie auswertet und in die Adressvergabe einbezieht. Logging und Monitoring der DHCP-Relay-Statistiken helfen, fehlerhafte Clients oder Konfigurationsprobleme schnell zu erkennen. In Kombination mit DHCP-Snooping und IP-Source-Guard auf Layer 2 lässt sich ein robustes und sicheres DHCP-System aufbauen.