DHCP-Server vergibt keine Adressen (IPv4)

m8ichael
Goto Top
Hallo zusammen,

irgendwie ist bei mir hier gerade gehörig der Wurm drin und ich überlege gerade, warum meine bisherigen Servermigrationen fast reibungslos geklappt haben.

Problem ist die Migration eines DHCP-Servers (von Server 2012 R2 nach 2019). Übliche Vorgehensweise:

  • DHCP-Rolle auf dem neuen Server installieren
  • DHCP-Einstellungen auf dem alten Server exportieren (netsh dhcp server export c:\dhcp.dat all)
  • DHCP-Einstellungen auf dem neuen Server importieren (netsh dhcp server import c:\dhcp.dat all)
  • DHCP-Server auf dem alten Server beenden/deinstallieren
  • DHCP-Server auf dem neuen Server neustarten und Autorisierung für neuen Server anpassen bzw. alten löschen.

Problem ist: Der neue Server verteilt keine IP-Adressen. Aktiviere ich parallel wieder den alten DHCP-Server, dann werden IP-Adressen vergeben. Der neue DHCP-Server läuft direkt auf einem DC und auch testweise mit dem Domänen-Admin-Account.

Habt ihr einen Tipp? Eigentlich schon x-mal so vorgegangen, aber aktuell geht es nicht... face-confused

Gruß

Michael

Content-Key: 2668697446

Url: https://administrator.de/contentid/2668697446

Ausgedruckt am: 09.08.2022 um 22:08 Uhr

Mitglied: Dani
Dani 02.05.2022 um 20:43:31 Uhr
Goto Top
Moin Michael,
stehen die Server und Clients im selben Subnetz? Nein, dann muss vermutlich die IP-Adresse auf dem DHCP-Helper noch angepasst werden. Je nachdem auf dem Router oder L3 Switch.


Gruß,
Dani
Mitglied: lcer00
lcer00 02.05.2022 um 21:14:06 Uhr
Goto Top
Hallo,

und hast Du den DHCP-Server im Active Directory authorisiert?

Grüße

lcer
Mitglied: m8ichael
m8ichael 03.05.2022 um 07:17:24 Uhr
Goto Top
Moin!

Zitat von @Dani:
stehen die Server und Clients im selben Subnetz?

Ja, beide Server (alt und neu) besitzen eine statische Adresse im Bereich 10.20.0.0/16 und sollen auch dort IP-Adressen vergeben:

dhcp_config

Adresse des neuen Servers:

ip_server

Zitat von @lcer00:
und hast Du den DHCP-Server im Active Directory authorisiert?

Ja, siehe Schritte oben. Im AD gibt es nun in der Konfiguration unter Services/NetServices zwei Einträge: DhcpRoot und den Eintrag vom neuen Server.

Gruß

Michael
Mitglied: Doskias
Doskias 03.05.2022 um 08:12:20 Uhr
Goto Top
Moin,

Hast du die Bindung denn einmal geprüft? Oder gibt es vielleicht mehrere Netzwerkkarten, so dass die Bindung nicht korrekt ist?

Gruß
Doskias
Mitglied: lcer00
lcer00 03.05.2022 um 08:40:50 Uhr
Goto Top
Hallo,

bevor es ans eingemachte geht - Schau noch mal nach, ob:
  • die Firewall UDP Port 67/68 durchläßt
  • die Clients überhaupt Leases wollen ....

Der Client wird zur Erneuerung eines ablaufenden Leases zunächst den alten DHCP per Unicast! kontaktieren. Nur wenn der nicht antwortet, fällt er dann in das DHCP Broadcast-Veralten zurück.

Wenn das alles stimmt, geht es weiter mit Wireshark auf dem Server.

Grüße

lcer
Mitglied: aqui
aqui 03.05.2022 um 09:10:03 Uhr
Goto Top
16er Prefixes zeugen ja nun auch nicht gerade von gutem IP Adressdesign....
Mitglied: m8ichael
m8ichael 03.05.2022 um 19:15:33 Uhr
Goto Top
Hallo!

Zitat von @aqui:
16er Prefixes zeugen ja nun auch nicht gerade von gutem IP Adressdesign....

Nun ja, was soll ich sagen: Mal wieder "historisch gewachsen". Bin ja schon froh, dass hier tatsächlich private Adressen zum Einsatz kommen. Auch das ist nicht selbstverständlich...aber ich schweife ab... face-wink


Zitat von @Doskias:
Hast du die Bindung denn einmal geprüft? Oder gibt es vielleicht mehrere Netzwerkkarten, so dass die Bindung nicht korrekt ist?

Ja, die Bindung habe ich auch überprüft; die korrekte Netzwerkschnittstelle ist ausgewählt.


Zitat von @lcer00:
bevor es ans eingemachte geht - Schau noch mal nach, ob:
  • die Firewall UDP Port 67/68 durchläßt

Laut der Firewalleinstellung ist dies der Fall

firewall

* die Clients überhaupt Leases wollen ....

Der Client wird zur Erneuerung eines ablaufenden Leases zunächst den alten DHCP per Unicast! kontaktieren. Nur wenn der nicht antwortet, fällt er dann in das DHCP Broadcast-Veralten zurück.

Jo, das hatte ich auch auf'n Zettel, aber dann müsste ja als Fallback auf jeden Fall der Server irgendwann ne Adresse ausspucken. Und das passiert eben nicht.

Wenn das alles stimmt, geht es weiter mit Wireshark auf dem Server.

Das ist dann das nächste Todo...

Viele Grüße

Michael
Mitglied: m8ichael
m8ichael 05.05.2022 um 14:52:50 Uhr
Goto Top
Hallo,

habe jetzt mal Wireshark bemüht. Offenbar kommen Pakete an, aber es erfolgt keine Antwort vom Server:


Was mir noch aufgefallen ist: Der alte/bisherige Server vergibt IP-Adressen unabhängig davon, ob er im AD autorisiert ist oder auch nicht. Nach meinem Verständnis dürfte er doch eigentlich nur bei einer Autorisierung etwas vergeben, oder?

Habe zwischenzeitlich den DHCP-Server noch einmal komplett deinstalliert und neu installiert - leider weiterhin ohne Erfolg. Hat noch jemand eine Idee? Liegt das ggf. am Zusammenspiel mit dem DNS-Server?

Viele Grüße

Michael
Mitglied: lcer00
lcer00 05.05.2022 um 15:18:43 Uhr
Goto Top
Hallo,

In dem Trace folgt sieht man 1) einen Request und dann 2) ein Discover. Das ist unvollständig. Kannst Du bitte mal alle DHCP-Nachrichten filtern und dann einen Screenshot posten?

Grüße

lcer
Mitglied: m8ichael
m8ichael 05.05.2022 um 16:39:24 Uhr
Goto Top
Hi,

Zitat von @lcer00:
In dem Trace folgt sieht man 1) einen Request und dann 2) ein Discover. Das ist unvollständig. Kannst Du bitte mal alle DHCP-Nachrichten filtern und dann einen Screenshot posten?

Jupp, das hat mich in der Tat auch gewundert, warum a) die Reihenfolge nicht passt und b) der Request ohne Offer gesendet wird. Mehr Logs (gefiltert auf BOOTP) waren allerdings nicht enthalten.

Ich habe das daher jetzt noch einmal mit einem anderen Client nachvollzogen (sowohl Client- wie auch Serverseite). Dort werden tatsächlich nur mehrere Discover-Pakete an Broadcast gesendet; diese kommen auch laut Wireshark am Server an, werden aber überhaupt nicht weiter beantwortet. Für mich wirkt das, als wäre der DHCP-Server überhaupt nicht autorisiert und verwirft daher die Pakete. Tatsächlich ist er aber ja autorisiert und auch im AD existieren die entsprechenden Einträge.

Gruß

Michael
Mitglied: aqui
Lösung aqui 05.05.2022 um 16:59:04 Uhr
Goto Top
BOOTP ist keine so gute Idee. Besser ist "udp port 68 or port 67" als Capture Filter zu nehmen. Das zeigt die gesamte DHCP Kommunikation.
De facto ist es aber der Server selber oder dessen lokale Firewall.
Mitglied: m8ichael
m8ichael 05.05.2022 um 17:23:06 Uhr
Goto Top
Zitat von @aqui:
De facto ist es aber der Server selber oder dessen lokale Firewall.

Juhu, das war's: Ich hatte zwar die eingehenden Firewalleinstellungen auf dem Schirm, nicht aber die ausgehenden, die gesperrt waren... *grhh*

Jetzt geht es! Danke!!