it-swarm.com.de

Durch die VPN-Verbindung verwendet DNS einen falschen DNS-Server

Ich habe einen Windows 7-PC in unserem Unternehmensnetzwerk (der 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 wir eine Richtlinie zur Ordnerumleitung haben. 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 abgerufen werden.

Unser Netzwerk wird geroutet (10.58.5.0/24), wobei andere lokale Subnetze im Bereich von 10.58.0.0/16 vorhanden sind. Das Remote-Netzwerk befindet sich unter 192.168.0.0/24.

Ich habe das Problem auf DNS-bezogen zurückgeführt. Sobald ich den VPN-Tunnel öffne, all geht mein DNS-Verkehr über das Remote-Netzwerk, was den Verlust lokaler Ressourcen erklärt, aber meine Frage lautet: Wie kann ich lokale DNS-Abfragen dazu zwingen, zu unseren lokalen DNS-Servern und nicht zu unseren Kunden zu gehen?

Die Ausgabe von ipconfig /all wenn 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

Netzwerkziel-Netzmasken-Gateway-Schnittstellenmetrik

          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 Bindungsreihenfolge für die Schnittstellen lautet wie folgt:

enter image description here

Ich habe den VPN-Tunnel nicht für die Verwendung des Standard-Gateways am Remote-Ende konfiguriert, und Netzwerkkommunikation zu Knoten in beiden Netzwerken ist in Ordnung. (d. h. ich kann jeden Knoten in unserem Netzwerk oder im Remote-Netzwerk anpingen).

Ich habe die Verbindungseigenschaften PPTP] geändert, um die DNS-Server zu verwenden 10.58.3.32 gefolgt von 192.168.0.16, aber die Abfrage geht immer noch zu 192.168.0.16.


Bearbeiten:

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


Weitere Bearbeitung:

Dies scheint nur Domänen-DFS-Wurzeln zu betreffen. Wenn ich die Freigabe über den Servernamen verweise (d. H. \\server\share Anstatt von \\dfsroot\share) Kann ich auf die Freigaben zugreifen.

Gemäß meinem Kommentar gegen diese Antwort habe ich festgestellt, dass ich den DNS-Namen der Domäne zu meiner Hosts-Datei hinzufügen kann, wodurch verhindert wird, dass meine (DFS) Netzwerklaufwerke verschwinden, aber ich möchte immer noch den kühner Teil meiner Frage (oben) zu beantworten, wenn jemand irgendwelche Ideen hat.

19
Bryan

OK, ich habe 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 Reihenfolge wird in der Registrierung an folgendem Speicherort 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 Fakten:

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 oben in der Bindungsreihenfolge hinzugefügt, falls sie noch nicht vorhanden ist
  • Wenn eine VPN-Verbindung geschlossen wird, wird der Eintrag GUID für die Verbindung) entfernt
  • Wenn mehrere GUID Einträge für die Verbindung vorhanden sind), wird beim Schließen der Verbindung nur einer entfernt

Dieser Mechanismus bietet die Möglichkeit der folgenden Problemumgehung:

  1. Überprüfen Sie den Registrierungsschlüssel binden
  2. Stellen Sie eine Verbindung zu Ihrer VPN-Verbindung her
  3. Überprüfen Sie den Bindungsschlüssel erneut und kopieren Sie die GUID, die oben in der Liste hinzugefügt wurde
  4. Fügen Sie den Eintrag GUID) am Ende der Liste 20 Mal ein
  5. Exportieren Sie den Schlüssel und bereinigen Sie die exportierte Datei, um nur den Bindeschlüssel einzuschließen

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 die GUID) unten ist, wird die DNS-Auflösung angezeigt 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) mehrmals einfügen, um zu reduzieren, wie oft Sie den Schlüssel erneut importieren müssen.

Denken Sie auch daran, dieses Verfahren zu wiederholen, wenn Änderungen an Netzwerkadaptern vorgenommen werden.

12
ZnArK

Es scheint mir, dass der VPN-Tunnel irgendwie Vorrang vor der lokalen Schnittstelle hat, die den DNS-Verkehr zu den VPN-DNS-Servern leitet (Sie können die Anforderung auf diesen Servern überprüfen, um dieses Verhalten zu überprüfen, wenn Sie Zugriff darauf haben oder jemand dieses Verhalten überprüfen kann Du).

Das kann ich nicht ganz erklären, da die verbindliche Reihenfolge anders angibt. Demnach hier posten (siehe die Antwort mit der höheren Punktzahl) Windows hat eine andere Wahrnehmung, wenn es darum geht, einen Kanal mit höherer Priorität zu wählen, abhängig von der Geschwindigkeit der Verbindung, NICHT von der Adapterbindungsreihenfolge. Versuchen Sie zum Testen Folgendes, um dieses automatische Verhalten zu ändern: 1) Gehen Sie zu Netzwerkverbindungen und führen Sie jeweils 2) IP v4-Eigenschaften aus. 3) Erweitert. 4) Deaktivieren Sie "Automatische Metrik". 5) Geben Sie manuell eine Metrik von 1 für Ihr lokales Verhalten ein Verbindung und eine Metrik von 2 auf Ihrer VPN-Verbindung (PPP). Auf diese Weise wird der Pfad zu den lokalen DNS-Servern fest verdrahtet, wie dies gegenüber dem Remote-DNS bevorzugt wird.

Hoffe das hilft!

5
ank

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

Drei Korrekturen, empfehlen # 2, da es einfach ist und eine gute Leistung bietet, wenn eine gute Box mit VMware Workstation 8 verwendet wird

1 - Split-Tunneling aktivieren - unsicher und erfordert möglicherweise Arbeit auf der Client-Seite. Es ist unwahrscheinlich, dass IT-Sicherheitsgestapo Sie herunterfährt.

2 - Virtualisierter Desktop-Ansatz - P2Ven Sie Ihren vorhandenen Desktop und verwandeln Sie ihn in eine VM. Verwenden Sie die Option VM, um eine VPN-Verbindung zum Client herzustellen. Sie behalten Ihren Desktop bei und können ihn nach Bedarf ein- und ausschalten.

3 - Virtualisierter Server-Ansatz - P2Ven Sie Ihren vorhandenen Desktop und verwandeln Sie ihn in eine VM. Stellen Sie ihn dann auf eine kostenlose Version von ESXi. Sie behalten Ihren Desktop und können bei Bedarf über eine Konsole zu VM] wechseln. Dies kann langsam sein ...

4
Brennan

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 zum Remotestandort hergestellt haben.

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

netsh interface ipv4 delete dnsservers name = "Name des VPN" address = all validate = no

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

3
MichelZ

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.

2
dunxd

Ich hatte dieses Problem vor einigen Jahren und habe es durch Bearbeiten der VPN-Verbindungsdatei behoben. Erstellen Sie einfach eine vpn.pbk-Datei (Sie finden sie in Google). Öffnen Sie diese Datei über einen Texteditor wie den Editor und ändern Sie den UseRasCredentials-Wert auf Null. Das Problem ist gelöst. Das einzige Problem ist jedoch, dass die DNS-Priorität Ihrer lokalen Verbindungen höher ist als die von VPN-DNS und die Namensauflösung länger dauert (wenn VPN für die Verbindung zum Internet verwendet wird).

0
Mohsen Bigdeli

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

setenv opt block -side-dns

Das Problem wurde behoben

0
Ismail

Diese Frage wurde zwar schon vor langer Zeit gestellt, aber diese Antwort zu veröffentlichen, da dies anderen helfen kann. Ich hatte das gleiche Problem mit VPN, bei dem Benutzer, die eine Verbindung zu Remote-VPN herstellten, ihre externen DNS z. google.com Es wurden nur Unternehmensdomänen verwendet, die unter split-dns Aufgeführt wurden.

Problem war, wenn der verwendete lokale DNS-Abfrageverkehr zum VPN-Tunnel geleitet wird und wenn der DNS im Tunnel zulässig ist, fällt er zurück. Wenn es zurückfällt, wählt es zuerst IPv6 als Auflösung und kehrt dann nie mehr zu IPv4 zurück.

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

wenn Sie also die Firewall nicht steuern können und wissen, dass der geteilte Tunnel und die geteilten DNS vorhanden sind, dies jedoch fehlschlägt, können Sie versuchen, ipv6 auf dem lokalen Computer zu deaktivieren. Wenn Sie es steuern können, können Sie den obigen Befehl als aktivieren Solange Sie IPv6 nicht in Ihrem Remote-Netzwerk verwenden.

Das hat mir geholfen, hoffe das hilft anderen :)

0
Rsingh

Ja, 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 lokal für das VPN-LAN 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 Abfrage nslookup. Sie erhalten eine öffentliche IP-Adresse, dh Sie haben Ihren lokalen/ISP-DNS-Server verwendet, um die Abfrage der VPN-Domäne zu lösen. Bam !!!!

0
Graham.Fraser