22 votes

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

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 . . . . . . . . . .

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.

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.

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.

0voto

Graham.Fraser Points 159

Hourra quelque chose avec quoi j'ai de l'expérience!

Configurez la connexion VPN avec le serveur DNS local et connectez-vous au VPN utilisé nslookup pour interroger le nom de domaine VPN. Vous devriez obtenir une réponse avec une IP qui est locale au LAN VPN. Cela signifie que vous avez utilisé les serveurs DNS VPN pour résoudre la requête.

Maintenant, ouvrez votre connexion LAN et configurez manuellement le DNS vers votre DNS local ou celui de votre FSI. un Volia!!! utilisez la touche flèche et répétez la requête nslookup. Vous recevrez une IP publique signifiant que vous avez utilisé votre serveur DNS local/FSI pour résoudre la requête du domaine VPN. Bam!!!!

0voto

Rsingh Points 1

Bien que cette question ait été posée il y a longtemps, je poste cette réponse car cela peut aider d'autres personnes. J'avais le même problème avec le VPN où lorsque les utilisateurs se connectaient au VPN distant, leur DNS externe s'arrêtait par exemple. google.com seul les domaines de l'entreprise fonctionnaient, qui étaient répertoriés dans split-dns.

Le problème était que lorsque la machine locale effectuait une requête DNS, le trafic passait par le tunnel VPN et, si le DNS était autorisé dans le tunnel, il échouait. Lorsqu'il échouait, il commençait alors à utiliser IPv6 comme résolution en premier et ne retournait jamais à IPv4.

Donc, pour tester les résultats, nous avons d'abord désactivé l'IPv6 sur la machine locale et cela a commencé à fonctionner. Pour le corriger de manière permanente pour tous les utilisateurs, nous avons activé la commande client-bypass-protocol sur le pare-feu ASA, qui ignorait IPv6 s'il n'était pas configuré sur les pools VPN.

Donc, si vous ne pouvez pas contrôler le pare-feu et que vous savez que le tunnel fractionné et le DNS fractionné sont en place mais que cela échoue, vous pouvez essayer de désactiver ipv6 sur la machine locale et si vous pouvez le contrôler, vous pouvez activer la commande ci-dessus tant que vous n'utilisez pas IPv6 dans votre réseau distant.

Cela m'a aidé, j'espère que cela aidera d'autres personnes :)

0voto

Ismail Points 1

Je supprime simplement cette option de la configuration VPN du client

setenv opt block-outside-dns

Le problème a été résolu

0voto

Anant Points 61

J'ai eu ce problème il y a quelques années et je l'ai corrigé en éditant le fichier de connexion VPN. Il suffit de créer un fichier vpn.pbk (que vous pouvez trouver sur Google), d'ouvrir ce fichier via un éditeur de texte tel que le bloc-notes, de changer la valeur de UseRasCredentials à zéro et votre problème est résolu. Mais le seul problème est que la priorité DNS des connexions de votre réseau local devient plus élevée que celle du VPN et la résolution des noms prend plus de temps (si le VPN est utilisé pour se connecter à Internet).

-1voto

Ben Lessani Points 5146

Pourquoi pensez-vous que c'est le DNS?

Si vous perdez l'accès à vos partages réseau lorsque vous vous connectez au VPN, il semble presque certain que votre machine a des difficultés avec WINS / NETBIOS.

Définissez un serveur WINS et testez à nouveau.

0 votes

Je ne sais pas avec certitude que c'est la cause de mes problèmes, mais ce que je sais, c'est que les clients AD devraient utiliser les serveurs DNS qui sont utilisés pour héberger AD, et ce n'est pas le cas. Comme le problème ne se manifeste que lorsque je me connecte en VPN, et que ma résolution DNS devient défectueuse en même temps, il semble que DNS soit le candidat le plus probable. Quoi qu'il en soit, je ne veux pas utiliser le serveur DNS distant lorsque je me connecte à un autre réseau en utilisant VPN.

0 votes

Avez-vous défini un serveur WINS comme je l'ai suggéré? Il n'est pas typique de Windows d'utiliser le serveur DNS sur un VPN à moins que vous ne l'ayez défini ou que "Utiliser la passerelle distante" soit activé, ce que vous avez dit être désactivé. De plus, vous utilisez une adresse IP statique sur le tunnel VPN, pourquoi avez-vous défini des entrées DNS? Supprimez ces serveurs DNS (192.168.0.16-17) ou définissez un serveur WINS.

0 votes

Non, je n'ai pas essayé cela car nous n'avons pas de serveur WINS vers lequel pointer les clients. Je ne suis pas convaincu que WINS aidera honnêtement, donc je ne suis pas enthousiaste à l'idée d'installer un serveur WINS sur notre réseau parce que cela pourrait aider. Je vais certainement garder l'idée à l'esprit cependant, donc merci. L'IP est assignée par le serveur VPN et est dynamique. Si je n'attribue pas de serveur DNS pour la connexion VPN, il est assigné dynamiquement par le serveur. J'ai même codé en dur mes propres serveurs DNS dans les propriétés de la connexion VPN, pourtant il utilise toujours les serveurs DNS du site distant.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X