haukeha
Goto Top

Win Server 2019: DNS Probleme mit Clients im VLAN

Hallo,

ich habe in einem relativ kleinen Netzwerk als VM einen Win Server 2019 als DC, DHCP und DNS.

Ich habe im Netzwerk mehrere VLANs. Die VMs laufen im VLAN 192.168.20.x und die Bürorechner im Netz 192.168.70.x. DC hat die Adresse 192.168.20.20.
Habe im Unifi Switch im Netzwerk 192.168.70.x DHCP-Relay aktiviert und DHCP-Relay dort den Server eingetragen. Im DHCP-Server habe ich die Bereich für die 192.168.70.x angelegt dort als DNS auch den DC eingetragen.

Habe im DHCP-Server für IPv4 einen User eingetragen für dynamische Aktualisierungen im DNS und im DNS sichere und unsichere Aktualisierungen aktiviert. Mittlerweile werden die Clients auch automatisch aus dem 70er VLAN im DNS angelegt. Ich kann auch den DC pingen, aber es funktioniert kein nslookup, ich kann keine Rechner im 20er VLAN anpingen. Hier funktioniert die Auflösung auch nicht obwohl die im DNS vorhanden sind.

Größtes Problem ist jetzt natürlich das ich die Clients aus dem 70er VLAN nicht ins AD bekomme, da keine Verbindung zur Domäne hergestellt werden kann. Ping auf meinedomain.local funktioniert nicht.

Im 20er VLAN läuft alles super und ohne Probleme.

Wo könnte hier der Fehler sein in meiner Kofiguration?

Ich hoffe die Informationen reichen irgendwie aus. Ansonsten liefere ich gerne mehr nach.

Gruß
Hauke

Content-ID: 648785

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

Ausgedruckt am: 04.12.2024 um 18:12 Uhr

mbehrens
mbehrens 06.02.2021 um 19:28:47 Uhr
Goto Top
Zitat von @haukeha:

ich habe in einem relativ kleinen Netzwerk als VM einen Win Server 2019 als DC, DHCP und DNS.

Ich habe im Netzwerk mehrere VLANs. Die VMs laufen im VLAN 192.168.20.x und die Bürorechner im Netz 192.168.70.x. DC hat die Adresse 192.168.20.20.
Habe im Unifi Switch im Netzwerk 192.168.70.x DHCP-Relay aktiviert und DHCP-Relay dort den Server eingetragen. Im DHCP-Server habe ich die Bereich für die 192.168.70.x angelegt dort als DNS auch den DC eingetragen.

Warum gibt es zwei VLANs? Welcher "Sicherheitsgewinn" soll hiermit erreicht werden? Wo steht der Router?
haukeha
haukeha 06.02.2021 um 19:48:31 Uhr
Goto Top
Es gibt neben den VLANs noch einige andere Bereiche. Das ist nur ein Beispiel. Neben den Unifi Pro Switch befindet sich noch eine Unifi Dream Machine Pro im Netzwerk. Diese ist über das Management VLAN erreichbar.

Warum verschiedene VLANs? Weil zwischen einigen Rechner der Zugriff von anderen beschränkt sein soll.
LordGurke
LordGurke 06.02.2021 um 21:03:53 Uhr
Goto Top
Endet deine Domäne wirklich auf ".local"?
Diese TLD ist für mDNS reserviert und ist nicht für normales DNS gedacht.
Wenn dem so ist, korrigiere den Fehler möglichst jetzt und nimm einen Namen wie "ad.firmendomain.de". Eine Subdomain deshalb, damit ihr nicht mit Split-DNS herumbasteln müsst um eure eigene Webseite zu erreichen.

Ansonsten die üblichen Verdächtigen:
Nutzen die Clients den richtigen DNS-Server? Bekommen sie eine falsche Antwort oder Timeout? Ist die Firewall auf dem Server offen?
haukeha
haukeha 12.02.2021 um 18:49:32 Uhr
Goto Top
Endet deine Domäne wirklich auf ".local"?
Diese TLD ist für mDNS reserviert und ist nicht für normales DNS gedacht.
Wenn dem so ist, korrigiere den Fehler möglichst jetzt und nimm einen Namen wie "ad.firmendomain.de". Eine Subdomain deshalb, damit ihr nicht mit Split-DNS herumbasteln müsst um eure eigene Webseite zu erreichen.

Darf man das wirklich nicht mehr nutzen? Wäre mir neu.... Zumal es für mich das Verhalten nicht erklärt das im gleichen 20er Netz (Rechner befindet sich in der Workgroup und nicht in der Domäne) in dem sich der Server befindet eigentlich alles gut funktioniert. Allerdings bekomme ich beim Ping auf eine IP-Adresse im 20er Netz dann nur Rechnername.local zurück und nicht Rechnername.meinedomain.local. Allerdings kann ich dann auch einen Ping auf meinedomain.local machen und bekomme eine Antwort und der Windows Server wir sauber aufgelöst.

Ansonsten die üblichen Verdächtigen:
Nutzen die Clients den richtigen DNS-Server? Bekommen sie eine falsche Antwort oder Timeout? Ist die Firewall auf dem Server offen?
Alle Clients die per DHCP eine Adresse bekommen werden im DNS in der Forward und Reverse-Zone eingetragen. Ich habe nur noch den Windows Server als DNS eingetragen. nslookup liefert Ergebnis s. Bild
dns
Firewall ist ausgehend der Port 53 offen für das Kernnetzwerk. Muss die Regel noch erweitert werden damit auch Anfragen aus privaten Netzwerken beantwortet werden?
LordGurke
LordGurke 12.02.2021 um 20:42:17 Uhr
Goto Top
Zitat von @haukeha:
Darf man das wirklich nicht mehr nutzen? Wäre mir neu....

War realistisch betrachtet schon lange nicht mehr richtig - der Standard für mDNS ist von 2013 face-wink


Zumal es für mich das Verhalten nicht erklärt das im gleichen 20er Netz (Rechner befindet sich in der Workgroup und nicht in der Domäne) in dem sich der Server befindet eigentlich alles gut funktioniert. Allerdings bekomme ich beim Ping auf eine IP-Adresse im 20er Netz dann nur Rechnername.local zurück und nicht Rechnername.meinedomain.local. Allerdings kann ich dann auch einen Ping auf meinedomain.local machen und bekomme eine Antwort und der Windows Server wir sauber aufgelöst.

mDNS funktioniert per Multicast. Und das Phänomen, was du siehst (nämlich dass der Domain-Teil fehlt) ist ebenfalls ein Indiz, dass deine funktionierenden Anfragen per mDNS gestellt werden.
Die Auflösung funktioniert in dem selben Netz deshalb, weil dort der Server per Multicast erreichbar ist, daher per mDNS antworten kann und die Auflösung am normalen DNS vorbei geht.
Multicast wird aber standardmäßig nicht geroutet, weshalb dann in anderen Netzen keine Auflösung per mDNS mehr möglich ist.
Windows fällt dann nach einer gewissen Wartezeit auf normales DNS zurück. Bei der Auflösung über normales DNS kommt aber NXDomain, der Name oder die Zone wurde also auf dem DNS-Server selbst nicht gefunden.
So oder so solltest du wie gesagt dringend auf ".local" verzichten, bevor du da jetzt viel Infrastruktur um den DC herum baust.

Vermutlich würde es ohne mDNS in überhaupt keinem Netz funktionieren. Das kannst du testen, indem du per GPO die Auflösung per Multicast-DNS abschaltest. Das solltest du aber auch nicht unbedingt dauerhaft gesetzt lassen, denn das ist, worauf die "automatische Erkennung" von Netzwerkgeräten wie Druckern oder anderen Geräten letztlich basiert.


Alle Clients die per DHCP eine Adresse bekommen werden im DNS in der Forward und Reverse-Zone eingetragen. Ich habe nur noch den Windows Server als DNS eingetragen. nslookup liefert Ergebnis s. Bild
dns
Firewall ist ausgehend der Port 53 offen für das Kernnetzwerk. Muss die Regel noch erweitert werden damit auch Anfragen aus privaten Netzwerken beantwortet werden?
Ich verstehe nicht ganz, wo die ausgehende Regel ist - auf dem Client?

Der Server muss eingehend DNS-Anfragen auf Port 53 (TCP und UDP) zulassen, in Richtung Server muss der Traffic natürlich ebenfalls erlaubt werden.
haukeha
haukeha 12.02.2021 um 21:33:46 Uhr
Goto Top
Danke für deine ausführliche Antwort!

Bezüglich mDNS, kann es jetzt aber nicht ein Problem geben das mDNS im Unifi Cotrnoller auf den Switchen und dem Unifi Gatewa nichtaktiviert ist?

Und ist es empfehlenswert den Namen der Domäne zu ändern (gibt es dazu eine gute Anleitung) oder diese neu aufzusetzen?

Ich verstehe nicht ganz, wo die ausgehende Regel ist - auf dem Client?

Ja ich Schussel habe auf dem Client geguckt gehabt.

Der Server muss eingehend DNS-Anfragen auf Port 53 (TCP und UDP) zulassen, in Richtung Server muss der Traffic natürlich ebenfalls erlaubt werden.

Auf dem Server finde ich in der Firewall keine Regel für Port 53.
haukeha
haukeha 13.02.2021 um 15:40:10 Uhr
Goto Top
Habe die Domäne jetzt geändert auf ad.meinedomain.de..
meinedoamn.de ist auf ist eine domain auf uns registriert

Intern im 20er Netz ist alles gut Namensauflösung funktioniert. Auch aus den anderen VLANs werden alle Rechner im DNS registriert. Aber aus den anderen VLANs wo die Rechner in der Workgroup sind werde ich egal was ich anpinge oder nslookup ausführe, werde ich auf die öffentliche IP geleitet. Warum?

Ich habe nur den DC als DNS eingetragen.

Das kann/muss dann doch an dem Unifi Switch liegen das ich dann die falsche Ip-Adresse zurückbekomme?
haukeha
haukeha 16.02.2021 um 13:00:20 Uhr
Goto Top
Jemand anderes hier der mir bei meinem Problem mit der DNS-Auflösung weiterhelfen kann?
goscho
goscho 16.02.2021 um 13:09:21 Uhr
Goto Top
Mahlzeit
Zitat von @LordGurke:

Endet deine Domäne wirklich auf ".local"?
Diese TLD ist für mDNS reserviert und ist nicht für normales DNS gedacht.
Das mag durchaus so sein. Durch MS und die jahrzehntelange Vorgabe (u.a. bei SBS), gibt es sicherlich viele Millionen Domänen, die auf .local enden.
Die meiner Firma und vieler KMU, die ich betreue enden ebenfalls auf .local.
Ich sehe darin auf absehbare Zeit kein wirkliches Problem.
Wenn dem so ist, korrigiere den Fehler möglichst jetzt und nimm einen Namen wie "ad.firmendomain.de".
Das ist nicht immer so einfach. Wenn es bspw. einen Exchange in dieser Domäne gibt, ist diese Umbenennung alles andere als einfach.
Eine Subdomain deshalb, damit ihr nicht mit Split-DNS herumbasteln müsst um eure eigene Webseite zu erreichen.
Was ist an einem Eintrag im DNS für die Website denn so kompliziert?
haukeha
haukeha 16.02.2021 um 15:16:33 Uhr
Goto Top
Moin!

Endet deine Domäne wirklich auf ".local"?
Diese TLD ist für mDNS reserviert und ist nicht für normales DNS gedacht.
Das mag durchaus so sein. Durch MS und die jahrzehntelange Vorgabe (u.a. bei SBS), gibt es sicherlich viele Millionen Domänen, die auf .local enden.
Die meiner Firma und vieler KMU, die ich betreue enden ebenfalls auf .local.
Ich sehe darin auf absehbare Zeit kein wirkliches Problem.
Komme wie du auch noch aus der SBS und KMU-Schiene und da war es normal.

Wenn dem so ist, korrigiere den Fehler möglichst jetzt und nimm einen Namen wie "ad.firmendomain.de".
Das ist nicht immer so einfach. Wenn es bspw. einen Exchange in dieser Domäne gibt, ist diese Umbenennung alles andere als einfach.
Habe keinen Exchange laufen und somit funktionierte die Umbennung ohne Probleme und scheitert jetzt wie oben geschrieben daran das Rechner, die nicht im gleichen VLAN sind wie der Win Server 2019, als Antwort auf DC.mydomain.de die IP von mydomain.de (ist registriert und ist Domain der Webseite) zurückbekommen. Anscheinend gelangen die DNS-Anfragen aus den anderen VLANs nicht zum Sever obwohl dieser aber die DHCP-Adressen aller VLANs sauber vergibt und auch die DNS-Einträge entsprechend erstellt.
LordGurke
LordGurke 18.02.2021 um 11:31:44 Uhr
Goto Top
Hast du mal testweise die Firewall auf dem Server komplett deaktiviert?
Kannst du einen Traceroute vom Server zum Client machen? Nimmt der den erwarteten Weg?
Ansonsten mal mit Wireshark gucken, ob was kommt.

Eine Subdomain deshalb, damit ihr nicht mit Split-DNS herumbasteln müsst um eure eigene Webseite zu erreichen.
Was ist an einem Eintrag im DNS für die Website denn so kompliziert?

Weil dein Anbieter, wo die Webseite gehostet wird, eventuell ohne Vorankündigung die IP-Adresse ändert face-wink
haukeha
haukeha 19.02.2021 um 17:19:47 Uhr
Goto Top
Hast du mal testweise die Firewall auf dem Server komplett deaktiviert?
Kannst du einen Traceroute vom Server zum Client machen? Nimmt der den erwarteten Weg?
Ansonsten mal mit Wireshark gucken, ob was kommt.

Kennst du zufällig die Unifi Dream Machine Pro und den Unifi Controller? Problem liegt vermutlich daran, das die Firewal in der UDM Prol kein VPN Relay macht was nach Recherche notwendig ist damit die DNS-Anfragen geroutet werden.
haukeha
haukeha 24.02.2021 um 17:14:18 Uhr
Goto Top
Hallo,

bisher bin ich nicht wirklich weitergekommen.

Kurz zusammengefasst:
  • DNS (=DC) hat IP-Adresse 192.168.20.20
  • Client1 mit IP-Adresse 192.168.20.40 -> nslookup funktioniert. Alles einwandfrei
  • nslookup von Client1 auf Client2 (IP 192.168.10.21) im VLAN 192.168.10.0 funktioniert
  • nslookup von Client2 auf Client2 schlägt fehl
nslookup Client1
DNS request timed out.
timeout 2 seconds
Server: Unknown
Address: 192.168.20.20

Nicht autorisierende Antwort:
Name: Client2.ad.mydomain.de
Address: 85.13.xxx.xx
  • Ebenso schlägt natürlich der nslookup von Client2 auf Client1 fehlt
  • Deweiteren liefert ein nslookup auf zum Beispiel google.com
nslookup Client1
DNS request timed out.
timeout 2 seconds
Server: Unknown
Address: 192.168.20.20

Nicht autorisierende Antwort:
Name: google.com.ad.mydomain.de
Address: 85.13.xxx.xx

Ich würde hier gerne endlich den Knoten lösen.

Gruß
Hauke
haukeha
haukeha 24.02.2021 um 17:18:15 Uhr
Goto Top
Zitat von @LordGurke:

Hast du mal testweise die Firewall auf dem Server komplett deaktiviert?
Es sieht so aus als ob die DNS-Anfragen von der Unifi Dream Maschine Pro nicht korrekt geroutet werden.
Kannst du einen Traceroute vom Server zum Client machen? Nimmt der den erwarteten Weg?
Ja, das ist alles korrekt
haukeha
haukeha 24.02.2021 um 17:18:44 Uhr
Goto Top
Hallo,

bisher bin ich nicht wirklich weitergekommen.

Kurz zusammengefasst die aktuellen Erkenntnisse:
  • DNS (=DC) hat IP-Adresse 192.168.20.20
  • Client1 mit IP-Adresse 192.168.20.40 -> nslookup funktioniert. Alles einwandfrei
  • nslookup von Client1 auf Client2 (IP 192.168.10.21) im VLAN 192.168.10.0 funktioniert
  • nslookup von Client2 auf Client2 schlägt fehl
nslookup Client1
DNS request timed out.
timeout 2 seconds
Server: Unknown
Address: 192.168.20.20

Nicht autorisierende Antwort:
Name: Client2.ad.mydomain.de
Address: 85.13.xxx.xx
  • Ebenso schlägt natürlich der nslookup von Client2 auf Client1 fehlt
  • Deweiteren liefert ein nslookup auf zum Beispiel google.com
nslookup Client1
DNS request timed out.
timeout 2 seconds
Server: Unknown
Address: 192.168.20.20

Nicht autorisierende Antwort:
Name: google.com.ad.mydomain.de
Address: 85.13.xxx.xx

Ich würde hier gerne endlich den Knoten lösen.

Gruß
Hauke
LordGurke
LordGurke 24.02.2021 um 19:46:00 Uhr
Goto Top
Dann bleibt nur, mit Wireshark auf dem Server nachzugucken was kommt und ob geantwortet wird.
haukeha
haukeha 08.03.2021 um 19:49:10 Uhr
Goto Top
Hallo,

Lösung war das Unifi bei aktiviertem Contentfilter auch einen DNS-Filter ativiert, der alles blockt.

Nach Rücksprache mit deren Support läuft es jetzt soweit.

Vielen Dank!