La connexion VPN provoque l'utilisation incorrecte du serveur DNS.

Question

La connexion VPN provoque l'utilisation incorrecte du serveur DNS.

Demandé el 2 de Février, 2012: Quand la question a-t-elle été
121822 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

J'ai un PC Windows 7 sur notre réseau d'entreprise (qui est un membre de notre Active Directory). Tout fonctionne bien jusqu'à ce que j'ouvre une connexion VPN vers le site d'un client.

Lorsque je me connecte, je perds l'accès au réseau aux partages sur le réseau, y compris des répertoires tels que 'Application Data' pour lesquels nous avons une politique de redirection de dossier. Comme vous pouvez l'imaginer, cela rend très difficile de travailler sur le PC, car les raccourcis du bureau ne fonctionnent plus, les logiciels ne fonctionnent plus correctement en raison de l'extraction de 'Application Data' sous eux.

Notre réseau est routé (10.58.5.0/24), avec d'autres sous-réseaux locaux existant dans la plage de 10.58.0.0/16. Le réseau distant est sur 192.168.0.0/24.

J'ai identifié le problème comme étant lié au DNS. Dès que j'ouvre le tunnel VPN, tout mon trafic DNS passe par le réseau distant, ce qui explique la perte de ressources locales, mais ma question est, comment puis-je forcer les requêtes DNS locales à aller vers nos serveurs DNS locaux plutôt que ceux de nos clients?

La sortie de ipconfig /all lorsque je ne suis pas connecté au VPN est ci-dessous :

Configuration IP de Windows

   Nom d'hôte . . . . . . . . . . : 7k5xy4j
   Suffixe DNS principal  . . . . :
   Type de noeud . . . . . . . . . : Hybride
   Routage IP activé . . . . . . . : Non
   Proxy WINS activé . . . . . . . : Non
   Liste de recherche de suffixe DNS : mydomain.local

Adaptateur Ethernet Connexion au réseau local :

   Suffixe DNS propre à la connexion : mydomain.local
   Description . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Adresse physique . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP activé. . . . . . . . . . . : Oui
   Configuration automatique activée : Oui
   Adresse IPv6 de liaison locale . : fe80::9457:c5e0:6f10:b298%10(Préféré)
   Adresse IPv4. . . . . . . . . . : 10.58.5.89(Préféré)
   Masque de sous-réseau . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . : 31 janvier 2012 15:55:47
   Bail expirant. . . . . . . . . . : 10 février 2012 10:11:30
   Passerelle par défaut . . . . . : 10.58.5.1
   Serveur DHCP . . . . . . . . . .

Demandé el 2 de Février, 2012 par D.Spetz

0 votes

Vous n'avez jamais mentionné quel pare-feu vous utilisez? C'est un facteur assez important à mon avis, car je pense que c'est là que vous trouverez potentiellement la réponse à cette question.

Commenté el 20 de Juin, 2012 par iTechy

0 votes

@hanny le pare-feu est fourni par la translation d'adresse réseau sur les modems ADSL des deux sites. Je peux probablement fournir les numéros de modèle si vraiment nécessaire, mais ce seront simplement des modems ADSL NAT standard. Étant donné que nous parlons de AD avec DNS intégré, je ne considère pas que ces appareils soient pertinents, car les problèmes sont uniquement liés au DNS.

Commenté el 20 de Juin, 2012 par D.Spetz

0 votes

Si le VPN n'est pas géré par le pare-feu mais par Windows, cela présente un ensemble différent de paramètres à travailler, car le VPN Windows est assez limité selon mon expérience. Par exemple, avec un ASA 5505, le fractionnement du tunnel est quelque chose de vraiment facile à diagnostiquer et il y a beaucoup de configurations possibles, notamment en ce qui concerne les problèmes de DNS et l'attribution des DNS. C'est pourquoi j'ai demandé, merci pour la clarification.

Commenté el 20 de Juin, 2012 par iTechy

Afficher 5 autres commentaires

Answer 1

5 Réponses

Answer 2

11voto

ZnArK Points 629

OK, found a excellent resource here

It's not perfect, but could work.

The binding order is stored in the registry in the following location: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. The list includes all the device GUIDs for network adapters and active connections in the binding priority order.

When working with the registry key, the following facts emerge:

Changing the order of the GUIDs in the registry does impact the binding order, including for VPN connections

Any changes to the key take effect immediately

When a VPN connection is completed, the GUID for the connection is added to the top of the bind order if it does not already exist

When a VPN connection is closed, the GUID entry for the connection is removed

If there are multiple GUID entries for the connection, only one is removed when the connection is closed

This mechanism creates the possibility of the following workaround:

Examine the Bind registry key

Connect to your VPN connection

Check the Bind key again and copy the GUID that was added to the top of the list

Paste the GUID entry at the bottom of the list 20 times

Export the key and clean up the exported file to only include the bind key

The result is a key that will support the desired behavior. Every time a VPN connection is established, since the GUID is present, it will not be added. Since the GUID is at the bottom, DNS resolution will be done locally to the client. When the connection is disconnected, one GUID entry will be removed. After 20 VPN connections, the exported registry file can be used to reimport the key.

Of course, you can paste the GUID more times to reduce how often you have to reimport the key.

Also important to remember to redo this procedure if there are any changes to network adapters.

Répondu el 26 de Juin, 2012 par ZnArK (629 Points )

0 votes

Bon résultat. Cela fonctionne très bien, associé à un script de démarrage de l'ordinateur pour réinitialiser la valeur de la clé de registre à chaque démarrage, cela devrait être une excellente solution de contournement pour ce qui ne devrait pas être un problème en premier lieu. Merci beaucoup. Je vais faire quelques tests supplémentaires.

Commenté el 26 de Juin, 2012 par D.Spetz

3 votes

Je recommanderais de créer une tâche planifiée. Surveillez l'ID d'événement 20226, qui correspond à l'événement de déconnexion du VPN. Ensuite, lancez un petit script powershell (powershell -File c:\scripts\fixdnsbind.ps1) qui contient : $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. (n'oubliez pas d'adapter l'ID de l'adaptateur). Vous pouvez également exécuter ce script une fois avant de vous connecter au VPN.

Commenté el 12 de Août, 2013 par Asad

0 votes

Dans ma situation, JVM et seulement JVM choisissait un serveur DNS incorrect reçu par DHCP pour la connexion locale. Il est impossible de le supprimer via netsh mais seulement via le registre: Cette réponse a aidé dans ma situation superuser.com/questions/392269/…

Commenté el 6 de Août, 2020 par Puterdo Borato

Answer 3

5voto

richsage Points 12266

Il me semble que le tunnel VPN prend somehow precedence sur l'interface de réseau local dirigeant le trafic DNS vers les serveurs DNS VPN (vous pourriez vérifier la requête sur ces serveurs pour vérifier ce comportement si vous y avez accès ou quelqu'un peut vérifier ce comportement pour vous).

Que je ne peux pas, entièrement, expliquer depuis l'ordre de liaison indique différemment. Selon ce post ici (voir la réponse avec le score le plus élevé) Windows a une perception différente en ce qui concerne ceci, en choisissant un canal de priorité plus élevée en fonction de la vitesse de la connexion et non pas sur l'ordre de liaison de l'adaptateur. Donc pour tester, essayez ce qui suit pour changer ce comportement automatique : 1) allez dans Connexions réseau et pour chacune d'entre elles 2) Propriétés IP v4 3) Avancé 4) Désactivez "Métrique automatique" 5) Mettez manuellement une métrique de 1 pour votre connexion locale et une métrique de 2 sur votre connexion VPN (PPP). De cette façon, cela câblera un peu plus le chemin vers les serveurs DNS locaux comme préférés plutôt que les serveurs DNS distants.

J'espère que cela vous aidera!

Répondu el 21 de Juin, 2012 par richsage (12266 Points )

0 votes

Intéressant, en regardant ma table de routage ci-dessus, la métrique sur l'interface LAN est la plus basse (20), la connexion VPN a une métrique de 21. Cela étant dit, ce problème peut être quelque peu intermittent, et avec la table de routage telle qu'affichée ci-dessus, tout fonctionne actuellement correctement. Je vais essayer de recréer le problème et de vérifier à nouveau la table de routage.

Commenté el 21 de Juin, 2012 par D.Spetz

0 votes

Mise à jour, je viens de rouvrir le tunnel, et toutes mes connexions aux lecteurs ont été interrompues, mais la table de routage est la même qu'auparavant. c'est-à-dire, Métrique 20 pour le LAN, Métrique 21 pour le VPN.

Commenté el 21 de Juin, 2012 par D.Spetz

1 votes

@Bryan, cet article Microsoft (support.microsoft.com/kb/299540), en quelque sorte, confirme ce que j'ai dit ci-dessus. Il serait intéressant de voir ce qui se passe si vous suivez la procédure que j'ai écrite ci-dessus lorsque vous avez le temps. D'autres ont signalé les mêmes problèmes intermittents que vous voyez et les ont résolus en câblant les métriques (serverfault.com/questions/70792/…). Malheureusement, je n'ai actuellement pas une configuration similaire pour faire quelques tests.

Commenté el 22 de Juin, 2012 par richsage

Afficher 2 autres commentaires

Answer 4

3voto

MichelZ Points 10938

Malheureusement, Windows VPN n'est pas capable de faire du "Split-DNS". Cependant, vous pouvez supprimer le serveur DNS de la connexion VPN après vous être connecté au site distant.

Vous pouvez le faire en tapant :

netsh interface ipv4 delete dnsservers name="nom du VPN" address=all validate=no

Vous DEVEZ faire cela chaque fois que vous vous connectez au réseau VPN.

Répondu el 20 de Juin, 2012 par MichelZ (10938 Points )

1 votes

FYI... cela vous empêche d'utiliser le DNS distant (VPN).

Commenté el 20 de Juin, 2012 par MichelZ

0 votes

Le problème est que dès que le tunnel est établi, je souffre déjà du problème décrit dans ma question, donc la commande sera trop tard. De plus, après avoir expérimenté avec cela, la commande ne semble pas faire de différence (nslookup utilise toujours le serveur DNS distant, en plus de ipconfig qui liste toujours le serveur DNS distant). J'ai également modifié les paramètres DNS pour la connexion au tunnel VPN afin d'utiliser mes propres paramètres DNS internes, mais cela est ignoré, tout mon trafic DNS semble toujours partagé vers le serveur DNS distant.

Commenté el 20 de Juin, 2012 par D.Spetz

1 votes

J'avais essayé cela comme j'avais le même problème, et cela a fonctionné ici. Avez-vous ajusté le "nom du VPN"? De plus, si vous êtes principalement préoccupé par ce serveur sur lequel vos lecteurs sont connectés, ajoutez-le dans votre fichier hosts et rien ne pourra le remplacer.

Commenté el 20 de Juin, 2012 par MichelZ

Afficher 8 autres commentaires

Answer 5

3voto

pyronaur Points 111

Comme indiqué, il s'agit d'un problème de fractionnement du tunnel.

Trois solutions, je recommande la #2 car elle est facile et offrira de bonnes performances si vous utilisez une bonne boîte avec VMware Workstation 8

1 - Activer le fractionnement du tunnel - non sécurisé et peut nécessiter du travail du côté du client. Peu probable, la Gestapo de la sécurité informatique va vous arrêter.

2 - Approche du bureau virtualisé - P2V votre bureau existant et créez une machine virtuelle. Utilisez la machine virtuelle pour vous connecter en VPN au client. Vous conservez votre bureau et pouvez basculer dedans et dehors selon vos besoins.

3 - Approche du serveur virtualisé - P2V votre bureau existant et créez une machine virtuelle, puis placez-la sur une version gratuite de l'ESXi. Vous conservez votre bureau et pouvez basculer vers la machine virtuelle selon vos besoins via une console. Cela pourrait être lent...

Répondu el 23 de Juin, 2012 par pyronaur (111 Points )

0 votes

+1; J'aime l'idée d'avoir un système virtualisé dédié pour la tâche, cependant je ne vois pas cela fonctionner bien ici à ce stade pour diverses raisons. Ce sera certainement une bonne solution à l'avenir cependant. Merci.

Commenté el 26 de Juin, 2012 par D.Spetz

Answer 6

1voto

dunxd Points 9390

Votre tunnel VPN est entre le client et le réseau du client. Il semble qu'il n'utilise pas de fractionnement de tunnel, ce qui vous empêchera d'accéder aux ressources de votre propre réseau lorsque le tunnel est actif.

Donc, vous (ou votre client) devez activer le fractionnement du tunnel, ou vous avez besoin d'une connexion réseau supplémentaire et d'une table de routage personnalisée pour accéder aux deux réseaux en même temps.

Répondu el 2 de Février, 2012 par dunxd (9390 Points )

0 votes

Pour info, je peux accéder aux ressources du réseau lorsque le tunnel est activé, c'est juste la résolution DNS qui semble poser problème. Je n'étais pas familier avec le terme split tunneling pour être honnête, mais autant que je sache, cela implique simplement de s'assurer que je n'utilise pas la passerelle par défaut sur le site distant, ce que je fais déjà malgré le fait de ne pas l'avoir spécifié. Merci pour la réponse, je vais modifier ma question pour refléter cela.

Commenté el 2 de Février, 2012 par D.Spetz

1 votes

Dans ce cas, il semble que le VPN du client ne soit pas configuré pour le DNS split. Avec le DNS split, le concentrateur VPN donne à votre client VPN une liste de serveurs DNS (comme il le fait actuellement), ainsi qu'une liste de domaines qui sont les seuls domaines à être utilisés avec ces serveurs DNS; tous les autres utiliseraient le DNS par défaut de votre système.

Commenté el 21 de Juin, 2012 par James Sneeringer

La connexion VPN provoque l'utilisation incorrecte du serveur DNS.

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

La connexion VPN provoque l'utilisation incorrecte du serveur DNS.

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: