Statische IP wird trotzdem per DHCP vergeben

Eine reservierte IP Adresse darf nicht im DHCP bereich sein da diese (wie du bemerkt hast) ansonsten trotzdem vergeben wird. Das ist kein Bug.

Der Client erhält aber dann immer die reservierte Adresse.

@tdthomas
Wir reden hier ausschließlich vom DHCP Server auf der UTM?

Eine reservierte IP Adresse darf nicht im DHCP bereich sein da diese (wie du bemerkt hast) ansonsten trotzdem vergeben wird. Das ist kein Bug.

Der Client erhält aber dann immer die reservierte Adresse.

Eine im DHCP reservierte IP-Adresse darf nicht im DHCP Bereich sein, damit der Client vom DHCP immer die gleiche IP-Adresse erhält und kein anderer Rechner? Sprich, der Client erhält vom DHCP seine reservierte IP-Adresse aus einem IP-Adressbereich, für den der DHCP nicht zuständig ist?

Doch, das ist ein Bug - oder Dummheit der Programmierer.

Eine reservierte IP Adresse darf nicht im DHCP bereich sein da diese (wie du bemerkt hast) ansonsten trotzdem vergeben wird.

Ich würde eine statische IP nie aus dem Adress-Bereich des DHCP nehmen, eben um doppelte Vergabe (1x per statischer IP, 1x per DHCP) zu vermeiden.

Ich habe aber keine statische IP verwendet.

Der Rechner läuft mit DHCP und soll dementsprechend auch eine IP-Adresse aus dem DHCP-Pool erhalten. Auf der Sophos ist diese eine IP-Adresse für den gewünschten Rechner reserviert. 
Diese Tatsache ist der Sophos also bekannt und sollte somit bei der Vergabe von Adressen per DHCP aus dem DHCP-Pool automatisch berücksichtigt werden, d.h. die reservierte Adresse wird nicht an fremde Geräte vergeben - schon gar nicht, wenn im DHCP-Pool noch genügend frei ist.

Eine doppelte Vergabe per DHCP sollte im meinen Augen grundsätzlich nicht passieren - und schon gar nicht, wenn es sogar eine reservierte IP ist.

@tdthomas
Wir reden hier ausschließlich vom DHCP Server auf der UTM?

Ja genau, nichts anderes.

Sprich, der Client erhält vom DHCP seine reservierte IP-Adresse aus einem IP-Adressbereich, für den der DHCP nicht zuständig ist?

So sieht sogar mein momentaner Workaround aus:
Für die MAC des gewünschten Rechners ist nun unter Netzwerkdefinitionen -> Host eine IP ausserhalb des DHCP-Pool reserviert worden. Der Rechner empfängt nun per DHCP die reservierte IP, die aber ausserhalb des DHCP-Adresspool liegt... oO

Ob Bug, Dummheit oder logisch, darüber lässt sich streiten.

Fakt ist, dass sich z.B. der Windows-DHCP-Server hier anders verhält, als andere DHCP-Server.
Bei Microsoft muss die Reservierung innerhalb des Bereichs sein (wobei man ja für Bereiche innerhalb des DHCP Scope auch wieder Ausnahmen definieren kann, die nicht vergeben werden), während bei den meisten anderen DHCP-Servern (z.B. ISC DHCP) diese außerhalb des definierten Bereichs liegen sollten.

Also beim Verwenden der UTM als DHCP: Reservierungen IMMER außerhalb des DHCP-Scope vornehmen!

Edit: Übrigens steht's sogar in der Online-Hilfe:

To avoid an IP address clash between regularly assigned addresses from the DHCP pool and those statically mapped make sure that the latter are not in the scope of the DHCP pool. For example, a static mapping of 192.168.0.200 could result in two systems receiving the same IP address if the DHCP pool is 192.168.0.100 – 192.168.0.210

...Bei Microsoft muss die Reservierung innerhalb des Bereichs sein...

Falsch.
Man kann auch feste Leases ausserhalb des wirklichen DHCP-Bereichs definieren.

Funktioniert bei mehreren MS-DHCP auf 2008R2 [:D]

@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.

@tdthomas

Wie gesagt, die Funktionsweise von DHCP allgemein ist einfach so,
dass eine IP-Adresse einem Client auch dann angeboten wird,
wenn diese für eine bestimmte MAC-Adresse reserviert ist.

Eine Reservierung verhindert nicht, dass der DHCP-Server auch einem anderen Client diese IP-Adresse anbietet.

Um das zu erreichen muss die Reservierung außerhalb der DHCP-Range liegen.

Du vertauscht da einfach deine persönlichen logischen Vorstellungen mit der wirklichen Funktionsweise von DHCP.

Das Verhalten ist nicht UTM-spezifisch, sondern ein DHCP-konformes "normales" Verhalten.

DHCP funktioniert wie gesagt nicht so wie es sich viele Leute vorstellen,
es gibt spezielle Situationen, die berücksichtigt werden müssen.

Gruß, Datax

Ihr könnt diese Aussagen zu den Reservierungen belegen? Vielleicht gibt es ja eine RFC, die das Thema Reservierung genauso definiert, wie es in der UTM von statten geht ...

Gut, vielleicht ist es kein Bug sondern ein Feature, aber dann ist es definitiv mindestens irreführend, verstößt gegen die RFC und sollte schleunigst korrigiert werden.