m8ichael
May 02, 2022
view3030
view12
0
Goto Top

DHCP-Server vergibt keine Adressen (IPv4)

GermansolvedQuestionWindows ServerMicrosoft
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
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 2668697446

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

Printed on: April 16, 2024 at 10:04 o'clock

12 Comments
Latest comment
Goto Top
Member: Dani
Dani May 02, 2022 at 18:43:31 (UTC)
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
Member: lcer00
lcer00 May 02, 2022 at 19:14:06 (UTC)
Goto Top
Hallo,

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

Grüße

lcer
Member: m8ichael
m8ichael May 03, 2022 at 05:17:24 (UTC)
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
Member: Doskias
Doskias May 03, 2022 at 06:12:20 (UTC)
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
Member: lcer00
lcer00 May 03, 2022 at 06:40:50 (UTC)
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
Member: aqui
aqui May 03, 2022 at 07:10:03 (UTC)
Goto Top
16er Prefixes zeugen ja nun auch nicht gerade von gutem IP Adressdesign....
heart1
Member: m8ichael
m8ichael May 03, 2022 at 17:15:33 (UTC)
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
Member: m8ichael
m8ichael May 05, 2022 at 12:52:50 (UTC)
Goto Top
Hallo,

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

Frame 801: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on interface \Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9}, id 0
    Interface id: 0 (\Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9})
    Encapsulation type: Ethernet (1)
    Arrival Time: May  5, 2022 14:41:04.376078000 Mitteleuropäische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1651754464.376078000 seconds
    [Time delta from previous captured frame: 0.062236000 seconds]
    [Time delta from previous displayed frame: 1.949274000 seconds]
    [Time since reference or first frame: 13.560678000 seconds]
    Frame Number: 801
    Frame Length: 346 bytes (2768 bits)
    Capture Length: 346 bytes (2768 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:dhcp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Dummy_xx:9f:a6 (xx:xx:xx:xx:9f:a6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Dummy_xx3:9f:a6 (xx:xx:xx:xx:9f:a6)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
    Total Length: 332
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment  
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x3992 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 0.0.0.0
    Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 312
    Checksum: 0x1c4a [unverified]
    [Checksum Status: Unverified]
    [Stream index: 6]
    [Timestamps]
    UDP payload (304 bytes)
Dynamic Host Configuration Protocol (Request)
[Community ID: 1:t9O1j0qj71O4wJM7gnaHtgmfev8=]

Frame 873: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9}, id 0
    Interface id: 0 (\Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9})
    Encapsulation type: Ethernet (1)
    Arrival Time: May  5, 2022 14:41:06.358532000 Mitteleuropäische Sommerzeit
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1651754466.358532000 seconds
    [Time delta from previous captured frame: 0.005867000 seconds]
    [Time delta from previous displayed frame: 1.982454000 seconds]
    [Time since reference or first frame: 15.543132000 seconds]
    Frame Number: 873
    Frame Length: 342 bytes (2736 bits)
    Capture Length: 342 bytes (2736 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:dhcp]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: Dummy_xx:9f:a6 (xx:xx:xx:xx:9f:a6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Dummy_xx:9f:a6 (xx:xx:xx:xx:9f:a6)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
    Total Length: 328
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment  
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x3996 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 0.0.0.0
    Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 308
    Checksum: 0xad88 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 6]
    [Timestamps]
    UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Discover)
[Community ID: 1:t9O1j0qj71O4wJM7gnaHtgmfev8=]

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
Member: lcer00
lcer00 May 05, 2022 at 13:18:43 (UTC)
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
Member: m8ichael
m8ichael May 05, 2022 at 14:39:24 (UTC)
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
Member: aqui
Solution aqui May 05, 2022 at 14:59:04 (UTC)
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.
Member: m8ichael
m8ichael May 05, 2022 at 15:23:06 (UTC)
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!!
GermansolvedQuestionWindows ServerMicrosoft