1
DHCPREQUEST für ungültige IP-Adressen zurückweisen
Hallo,
in unserem WLAN-Netzwerk gibt es immer wieder das Problem, dass manche Clients ein DHCPREQUEST senden mit einer IP-Adresse, die nicht im Bereich der vom DHCP-Server zu vergebenen Adressen liegt.
Das endet dann in solchen Meldungen:
May 22 08:25:12 server dhcpd: DHCPREQUEST for 10.0.0.109 from 74:2f:68:72:XX:YY via eth1: unknown lease 10.0.0.109.
Der Bereich 10.0.0.0 ist vorgesehen für Geräte mit festen IP-Adressen (insbesondere die APs).
Meine DHCP-Config:
---
subnet 10.0.0.0 netmask 255.255.0.0 {
option subnet-mask 255.255.0.0;
range 10.0.10.0 10.0.30.254;
option broadcast-address 10.0.255.255;
option routers 10.0.0.1;
}
---
Ein DHCPACK wird in dem Fall dann nicht gesendet.
Jetzt scheinen die Clients aber vom DHCP leider nicht mitgeteilt zu bekommen (z.B. durch ein NACK!?), dass er mit der vom Client angeforderten Adresse nicht zufrieden ist. Statt dessen funktioniert der Client dann nicht richtig.
Gibt es eine Möglichkeit alle DHCPREQUEST mit ungültigen IP-Adressen zurückzuweisen?
PS: Bisher konnte ich das teilweise durch leeren des DHCP-Cache bei den (Windows-)Clients lösen, aber das scheint auch nicht von großer Dauer zu sein. (Bzw. bei einem großen WLAN wie unserem nicht zu administrieren)
Gruß
Tobias
in unserem WLAN-Netzwerk gibt es immer wieder das Problem, dass manche Clients ein DHCPREQUEST senden mit einer IP-Adresse, die nicht im Bereich der vom DHCP-Server zu vergebenen Adressen liegt.
Das endet dann in solchen Meldungen:
May 22 08:25:12 server dhcpd: DHCPREQUEST for 10.0.0.109 from 74:2f:68:72:XX:YY via eth1: unknown lease 10.0.0.109.
Der Bereich 10.0.0.0 ist vorgesehen für Geräte mit festen IP-Adressen (insbesondere die APs).
Meine DHCP-Config:
---
subnet 10.0.0.0 netmask 255.255.0.0 {
option subnet-mask 255.255.0.0;
range 10.0.10.0 10.0.30.254;
option broadcast-address 10.0.255.255;
option routers 10.0.0.1;
}
---
Ein DHCPACK wird in dem Fall dann nicht gesendet.
Jetzt scheinen die Clients aber vom DHCP leider nicht mitgeteilt zu bekommen (z.B. durch ein NACK!?), dass er mit der vom Client angeforderten Adresse nicht zufrieden ist. Statt dessen funktioniert der Client dann nicht richtig.
Gibt es eine Möglichkeit alle DHCPREQUEST mit ungültigen IP-Adressen zurückzuweisen?
PS: Bisher konnte ich das teilweise durch leeren des DHCP-Cache bei den (Windows-)Clients lösen, aber das scheint auch nicht von großer Dauer zu sein. (Bzw. bei einem großen WLAN wie unserem nicht zu administrieren)
Gruß
Tobias
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 186889
Url: https://administrator.de/contentid/186889
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
1 Kommentar
Das Problem ist das diese Clients irgendwann schon einmal eine 10.0.0er DHCP Adresse bekommen haben und versuchen diese zu erneuern (Renew).
Ein "Nackter" DHCP Request kommt ja niemals mit einer dedizierten Absender IP ! Wie auch denn der Client hat ja gar keine IP und versucht erst eine zu bekommen. Logischerweise geht ein frischer Request deshalb auch an die Broadcast Adresse 255.255.255.255.
Anders sieht das bei gerouteten Netzen und einem zentralen DHCP aus. Dort sind auf den Routern dann sog. DHCP Forwarder (IP Helper) auf den Interfaces definiert, die die UDP DHCP Broadcasts mit ihrer IP als Absender IP versehen und an den zentralen DHCP forwarden, der dann wiederum aus seinem Scope eine IP dafür vergibt.
Sofern du sowas hast sieht es so aus als ob du hier so einen fehler hast also einen falsche Subnetzmaske oder IP auf so einen Router oder L3 VLAN Switch.
Wie gesagt ein DHCP Client Request kommt niemals mit einer dedizierten Absender IP ! Wie auch, wenn er selber gar keine IP hat und danach fragt... ?!
Ein "Nackter" DHCP Request kommt ja niemals mit einer dedizierten Absender IP ! Wie auch denn der Client hat ja gar keine IP und versucht erst eine zu bekommen. Logischerweise geht ein frischer Request deshalb auch an die Broadcast Adresse 255.255.255.255.
Anders sieht das bei gerouteten Netzen und einem zentralen DHCP aus. Dort sind auf den Routern dann sog. DHCP Forwarder (IP Helper) auf den Interfaces definiert, die die UDP DHCP Broadcasts mit ihrer IP als Absender IP versehen und an den zentralen DHCP forwarden, der dann wiederum aus seinem Scope eine IP dafür vergibt.
Sofern du sowas hast sieht es so aus als ob du hier so einen fehler hast also einen falsche Subnetzmaske oder IP auf so einen Router oder L3 VLAN Switch.
Wie gesagt ein DHCP Client Request kommt niemals mit einer dedizierten Absender IP ! Wie auch, wenn er selber gar keine IP hat und danach fragt... ?!
