Bei einer VPN-Verbindung verwendet DNS einen falschen DNS-Server


17

Ich habe einen Windows 7-PC in unserem Firmennetzwerk (das Mitglied unseres Active Directory ist). Alles funktioniert einwandfrei, bis ich eine VPN-Verbindung zum Standort eines Kunden herstelle.

Wenn ich eine Verbindung herstelle, verliere ich den Netzwerkzugriff auf Freigaben im Netzwerk, einschließlich Verzeichnissen wie "Anwendungsdaten", für die eine Ordnerumleitungsrichtlinie festgelegt wurde. Wie Sie sich vorstellen können, ist die Arbeit am PC sehr schwierig, da Desktop-Verknüpfungen nicht mehr funktionieren und die Software nicht mehr ordnungsgemäß funktioniert, da Anwendungsdaten darunter abgelegt wurden.

Unser Netzwerk wird geroutet (10.58.5.0/24), wobei andere lokale Subnetze im Umfang von 10.58.0.0/16 existieren. Das Remote-Netzwerk ist auf 192.168.0.0/24.

Ich habe das Problem im Zusammenhang mit DNS aufgespürt. Sobald ich den VPN-Tunnel öffne, wird der gesamte DNS-Verkehr über das Remotenetzwerk abgewickelt. Dies erklärt den Verlust lokaler Ressourcen. Meine Frage ist jedoch, wie ich lokale DNS-Abfragen zwingen kann, an unsere lokalen DNS-Server und nicht an unsere Kunden zu gehen ?

Die Ausgabe von, ipconfig /allwenn nicht mit dem VPN verbunden, ist unten:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Dies ist die Ausgabe desselben Befehls mit verbundenem VPN-Tunnel:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

PPP adapter Customer Domain:

   Connection-specific DNS Suffix  . : customerdomain.com
   Description . . . . . . . . . . . : CustomerDomain
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.0.16
                                       192.168.0.17
   Primary WINS Server . . . . . . . : 192.168.0.17
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Routing-Tabelle

Metrik der Netzwerkziel-Netzmasken-Gateway-Schnittstelle

          0.0.0.0          0.0.0.0        10.58.5.1       10.58.5.89     20
        10.58.5.0    255.255.255.0         On-link        10.58.5.89    276
       10.58.5.89  255.255.255.255         On-link        10.58.5.89    276
      10.58.5.255  255.255.255.255         On-link        10.58.5.89    276
    91.194.153.42  255.255.255.255        10.58.5.1       10.58.5.89     21
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0     192.168.0.95     192.168.0.85     21
     192.168.0.85  255.255.255.255         On-link      192.168.0.85    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.58.5.89    276
        224.0.0.0        240.0.0.0         On-link      192.168.0.85    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.58.5.89    276
  255.255.255.255  255.255.255.255         On-link      192.168.0.85    276

Die verbindliche Reihenfolge für die Schnittstellen lautet wie folgt:

Bildbeschreibung hier eingeben

Ich habe den VPN-Tunnel nicht für die Verwendung des Standardgateways auf der Remote-Seite konfiguriert, und die Netzwerkkommunikation zu Knoten in beiden Netzwerken ist in Ordnung. (dh ich kann jeden Knoten in unserem Netzwerk oder dem entfernten Netzwerk anpingen).

Ich habe die PPTP-Verbindungseigenschaften so geändert, dass die DNS-Server 10.58.3.32gefolgt von verwendet 192.168.0.16werden. Die Abfrage geht jedoch weiterhin zu 192.168.0.16.


Bearbeiten:

Die lokalen Ressourcen, die verschwinden, werden in Domänen-DFS-Stammverzeichnissen gehostet, die möglicherweise relevant sind (oder auch nicht).


Weitere Bearbeitung:

Dies scheint nur Domänen-DFS-Roots zu betreffen. Wenn ich über den Servernamen auf die Freigabe verweise (dh \\server\sharestatt \\dfsroot\share), kann ich auf die Freigaben zugreifen.

In meinem Kommentar zu dieser Antwort habe ich festgestellt, dass ich den DNS-Namen der Domäne zu meiner Hosts-Datei hinzufügen kann, wodurch das Verschwinden meiner (DFS-) Netzwerklaufwerke verhindert wird, aber ich möchte trotzdem den kühnen Teil meiner Frage (oben) ) Antworten, wenn jemand irgendwelche Ideen hat.


Sie haben nie erwähnt, welche Firewall Sie verwenden? Das ist ein ziemlich wichtiger Faktor, da ich denke, dass Sie hier möglicherweise die Antwort auf diese Frage finden werden.
Hanny

@hanny Die Firewall wird von der Netzwerkadressübersetzung auf den ADSL-Modems an beiden Standorten bereitgestellt. Ich kann wahrscheinlich Modellnummern angeben, wenn sie wirklich benötigt werden, aber es handelt sich nur um standardmäßige ADSL-NAT-Modems. Da es sich um AD mit integriertem DNS handelt, halte ich diese Geräte nicht für relevant, da es sich nur um DNS handelt.
Bryan,

Wenn das VPN nicht von der Firewall, sondern von Windows verarbeitet wird, wird eine andere Anzahl von Parametern gesendet, die verwendet werden können, da Windows VPN meiner Erfahrung nach nur in begrenztem Umfang verwendet wird. Zum Beispiel ist mit einem ASA 5505-Split-Tunneling eine sehr einfache Fehlerbehebung möglich, und es können zahlreiche Konfigurationsschritte durchgeführt werden, insbesondere in Bezug auf DNS-Probleme und die Zuweisung von DNS. Deshalb habe ich gefragt, danke für die Klarstellung.
Hanny

Könnten Sie bitte eine route print(von der VPN-Verbindung) zum Beitrag hinzufügen ?
Florianb

Am Routing ist nichts auszusetzen, da er eine Verbindung über IP herstellen kann, aber nicht über DNS
MichelZ 21.06.12

Antworten:


12

OK, hier eine großartige Ressource gefunden: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

Es ist nicht perfekt, könnte aber funktionieren.

Die verbindliche Bestellung wird in der Registrierung in dem folgenden Pfad gespeichert: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. Die Liste enthält alle Geräte-GUIDs für Netzwerkadapter und aktive Verbindungen in der Reihenfolge der Bindungspriorität.

Bei der Arbeit mit dem Registrierungsschlüssel ergeben sich folgende Tatsachen:

Das Ändern der Reihenfolge der GUIDs in der Registrierung wirkt sich auf die Bindungsreihenfolge aus, auch für VPN-Verbindungen

  • Änderungen am Schlüssel werden sofort wirksam
  • Wenn eine VPN-Verbindung hergestellt ist, wird die GUID für die Verbindung am Anfang der Bindungsreihenfolge hinzugefügt, sofern sie noch nicht vorhanden ist
  • Wenn eine VPN-Verbindung geschlossen wird, wird der GUID-Eintrag für die Verbindung entfernt
  • Wenn für die Verbindung mehrere GUID-Einträge vorhanden sind, wird beim Schließen der Verbindung nur einer entfernt

Dieser Mechanismus schafft die Möglichkeit der folgenden Problemumgehung:

  1. Untersuchen Sie den Registrierungsschlüssel Bind
  2. Stellen Sie eine Verbindung zu Ihrer VPN-Verbindung her
  3. Überprüfen Sie den Bindungsschlüssel erneut und kopieren Sie die GUID, die am Anfang der Liste hinzugefügt wurde
  4. Fügen Sie den GUID-Eintrag 20 Mal am Ende der Liste ein
  5. Exportieren Sie den Schlüssel und bereinigen Sie die exportierte Datei, sodass nur der Bindungsschlüssel enthalten ist

Das Ergebnis ist ein Schlüssel, der das gewünschte Verhalten unterstützt. Jedes Mal, wenn eine VPN-Verbindung hergestellt wird, wird diese nicht hinzugefügt, da die GUID vorhanden ist. Da sich die GUID unten befindet, erfolgt die DNS-Auflösung lokal auf dem Client. Wenn die Verbindung getrennt wird, wird ein GUID-Eintrag entfernt. Nach 20 VPN-Verbindungen kann die exportierte Registrierungsdatei zum erneuten Importieren des Schlüssels verwendet werden.

Natürlich können Sie die GUID auch öfter einfügen, um zu reduzieren, wie oft Sie den Schlüssel erneut importieren müssen.

Denken Sie auch daran, diesen Vorgang zu wiederholen, wenn Änderungen an Netzwerkadaptern vorgenommen wurden.


Guter Fund. Das funktioniert sehr gut, zusammen mit einem Startskript für den Computer, mit dem der Wert des Registrierungsschlüssels bei jedem Start zurückgesetzt wird. Dies sollte eine großartige Lösung sein, um das Problem zu umgehen, das eigentlich kein Problem sein sollte. Danke vielmals. Ich werde das weiter testen.
Bryan

3
Ich würde empfehlen, eine geplante Aufgabe zu erstellen. Überwachen Sie die Ereignis-ID 20226, die dem Ereignis "VPN-Trennung" entspricht. Dann feuert einen kleinen Powershell - Skript ( powershell -File c:\scripts\fixdnsbind.ps1) , die enthält: $val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind; $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}"; Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind. (Vergessen Sie nicht, die Adapter-ID anzupassen). Sie führen dieses Skript auch einmal aus, bevor Sie eine Verbindung zum VPN herstellen.
Steve B

4

Es scheint mir, dass der VPN-Tunnel irgendwie Vorrang vor der LAN-Schnittstelle hat, die den DNS-Verkehr an die VPN-DNS-Server weiterleitet Sie).

Das kann ich nicht ganz erklären, da die verbindliche Reihenfolge anders angibt. Laut diesem Beitrag hier (siehe die Antwort mit der höheren Punktzahl) sieht Windows diesbezüglich anders aus und wählt einen Kanal mit höherer Priorität, abhängig von der Geschwindigkeit der Verbindung, NICHT von der Adapterbindungsreihenfolge. Versuchen Sie daher zu Testzwecken Folgendes, um dieses automatische Verhalten zu ändern: 1) Gehen Sie zu Netzwerkverbindungen und führen Sie für jede Aktion 2) IP v4-Eigenschaften 3) Erweitert 4) Deaktivieren Sie "Automatische Metrik" 5) Geben Sie für Ihre lokale Metrik manuell eine 1 ein Verbindung und eine Metrik von 2 auf Ihrer VPN-Verbindung (PPP). Auf diese Weise wird der Pfad zu den lokalen DNS-Servern wie bevorzugt gegenüber dem Remote-DNS fest verdrahtet.

Hoffe das hilft!


Interessanterweise ist in der obigen Routing-Tabelle die Metrik auf der LAN-Schnittstelle die niedrigste (20), die VPN-Verbindung hat eine Metrik von 21. Allerdings kann dieses Problem zeitweise auftreten, und die Routing-Tabelle wird oben angezeigt , alles funktioniert momentan einwandfrei. Ich werde versuchen, das Problem erneut zu erstellen und die Routingtabelle erneut zu überprüfen.
Bryan

Update, habe gerade den Tunnel wieder geöffnet und alle meine Verbindungen zu Laufwerken wurden getrennt, aber die Routing-Tabelle unterscheidet sich nicht von oben. dh Metrik 20 für LAN, Metrik 21 für VPN.
Bryan

1
@ Bryan, dieser Microsoft-Artikel ( support.microsoft.com/kb/299540 ) bestätigt, was ich oben gesagt habe. Es wäre interessant zu sehen, was passiert, wenn Sie die oben beschriebene Prozedur durchlaufen, wenn Sie Zeit haben. Andere haben die genauen zeitweiligen Probleme gemeldet, die Sie sehen, und sie durch Festverdrahtung der Metriken behoben ( serverfault.com/questions/70792/… ). Leider habe ich momentan kein ähnliches Setup, um einige Tests durchzuführen.
ank

Vielen Dank für diesen @ank, ich werde es sicherlich später nächste Woche versuchen, wenn ich wieder im Büro bin. Interessanter Artikel übrigens. Vielen Dank.
Bryan

1
Es hat den Trick für mich getan! Die Metrix in den IPv4-Einstellungen für die Netzwerkkarte scheint nichts mit der Metrix in der Routing-Tabelle zu tun zu haben! Das Ändern der GUID-Reihenfolge in HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind, über die ZnArK schrieb, hat nichts daran geändert, welche NIC / DNS verwendet wird. Dies wird unter Windows 10 getestet
MrCalvin

4

Wie bereits erwähnt, handelt es sich hierbei um ein Split-Tunneling-Problem.

Drei Fehlerbehebungen, empfehlen 2, da dies einfach ist und eine gute Leistung erzielt, wenn eine gute Box mit VMware Workstation 8 verwendet wird

1 - Split-Tunneling aktivieren - Unsicher und erfordert möglicherweise Arbeiten auf der Client-Seite. Es ist unwahrscheinlich, dass die IT-Sicherheitsgestapo Sie ausschaltet.

2 - Virtualisierter Desktop-Ansatz - Versetzen Sie Ihren vorhandenen Desktop in eine virtuelle Maschine. Verwenden Sie die VM zum VPN zum Client. Sie behalten Ihren Desktop und können bei Bedarf zwischen diesen wechseln.

3 - Virtualisierter Server-Ansatz - Führen Sie eine P2V-Aktualisierung Ihres vorhandenen Desktops durch, und verwandeln Sie ihn in eine VM. Setzen Sie ihn dann auf eine kostenlose Version von ESXi. Sie behalten Ihren Desktop und können bei Bedarf über eine Konsole zur VM wechseln. Dies kann langsam sein ...


+1; Ich mag die Idee, ein dediziertes virtualisiertes System für diese Aufgabe zu haben, aber ich sehe, dass dies aus verschiedenen Gründen zum jetzigen Zeitpunkt hier nicht gut funktioniert. Dies wird jedoch auf jeden Fall eine gute Lösung für die Zukunft sein. Vielen Dank.
Bryan

3

Leider kann Windows VPN "Split-DNS" nicht ausführen. Sie können den DNS-Server jedoch von der VPN-Verbindung entfernen, nachdem Sie eine Verbindung zur Remote-Site hergestellt haben.

Sie können dies tun, indem Sie Folgendes eingeben:

Netsh-Schnittstelle ipv4 löschen dnsservers name = " Name des VPN " address = all validate = no

Sie MÜSSEN dies jedes Mal tun, wenn Sie eine Verbindung zum VPN-Netzwerk herstellen.


Zu Ihrer Information ... dies hindert Sie daran, den Remote-DNS (VPN) zu verwenden.
MichelZ

Das Problem ist, dass ich, sobald der Tunnel hoch ist, bereits unter dem in meiner Frage beschriebenen Problem leide, sodass der Befehl zu spät kommt. Nachdem Sie damit experimentiert haben, scheint der Befehl tatsächlich keinen Unterschied zu machen (verwendet nslookupweiterhin den Remote-DNS-Server und ipconfiglistet weiterhin den Remote-DNS-Server auf). Ich habe auch die DNS-Einstellungen für die VPN-Tunnelverbindung so bearbeitet, dass sie meine eigenen internen DNS-Einstellungen verwenden. Dies wird jedoch ignoriert. Der gesamte DNS-Verkehr scheint weiterhin auf den Remote-DNS-Server zuzulaufen.
Bryan

1
Ich hatte es versucht, da ich das gleiche Problem hatte, und es funktionierte hier. Haben Sie den " Namen des VPN " angepasst ? Wenn Sie sich außerdem hauptsächlich um diesen einen Server
sorgen, mit

Danke, ich habe versucht, den Namen zu ändern (Ausschneiden und Einfügen aus der ipconfigAusgabe, und wenn ich einen Fehler gemacht habe, habe ich den Fehler erhalten The filename, directory name, or volume label syntax is incorrect), also bin ich mir ziemlich sicher, dass ich den Befehl richtig verstanden habe. Möglicherweise kann ich die DNS-Einstellung auf dem Remote-PPTP-Server nicht überschreiben. Ich werde nachforschen, aber ich mag die Idee der Hosts-Dateieingabe. Ich werde es versuchen. Siehe auch meine Bearbeitung zu der Frage.
Bryan

Ich habe den Befehl gerade noch einmal ausprobiert und er hat den DNS-Server von der PPP-Verbindung entfernt. Könnten Sie mit bestätigen ipconfig /all? Ich denke jedoch, dass der Hosts-Eintrag die einfachste Lösung für Sie sein sollte.
MichelZ

2

Ihr VPN-Tunnel befindet sich zwischen dem Client und dem Client-Netzwerk. Klingt so, als würde kein Split-Tunneling verwendet, wodurch Sie nicht mehr auf Ressourcen in Ihrem eigenen Netzwerk zugreifen können, während der Tunnel aktiv ist.

Sie (oder Ihr Client) müssen also Split-Tunneling aktivieren, oder Sie benötigen eine zusätzliche Netzwerkverbindung und eine angepasste Routentabelle, um gleichzeitig auf beide Netzwerke zuzugreifen.


Ich kann auf Netzwerkressourcen zugreifen, während der Tunnel aktiv ist. Es scheint nur die DNS-Auflösung zu stören. Ich kannte den Begriff nicht split tunnelling, um ehrlich zu sein, aber soweit ich das beurteilen kann, muss ich nur sicherstellen, dass ich nicht das Standard-Gateway am Remotestandort verwende, was ich, obwohl ich es nicht spezifiziere, bereits tue. Vielen Dank für die Antwort, ich werde meine Frage bearbeiten, um dies widerzuspiegeln.
Bryan

1
In diesem Fall scheint das VPN des Kunden nicht für Split-DNS eingerichtet zu sein. Bei aufgeteiltem DNS gibt der VPN-Konzentrator dem VPN-Client eine Liste der DNS-Server (wie derzeit) sowie eine Liste der Domänen an, die die einzigen Domänen sind, die mit diesen DNS-Servern verwendet werden sollten. Alle anderen würden das Standard-DNS Ihres Systems verwenden.
James Sneeringer

0

Obwohl diese Frage lange zurück gestellt wurde, kann das Posten dieser Antwort anderen helfen. Ich hatte das gleiche Problem mit VPN, bei dem Benutzer beim Herstellen einer Verbindung zu Remote-VPNs ihre externen DNS-Adressen stoppten, z. google.comEs funktionierten nur Firmen-Domains, auf denen gelistet war split-dns.

Das Problem bestand darin, dass der DNS-Abfrageverkehr auf einem lokalen Computer an den VPN-Tunnel weitergeleitet wurde und dass der DNS-Datenverkehr zurückfällt, wenn er im Tunnel zulässig ist. Bei einem Fallback wurde zuerst ipv6 als Auflösung ausgewählt und danach nie mehr zu ipv4 zurückgekehrt.

Um die Ergebnisse zu testen, haben wir zuerst das IPv6 auf dem lokalen Computer deaktiviert, auf dem es funktioniert. Um client-bypass-protocoldas Problem dauerhaft für alle Benutzer zu beheben, haben wir den Befehl in der ASA-Firewall aktiviert, der IPv6 ignoriert, wenn er nicht in VPN-Pools konfiguriert ist.

Wenn Sie die Firewall nicht kontrollieren können und wissen, dass der Split-Tunnel und die Split-DNS vorhanden sind, dies jedoch fehlschlägt, können Sie versuchen, sie ipv6auf dem lokalen Computer zu deaktivieren. Wenn Sie sie kontrollieren können, können Sie den obigen Befehl aktivieren, solange Sie ipv6 nicht verwenden in Ihrem entfernten Netzwerk.

Das hat mir geholfen, hoffe das hilft anderen :)


0

Yay etwas, mit dem ich Erfahrung habe!

Stellen Sie die VPN-Verbindung mit dem lokalen DNS-Server ein und stellen Sie eine Verbindung zu dem VPN her, mit dem nslookup den VPN-Domänennamen abfragt. Sie sollten eine Antwort mit einer IP erhalten, die für das VPN-LAN lokal ist. Dies bedeutet, dass Sie die VPN-DNS-Server zum Auflösen der Abfrage verwendet haben.

Öffnen Sie nun Ihre LAN-Verbindung und stellen Sie den DNS manuell auf Ihren lokalen oder ISP-DNS ein. eine Volia !!! Verwenden Sie die Pfeiltaste, und wiederholen Sie die Nslookup-Abfrage. Sie erhalten eine öffentliche IP, was bedeutet, dass Sie Ihren lokalen / ISP-DNS-Server zum Auflösen der Abfrage der VPN-Domäne verwendet haben. Bam !!!!


0

Ich entferne diese Option einfach aus der Client-VPN-Konfiguration

setenv opt block-outside-dns

Das Problem wurde behoben


0

Ich hatte dieses Problem vor ein paar Jahren und korrigierte es, indem ich die VPN-Verbindungsdatei bearbeitete. Erstelle einfach eine vpn.pbk-Datei (du findest sie in Google), öffne diese Datei über einen Texteditor wie Notepad und ändere den UseRasCredentials-Wert auf Null und dein Problem ist gelöst. Das einzige Problem ist jedoch, dass die DNS-Priorität Ihrer LAN-Verbindungen höher ist als die von VPN. Die Namensauflösung nimmt mehr Zeit in Anspruch (wenn VPN für die Verbindung zum Internet verwendet wird).


-1

Warum denkst du, ist es DNS?

Wenn Sie beim Herstellen einer VPN-Verbindung den Zugriff auf Ihre Netzwerkfreigaben verlieren, hat Ihr Computer mit ziemlicher Sicherheit Probleme mit WINS / NETBIOS.

Definieren Sie einen WINS-Server und testen Sie ihn erneut.


Ich weiß nicht genau, ob dies die Ursache für meine Probleme ist, aber ich weiß, dass AD-Clients die DNS-Server verwenden sollten, die zum Hosten von AD verwendet werden. Dies ist jedoch nicht der Fall. Da das Problem nur auftritt, wenn ich eine VPN-Verbindung herstelle und meine DNS-Auflösung gleichzeitig fehlerhaft ist, scheint DNS der wahrscheinlichste Kandidat zu sein. Unabhängig davon möchte ich den Remote-DNS-Server nicht verwenden, wenn ich über VPN eine Verbindung zu einem anderen Netzwerk herstelle.
Bryan

Haben Sie einen WINS-Server gemäß meinem Vorschlag definiert? Es ist nicht typisch für Windows, den DNS-Server in einem VPN zu verwenden, es sei denn, Sie haben die Option "Remote-Gateway verwenden" definiert oder deaktiviert. Außerdem verwenden Sie eine statische IP-Adresse für den VPN-Tunnel. Warum haben Sie dann überhaupt DNS-Einträge festgelegt? Entfernen Sie diese DNS-Server (192.168.0.16-17) oder legen Sie einen WINS-Server fest.
Ben Lessani - Sonassi

Nein, das habe ich nicht versucht, da wir keinen WINS-Server haben, auf den die Clients verweisen können. Ich bin nicht davon überzeugt, dass WINS helfen wird, um ehrlich zu sein. Daher bin ich nicht daran interessiert, einen WINS-Server in unserem Netzwerk zu installieren, da dies möglicherweise hilfreich ist. Ich werde die Idee allerdings auf jeden Fall im Hinterkopf behalten, also danke. Die IP wird vom VPN-Server vergeben und ist dynamisch. Wenn ich keinen DNS-Server für die VPN-Verbindung vergebe, wird dieser vom Server dynamisch zugewiesen. Ich habe sogar meine eigenen DNS-Server in den VPN-Verbindungseigenschaften fest codiert, es werden jedoch weiterhin die DNS-Server am Remotestandort verwendet.
Bryan

Ich brauche nicht will , noch den Remote - DNS - Server verwenden, überhaupt, ich will immer die DNS - Auflösung auf dem lokalen Server ausgeführt werden, dies wird mein Problem beheben, daher meine Frage auf DNS konzentrieren. Ich könnte wahrscheinlich eine Firewall-Regel verwenden, um den Zugriff auf den Remote-DNS-Server zu blockieren, dies behebt jedoch nicht das zugrunde liegende Problem der Fehlkonfiguration.
Bryan

1
Ihre Interpretation ist falsch. Die IP-Adresse wird vom PPTP-Server zugewiesen, der DHCP nicht verwendet. Der PPTP-Server verfügt über einen Pool, den er zuordnen kann, dies ist jedoch kein DHCP. Ich erhalte jedoch jedes Mal eine andere IP-Adresse, wenn ich eine Verbindung herstelle. Außerdem habe ich das Kästchen für die Verwendung des Remote-Gateways nicht angekreuzt, wie Sie in der Routing-Tabelle deutlich sehen können.
Bryan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.