DHCP nie działa? Zamiast zgadywać, przejdź przez DORA

Kiedy DHCP przestaje działać, sieć zwykle wygląda tak, jakby zepsuło się wszystko naraz. Komputer nie dostaje adresu, DNS nie działa, brama jest pusta, a człowiek zaczyna odruchowo restartować router, switcha i własną cierpliwość.

Tylko że DHCP rzadko psuje się w widowiskowy sposób. Częściej ginie jeden pakiet, odpowiedź wraca inną ścieżką, firewall wycina UDP 68 albo w segmencie siedzi drugi serwer, który rozdaje adresy z kosmosu. Dlatego zrobiłem małe narzędzie: dhcp-dora.

Repozytorium: https://repo.noop.re/drops/dhcp-dora

Co właściwie debugujemy przy DHCP

DHCPv4 działa na broadcastach i portach UDP 67/68. Klient zwykle nie ma jeszcze adresu IP, więc nie może po prostu zapytać serwera po normalnym unicast TCP. Zamiast tego krzyczy w segmencie L2: „czy ktoś ma dla mnie adres?”.

Klasyczny przepływ to DORA:

DISCOVER – klient szuka serwera DHCP.
OFFER – serwer proponuje adres i parametry sieci.
REQUEST – klient mówi, którą ofertę wybiera.
ACK – serwer potwierdza dzierżawę.

Jeśli zatrzymasz się na „nie mam IP”, to nie wiesz jeszcze prawie nic. Trzeba ustalić, na którym etapie DORA się wysypuje.

Czy DISCOVER wychodzi z właściwego interfejsu? Czy OFFER wraca? Czy klient wybiera właściwy serwer? Czy dostaje ACK, czy NAK? Czy w sieci nie ma drugiego serwera DHCP? To są konkretne pytania. Bez nich debugowanie zmienia się w rytuał z restartem urządzeń.

Najczęstsze problemy z DHCP, które wyglądają podobnie

Pierwszy klasyk: klient i serwer nie są w tym samym segmencie L2. DHCPv4 opiera się na broadcastach, więc zwykły router ich nie przepuści. Jeśli masz VLAN-y, private VLAN, izolację klientów na Wi-Fi albo AP w trybie „client isolation”, klient może nigdy nie zobaczyć serwera.

Drugi klasyk: zły interfejs. Laptop ma Wi-Fi, Ethernet, VPN, bridge od wirtualizacji i jeszcze coś od kontenerów. DHCP testowane na en0 może działać, a na bridge100 będzie cisza. Narzędzie powinno zmuszać do podania interfejsu, bo automatyczne zgadywanie tutaj bardziej szkodzi niż pomaga.

Trzeci: firewall albo systemowy klient DHCP trzyma port 68. Na Windowsie usługa DHCP Client może przeszkadzać w testach, a Defender Firewall może blokować przychodzący UDP 68. Na macOS dochodzi Application Firewall, pf i Gatekeeper, jeśli binarka została pobrana z internetu.

Czwarty: rogue DHCP server. To jest ten przypadek, który boli najbardziej, bo sieć „działa”, tylko czasem rozdaje zły gateway, zły DNS albo adres z nie tej puli. Jedna testowa VM z dnsmasq zostawiona w złym VLAN-ie potrafi zrobić dzień pełen fałszywych tropów.

Dlaczego napisałem dhcp-dora

Chciałem mieć proste CLI, które odpowie na dwa pytania:

czy serwer DHCP przechodzi pełny handshake DORA?
czy w segmencie odpowiada ktoś, kto nie powinien?

Da się to zrobić ręcznie przez tcpdump albo Wiresharka. I czasem nadal trzeba. Ale nie zawsze chcę zaczynać od analizy ramek, szczególnie gdy potrzebuję szybkiego testu na kilku systemach albo chcę wkleić komuś wynik w zgłoszeniu.

dhcp-dora jest napisane w Go i skupia się tylko na DHCPv4. Ma dwa tryby: dora do pełnego testu DISCOVER, OFFER, REQUEST, ACK oraz probe do wykrywania obcych serwerów DHCP.

Projekt jest nadal rozwijany. W release’ach są binarki dla Linux, macOS i Windows, dla amd64 i arm64. Aktualna checklista labowa w repo opisuje testy dla wersji v0.1.3; Linux jest sprawdzony, macOS był weryfikowany na v0.1.2, a Windows ma przygotowaną checklistę do ręcznego testu.

Tryb dora: pełny handshake bez zgadywania

Najprostszy test wygląda tak:

dhcp-dora dora --iface eth0

Wynik mówi, czy udało się przejść cały handshake. W raporcie dostajesz między innymi:

IP serwera DHCP
oferowany adres IP
maskę podsieci
bramę
DNS-y
czas dzierżawy
czasy poszczególnych faz w milisekundach.

Możesz też wymusić konkretny serwer:

dhcp-dora dora --iface eth0 --server 192.168.1.1

To jest przydatne w sieciach, gdzie podejrzewasz dodatkowe odpowiedzi. Narzędzie zaakceptuje ofertę tylko od wskazanego serwera, ale obce oferty odnotuje w raporcie jako foreign_offers.

Jest też JSON:

dhcp-dora dora --iface eth0 --json

To brzmi jak drobiazg, dopóki nie chcesz porównać wyników z kilku hostów albo wrzucić testu do skryptu. Czasy są w milisekundach, pola mają stabilny schemat, więc output nie jest tylko tekstem do czytania przez człowieka.

Tryb probe: szybkie polowanie na rogue DHCP

Drugi tryb zbiera oferty DHCP przez określony czas i klasyfikuje serwery względem allowlisty:

dhcp-dora probe --iface eth0 --trusted 192.168.1.1 --duration 15s

Każdy odpowiadający serwer dostaje werdykt TRUSTED albo ROGUE. Jeśli chcesz używać tego jako testu w automatyzacji, możesz dodać:

dhcp-dora probe --iface eth0 --trusted 192.168.1.1 --duration 15s --fail-on-rogue

Wtedy obecność obcego serwera kończy się kodem wyjścia 1. Bez tej flagi narzędzie nadal pokazuje rogue, ale sam test może zakończyć się kodem 0, bo raport został zebrany poprawnie.

Allowlistę można trzymać w pliku:

192.168.1.1
# zapasowy DHCP na VLAN corp
192.168.2.10

I uruchomić:

dhcp-dora probe --iface eth0 --trusted-file trusted.txt --duration 15s

Błędne linie w pliku trafiają do warnings, zamiast od razu zabijać cały test. To celowe. W praktyce pliki konfiguracyjne mają komentarze, puste linie i czasem literówki. Test ma to pokazać, a nie udawać, że nic się nie stało.

Jak debugować, gdy nadal nie ma odpowiedzi

dhcp-dora nie zastępuje sniffera. Ono skraca drogę do momentu, w którym wiesz, co sprawdzić dalej.

Na Linuxie i macOS najprostszy podgląd wygląda tak:

sudo tcpdump -ni <iface> udp port 67 or 68

Szukasz dwóch rzeczy:

DISCOVER wychodzący z klienta, zwykle source port 68 do destination port 67
OFFER wracający z serwera, source port 67 do destination port 68.

Jeśli DISCOVER nie wychodzi, problem jest po stronie klienta, interfejsu albo uprawnień. Jeśli DISCOVER wychodzi, ale OFFER nie wraca, patrzysz na segment L2, VLAN, serwer DHCP albo firewall po drodze. Jeśli OFFER jest w tcpdump, ale narzędzie go nie widzi, problem jest bliżej systemu, socketu albo lokalnego firewalla.

Na Windowsie checklista w repo proponuje pktmon albo Wiresharka z filtrem:

udp.port == 67 || udp.port == 68

Warto też sprawdzić usługę DHCP Client:

sc query dhcp

Przy testach może być potrzebne zatrzymanie usługi i reguła firewalla dla UDP 68. Po teście trzeba oczywiście przywrócić stan systemu.

Różnice między systemami są nudne, dopóki nie zepsują testu

Najwygodniej jest na Linuxie. dhcp-dora może używać raw AF_PACKET socket i nie musi wiązać się z portem 68, więc łatwiej ominąć konflikty z innymi usługami. Można uruchomić jako root albo nadać capability:

sudo setcap cap_net_raw+ep /usr/local/bin/dhcp-dora

Na macOS trzeba uruchomić narzędzie z rootem, bo wchodzi port uprzywilejowany 68. Po pobraniu binarki z release’a trzeba też usunąć quarantine attribute:

xattr -cr dhcp-dora

Na Windowsie dochodzi uruchomienie PowerShella jako administrator, usługa DHCP Client, firewall i SmartScreen przy pierwszym uruchomieniu. To nie są ciekawe problemy, ale są dokładnie tym typem rzeczy, które zabierają czas, jeśli nie masz listy kontrolnej.

Błąd, który wyszedł po drodze

W v0.1.0 był problem z odpowiedziami przez limited broadcast na macOS i Windows. Serwer mógł odpowiedzieć tak, że test tego nie widział. To zostało poprawione w v0.1.1: transport UDP wiąże się na 0.0.0.0:68, przypina ruch do wskazanego interfejsu i wysyła DISCOVER/REQUEST zarówno na 255.255.255.255:67, jak i na directed broadcast interfejsu.

To jest dobry przykład, dlaczego debugowanie DHCP bywa mylące. Serwer może działać, pakiet może istnieć, a aplikacja nadal może go nie zobaczyć przez szczegóły socketów i zachowania systemu operacyjnego.

Kody wyjścia, czyli mała rzecz ważna w automatyzacji

Narzędzie zwraca konkretne kody:

Kod	Znaczenie
0	ACK otrzymany albo raport `probe` zebrany poprawnie
1	błąd uruchomienia, timeout, NAK albo `--fail-on-rogue`
2	błąd użycia, na przykład brak `--iface`
130	przerwanie `probe` przez SIGINT, z częściowym raportem

To pozwala używać dhcp-dora w prostych smoke testach. Na przykład po zmianie konfiguracji VLAN-u możesz puścić probe --fail-on-rogue i od razu wiedzieć, czy w segmencie odezwał się nieautoryzowany serwer.

Minimalny scenariusz

Najpierw sprawdziłbym interfejs:

ip -brief addr

Potem DORA:

dhcp-dora dora --iface eth0 --json > dora.json
python3 -m json.tool dora.json

Potem rogue DHCP:

dhcp-dora probe --iface eth0 --trusted 192.168.1.1 --duration 15s --json > probe.json
python3 -m json.tool probe.json

Jeśli coś nie gra, dokładam sniffer:

sudo tcpdump -ni eth0 udp port 67 or 68

I dopiero wtedy zaczynam ruszać konfigurację. Nie odwrotnie.

Co dalej z dhcp-dora

Kod jest ułożony warstwowo: transport, logika dora/probe, raporty i CLI. Dzięki temu później można dołożyć TUI bez przepisywania rdzenia. Na razie najważniejsza jest stabilność testów na realnych sieciach i dopięcie scenariuszy per OS, szczególnie Windowsa.

Jeśli chcesz sprawdzić narzędzie u siebie, pobierz release, zweryfikuj SHA256SUMS i odpal test w tym samym segmencie L2 co serwer DHCP:

https://repo.noop.re/drops/dhcp-dora/releases/tag/v0.1.3

A jeśli trafisz przypadek, w którym tcpdump widzi OFFER, a dhcp-dora nie, to jest właśnie ten typ zgłoszenia, który mnie interesuje najbardziej. W raporcie przydadzą się: pełna komenda, wersja z dhcp-dora version, output human i JSON oraz capture z tcpdump, pktmon albo Wiresharka.

FAQ

Co oznacza DORA w DHCP?

DORA to skrót od DISCOVER, OFFER, REQUEST, ACK. To podstawowy handshake DHCPv4, w którym klient znajduje serwer, dostaje ofertę adresu, wybiera ją i otrzymuje potwierdzenie dzierżawy.

Dlaczego DHCP nie działa przez router?

DHCPv4 używa broadcastów w segmencie L2. Router zwykle ich nie przepuszcza. Jeśli DHCP ma działać między podsieciami, potrzebny jest relay DHCP, często konfigurowany jako ip helper-address albo odpowiednik na danym sprzęcie.

Jak wykryć rogue DHCP server?

Najprościej wysłać DHCPDISCOVER i zebrać wszystkie DHCPOFFER w segmencie. dhcp-dora probe robi dokładnie to, a potem porównuje odpowiadające serwery z listą zaufanych IP.

Czy dhcp-dora obsługuje IPv6?

Nie. Projekt dotyczy DHCPv4 zgodnie z RFC 2131. DHCPv6 to osobny protokół i inna ścieżka diagnostyczna.