7
fehlerhafte DHCP-Adressvergabe durch Windows 2008
DHCP-Server von Windows 2008 mit mehreren Bereichen (IP-Adressbereichen) und fehlerhafte IP-Adressvergabe beim Wechsel zwischen den Bereichen, z.B. mit einem Notebook
Hallo an alle,
ich hoffe, ihr könnt mir bei einem Problem weiterhelfen, das ich aktuell lösen muss.
Wir haben einem Kunden mit verteilten Standorten. Diese Struktur ist sternförmig ausgelegt. Mehrere Standorte mit jeweils eigenem IP-Adressbereich greifen über Site-to-Site-VPN-Tunnel (IPSec) auf die Zentrale zu. Der Admin hat seinen Standort in der Zentrale. Daher war es Ziel, möglichst alle Dienste (grundlegende Netzwerkdienste wie ADS, DNS, DHCP sowie Datei- und Druckdienst, Citrix-Farm, usw.) in der Zentrale zu konzentrieren. Das Projekt ist (fast) durch und die Anwender arbeiten in der neuen Umgebung.
Ein Problem haben wir mit dem zentralen DHCP-Server (Windows Server 2008). Dieser versorgt über die verschiedenen VPN-Tunnel die Standorte. Pro Standort, also pro IP-Adressbereich, wurde ein DHCP-Bereich eingerichtet. Entsprechend wurde in den VPN-Routern die DHCP Relay Agent-Funktion aktiviert. Auch das klappt soweit. Problematisch wird es nur, wenn ein Anwender z.B. mit seinem Notebook erst an Standort A arbeitet und kurz darauf, d.h. innerhalb weniger Stunden, zu Standort B wechselt und dort weiterarbeitet. Denn wenn er sich am Standort B wieder ans Netzwerk ansteckt und das Notebook eine IP-Adresse anfordert, erhält er trotzdem eine IP-Adresse, die eigentlich zum Standort A gehört.
Der DHCP-Server berücksichtigt also nicht, dass sich der anfragende DHCP-Client von Standort A nach Standort B bewegt hat und daher der DHCP-Request aus einem anderen IP-Adressbereich kommt. Ich vermute, dass der Windows-DHCP-Server - solange ein DHCP-Lease einmal gültig ist - pro Client immer die diesem Lease zugeordnete IP-Adresse und die entsprechenden Optionen vergibt.
Tritt dieses Verhalten einmal ein, ist dieser Missstand ohne Eingriff des Admins nicht zu beheben. Ein "ipconfig -renew" bzw. das "Reparieren der Netzwerkverbindung" ändert am Zustand nichts. Selbst das manuelle Löschen des Leases am DHCP-Server ist nicht ausreichend - bei der nächsten Kommunikation zwischen DHCP-Server und -Client wird die gemäß DHCP die vom Client vorgeschlagenen, aber falsche IP-Adresse vom DHCP-Server "abgenickt".
Manchmal genügt es, den Lease am DHCP-Server manuell zu löschen und anschließend das Netzwerkkabel am Client an- und abzustecken. Immer klappt das aber auch nicht. Zuverlässig funktioniert nur, den Lease am DHCP-Server manuell zu löschen und anschließend den Client durchzustarten...
Die Lease-Dauer zu verkürzen bringt ebenfalls nicht immer den gewünschten Erfolgt: Obwohl der Lease abgelaufen ist (derzeit 8 h), erhält der Client (manchmal) weiterhin eine einmal vergebene IP-Adresse - wieder ohne des aktuellen Standorts. Das selbe Problem zeigte sich auch mit dem DHCP-Server von Windows 2003. Auch mit den VPN-Tunnel bzw. DHCP Relay Agents scheint es nichts zu tun zu haben. Wir haben das Problem auch im LAN und mit VPN-Routern eines anderen Herstellers reproduzieren können
Ist euch dieses Problem bekannt? Wie kann man dem DHCP-Server dies geschilderte Verhalten austreiben oder machen gar wir etwas falsch???
Viele Grüße!
Hallo an alle,
ich hoffe, ihr könnt mir bei einem Problem weiterhelfen, das ich aktuell lösen muss.
Wir haben einem Kunden mit verteilten Standorten. Diese Struktur ist sternförmig ausgelegt. Mehrere Standorte mit jeweils eigenem IP-Adressbereich greifen über Site-to-Site-VPN-Tunnel (IPSec) auf die Zentrale zu. Der Admin hat seinen Standort in der Zentrale. Daher war es Ziel, möglichst alle Dienste (grundlegende Netzwerkdienste wie ADS, DNS, DHCP sowie Datei- und Druckdienst, Citrix-Farm, usw.) in der Zentrale zu konzentrieren. Das Projekt ist (fast) durch und die Anwender arbeiten in der neuen Umgebung.
Ein Problem haben wir mit dem zentralen DHCP-Server (Windows Server 2008). Dieser versorgt über die verschiedenen VPN-Tunnel die Standorte. Pro Standort, also pro IP-Adressbereich, wurde ein DHCP-Bereich eingerichtet. Entsprechend wurde in den VPN-Routern die DHCP Relay Agent-Funktion aktiviert. Auch das klappt soweit. Problematisch wird es nur, wenn ein Anwender z.B. mit seinem Notebook erst an Standort A arbeitet und kurz darauf, d.h. innerhalb weniger Stunden, zu Standort B wechselt und dort weiterarbeitet. Denn wenn er sich am Standort B wieder ans Netzwerk ansteckt und das Notebook eine IP-Adresse anfordert, erhält er trotzdem eine IP-Adresse, die eigentlich zum Standort A gehört.
Der DHCP-Server berücksichtigt also nicht, dass sich der anfragende DHCP-Client von Standort A nach Standort B bewegt hat und daher der DHCP-Request aus einem anderen IP-Adressbereich kommt. Ich vermute, dass der Windows-DHCP-Server - solange ein DHCP-Lease einmal gültig ist - pro Client immer die diesem Lease zugeordnete IP-Adresse und die entsprechenden Optionen vergibt.
Tritt dieses Verhalten einmal ein, ist dieser Missstand ohne Eingriff des Admins nicht zu beheben. Ein "ipconfig -renew" bzw. das "Reparieren der Netzwerkverbindung" ändert am Zustand nichts. Selbst das manuelle Löschen des Leases am DHCP-Server ist nicht ausreichend - bei der nächsten Kommunikation zwischen DHCP-Server und -Client wird die gemäß DHCP die vom Client vorgeschlagenen, aber falsche IP-Adresse vom DHCP-Server "abgenickt".
Manchmal genügt es, den Lease am DHCP-Server manuell zu löschen und anschließend das Netzwerkkabel am Client an- und abzustecken. Immer klappt das aber auch nicht. Zuverlässig funktioniert nur, den Lease am DHCP-Server manuell zu löschen und anschließend den Client durchzustarten...
Die Lease-Dauer zu verkürzen bringt ebenfalls nicht immer den gewünschten Erfolgt: Obwohl der Lease abgelaufen ist (derzeit 8 h), erhält der Client (manchmal) weiterhin eine einmal vergebene IP-Adresse - wieder ohne des aktuellen Standorts. Das selbe Problem zeigte sich auch mit dem DHCP-Server von Windows 2003. Auch mit den VPN-Tunnel bzw. DHCP Relay Agents scheint es nichts zu tun zu haben. Wir haben das Problem auch im LAN und mit VPN-Routern eines anderen Herstellers reproduzieren können
Ist euch dieses Problem bekannt? Wie kann man dem DHCP-Server dies geschilderte Verhalten austreiben oder machen gar wir etwas falsch???
Viele Grüße!
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: 126274
Url: https://administrator.de/contentid/126274
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
7 Kommentare
Neuester Kommentar
"Das Problem ist uns bekannt, wir arbeiten daran"...kennt man aus der Supportabteilung eines anderen Unternehmens ;) Die Problematik ist allgemein bekannt, die einzige Lösungsvariante, die mir bisher bekannt ist, ist, die Leasetime soweit wie vertretbar herunter zu setzen..mit 4 Stunden ist man da auf der recht sicheren Seite. Die andere Möglichkeit, die preferiert wird, ist, an jedem Standort einen eigenen DHCP zu stellen der eigenverantwortlich verteilt, dann hat man die Probleme nicht. Ich denke aber, daß dies nicht gewünscht wird...bleibt also nur das Lease heruntersetzen.
Alternativ ginge es nur noch, da ihr ja in einer Domäne seid, jedem dieser beweglichen Clients ein Startskript zu verpassen, was schon beim hochfahren jedesmal ein /Release /renew durchführt. ..zur Not auch per Autoexec. Das /release ist dabei das wirklich wichtige, damit wird dem Server gesagt, daß er den Lease freigeben darf...was er dann auch gehorsam tut. Müsste man nur noch das "Warten aufs Netzwerk" in den GPOs konfigurieren.
Man könnte auch ein Abmeldeskript verpassen, in dem einfach nur ein /release durchgeführt wird...welche der beiden Varianten besser funktioniert, müsste man testen, ich persönlich würde die zweite Variante bevorzugen.
Alternativ ginge es nur noch, da ihr ja in einer Domäne seid, jedem dieser beweglichen Clients ein Startskript zu verpassen, was schon beim hochfahren jedesmal ein /Release /renew durchführt. ..zur Not auch per Autoexec. Das /release ist dabei das wirklich wichtige, damit wird dem Server gesagt, daß er den Lease freigeben darf...was er dann auch gehorsam tut. Müsste man nur noch das "Warten aufs Netzwerk" in den GPOs konfigurieren.
Man könnte auch ein Abmeldeskript verpassen, in dem einfach nur ein /release durchgeführt wird...welche der beiden Varianten besser funktioniert, müsste man testen, ich persönlich würde die zweite Variante bevorzugen.
Hast Du denn auf Deinen DHCP-Servern jeweils den Bereich der anderen DHCP (also die der anderen Standorte) ausgeschlossen?
Zitat von @KowaKowalski:
Hast Du denn auf Deinen DHCP-Servern jeweils den Bereich der anderen
DHCP (also die der anderen Standorte) ausgeschlossen?
Hast Du denn auf Deinen DHCP-Servern jeweils den Bereich der anderen
DHCP (also die der anderen Standorte) ausgeschlossen?
Es ist nur ein einziger zentraler Server, es war keine Rede von mehreren Servern, nur von Relay Agents...ansonsten habe ich den Text falsch gelesen^^
Servus,
da du in deiner letzten Zeile so freundlich drauf ansprichst...
ganz ehrlich - das ist keine fehlerhafte Vergabe seitens des DHCP Servers, sondern ein Fehler im System.
Den DHCP Dienst kann man heutzutage doch wirklich überall laufen lassen (wenn das zugehörige Gerät 24/7 in Betrieb ist)
Per MMC auf einen Server zuzugreifen, der in einem anderen Standort steht - was ist daran so schlimm für den Admin?
"Einfacher" richtig gemacht, als in dem oben beschriebenen Fall, mit Lease löschen bla bla...
Btw: ein "echter" Standort hat üblicherweise einen eigenen DC vor Ort.
Macht es richtig
gruß
da du in deiner letzten Zeile so freundlich drauf ansprichst...
"Das Problem ist uns bekannt, wir arbeiten daran"...
ganz ehrlich - das ist keine fehlerhafte Vergabe seitens des DHCP Servers, sondern ein Fehler im System.
Den DHCP Dienst kann man heutzutage doch wirklich überall laufen lassen (wenn das zugehörige Gerät 24/7 in Betrieb ist)
Per MMC auf einen Server zuzugreifen, der in einem anderen Standort steht - was ist daran so schlimm für den Admin?
"Einfacher" richtig gemacht, als in dem oben beschriebenen Fall, mit Lease löschen bla bla...
Btw: ein "echter" Standort hat üblicherweise einen eigenen DC vor Ort.
Macht es richtig
gruß
Hallo an meine fleißigen Helfer,
@KowaKowalski
Soweit ich weiß, müssen "ausgeschlossene Bereiche" innerhalb des vom DHCP-Server zu bedienenden IP-Adressbereiches liegen.
@timobeil
Ziel war es eben nicht, in jeden Standort einen eigenen Server zu stellen! Denn auch wenn ich via Fernwartung bequem den Server verwalten kann, müssen entsprechende Server gekauft werden, die Server müssen gepflegt, gesichert usw. werden. Zudem ist es bei diesem Kunden nicht notwendig, da a) an den meisten Standort nur um die fünf Benutzer arbeiten und b) der die allermeisten Benutzer in Citrix arbeiten und die Arbeitstationen nur den Citrix-Client ausführen.
Zudem wird meiner Ansicht nach vom (Windows-)DHCP-Server keine besondere Eigenschaft verlangt, sondern nur, dass funktioniert, was laut Hersteller funktionieren soll!
Viele Grüße!
@KowaKowalski
Soweit ich weiß, müssen "ausgeschlossene Bereiche" innerhalb des vom DHCP-Server zu bedienenden IP-Adressbereiches liegen.
@timobeil
Ziel war es eben nicht, in jeden Standort einen eigenen Server zu stellen! Denn auch wenn ich via Fernwartung bequem den Server verwalten kann, müssen entsprechende Server gekauft werden, die Server müssen gepflegt, gesichert usw. werden. Zudem ist es bei diesem Kunden nicht notwendig, da a) an den meisten Standort nur um die fünf Benutzer arbeiten und b) der die allermeisten Benutzer in Citrix arbeiten und die Arbeitstationen nur den Citrix-Client ausführen.
Zudem wird meiner Ansicht nach vom (Windows-)DHCP-Server keine besondere Eigenschaft verlangt, sondern nur, dass funktioniert, was laut Hersteller funktionieren soll!
Viele Grüße!
zurück,
Zudem wird meiner Ansicht nach vom (Windows-)DHCP-Server keine besondere Eigenschaft verlangt, sondern nur, dass
funktioniert, was laut Hersteller funktionieren soll!
funktioniert, was laut Hersteller funktionieren soll!
Kannst du mich mal näher aufklären, ich lern ja immer gerne dazu
Wo "genau" steht das denn?
nicht das mit den besonderen Eigenschaften", das funktionieren - wenn der Client innerhalb der Lease Zeit am gleichen DHCP in einem anderen Standort eine andere IP aus einem anderen Range bekommen soll...
Viele Grüße!
zurück
btw: auch ich bin Admin von mehreren Standorten und auch da wird Citrix eingesetzt und es gibt auch Standorte mit 5 Peoples...
Heutzutage "vergessen" die meisten, das eine Standleitung nicht immer stehen muß - Ich grüße an dieser Stelle die Baggerfahrer
Hallo,
@timobeil
Auszug aus einem Technet-Artikel Link:
...Ein DHCP-Server mit eingerichteter Bereichsgruppierung kann folgende Funktionen ausführen:
...
Nichtlokale Unterstützung für DHCP-Clients über remote installierte DHCP- und BOOTP-Relay-Agents (wobei das Netzwerk des betreffenden Relay-Agents Multinets verwendet).
...
Soweit klappt das ja: initial erhält ein DHCP-Client eine IP-Adresse genau für den IP-Adressbereich, indem er sich befindet. Nur das "Roaming", z.B. mit einem Notebook" klappt eben nicht!
Viele Grüße!
@timobeil
Auszug aus einem Technet-Artikel Link:
...Ein DHCP-Server mit eingerichteter Bereichsgruppierung kann folgende Funktionen ausführen:
...
Nichtlokale Unterstützung für DHCP-Clients über remote installierte DHCP- und BOOTP-Relay-Agents (wobei das Netzwerk des betreffenden Relay-Agents Multinets verwendet).
...
Soweit klappt das ja: initial erhält ein DHCP-Client eine IP-Adresse genau für den IP-Adressbereich, indem er sich befindet. Nur das "Roaming", z.B. mit einem Notebook" klappt eben nicht!
Viele Grüße!
