Statische IP wird trotzdem per DHCP vergeben

@tdthomas

Ich hab das ganze Problem jetzt umgangen, aber mich interessiert schon, warum
- eine reservierte IP überhaupt an eine falsche MAC vergeben wird

Hier besteht einfach ein sehr verbreitetes Missverständnis von IP-Reservierungen auf einem DHCP-Server.

Eine Reservierung einer IP-Adresse für eine bestimmte MAC-Adresse bedeutet NICHT, dass diese IP-Adresse ausschließlich an die gewünschte MAC-Adresse verteilt wird.

Eine Reservierung bedeutet nur, dass diese IP-Adresse an die MAC-Adresse vergeben wird,
wenn die betreffende IP-Adresse NOCH FREI IST.

- diese reservierte IP mehrfach an die gleiche falsche MAC vergeben wird

Das erfolgt einfach dadurch, dass der betreffende Client sein Lease so lange behalten kann wie das Lease gültig ist und dieses auch durch Anfrage beim DHCP-Server weiter verlängern kann.

Das ist ganz "normales" DHCP-Verhalten.

- das ursprünglich vorgesehen Gerät die IP dann ebenfalls bekommt, obwohl zu diesem Zeitpunkt bereits das falsche Gerät mit der zugewiesenen IP im Netzwerk ist.

Ich vermute hier einfach, dass der DHCP-Server der UTM ( das ist nichts UTM-spezifisches, sondern so verhalten sich Linux-DHCP-Server einfach. Keine Ahnung, ob MS-DHCP-Server sich anders verhalten!? )
bei IP-Leases, die durch Reservierungen vergeben wurden, nicht prüft,
ob diese IP-Adresse schon vergeben ist.

Bin mir nicht ganz sicher, aber anders kann ich es mir auch nicht erklären.

Gibt es hier DHCP-Experten, die diese Frage zweifelsfrei beantworten können?

Wie auch die anderen bereits gesagt haben, verhält sich die UTM völlig normal.

DHCP funktioniert in bestimmten Situationen einfach nicht so wie man es vermutet,
es gibt da schon spezielle Situationen, die man berücksichtigen muss.

Und nochmal: Eine Reservierung reserviert eine IP-Adresse nicht wie vermutet ausschließlich für eine bestimmte MAC-Adresse.

Wenn die Reservierung innerhalb der DHCP-Range liegt und ein anderer Client hat vor dem Client, der  die IP-Adresse eigentlich bekommen soll, bereits die IP-Adresse angefragt, dann vergibt der DHCP-Server diese IP einfach an den "schnelleren" Client und fertig.

Deshalb: Egal um was für einen DHCP-Server es sich handelt. IP-Adress-Reservierungen müssen IMMER außerhalb der DHCP-Range liegen.

Das ist nichts UTM-spezifisches und weder ein Bug noch "unlogisch".

So funktioniert DHCP nun mal einfach.

Bei Interesse kannst du dir einfach mal folgenden Link anschauen,
dort kannst du auch nachlesen, dass ein Client seine IP-Adresse ( sein Lease ) auch nach nach einem Reboot weiternutzen kann, wenn eine Lease-Verlängerung scheitert, weil der DHCP-Server einfach nicht antwortet.

Erschienen im Linux

Gruß, Datax

Eine Reservierung bedeutet nur, dass diese IP-Adresse an die MAC-Adresse vergeben wird,
wenn die betreffende IP-Adresse NOCH FREI IST.

Es gab in diesem Fall allerdings auch keinen Grund seitens der Sophos, die reservierte IP-Adresse an das fremde Gerät zu vergeben! Es war bei weitem nicht die letzte freie Adresse, sie lag außerdem am Ende des DHCP-Adresspools.

Der Client dürfte die Adresse auch nicht angefragt haben, da meinem Verständnis nach der DHCP-Server Adressen anbietet - nicht umgekehrt.

Wenn die Reservierung innerhalb der DHCP-Range liegt und ein anderer Client hat vor dem Client, der  die IP-Adresse eigentlich bekommen soll, bereits die IP-Adresse angefragt, dann vergibt der DHCP-Server diese IP einfach an den "schnelleren" Client und fertig.

Aber wie oben geschrieben, ein Client fragt doch keine bestimmte IP an, sondern bekommt ein DHCP-Offer vom Server (siehe auch Erschienen im Linux).
Und dieses Offer hätte nicht mit der reservierten IP kommen dürfen, da die IP reserviert ist und ganz sicher nicht die letzte freie IP war.

Ein "schnellerer Client" dürfte also nur die reservierte IP bekommen, wenn es die letzte freie IP im Adresspool ist. Eine Verlegung der reservierten DHCP-IP in den Bereich ausserhalb des Adresspool umgeht in meinen Augen das Problem nur.

Eine Reservierung bedeutet nur, dass diese IP-Adresse an die MAC-Adresse vergeben wird,
wenn die betreffende IP-Adresse NOCH FREI IST.

Es gab in diesem Fall allerdings auch keinen Grund seitens der Sophos, die reservierte IP-Adresse an das fremde Gerät zu vergeben! Es war bei weitem nicht die letzte freie Adresse, sie lag außerdem am Ende des DHCP-Adresspools.

Der Client dürfte die Adresse auch nicht angefragt haben, da meinem Verständnis nach der DHCP-Server Adressen anbietet - nicht umgekehrt.

Wenn die Reservierung innerhalb der DHCP-Range liegt und ein anderer Client hat vor dem Client, der  die IP-Adresse eigentlich bekommen soll, bereits die IP-Adresse angefragt, dann vergibt der DHCP-Server diese IP einfach an den "schnelleren" Client und fertig.

Aber wie oben geschrieben, ein Client fragt doch keine bestimmte IP an, sondern bekommt ein DHCP-Offer vom Server (siehe auch Erschienen im Linux).
Und dieses Offer hätte nicht mit der reservierten IP kommen dürfen, da die IP reserviert ist und ganz sicher nicht die letzte freie IP war.

Ein "schnellerer Client" dürfte also nur die reservierte IP bekommen, wenn es die letzte freie IP im Adresspool ist. Eine Verlegung der reservierten DHCP-IP in den Bereich ausserhalb des Adresspool umgeht in meinen Augen das Problem nur.