XPLN/Lernbereiche

F01 · DHCPv4 · Protokoll

Transport und Erreichbarkeit

Kapitel in dieser Lernstufe

Das lernst du

  • UDP-Ports und Adressierung je Netzabschnitt bestimmen.
  • Eine Firewallfreigabe aus dem tatsächlichen Nachrichtenweg ableiten.

Voraussetzungen: G04 · Client, Server, Switch und RouterG09 · Die erste Vergabe: DORA

Die Regel „UDP 67 und 68 öffnen“ ist ohne Richtung und Netzabschnitt unvollständig. Ein Client, ein Relay und ein Server senden unterschiedliche IP-Pakete.

Broadcast-Domäne
Der Netzbereich, in dem ein lokaler Broadcast verteilt wird. Ein VLAN bildet üblicherweise eine solche Domäne; ein Router verbindet Netze, ohne gewöhnliche Limited Broadcasts einfach zu routen.

Die Firewall sieht den Relayverkehr

Zwei Netzabschnitte, andere PortpaareRelayServerFirewallUDP 67 → 67Rückweg ebenfalls freigebenLokale ClientstreckeAnfrage: 68 → 67Antwort: 67 → 68
Grafik vergrößern
Zwei Netzabschnitte, andere PortpaareRelayServerFirewallUDP 67 → 67Rückweg ebenfalls freigebenLokale ClientstreckeAnfrage: 68 → 67Antwort: 67 → 68
Auf der Strecke zwischen klassischem DHCPv4-Relay und Server laufen Anfrage und Antwort über UDP 67 → 67. Die lokale Clientstrecke hat andere Ports: 68 → 67 für die Anfrage und 67 → 68 für die Antwort. Eine reine 68-zu-67-Regel am Servernetz verfehlt deshalb den Relayverkehr.

Lokaler Erstbezug

UDP stellt datagrammorientierten Transport ohne vorherigen Verbindungsaufbau bereit. Für DHCPv4 hört der Client auf Port 68 und der Server auf 67. Beim Erstbezug kann der Client 0.0.0.0:68 → 255.255.255.255:67 senden. Die Broadcast-Domäne begrenzt den lokalen Empfängerkreis.

Ein Router leitet diesen Limited Broadcast nicht wie eine normale geroutete Zieladresse weiter. Ein Relay verarbeitet DHCP gezielt und sendet eine neue, adressierte Übertragung zum Server. Ein Switch ohne Relayfunktion löst dieses Problem nicht.

Hin- und Rückweg

Zwischen Relay und Server verwendet der klassische DHCPv4-Relayweg UDP 67 auf beiden Seiten. Vom Server an einen unmittelbar erreichbaren Client gehen Antworten typischerweise von 67 an 68. Ob diese Antwort broadcast oder unicast ist, hängt vom Zustand und den Feldern ab.

Eine Firewall muss den für die konkrete Topologie vorgesehenen Austausch erlauben. Nur die Clientregel 68→67 auf dem Servernetz zu öffnen kann Relayverkehr blockieren. Eine Route zum Server ohne Rückroute zum Relay reicht ebenfalls nicht. ICMP-Erreichbarkeit belegt keine UDP-Freigabe.

AbschnittTypischer TransportPrüfung
Client → lokaler DienstUDP 68 → 67, Broadcast beim StartPaket im Client-VLAN sichtbar?
Relay → ServerUDP 67 → 67, adressiertZiel, giaddr, Route, ACL?
Server → RelayUDP 67 → 67Rückweg und Filter?
Relay/Server → ClientUDP 67 → 68Richtiger Client-Link?

Zwei Adressschichten getrennt betrachten

Ein IP-Broadcast beim Start wird im lokalen Ethernet normalerweise an die Broadcast-MAC ff:ff:ff:ff:ff:ff verpackt. Der Switch verteilt den Rahmen innerhalb des betreffenden VLANs. Ein Relay nimmt den DHCP-Inhalt entgegen und transportiert ihn in einem neuen IP/UDP-Paket zum Server. Die äußere Zieladresse wechselt damit von einem lokalen Broadcast zur konkreten Serveradresse; der fachliche Bezug zum ursprünglichen Client bleibt in den DHCP-Feldern erhalten.

Ein Capture auf der Serverseite muss deshalb anders aussehen als eines neben dem Client. Wer nur nach Ziel 255.255.255.255 filtert, kann auf dem Servernetz sämtliche korrekt weitergeleiteten Anfragen übersehen. Prüfe den Messpunkt, bevor du aus einem leeren Mitschnitt auf fehlenden Verkehr schließt. Auch VLAN-Tags können je nach Capturepunkt und Hardware anders sichtbar sein.

Warum zustandsbehaftete Filter trotzdem geprüft werden müssen

UDP baut keine Verbindung mit einem Handshake auf. Eine Firewall kann trotzdem vorübergehende Zustände für UDP-Flüsse speichern. DHCP-Antworten passen wegen Broadcast, Relay und noch nicht eingerichteter Clientadresse jedoch nicht immer zu einer vereinfachten Vorstellung von „Antwort auf genau dieselben Adressen“. Eine allgemeine Regel für etablierte TCP-Verbindungen beschreibt diesen Verkehr nicht.

Lege für jede Strecke Quelle, Ziel, UDP-Ports und erlaubte Richtung fest. Beobachte dann denselben Bezug am Eingang und Ausgang des Filters. Kommt der REQUEST an und verlässt ein ACK den Server, verschiebt sich die Untersuchung auf Rückroute, Relay und Zustellung zum Client. Eine unnötig breite Freigabe kann zwar den Test verändern, erklärt aber nicht, welche benötigte Teilstrecke zuvor fehlte.

DURCHGEARBEITETES BEISPIEL

Ping funktioniert, DHCP nicht

  1. Der Relay 192.168.10.1 kann 192.168.20.10 pingen. Ein Capture im Büro sieht DISCOVER, ein Capture am Server nicht.
  2. Die Firewall erlaubt nur UDP mit Quellport 68. Relaypakete mit Quellport 67 werden verworfen.
  3. Eine auf Relay- und Serveradressen begrenzte Regel für den vorgesehenen UDP-Austausch ergänzen, Rückweg prüfen, neuen Bezug auslösen und OFFER/ACK auf beiden Abschnitten beobachten.

Ergebnis: Die Reparatur folgt der Paketadressierung. Eine pauschale Freigabe aller Broadcasts ist weder erforderlich noch eine saubere Diagnose.

Typische Fehler

  • Ports allein ohne Adress- und Richtungsbezug sind keine vollständige Regel.
  • DHCPv6 benutzt andere Ports.
  • Ein erfolgreicher Ping sagt nichts über eine bestimmte UDP-Regel.

Praktisch anwenden

P14 öffnen P20 öffnen P24 öffnen

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.