Fragensteller
Best Practice DNS VPN

Frage
-
Hallo zusammen,
was sagt ihr zum Thema Best Practice DNS an entfernten Standorten? Wir haben mehrere kleine Standorte die sich via VPN am AD anmelden. Derzeit ist als erster DNS der DNS/DC am Hauptstandort und als zweiter ein externer (öffentlicher) eingetragen. Ich würde gerne, als zweiten einen weiteren DNS vom Hauptstandort eintragen. Nur wenn die VPN Verbindung dann mal nicht aufgebaut werden kann, dann geht an den Standorten dementsprechend nichts mehr.
Wie geht ihr damit um?
Alle Antworten
-
Nun, die Reihenfolge und Anzahl der DNS-Server ist nicht mehr wichtig.
Meine Erfahrung ist, dass Windows das sowieso intern beliebig regelt und ja nach Antwortverhalten die Reihenfolge schon mal tauscht.
Da die Antwortzeiten von DNS-Servern sehr kurz sein müssen (Windows Default 1-2 Sekunden) kann das bei manchen Adressen zu unerwünschten Ergebnissen führen.
Ich muss mich z.B. mit meiner Fritz-Box ins Firmennetzwerk einwählen.
Dadurch erhalte ich 2 zusätzliche DNS-Server zu meiner FritzBox.
Möchte ich dann z.B. drucken, und mein Drucker ist per "Printer.fritz.box" erreichbar, kann es passieren, dass der DNS-Server vom VPN zuerst gefragt wird und mir die Adresse 127.0.53.53 gemeldet wird (.box-Adresse nicht registriert). Somit kann ich dann lokal nicht drucken. Dies geht auf Grund des DNS-Caches dann erst nach dem Verbindungsabbau und ggf. löschen des Caches.
Ebenso kann es dann schon mal vorkommen, dass Internetseiten (wie diese hier) manchmal nicht erreichbar sind, da vom falschen Server die falsche Antwort kommt oder, was auch nicht besser ist, die Ladezeiten der Internetseiten unzumutbar lange dauern (ich hatte da sogar einen Fehler beim Internetdienstleister gemeldet).Um dieses zu vermeiden, bekomme ich nun regelmäßig eine HOSTS mit den DNS-Adressen des VPN-Netzwerkes während die DNS-Server im VPN ausgetragen sind.
Dies ist die sicherste und schnellste Methode, aber zugegeben, nicht die eleganteste.
-
-
Ja das stimmt. Ich bin nur davon ausgegangen, dass es vllt eine elegantere Lösung gibt. Danke auf jeden Fall für den Tipp.
Die gibt es, wenn Deine Router davon überzeugt werden können, einen Conditional Forwarder zu realisieren. Dann leitest Du nur die Anfragen nach der AD-Domain an die Zentrale weiter (vorausgesetzt, der Tunnel steht) und die Site-lokale Sachen wie printer01.fritz.box sowie die Außenwelt löst der Router selber auf gegen welche DNS-Server auch immer. Dann musst Du bei den Clients nur den Router eintragen.
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Das verstehe ich nun wiederum nicht.
Daher noch mal die Nachfrage:
Wenn der Windowsclient an den VPN-DSN-Server eine Anfrage schickt, die dieses Zielnetz nicht betrifft, wird diese Anfrage dann nicht beantwortet (also Timeout) oder mit "Ziel unbekannt" abgewiesen?
Soweit ich festgestellt habe, fragt Windows bei Timeout nicht (immer?) den nächsten DNS-Server ab.
Dies macht sich bei mir eben auch mit "Seite kann nicht angezeigt werden" bemerkbar obwohl die Zieladresse ja existiert.
- Bearbeitet Der Suchende Montag, 8. Mai 2017 18:48
-
Das ist ja eine feine Sache. Können die RV320 aber leider nicht..
Iiiiih, das ist ja dann quasi ein LinkSys.... Die können es wirklich nicht :-(
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Liebe Gemeinde,
Die DNS Server eines in eine Domäne integrierten Rechners sollten, bei LAN-Verbindungen im eigenen Netzwerk auch DNS Server erreichen, die eine Auflösung der Active Directory Domain Dienste ermöglichen.
Es war bisher keine gute Idee als alternativen DNS Server ein DNS System ohne Kenntnis der SRV-Records der Domain zu verwenden.
Windows Systeme wechseln den DNS Server nur, wenn der aktuell verwendete nicht erreichbar ist. Haben sie den alternativen im Zugriff, dann wird auf den primär konfigurierten DNS erst zurück gewechselt, wenn der alternative DNS nicht mehr antwortet. Die Mitteilung "Host unbekannt" ist jedoch eine Antwort.
Welche Optionen stehen jetzt also zur Verfügung?
1. Der VPN Router bietet (wie Evgenij Smirnov schreibt) die Möglichkeit als lokaler DNS Server zu agieren. Und es besteht die Möglichkeit mit gerichteten Weiterleitungen zu arbeiten.
2. Du betreibst in Deinen "kleinen" Standorten einen zusätzlichen DNS Server, sicher auch möglich auf einem beliebigen Windows Server (Einrichten einer Sekundären oder Stub Zone). Dieser zusätzliche DNS Server leitet alle DNS Anfragen für externe Ressourcen an den Internetprovider weiter. Alle internen Anfragen werden selbst beantwortet oder zur Zentrale geroutet.
Das hat den Vorteil, das beim Verlust der VPN Site-to-Site Kopplung in jedem Fall die Auflösung für Goo... & Co funktioniert. Sobald die VPN Site-to-Site Kopplung wieder besteht, dann werden auch die Domaindienst wieder erreicht.Gruß Malte
-
Das verstehe ich nun wiederum nicht.
Daher noch mal die Nachfrage:
Wenn der Windowsclient an den VPN-DSN-Server eine Anfrage schickt, die dieses Zielnetz nicht betrifft, wird diese Anfrage dann nicht beantwortet (also Timeout) oder mit "Ziel unbekannt" abgewiesen?
Soweit ich festgestellt habe, fragt Windows bei Timeout nicht (immer?) den nächsten DNS-Server ab.
Dies macht sich bei mir eben auch mit "Seite kann nicht angezeigt werden" bemerkbar obwohl die Zieladresse ja existiert.
Moin,
was ist für Dich der VPN-DNS-Server? Ein DC hinter dem Tunnel? Dieser müsste ja theoretisch fast alle anfragen bedienen können - bis auf printer.firtz.box halt - solange der Tunnel steht.
Windows fragt seit XP die Server nicht in der Reihenfolge ab, sondern würfelt quasi alle 15 Minuten die Reihenfolge neu aus. Man kann es abstellen, inderm man einen Reg Key setzt wie hier beschrieben: https://support.microsoft.com/en-us/help/320760/the-dns-client-service-does-not-revert-to-using-the-first-server-in-the-list-in-windows-xp
Wenn Du einen DNS-Server nach printer.fritz.box fragst, schickt er das zuerst per Rekursion oder per Root Hint raus. Je nachdem, wie Deine Rekursion konfiguriert ist, kann es natürlich auch zu einem Timeout kommen. Ansonsten kommt NXDOMAIN als Antwort zurück.
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Jaa ich ärgere mich auch tierisch über diesen Müll Router. VPN Verbindungen brechen ständig ab, routing klappt nicht wirklich usw. Da wurde leider am falschen Ende gespart und sind gerade erst angeschafft wurden. Hmm ein lokaler DNS Server kommt leider auch nicht in Frage. Ich denke, dass ich dann wohl wirklich mit der hosts Datei arbeiten muss...
-
Moin, Moin,
oder die VPN Router austauschen. Domain Member im internen LAN mit einem sekundären DNS Server im "Internet" zu versorgen, war bisher keine gute Idee.
U.U. waren die "VPN Router" für andere Anwendungsfälle vorgesehen und sind jetzt nicht den aktuellen Anforderungen gewachsen.
Gruß Malte
-
oder die VPN Router austauschen. Domain Member im internen LAN mit einem sekundären DNS Server im "Internet" zu versorgen, war bisher keine gute Idee.
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Ja die peripheren Sites bestehen aus 1-3 Geräten. Daher wird hier nicht viel Geld in die Hand genommen. Der Geräte müssten leider also weiter eingesetzt werden.
Ein Vorteil den wir haben: Der Domainname ist auch eine Internet Domain. Ich weiß nur nicht wie es aus Sicherheitsgründen aussieht: Stellt es ein großes Risiko dar, die entsprechenden Server direkt in den public DNS zu vermerken? Dann spart man sich die hosts Dateien.
-
In meinem Homenetz habe ich meine Fritzbox als DNS-Server eingetragen.
Verbinde ich mich nun mit dem VPN ins Firmen-Netz, bekomme ich aus dem Firmen-Netz einen weiteren DNS-Server genannt, der in der Liste (WinIpCfg) dann an 1. Stelle steht.
Somit werden nun alle DNS-Anfragen wohl erst mal ins VPN geschickt, denn printer.fritz.box kommt mit 127.0.53.53 zurück (.Box-Problematik). Das Firmennetzwerk erlaubt eben auch Interntzugriffe.
Deinen Link hatte ich schon gefunden, scheint aber in Windows 10 nicht mehr zu greifen bzw. der VPN trägt den Firmen-DNS-Server immer an 1. Stelle ein.
Das manuelle setzen der IP-Metrik hat da ebenso keinen Einflluss. Adapter und Bindungs-Einstellungen gibt es in Windows 10 nicht mehr (zuletz wohl noch auf Windows 8.1, aber da ist mein privates Netzwerk auf Stelle 1).
Ausprobiert habe ich das mit OpenVPN, Windows-VPN, ShrewSoft und FortiClient.
-
Liebe Gemeinde,
für den Client ist es ein Unterschied ob die Verbindung zum "Hauptstandort" durch eine VPN-Site-to-Site Kopplung über "Routingdevices" hergestellt wird, oder über einen VPN-Client direkt durch den Client.
Eine Site-to-Site Kopplung hat keinen direkten konfigurierenden Einfluss auf die DNS Konfiguration des Clients. Dem Client ist es egal ob die Verbindung online ist oder nicht, er arbeitet stumpf die Liste seiner in der IP Config abgelegten DNS Server ab.
VPN Clients haben direkten Einfluss auf die Liste der DNS Server des Clients. Es ist also ein völlig anderes Verhalten.
Zurück zur ursprünglichen Frage: "Best Practice DNS VPN"
Wenn eine Site-to-Site Kopplung besteht, sollte der Client mit einem alternativen DNS Server versorgt werden, der bei bestehender VPN Kopplung die Domainservices auflösen kann und gleichzeitig bei getrennter VPN Verbindung auch externe DNS Namen auflösen kann.
Gruß Malte
-
Zu letzterem besteht doch eigentlich keine Chance.
Wenn das VPN unterbrochen ist, kann ich den Firmen-DNS-Server doch gar nicht mehr erreichen.
Also habe ich im Zweifel mindestens 2.
- den lokalen DNS-Server (eben meine Fritzbox, meinen lokalen Router)
- den VPN-DNS-Server wenn Online -
Ja aber genau aus der Konfiguration des alternativen DNS Servers (eben Deine Fritzbox), die keine Kenntnisse über die Domainservices des Active Directory hat, entsteht das Problem.
Deine DNS Clients versuchen einen DNS Server zu kontaktieren. Je nach Antwortgeschwindigkeit nutzen Deine Clients den DNS Server im Hauptstandort oder, wenn dieser nicht schnell genug antwortet die Fritz.box. Sobald die Fritz.box als DNS Server vom Client genutzt wird entstehen die Problem die AD Dienste zu finden.
Es ist für Domain Member also keine gute Idee als alternativen DNS Server einen DNS Dienst zu verwenden, der keine Auflösung für die Domain Dienste bereitstellen kann.
Gruß Malte
-
Auch hier habe ich nun von meinem Admin eine neue VPN-Definition bekommen.
In dieser steht nun der Default-DNS-Suffix für diese Schnittstelle.
Bei uns ist das die Firmen-Domäne (z.B. Firma.local).
Dadurch werden alle unqualifizierten Anfragen mit dieser Domäne ergänzt, aber alle qualifizierten Anfragen nur noch an den zuständigen Server gesendet.
Dadurch wird "MeinPc.fritz.box" nicht mehr vom Firmen-DNS beantwortet sondern direkt von meiner Fritz.
Auch wenn ich "MeinPC" angebe, so antwortet die Fritz mit "MeinPc.fritz.box" und der Firmen Server mit "MeinPc.Firma.local" unbekannt, was zum Weitersuchen veranlasst.
Und schneller scheint das Ganze nun auch zu sein.
Das Thema 127.0.53.53 bzgl. der BOX-Endung ist nun auch Geschichte.