6
Seltsames Verhalten - DHCP Server verteilt "fremde" IPs
eins vorweg: jetzt wird's seltsam, vielleicht muss man den Text 2x lesen um ihn zu verstehen ;)
Hallo liebe Kollegen,
Ich habe heute ein mir sehr seltsam vorkommendes Verhalten unseres Windows DHCP-Servers festgestellt und kann mir nicht wirklich erklären wie er dazu überhaupt in der Lage ist... vielleicht kann mir jemand auf die Sprünge helfen?
Unser DHCP-Server kann IPs in "fremden" Subnetzen verteilen obwohl er keinen Adapter in diesen Netzen hat.
Der Plan war eigentlich wie folgt: ich wollte, dass der DHCP-Server IPs aus einem neuen Subnetz per Bereichsrichtlinie verteilt, um so bestimmte Geräte (Telefone, alle mit gleicher Hersteller-MAC) in ein extra Netz zu packen. Also hab ich einen neuen DHCP-Bereich angelegt (außerhalb der IP-Reichweite des DHCP-Server) ich nenn es einfach mal 10.0.1.0/24 und aktiviert.
Der DHCP-Server selbst ist "nur" im Netz 10.0.0.0/24 (sagen wir er hat die IP 10.0.0.2) und kommt auch nicht per Gateway/Route in das Netz 10.0.1.0/24 (dachte bis heute, dass die DHCP Abfragen eigentlich über Broadcasts funktionieren und keine Routen benötigen, da die Clients ja vorher in keinem oder einem APIPA Netz sind, den DHCP-Server aber irgendwie erreichen), er war aber nicht in der Lage IP Leases für die Geräte die ins 10.0.1.0/24 sollten über Bereichsrichtlinien auszustellen.
Laut meinen Recherchen ist das wohl ein normales Verhalten, da der DHCP-Server doch (anders als von mir vermutet) eine IP in dem zu verteilenden Subnetz braucht (wenn das so ist, kann ich auch damit leben, dann kriegt er halt noch mehr Adapter), was jedoch Merkwürdig daran ist: sobald ich eine Reservierung in dem Bereich 10.0.1.0/24 mache, dann kann er komischerweise die IPs verteilen (auch ohne einem Adapter in diesem Subnetz).
Ich wollte das in einem Testaufbau (mit VLAN abgekapseltes Spiel-Netzwerk auf einem Hyper-V-Server) nachstellen, jedoch verhalten sich da die DHCP-Server komplett anders! Die verteilen die IPs egal ob mit Reservierung, oder Richtlinie NUR, wenn der DHCP Server auch eine IP in dem Netz hat.
Hmm Okay.... 1:1 Unentschieden, also hab ich ein weiteren Versuchsaufbau in einer Citrix Hypervisor Umgebung gebaut. Auch hier werden die IPs nur verteilt, wenn der DHCP-Server eine IP in dem Subnetz hat.. nun stehts also 1:2 bzw. sogar 1:3 wenn man die allgemeinen Aussagen aus dem Netz mitzählt die sagen: der DHCP-Server BRAUCHT eine IP im zu verteilenden Subnetz.
Was ich jedoch absolut nicht verstehen kann ist, wie zum Teufel ist dann unser DHCP-Server in der Lage IPs über Reservierungen zu vergeben, obwohl er nicht in dem Netz ist (das macht ja auch Probleme, denn die Clients erreichen den DHCP-Server später sicher nicht mehr um den Lease zu erneuern etc. was sich durch einem Reboot der Telefone bemerkbar macht, wenn sie den Lease nicht verlängern können) und das Netz auch über keine(n) Route(r) erreicht.
Ich hab auch schon dem DHCP-Server das Gateway weggenommen und sogar die Firewall (Sophos XG) ausgeschalten, da ich vermutet hab, dass die vielleicht die DHCP-Requests weiter leitet, aber alles "ohne Erfolg"..
PS: Ich weiß auch nicht ob es für dieses Verhalten relevant ist, aber unser DHCP-Server ist gleichzeitig auch noch ein Hyper-V Server.
Kann mir bitte jemand erklären warum der DHCP die Reservierungen verteilen kann, aber die Bereichsrichtlinie jedoch ignoriert wird? Ich wills wirklich einfach nur verstehen..
Danke schonmal im Voraus!
Hallo liebe Kollegen,
Ich habe heute ein mir sehr seltsam vorkommendes Verhalten unseres Windows DHCP-Servers festgestellt und kann mir nicht wirklich erklären wie er dazu überhaupt in der Lage ist... vielleicht kann mir jemand auf die Sprünge helfen?
Unser DHCP-Server kann IPs in "fremden" Subnetzen verteilen obwohl er keinen Adapter in diesen Netzen hat.
Der Plan war eigentlich wie folgt: ich wollte, dass der DHCP-Server IPs aus einem neuen Subnetz per Bereichsrichtlinie verteilt, um so bestimmte Geräte (Telefone, alle mit gleicher Hersteller-MAC) in ein extra Netz zu packen. Also hab ich einen neuen DHCP-Bereich angelegt (außerhalb der IP-Reichweite des DHCP-Server) ich nenn es einfach mal 10.0.1.0/24 und aktiviert.
Der DHCP-Server selbst ist "nur" im Netz 10.0.0.0/24 (sagen wir er hat die IP 10.0.0.2) und kommt auch nicht per Gateway/Route in das Netz 10.0.1.0/24 (dachte bis heute, dass die DHCP Abfragen eigentlich über Broadcasts funktionieren und keine Routen benötigen, da die Clients ja vorher in keinem oder einem APIPA Netz sind, den DHCP-Server aber irgendwie erreichen), er war aber nicht in der Lage IP Leases für die Geräte die ins 10.0.1.0/24 sollten über Bereichsrichtlinien auszustellen.
Laut meinen Recherchen ist das wohl ein normales Verhalten, da der DHCP-Server doch (anders als von mir vermutet) eine IP in dem zu verteilenden Subnetz braucht (wenn das so ist, kann ich auch damit leben, dann kriegt er halt noch mehr Adapter), was jedoch Merkwürdig daran ist: sobald ich eine Reservierung in dem Bereich 10.0.1.0/24 mache, dann kann er komischerweise die IPs verteilen (auch ohne einem Adapter in diesem Subnetz).
Ich wollte das in einem Testaufbau (mit VLAN abgekapseltes Spiel-Netzwerk auf einem Hyper-V-Server) nachstellen, jedoch verhalten sich da die DHCP-Server komplett anders! Die verteilen die IPs egal ob mit Reservierung, oder Richtlinie NUR, wenn der DHCP Server auch eine IP in dem Netz hat.
Hmm Okay.... 1:1 Unentschieden, also hab ich ein weiteren Versuchsaufbau in einer Citrix Hypervisor Umgebung gebaut. Auch hier werden die IPs nur verteilt, wenn der DHCP-Server eine IP in dem Subnetz hat.. nun stehts also 1:2 bzw. sogar 1:3 wenn man die allgemeinen Aussagen aus dem Netz mitzählt die sagen: der DHCP-Server BRAUCHT eine IP im zu verteilenden Subnetz.
Was ich jedoch absolut nicht verstehen kann ist, wie zum Teufel ist dann unser DHCP-Server in der Lage IPs über Reservierungen zu vergeben, obwohl er nicht in dem Netz ist (das macht ja auch Probleme, denn die Clients erreichen den DHCP-Server später sicher nicht mehr um den Lease zu erneuern etc. was sich durch einem Reboot der Telefone bemerkbar macht, wenn sie den Lease nicht verlängern können) und das Netz auch über keine(n) Route(r) erreicht.
Ich hab auch schon dem DHCP-Server das Gateway weggenommen und sogar die Firewall (Sophos XG) ausgeschalten, da ich vermutet hab, dass die vielleicht die DHCP-Requests weiter leitet, aber alles "ohne Erfolg"..
PS: Ich weiß auch nicht ob es für dieses Verhalten relevant ist, aber unser DHCP-Server ist gleichzeitig auch noch ein Hyper-V Server.
Kann mir bitte jemand erklären warum der DHCP die Reservierungen verteilen kann, aber die Bereichsrichtlinie jedoch ignoriert wird? Ich wills wirklich einfach nur verstehen..
Danke schonmal im Voraus!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4422342930
Url: https://administrator.de/contentid/4422342930
Printed on: April 28, 2024 at 16:04 o'clock
6 Comments
Latest comment
Hi.
du schreibst zwar "keine Route", aber das klingt auch danach, das es einen Router gibt...
Router: DHCP Helper / DHCP Relay != Route
du schreibst zwar "keine Route", aber das klingt auch danach, das es einen Router gibt...
Router: DHCP Helper / DHCP Relay != Route
Grüß dich!
ja irgendwie klingt es danach, aber da ist wirklich keine Route im Spiel, die Reservierungen funktionieren ja sogar mit ausgeschalteter Firewall (also das Gateway, nicht die Windows Firewall ;) und entferntem Standardgateway auf dem DHCP-Server
Zudem hat die Firewall auch keine IP in dem 10.0.1.0/24 Netz und es gibt auch keinen DHCP Relay der in dieses Netz kommt, das macht mich ja so fertig
Die Telefone die per Reservierung irgendwie eine IP bekommen sind auch nicht vom DHCP-Server per Ping erreichbar, da ich denen kein Standardgateway als DHCP-Option übergeb. Der Bereich 10.0.1.0/24 hat wirklich nix außer dem IP-Verteilungsbereich (der trotz Bereichsrichtlinie nicht verteilt wird) und meinen Test-Reservierungen die wie von Geisterhand funktionieren obwohl das eigentlich nicht gehen sollte..
ja irgendwie klingt es danach, aber da ist wirklich keine Route im Spiel, die Reservierungen funktionieren ja sogar mit ausgeschalteter Firewall (also das Gateway, nicht die Windows Firewall ;) und entferntem Standardgateway auf dem DHCP-Server
Zudem hat die Firewall auch keine IP in dem 10.0.1.0/24 Netz und es gibt auch keinen DHCP Relay der in dieses Netz kommt, das macht mich ja so fertig
Die Telefone die per Reservierung irgendwie eine IP bekommen sind auch nicht vom DHCP-Server per Ping erreichbar, da ich denen kein Standardgateway als DHCP-Option übergeb. Der Bereich 10.0.1.0/24 hat wirklich nix außer dem IP-Verteilungsbereich (der trotz Bereichsrichtlinie nicht verteilt wird) und meinen Test-Reservierungen die wie von Geisterhand funktionieren obwohl das eigentlich nicht gehen sollte..
Hallo,
um das konkret abzugrenzen: du spricht von einem "Netz". Meinst du damit einen IP-Adressen-Kreis oder wirklich ein physikalisches oder virtuelles Netzwerksegment (sprich LAN/VLAN). Sollten sich die Telefone im selben (V)LAN wie die Clients befinden, beziehen sie anfangs per Broadcast eine IP. Diese soll ja deinen Wünschen zufolge aus einem anderen IP-Adressen-Kreis sein.
Zwei IP-Adressen-Kreise (also OSI-Layer 3) im selben Netzwerksegment (also Layer2) zu betreiben, ist kein guter Stil und sollte außer bei begründeten Fällen vermieden werden. Besser ist 1 (V)LAN <-> 1 IP-Kreis. Die DHCP-Verteilung kann dann über die von @MirkoKR genannten DHCP-Helper bedient werden.
Nur noch mal zu Klarstellung: Broadcasts laufen nur auf Layer2-Ebene und können gar nicht geroutet (Routing -> IP -> Layer3!) werden. Daher die DHCP-Helper auf Routern oder L3-fähigen Switches.
Gruß
TA
um das konkret abzugrenzen: du spricht von einem "Netz". Meinst du damit einen IP-Adressen-Kreis oder wirklich ein physikalisches oder virtuelles Netzwerksegment (sprich LAN/VLAN). Sollten sich die Telefone im selben (V)LAN wie die Clients befinden, beziehen sie anfangs per Broadcast eine IP. Diese soll ja deinen Wünschen zufolge aus einem anderen IP-Adressen-Kreis sein.
Zwei IP-Adressen-Kreise (also OSI-Layer 3) im selben Netzwerksegment (also Layer2) zu betreiben, ist kein guter Stil und sollte außer bei begründeten Fällen vermieden werden. Besser ist 1 (V)LAN <-> 1 IP-Kreis. Die DHCP-Verteilung kann dann über die von @MirkoKR genannten DHCP-Helper bedient werden.
dachte bis heute, dass die DHCP Abfragen eigentlich über Broadcasts funktionieren und keine Routen benötigen, da die Clients ja vorher in keinem oder einem APIPA Netz sind, den DHCP-Server aber irgendwie erreichen
Nur noch mal zu Klarstellung: Broadcasts laufen nur auf Layer2-Ebene und können gar nicht geroutet (Routing -> IP -> Layer3!) werden. Daher die DHCP-Helper auf Routern oder L3-fähigen Switches.
Gruß
TA
Moin,
also dass auf dem HyperV ein DHCP läuft… naja… normal gehört der woanders hin.
Schmeiß da oder am Client mal WireShark an, dann siehst du, was passiert.
Wichtig, wie von Kollegen oben genannt: mehrere IP-Netze immer nur in getrennten (V)LANs nutzen. Nur in kontrollierten Situationen, wenn man weiß, was man tut, davon abweichen.
Gruß
em-pie
also dass auf dem HyperV ein DHCP läuft… naja… normal gehört der woanders hin.
Schmeiß da oder am Client mal WireShark an, dann siehst du, was passiert.
Wichtig, wie von Kollegen oben genannt: mehrere IP-Netze immer nur in getrennten (V)LANs nutzen. Nur in kontrollierten Situationen, wenn man weiß, was man tut, davon abweichen.
Gruß
em-pie
1
Moin zusammen,
nach genauerer Betrachtung des DHCP-Servers und einer Gute-Nacht-Lektüre ala Microsoft Dokumentation hab ich den Grund für das Verhalten gefunden. Im DHCP-Server war ein Superscope/Bereichsgruppierung angelegt, in der sich die eigentlichen Subnetz Bereiche befanden. Durch diese Bereichsgruppierung kann man per Reservierung IPs vergeben ohne ein Bein in dem Subnetz zu haben.
Danke für die Anregung und Hinweise, auch die Trennung der Subnetze durch VLANs werde ich umsetzen.
nach genauerer Betrachtung des DHCP-Servers und einer Gute-Nacht-Lektüre ala Microsoft Dokumentation hab ich den Grund für das Verhalten gefunden. Im DHCP-Server war ein Superscope/Bereichsgruppierung angelegt, in der sich die eigentlichen Subnetz Bereiche befanden. Durch diese Bereichsgruppierung kann man per Reservierung IPs vergeben ohne ein Bein in dem Subnetz zu haben.
Danke für die Anregung und Hinweise, auch die Trennung der Subnetze durch VLANs werde ich umsetzen.
Ahhh… Superscopes… Teufelszeug.
Das hatte ich auch vor Jahren mal und völlig vergessen…
Das hatte ich auch vor Jahren mal und völlig vergessen…
