Re: dnsmasq antwortet nicht auf DHCP-Anfragen
Martin Steigerwald <Martin@lichtvoll.de> wrote:
> Am Montag, 4. Juni 2012 schrieb Sven Hartge:
>> Michael Hierweck <team@edv-serviceteam.net> wrote:
>>> Meine iptables haben offenbar DHCP-Traffic geblockt, wurden aber von
>>> ISC DHCP server irgendwie ausgehebelt. Für dnsmasq musste ich also
>>> meine iptables-Regeln ändern.
>>>
>>> Diesen "Trickgriff" seitens des ISC DHCP servers kann ich bislang
>>> nicht.
>> Der ISC-DHCPd nutzt Raw-Sockets, die "unterhalb" von iptables die
>> Pakete abgreifen und daher auch funktionieren, wenn man eingehenden
>> Traffic auf den BOOTPS/BOOTPC-Ports blockiert.
> Sehr interessant. Das lese ich zum ersten Mal. Es gibt immer wieder
> etwas zum Dazulernen.
Das ist IIRC seit isc-dhcp-v3 der Fall. Vorher nutzte dieser auch
normale Sockets und man musste die ipchains/ipfwadm-Regeln passend
setzen.
>> Dies führt allerdings zu einer extremen Unschönheit im
>> ISC-DHCP-Relay-Server, wodurch das Ding eigentlich unbenutzbar wird.
>> (Kann ich bei Bedarf erläutern.)
> Bedarf. ;)
Zuerst einmal:
Das dhcp-relay lauscht an einem oder mehreren "inneren" Interfaces auf
DHCP-Anfragen via Broadcast. Diese werden dann vi Unicast auf einem
"äußeren" Interface an den richtigen DHCP-Server weitergeleitet.
Das Problem:
Leider ist es so, dass der dhcp-relay auch auf dem äußeren Interface
lauschen muss, sonst bekommt er die Unicast-Antworten vom DHCP-Server
nicht mit (das ist das erste WTF?!).
Und dabei passiert es dann, der dhcp-relay sieht seine eigenen (!)
ausgehenden (!!) Unicast-Anfragen und schickt diese _erneut_ an den
DHCP-Server, als wären sie Broadcast-Anfragen von den inneren
Interfaces. (das ist das zweite WTF?!) Das führt dann dazu, dass aus
_einer_ Anfrage plötzlich dutzende Anfragen am realen DHCP-Server
werden.
Dem macht das nichts aus, da jede Anfrage eine eindeutige ID hat und
wenn die gleiche ID mehrfach ankommt, dann werden spätere Anfragen
ignoriert. Nervig ist das dennoch.
Vor allem: dadurch dass der isc-dhcp-relay auch am äußeren Interface
lauscht, reicht er dort eingehende Broadcast-DHCP-Anfragen _auch_ an den
realen DHCP-Server weiter, obwohl er für den Netzbereich evtl. gar nicht
zuständig ist, da dies ja eigentlich das _äußere_ Interface ist.
Auch dieses sorgt im Normalfall für keine Probleme, hinterläßt aber
evtl. irritierende Fehlermeldungen im Logfile auf dem realen
DHCP-Server.
Alles in allem: *bläch*
Ich nutze daher das Relay aus dem Paket "dhcp-helper". Das nutzt zwar
keine Raw-Sockets, man muss also wieder iptables-Regeln passend setzen,
hat aber dafür keine Un-Features wie der ISC-Code, ist kleiner und tut
einfach, was ich von ihm will.
S°
--
Sigmentation fault. Core dumped.
Reply to: