6
Server 2022 Freigabe nur noch über FQDN erreichbar - IPv6-Problem?
Moin zusammen! 
Ich habe mir hier ein Test-Netzwerk mit einem Windows-Server 2022 aufgebaut, in erster Linie, um Praxiserfahrung mit IPv6 in Windows-Domänenumgebungen zu sammeln. Das klappt im Grunde soweit auch schon ganz gut; der Server ist Domain Controller und verfügt über feste Adressen (IPv4 und IPv6). Zwei virtuelle Win10-Clients hängen dran.
Ferner habe ich auf dem DC einen DHCP-Server für IPv4 UND IPv6 eingerichtet. Letzteres möchte ich gerne mal ausprobieren, mir ist bewusst, dass DHCP auf Windows für IPv6 auch in Domänen-Netzwerken optional ist (so zumindest hier gelesen, bitte korrigiert mich, wenn ich Unsinn schreibe). Die IPv6-Seite soll in diesem Szenario nur der internen Kommunikation dienen, Internet spielt keine Rolle.
DHCP IPv6 wollte zunächst nicht recht klappen, denn es wurden zwar korrekt Adressen verteilt, die Systeme konnten sich aber im LAN nicht über IPv6 erreichen. HIER brachte mich jemand auf die richtige Spur, ich musste im Router noch ein Gateway setzen.
Ergebnis ist ein Netzwerk, in dem PINGs sowohl über IPv4 als auch IPv6 sauber hin- und hergehen.
ABER.
Seit ich die IPv6-Konfiguration (nach meiner Meinung) sauber eingerichtet habe, können die Clients plötzlich nicht mehr über den Kurznamen auf die Freigaben des Servers zugreifen. Also im Explorer \\SERVER und Enter führt zu "Auf \\SERVER konnte nicht zugegriffen werden" - Fehlercode 0x80004005.
Das verwirrt mich insofern, als dass ein PING auf SERVER direkt umgewandelt wird zu einem PING auf server.domain.local - und dort wiederum kommt die korrekte Adresse, entweder als IPv4 oder via -6 als IPv6, und auch eine korrekte Antwort.
Um alles noch schlimmer zu machen: SPORADISCH klappt der zugriff via \\SERVER dann plötzlich doch! Und klar, ich weiß, wonach sich das anhört - irgendwo ein Problem, ein Fehler, eine Unsauberheit. Aber ich komme partout nicht dahinter, wo diese liegen könnte! DNS & Co. sollten sauber konfiguriert sein, der Domänen-Suffix ist ebenfalls korrekt eingetragen. Nameserver wird per DHCP übergeben, und wie gesagt - die reine Adress-Auflösung funktioniert ja auch zuverlässig.
nslookup server
Server: SERVER.domain.local
Address: fd90:717f:13a9:7f7::1
Name: server.domain.local
Addresses: fd90:717f:13a9:7f7::1
192.168.1.1
tracert server
Routenverfolgung zu SERVER.domain.local [192.168.1.1]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms SERVER.domain.local [192.168.1.1]
tracert -6 server
Routenverfolgung zu server.domain.local [fd90:717f:13a9:7f7::1]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms fd90:717f:13a9:7f7::9
2 1 ms 1 ms <1 ms SERVER.domain.local [fd90:717f:13a9:7f7::1]
(fd90:717f:13a9:7f7::9 ist der Router).
ipconfig /all
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix: domain.local
Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter #2
Physische Adresse . . . . . . . . : 00-15-5D-01-02-02
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : fd90:717f:13a9:7f7:6334:78a1:5297:91fa(Bevorzugt)
Lease erhalten. . . . . . . . . . : Samstag, 29. Juni 2024 09:12:02
Lease läuft ab. . . . . . . . . . : Donnerstag, 11. Juli 2024 09:12:01
Verbindungslokale IPv6-Adresse . : fe80::5373:5ec4:e823:dfea%7(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.120(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.100
DHCPv6-IAID . . . . . . . . . . . : 251663709
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2A-A8-CB-E7-00-15-5D-01-07-04
DNS-Server . . . . . . . . . . . : fd90:717f:13a9:7f7::1
192.168.1.1
fd90:717f:13a9:7f7::1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
domain.local
intern
Wo ist der Knoten im Hirn, wo kann ich noch nachschauen? Ich komme leider momentan gedanklich echt nicht weiter. Oder ist das beim Server 2022 "by design", dass man nur noch FQDN nutzen soll, und die alternativen Auflösungen (wie läuft das - über WINS?) rausfliegen? Unter Server 2019 lief die obige Konstellation noch problemlos mit dem "kurzen" Freigabenamen, ich bin ja schon froh, dass ich 2022 vorher ausprobiert habe...
Bin für jeden gedanklichen Anstoß dankbar!
Ich habe mir hier ein Test-Netzwerk mit einem Windows-Server 2022 aufgebaut, in erster Linie, um Praxiserfahrung mit IPv6 in Windows-Domänenumgebungen zu sammeln. Das klappt im Grunde soweit auch schon ganz gut; der Server ist Domain Controller und verfügt über feste Adressen (IPv4 und IPv6). Zwei virtuelle Win10-Clients hängen dran.
Ferner habe ich auf dem DC einen DHCP-Server für IPv4 UND IPv6 eingerichtet. Letzteres möchte ich gerne mal ausprobieren, mir ist bewusst, dass DHCP auf Windows für IPv6 auch in Domänen-Netzwerken optional ist (so zumindest hier gelesen, bitte korrigiert mich, wenn ich Unsinn schreibe). Die IPv6-Seite soll in diesem Szenario nur der internen Kommunikation dienen, Internet spielt keine Rolle.
DHCP IPv6 wollte zunächst nicht recht klappen, denn es wurden zwar korrekt Adressen verteilt, die Systeme konnten sich aber im LAN nicht über IPv6 erreichen. HIER brachte mich jemand auf die richtige Spur, ich musste im Router noch ein Gateway setzen.
Ergebnis ist ein Netzwerk, in dem PINGs sowohl über IPv4 als auch IPv6 sauber hin- und hergehen.
ABER.
Seit ich die IPv6-Konfiguration (nach meiner Meinung) sauber eingerichtet habe, können die Clients plötzlich nicht mehr über den Kurznamen auf die Freigaben des Servers zugreifen. Also im Explorer \\SERVER und Enter führt zu "Auf \\SERVER konnte nicht zugegriffen werden" - Fehlercode 0x80004005.
Das verwirrt mich insofern, als dass ein PING auf SERVER direkt umgewandelt wird zu einem PING auf server.domain.local - und dort wiederum kommt die korrekte Adresse, entweder als IPv4 oder via -6 als IPv6, und auch eine korrekte Antwort.
Um alles noch schlimmer zu machen: SPORADISCH klappt der zugriff via \\SERVER dann plötzlich doch! Und klar, ich weiß, wonach sich das anhört - irgendwo ein Problem, ein Fehler, eine Unsauberheit. Aber ich komme partout nicht dahinter, wo diese liegen könnte! DNS & Co. sollten sauber konfiguriert sein, der Domänen-Suffix ist ebenfalls korrekt eingetragen. Nameserver wird per DHCP übergeben, und wie gesagt - die reine Adress-Auflösung funktioniert ja auch zuverlässig.
nslookup server
Server: SERVER.domain.local
Address: fd90:717f:13a9:7f7::1
Name: server.domain.local
Addresses: fd90:717f:13a9:7f7::1
192.168.1.1
tracert server
Routenverfolgung zu SERVER.domain.local [192.168.1.1]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms SERVER.domain.local [192.168.1.1]
tracert -6 server
Routenverfolgung zu server.domain.local [fd90:717f:13a9:7f7::1]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms fd90:717f:13a9:7f7::9
2 1 ms 1 ms <1 ms SERVER.domain.local [fd90:717f:13a9:7f7::1]
(fd90:717f:13a9:7f7::9 ist der Router).
ipconfig /all
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix: domain.local
Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter #2
Physische Adresse . . . . . . . . : 00-15-5D-01-02-02
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : fd90:717f:13a9:7f7:6334:78a1:5297:91fa(Bevorzugt)
Lease erhalten. . . . . . . . . . : Samstag, 29. Juni 2024 09:12:02
Lease läuft ab. . . . . . . . . . : Donnerstag, 11. Juli 2024 09:12:01
Verbindungslokale IPv6-Adresse . : fe80::5373:5ec4:e823:dfea%7(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.120(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.100
DHCPv6-IAID . . . . . . . . . . . : 251663709
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2A-A8-CB-E7-00-15-5D-01-07-04
DNS-Server . . . . . . . . . . . : fd90:717f:13a9:7f7::1
192.168.1.1
fd90:717f:13a9:7f7::1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
domain.local
intern
Wo ist der Knoten im Hirn, wo kann ich noch nachschauen? Ich komme leider momentan gedanklich echt nicht weiter. Oder ist das beim Server 2022 "by design", dass man nur noch FQDN nutzen soll, und die alternativen Auflösungen (wie läuft das - über WINS?) rausfliegen? Unter Server 2019 lief die obige Konstellation noch problemlos mit dem "kurzen" Freigabenamen, ich bin ja schon froh, dass ich 2022 vorher ausprobiert habe...
Bin für jeden gedanklichen Anstoß dankbar!
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: 8187650868
Url: https://administrator.de/contentid/8187650868
Printed on: July 1, 2024 at 13:07 o'clock
6 Comments
Latest comment
auf server.domain.local
Und wieder einmal der übliche DNS Fehler! Diese TLD ist bekanntlich TABU!! 
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
https://imatrix.at/schlechter-domain-name/
1
Morschen.
Die IP Adresse des Domain Controller hat die IP 192.168.1.120 und als DNS die 192.168.1.1.
Wer ist dann in deinem Konstrukt die 192.168.1.1?
Ist das eine ipconfig /all Ausgabe von einem der beiden Clients oder die des Servers?
Wenn es die Ausgabe des Servers ist, ist DNS nicht ganz richtig konfiguriert.
Der AD DNS sollte entweder sich selbst oder, wenn vorhanden, einen anderen AD DNS Server als primären DNS eingetragen haben.
Und du solltest (auch zum Test) keine AD Gesamtstruktur auf .local enden lassen.
Nimm doch einfach .ads oder .com oder, oder oder...
Kleiner Tipp, verwende Code Tags für die ipconfig Ausgabe.
Gruß
Marc
Die IP Adresse des Domain Controller hat die IP 192.168.1.120 und als DNS die 192.168.1.1.
Wer ist dann in deinem Konstrukt die 192.168.1.1?
Ist das eine ipconfig /all Ausgabe von einem der beiden Clients oder die des Servers?
Wenn es die Ausgabe des Servers ist, ist DNS nicht ganz richtig konfiguriert.
Der AD DNS sollte entweder sich selbst oder, wenn vorhanden, einen anderen AD DNS Server als primären DNS eingetragen haben.
Und du solltest (auch zum Test) keine AD Gesamtstruktur auf .local enden lassen.
Nimm doch einfach .ads oder .com oder, oder oder...
Kleiner Tipp, verwende Code Tags für die ipconfig Ausgabe.
Gruß
Marc
Jo, sorry, die Ausgabe stammt von Client - und ich sehe gerade, dass der zum Test noch eine feste IPv4 hatte... Beim 2. Client, der beide Adressen über DHCP holt, ist's aber das gleiche Spiel.
Die .local-Problematik ist bekannt, aber es handelt sich wie beschrieben um ein Testszenario... Da die Geräte nur innerhalb ihres gekapselten Hyper-V-Netzes kommunizieren, erwartete ich da keinen Kummer. Werde das aber zukünftig berücksichtigen und auch auf "Spielservern" eine andere TLD wählen.
Also: 192.168.1.120 ist der Client. 192.168.1.1 der Domain-Controller. ipconfig stammt vom Client - und ist somit (nach meiner Kenntnis) korrekt, oder? DNS-Server ist mit fd90:717f:13a9:7f7::1 und 192.168.1.1 jeweils der DC. Der DC hat sich selbst als DNS-Server eingetragen.
Router/Gateway ist 192.168.1.100 bzw. fd90:717f:13a9:7f7::9
Die .local-Problematik ist bekannt, aber es handelt sich wie beschrieben um ein Testszenario... Da die Geräte nur innerhalb ihres gekapselten Hyper-V-Netzes kommunizieren, erwartete ich da keinen Kummer. Werde das aber zukünftig berücksichtigen und auch auf "Spielservern" eine andere TLD wählen.
Also: 192.168.1.120 ist der Client. 192.168.1.1 der Domain-Controller. ipconfig stammt vom Client - und ist somit (nach meiner Kenntnis) korrekt, oder? DNS-Server ist mit fd90:717f:13a9:7f7::1 und 192.168.1.1 jeweils der DC. Der DC hat sich selbst als DNS-Server eingetragen.
Router/Gateway ist 192.168.1.100 bzw. fd90:717f:13a9:7f7::9
Dann ist die Konfiguration erstmal richtig.
Ein ipconfig /all des DC wäre auch nicht verkehrt zu wissen.
Auch die DHCP Optionen, welche du gewählt hast mal hier posten.
DFS wurde nicht verwendet, korrekt?
Gruß
Marc
Ein ipconfig /all des DC wäre auch nicht verkehrt zu wissen.
Auch die DHCP Optionen, welche du gewählt hast mal hier posten.
DFS wurde nicht verwendet, korrekt?
Gruß
Marc
Moin und vielen Dank für die Antwort!
DFS kommt nicht zum Einsatz.
Die DHCP-Optionen habe ich wie folgt gesetzt:
IPv4
003 Router = 192.168.1.100
006 DNS-Server = 192.168.1.1
015 DNS-Domänenname = domain.local
IPv6
00023 IPv6-Adressliste für DNS-Server... = fd90:717f:13a9:7f7::1
00024 Domänensuchliste = domain.local
ipconfig /all auf dem DC sieht wie folgt aus:
DFS kommt nicht zum Einsatz.
Die DHCP-Optionen habe ich wie folgt gesetzt:
IPv4
003 Router = 192.168.1.100
006 DNS-Server = 192.168.1.1
015 DNS-Domänenname = domain.local
IPv6
00023 IPv6-Adressliste für DNS-Server... = fd90:717f:13a9:7f7::1
00024 Domänensuchliste = domain.local
ipconfig /all auf dem DC sieht wie folgt aus:
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : SERVER
Primäres DNS-Suffix . . . . . . . : domain.local
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : domain.local
intern
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix: intern
Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter #2
Physische Adresse . . . . . . . . : 00-15-5D-01-02-00
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : fd90:717f:13a9:7f7::1(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::9238:4f40:bed2:9a7b%2(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : fd90:717f:13a9:7f7::9
192.168.1.100
DNS-Server . . . . . . . . . . . : fd90:717f:13a9:7f7::1
127.0.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
intern
Zitat von @AmigaOS:
Ferner habe ich auf dem DC einen DHCP-Server für IPv4 UND IPv6 eingerichtet. Letzteres möchte ich gerne mal ausprobieren, mir ist bewusst, dass DHCP auf Windows für IPv6 auch in Domänen-Netzwerken optional ist (so zumindest hier gelesen, bitte korrigiert mich, wenn ich Unsinn schreibe). Die IPv6-Seite soll in diesem Szenario nur der internen Kommunikation dienen, Internet spielt keine Rolle.
Ja, DHCPv6 ist für den IPv6 Betrieb in der Regel erst mal nicht erforderlich. Es würde eine Fehlerquelle weniger bedeuten.