Domäne hinzufügen: 0x0000232A RCODE SERVER FAILURE DCDIAG Keine LDAP-Konnektivität Wireguard
Hallo Experten,
ich schaffe es nicht einen Win11 PC über eine bestehende Wireguard-Verbindung an einem Windows Server 2019 - Domänen-Controller anzumelden mit dem Domänenname "sr.intra".
Der Win11-PC hat eine lokale IP von 10.14.0.49, und der Wireguard-Adapter 192.168.139.242.
Der Server 192.168.139.5. Die Wireguard-Gegenstelle ist eine Fritzbox 6660 mit der lokalen IP 192.168.139.1.
Die Wireguard-Verbindung und der Ping auf den Server sowie SMB-Netzlaufwerke etc. funktionieren tadellos.
Wireguard-Einstellung:
Wireguard läuft:
ipconfig /all auf dem Win11-PC:
Ping und nslookup sehen gut aus:
Wenn ich nun versuche den Win11-PC anzumelden, klappt es aber nicht:
Danach kommt der Fehler:
Fehlertext:
Auf dem Server selbst scheint es ein Problem mit DCDIAG zu geben:
In _msdcs ist eine feste IP für den Server hinterlegt:
Auch sonst müsste es passen:
ipconfig /all auf dem Server:
Bin ich auf der richtigen Spur mit dem DCDIAG und "Keine LDAP-Konnektivität"?
Im lokalen Netzwerk läuft die Domänenanmeldung, auch wenn ich es gerade mit diesem Win11-PC nicht testen kann (alle anderen PCs funktionieren dort). Muss speziell für Wireguard oder VPN die DNS-Einstellung korrekt sein, was lokal weniger wichtig ist?
Oder könnte noch etwas am Wireguard, den unterschiedlichen Subnetzen oder dem Win11-PC sein?
Es wäre sehr nett, wenn mir jemand helfen könnte. Gerne liefere ich weitere Infos und teste etwas, wenn Jemand eine Idee hat.
Danke schonmal!
ich schaffe es nicht einen Win11 PC über eine bestehende Wireguard-Verbindung an einem Windows Server 2019 - Domänen-Controller anzumelden mit dem Domänenname "sr.intra".
Der Win11-PC hat eine lokale IP von 10.14.0.49, und der Wireguard-Adapter 192.168.139.242.
Der Server 192.168.139.5. Die Wireguard-Gegenstelle ist eine Fritzbox 6660 mit der lokalen IP 192.168.139.1.
Die Wireguard-Verbindung und der Ping auf den Server sowie SMB-Netzlaufwerke etc. funktionieren tadellos.
Wireguard-Einstellung:
Wireguard läuft:
ipconfig /all auf dem Win11-PC:
C:\Users\Test1>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : DRL-Test1
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : sr.intra
fritz.box
Unbekannter Adapter dr_wg_20230709:
Verbindungsspezifisches DNS-Suffix: sr.intra
Beschreibung. . . . . . . . . . . : WireGuard Tunnel
Physische Adresse . . . . . . . . :
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.139.242(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 0.0.0.0
DNS-Server . . . . . . . . . . . : 192.168.139.5
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
sr.intra
fritz.box
Drahtlos-LAN-Adapter WLAN 2:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : TP-Link Wireless Nano USB Adapter
Physische Adresse . . . . . . . . : D0-37-45-EB-28-B8
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 10.14.0.49(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Lease erhalten. . . . . . . . . . : Montag, 24. Juli 2023 07:02:11
Lease läuft ab. . . . . . . . . . : Dienstag, 25. Juli 2023 07:02:14
Standardgateway . . . . . . . . . : 10.14.0.1
DHCP-Server . . . . . . . . . . . : 10.10.2.6
DNS-Server . . . . . . . . . . . : 208.67.222.222
208.67.220.220
NetBIOS über TCP/IP . . . . . . . : Aktiviert
C:\Users\Test1>
Ping und nslookup sehen gut aus:
C:\Users\Test1>ping server
Ping wird ausgeführt für server.sr.intra [192.168.139.5] mit 32 Bytes Daten:
Antwort von 192.168.139.5: Bytes=32 Zeit=31ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=28ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=33ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=23ms TTL=127
Ping-Statistik für 192.168.139.5:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 23ms, Maximum = 33ms, Mittelwert = 28ms
C:\Users\Test1>nslookup sr.intra
Server: server.sr.intra
Address: 192.168.139.5
Name: sr.intra
Addresses: 2a02:8070:99b0:3300:6809:d0e1:9843:1b4
192.168.139.5
C:\Users\Test1>nslookup server.sr.intra.
Server: server.sr.intra
Address: 192.168.139.5
Name: server.sr.intra
Address: 192.168.139.5
C:\Users\Test1>nslookup server
Server: server.sr.intra
Address: 192.168.139.5
*** server wurde von server.sr.intra nicht gefunden: Server failed.
Wenn ich nun versuche den Win11-PC anzumelden, klappt es aber nicht:
Danach kommt der Fehler:
Fehlertext:
Hinweis: Diese Informationen sind für einen Netzwerkadministrator bestimmt. Wenden Sie sich an den Netzwerkadministrator, wenn Sie kein Netzwerkadministrator sind, und leiten Sie die Informationen in der Datei C:\Windows\debug\dcdiag.txt weiter.
Der folgende Fehler ist beim Abfragen von DNS über den Ressourceneintrag der Dienstidentifizierung (SRV) aufgetreten, der zur Suche eines Active Directory-Domänencontrollers (AD DC) für die Domäne "sr.intra" verwendet wird:
Fehler: "DNS-Serverfehler."
(Fehlercode 0x0000232A RCODE_SERVER_FAILURE)
Es handelt sich um die Abfrage des Dienstidentifizierungseintrags (SRV) für _ldap._tcp.dc._msdcs.sr.intra.
Die häufigsten Ursachen dieses Fehlers sind:
- Die von dem Computer verwendeten DNS-Server enthalten falsche Stammhinweise. Der Computer wurde zur Verwendung der folgenden IP-Adressen konfiguriert:
208.67.220.220
208.67.222.222
192.168.139.5
- Mindestens eine der folgenden Zonen enthalten eine falsche Delegierung:
sr.intra
intra
. (die Stammzone)
Auf dem Server selbst scheint es ein Problem mit DCDIAG zu geben:
C:\Users\remote>dcdiag /test:dns
Verzeichnisserverdiagnose
Anfangssetup wird ausgeführt:
Der Homeserver wird gesucht...
Homeserver = server
* Identifizierte AD-Gesamtstruktur.
Sammeln der Ausgangsinformationen abgeschlossen.
Erforderliche Anfangstests werden ausgeführt.
Server wird getestet: Default-First-Site-Name\SERVER
Starting test: Connectivity
Bei der DNS-Hostsuche ist ein Fehler aufgetreten, der in der Regel temporärer Natur ist. Wiederholen Sie den
Vorgang zu einem späteren Zeitpunkt.
Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie die Firewalleinstellungen.
......................... Der Test Connectivity für SERVER ist fehlgeschlagen.
Primärtests werden ausgeführt.
Server wird getestet: Default-First-Site-Name\SERVER
Starting test: DNS
DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige Minuten...
......................... Der Test DNS für SERVER ist fehlgeschlagen.
Partitionstests werden ausgeführt auf: ForestDnsZones
Partitionstests werden ausgeführt auf: DomainDnsZones
Partitionstests werden ausgeführt auf: Schema
Partitionstests werden ausgeführt auf: Configuration
Partitionstests werden ausgeführt auf: sr
Unternehmenstests werden ausgeführt auf: sr.intra
Starting test: DNS
Testergebnisse für Domänencontroller:
Domänencontroller: server.sr.intra
Domäne: sr.intra
TEST: Basic (Basc)
Fehler: Keine LDAP-Konnektivität
Für diesen Domänencontroller wurden keine Hosteinträge (A oder AAAA) gefunden.
Warning: no DNS RPC connectivity (error or non Microsoft DNS server is running)
Zusammenfassung der DNS-Testergebnisse:
Auth. Bas. Weiterl. Entf. Dyn. RReg. Erw.
_________________________________________________________________
Domäne: sr.intra
server PASS FAIL n/a n/a n/a n/a n/a
......................... Der Test DNS für sr.intra ist fehlgeschlagen.
In _msdcs ist eine feste IP für den Server hinterlegt:
Auch sonst müsste es passen:
ipconfig /all auf dem Server:
C:\Users\remote>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : server
Primäres DNS-Suffix . . . . . . . : sr.intra
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : sr.intra
Ethernet-Adapter Ethernet0:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physische Adresse . . . . . . . . : 00-0C-29-D4-60-4D
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.139.5(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.139.1
DNS-Server . . . . . . . . . . . : 192.168.139.5
NetBIOS über TCP/IP . . . . . . . : Aktiviert
C:\Users\remote>
Bin ich auf der richtigen Spur mit dem DCDIAG und "Keine LDAP-Konnektivität"?
Im lokalen Netzwerk läuft die Domänenanmeldung, auch wenn ich es gerade mit diesem Win11-PC nicht testen kann (alle anderen PCs funktionieren dort). Muss speziell für Wireguard oder VPN die DNS-Einstellung korrekt sein, was lokal weniger wichtig ist?
Oder könnte noch etwas am Wireguard, den unterschiedlichen Subnetzen oder dem Win11-PC sein?
Es wäre sehr nett, wenn mir jemand helfen könnte. Gerne liefere ich weitere Infos und teste etwas, wenn Jemand eine Idee hat.
Danke schonmal!
Please also mark the comments that contributed to the solution of the article
Content-ID: 7936978383
Url: https://administrator.de/contentid/7936978383
Printed on: November 5, 2024 at 07:11 o'clock
18 Comments
Latest comment
Moin,
wie eigentlich fast immer ist das DNS falsch eingestellt. Woher bekommt der PC seine IP? Bei dem DHCP-Server musst Du nachschauen. Das IPCONFIG liefert für Deinen Win11-PC
Und im Fehlertext taucht zwar der wahrscheinlich richtige auf. Davor stehen aber noch die beiden öffentlichen.
Die wird Windows erstmal fragen und die Antwort "Domain not found" erhalten.
Das sind mit ziemlicher Sicherheit nicht Deine DNS-Server. Außerdem würde ich das Suffix fritz.box noch entfernen. Das stört auch nur. Gib dem Win11 als einzige DNS-Server die der Domain und dann klappt das auch.
hth
Erik
P.S.: Endlich mal einer, der gleich alle Infos liefert, die notwendig sind.
wie eigentlich fast immer ist das DNS falsch eingestellt. Woher bekommt der PC seine IP? Bei dem DHCP-Server musst Du nachschauen. Das IPCONFIG liefert für Deinen Win11-PC
DNS-Server . . . . . . . . . . . : 208.67.222.222
208.67.220.220
Und im Fehlertext taucht zwar der wahrscheinlich richtige auf. Davor stehen aber noch die beiden öffentlichen.
- Die von dem Computer verwendeten DNS-Server enthalten falsche Stammhinweise. Der Computer wurde zur Verwendung der folgenden IP-Adressen konfiguriert:
208.67.220.220
208.67.222.222
192.168.139.5
Die wird Windows erstmal fragen und die Antwort "Domain not found" erhalten.
Das sind mit ziemlicher Sicherheit nicht Deine DNS-Server. Außerdem würde ich das Suffix fritz.box noch entfernen. Das stört auch nur. Gib dem Win11 als einzige DNS-Server die der Domain und dann klappt das auch.
hth
Erik
P.S.: Endlich mal einer, der gleich alle Infos liefert, die notwendig sind.
Moin,
ok. Verstehe.
Erstmal: Du guckst im DNS-Server an der falschen Stelle. Auf der Ebenen sr.intra muss ein A-Eintrag für "server" vorhanden sein mit der korrekten IP. Alle darunter liegenden Ebenen beziehen sich auf diesen.
Dann: Die Reihenfolge der verwendeten DNS-Server kannst Du in den Einstellungen für den Adapter ändern. Ich habe gerade kein Win11 zur Verfügung. Bei Win10 findet man das unter Einstellungen->Netzwerk->Ethernet->Adapteroptionen ändern, rechte Maustaste auf den Adapter->Eigenschaften->TCP/IPv4->Erweitert->DNS
Liebe Grüße
Erik
ok. Verstehe.
Erstmal: Du guckst im DNS-Server an der falschen Stelle. Auf der Ebenen sr.intra muss ein A-Eintrag für "server" vorhanden sein mit der korrekten IP. Alle darunter liegenden Ebenen beziehen sich auf diesen.
Dann: Die Reihenfolge der verwendeten DNS-Server kannst Du in den Einstellungen für den Adapter ändern. Ich habe gerade kein Win11 zur Verfügung. Bei Win10 findet man das unter Einstellungen->Netzwerk->Ethernet->Adapteroptionen ändern, rechte Maustaste auf den Adapter->Eigenschaften->TCP/IPv4->Erweitert->DNS
Liebe Grüße
Erik
wie eigentlich fast immer ist das DNS falsch eingestellt.
Leider und auch wie immer, ist wieder Gateway Redirect und Split Tunneling fälschlicherweise zugleich im VPN Client konfiguriert worden. Der übliche WG Anfängerfehler.... Merkzettel: VPN Installation mit Wireguard
Du hast im Setup oben auch wieder einen groben Fehler gemacht: "192.168.139.0/32" Ist natürlich ziemlicher Blödsinn, denn eine Hostsubnetzmaske mit 32 Bit kann ja niemals ein ganzes Netzwerk beschreiben und "0" als Hostadresse gibt es nicht. Das der Unsinn dann natürlich in die Hose geht weisst du sicher als Administrator auch selber.
Im Tutorial ist genau beschrieben wie die Hostadresseinträge auszusehen haben! Lesen hilft wirklich.
Wenn du Redirect machen willst ist das per se ja kein Fehler. Es reicht dann aber der Eintrag AllowedIPs = 0.0.0.0/0.
Der besagt ja dann das ALLES in den Tunnel geroutet werden soll. Da muss man dann nicht auch noch weitere separate Netze dazu eintragen, denn mit "ALLES" ist auch wirklich alles gemeint.
Bei einem Redirect muss man eben nur beachten das der Tunnel auch mit sämtlichem lokalen Traffic belastet wird. Wenn man nur remote relevanten Traffic dort haben will ist das ein deutlicher Performance Nachteil. Hängt aber immer vom persönlichen VPN Konzept ab was man damit erreichen will.
Im Tutorial ist genau beschrieben wie die Hostadresseinträge auszusehen haben! Lesen hilft wirklich.
Wenn du Redirect machen willst ist das per se ja kein Fehler. Es reicht dann aber der Eintrag AllowedIPs = 0.0.0.0/0.
Der besagt ja dann das ALLES in den Tunnel geroutet werden soll. Da muss man dann nicht auch noch weitere separate Netze dazu eintragen, denn mit "ALLES" ist auch wirklich alles gemeint.
Bei einem Redirect muss man eben nur beachten das der Tunnel auch mit sämtlichem lokalen Traffic belastet wird. Wenn man nur remote relevanten Traffic dort haben will ist das ein deutlicher Performance Nachteil. Hängt aber immer vom persönlichen VPN Konzept ab was man damit erreichen will.
Steht eigentlich alles im Tutorial! 😉
Merkzettel: VPN Installation mit Wireguard
Für Split Tunneling reicht es wenn man beim WG Client unter den Allowed IPs nur den Server mit einer Hostmaske und das remote Netzwerk einträgt.
Beim Server für die Client Peer dann vice versa. Client mit Hostmaske und sofern ein remotes Netz geroutet werden soll das remote Client LAN. Soll lediglich nur auf dem Server bzw. seinem lokalen netz gearbeitet werden wird nur die interne Client IP eingetragen.
Z.B so bei Server intern=.254/24 und lokalem LAN 172.16.1.0/24 und Client intern=.1/24 u. optional lokalem LAN 192.168.1.0/24:
Eigentlich ne ganz einfache Logik!
Merkzettel: VPN Installation mit Wireguard
Für Split Tunneling reicht es wenn man beim WG Client unter den Allowed IPs nur den Server mit einer Hostmaske und das remote Netzwerk einträgt.
Beim Server für die Client Peer dann vice versa. Client mit Hostmaske und sofern ein remotes Netz geroutet werden soll das remote Client LAN. Soll lediglich nur auf dem Server bzw. seinem lokalen netz gearbeitet werden wird nur die interne Client IP eingetragen.
Z.B so bei Server intern=.254/24 und lokalem LAN 172.16.1.0/24 und Client intern=.1/24 u. optional lokalem LAN 192.168.1.0/24:
Server (Peer für Client 1):
AllowedIPs: 100.64.64.1/32, 192.168.1.0/24
Client (Peer für Server):
AllowedIPs: 100.64.64.254/32, 172.16.1.0/24
Wie kann ich denn auf der Fritzbox die Server-Konfiguration frei ändern?
Das ist unmöglich, das lässt die AVM Konfiguration im Gegensatz zur "normalen" WG Konfig nicht zu. Auf der Serverseite hast du bei AVM keine Chance.AVM lässt lediglich nur eine angepasste Client Konfig zum Importieren zu wenn die FB als VPN Initiator arbeitet.
ungültig und falsch ist mit dem AllowedIPs = 0.0.0.0/0?
Nein, falsch ist das per se nicht. die 0.0.0.0/0 bewirkt nur das ALLER Traffic des Clients durch den Tunnel geht, was sehr ineffizient ist wenn man das nicht möchte. Logisch, denn so geht nicht nur der VPN relevante Traffic in den Tunnel, sondern z.B. auch wenn du lokal z.B. nur rumsurfst auf YouTube oder dir Emails abholst. Alles wird dann durch den VPN Tunnel gezwungen. Gut, wenn man damit leben kann ist das OK, ansonsten sollte man seine Client Konfig in den Allowed IPs etwas anpassen. eine offizielle Doku, oder zumindest eine offizielle Doku wie man AllowedIPs korrekt setzt?
Jepp, natürlich! Das findest du alles auf der Wireguard Hompepage im Kapitel Cryptokey routing! Redirect und Split Tunneling sind aber allgemein bekannte VPN Binsenweisheiten weil sie für alle VPNs gelten, ausnahmslos.Sagt ja einem schon der gesunde IT Verstand. Bei einem Redirect wo ja eh schon alles in den Tunnel geroutet wird wäre es ja völliger Quatsch dann noch einmal on Top Netzwerk spezifisch einzelnen Traffic in den Tunnel zu routen. Ebenso vice versa. Nachdenken hilft...
Etwas Lachen muss man auch bei dem Statement „...dann wäre unsere Konfig anders...“! Die ganze IT Welt weiss ja mittlerweile das die AVM WG Konfig „anders“ ist und nicht der entspricht wie Wireguard sie vorgibt. Heise hat das ja auch mehrfach in seinen c’t Artikeln zu der Thematik berichtet. Aber nundenn.... AVM halt. Es wäre aber auch vermessen bei einem Consumer Plasterouter eine andere Antwort zu erwarten. Hoch anrechnen muss man dem AVM Support das er überhaupt geantwortet hat. Im Consumer Billigbereich ist sowas bekanntlich nicht üblich.
Lies dir die Grundlagen des Cryptokey Routings durch dann weisst du warum.
https://www.wireguard.com/#cryptokey-routing
Speziell äußert sich das in einem Responder Szenario wenn die FB als WG Server arbeitet. Dort ist nur ein Bruchteil der Optionen möglich die Wireguard vorsieht. Das z.B. ein Responder auch gleichzeitig Client sein kann ist für klassische Wireguard Setups kein Problem, für die AVM Implementation durch die spezielle Implementierung technisch unmöglich. Die obige Diskussion um Redirect bzw. Split Tunneling spricht für sich.
https://www.wireguard.com/#cryptokey-routing
Speziell äußert sich das in einem Responder Szenario wenn die FB als WG Server arbeitet. Dort ist nur ein Bruchteil der Optionen möglich die Wireguard vorsieht. Das z.B. ein Responder auch gleichzeitig Client sein kann ist für klassische Wireguard Setups kein Problem, für die AVM Implementation durch die spezielle Implementierung technisch unmöglich. Die obige Diskussion um Redirect bzw. Split Tunneling spricht für sich.