La connexion VPN oblige DNS à utiliser un mauvais serveur DNS
J'ai un PC Windows 7 sur notre réseau d'entreprise (qui est membre de notre Active Directory). Tout fonctionne bien jusqu'à ce que j'ouvre une connexion VPN au site d'un client.
Lorsque je me connecte, je perds l'accès réseau aux partages sur le réseau, y compris les répertoires tels que "Données d'application" pour lesquels nous avons une politique de redirection de dossiers. Comme vous pouvez l'imaginer, cela rend le travail sur le PC très difficile, car les raccourcis du bureau cessent de fonctionner, le logiciel cesse de fonctionner correctement en raison de l'extraction des `` données d'application ''.
Notre réseau est routé (10.58.5.0/24), avec d'autres sous-réseaux locaux existant dans le cadre 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, tous 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 sur nos serveurs DNS locaux plutôt que sur nos clients?
La sortie de ipconfig /all lorsqu'il n'est pas connecté au VPN est ci-dessous:
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
C'est la sortie de la même commande avec le tunnel VPN connecté:
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
Table de routage
Métrique d'interface de passerelle de masque de réseau
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
L'ordre de liaison pour les interfaces est le suivant:
Je n'ai pas configuré le tunnel VPN pour utiliser la passerelle par défaut à l'extrémité distante, et les communications réseau vers les nœuds des deux réseaux sont correctes. (c'est-à-dire que je peux cingler n'importe quel nœud de notre réseau ou du réseau distant).
J'ai modifié les propriétés de connexion PPTP pour utiliser les serveurs DNS 10.58.3.32 suivi par 192.168.0.16, mais la requête passe toujours à 192.168.0.16.
Éditer:
Les ressources locales qui disparaissent sont hébergées sur les racines DFS du domaine, qui peuvent (ou non) être pertinentes.
Modifier davantage:
Cela ne semble affecter que les racines du domaine DFS. Si je référence le partage via le nom du serveur (c'est-à-dire \\server\share au lieu de \\dfsroot\share), Je peux accéder aux partages.
Selon mon commentaire contre cette réponse , j'ai trouvé que je peux ajouter le nom DNS du domaine à mon fichier d'hôtes, ce qui empêche mes lecteurs réseau (DFS) de disparaître, mais j'aimerais quand même le partie audacieuse de ma question (ci-dessus) répondant si quelqu'un a des idées.
OK, j'ai trouvé une excellente ressource ici: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/
Ce n'est pas parfait, mais pourrait bien fonctionner.
L'ordre de liaison est stocké dans le registre à l'emplacement suivant:
HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. La liste inclut tous les GUID de périphérique pour les cartes réseau et les connexions actives dans l'ordre de priorité de liaison.Lorsque vous travaillez avec la clé de registre, les faits suivants apparaissent:
La modification de l'ordre des GUID dans le registre a un impact sur l'ordre de liaison, y compris pour les connexions VPN
- Toute modification de la clé prend effet immédiatement
- Lorsqu'une connexion VPN est établie, le GUID pour la connexion est ajouté en haut de l'ordre de liaison s'il n'existe pas déjà
- Lorsqu'une connexion VPN est fermée, l'entrée GUID pour la connexion est supprimée
- S'il y a plusieurs entrées GUID pour la connexion, une seule est supprimée lorsque la connexion est fermée
Ce mécanisme crée la possibilité de la solution de contournement suivante:
- Examiner la clé de registre Bind
- Connectez-vous à votre connexion VPN
- Vérifiez à nouveau la clé de liaison et copiez le GUID qui a été ajouté en haut de la liste
- Collez l'entrée GUID en bas de la liste 20 fois
- Exportez la clé et nettoyez le fichier exporté pour inclure uniquement la clé de liaison
Le résultat est une clé qui prendra en charge le comportement souhaité. Chaque fois qu'une connexion VPN est établie, puisque le GUID est présent, il ne sera pas ajouté. Comme le GUID est en bas, la résolution DNS sera fait localement au client. Lorsque la connexion est déconnectée, une entrée GUID sera supprimée. Après 20 connexions VPN, le fichier de registre exporté peut être utilisé pour réimporter la clé.
Bien sûr, vous pouvez coller le GUID plusieurs fois pour réduire la fréquence de réimportation de la clé.
N'oubliez pas non plus de recommencer cette procédure en cas de modification des adaptateurs réseau.
Il me semble que le tunnel VPN a en quelque sorte la priorité sur l'interface de la zone locale dirigeant le trafic DNS vers les serveurs DNS VPN (vous pouvez vérifier la demande sur ces serveurs pour vérifier ce comportement si vous y avez accès ou quelqu'un peut vérifier ce comportement pour vous).
Cela, je ne peux pas l'expliquer entièrement, car l'ordonnance contraignante indique différemment. En fonction de cela publier ici (voir la réponse avec le score le plus élevé) Windows a une perception différente en ce qui concerne ce choix, en choisissant un canal de priorité plus élevée en fonction de la vitesse de la connexion PAS sur l'ordre de liaison de l'adaptateur. Donc, pour des raisons de test, essayez ce qui suit pour changer ce comportement automatique: 1) allez dans Connexions réseau et pour chacune, faites 2) Propriétés IP v4 3) Avancé 4) Désactivez "Automatic Metric" 5) Mettez manuellement une métrique de 1 pour votre local connexion et une métrique de 2 sur votre connexion VPN (PPP). De cette façon, il triera en dur le chemin vers les serveurs DNS locaux comme préféré au DNS distant.
J'espère que cela t'aides!
Comme indiqué, il s'agit d'un problème de tunneling divisé.
Trois correctifs, recommandez # 2 car il est facile et aura de bonnes performances si vous utilisez une bonne boîte avec VMware Workstation 8
1 - Activer le tunneling fractionné - non sécurisé et peut nécessiter un travail du côté client. Il est peu probable que cela se produise, gestapo de sécurité informatique va vous arrêter.
2 - Approche du bureau virtualisé - P2V votre bureau existant et transformez-le en machine virtuelle. Utilisez le VM pour VPN au client. Vous gardez votre bureau et pouvez y basculer et en sortir si nécessaire.
3 - Approche serveur virtualisé - P2V votre bureau existant et transformez-le en VM, puis mettez-le sur une version gratuite d'ESXi. Vous gardez votre bureau et pouvez basculer vers le VM selon les besoins via une console. Cela peut être lent ...
Malheureusement, Windows VPN n'est pas en mesure de faire "Split-DNS". Vous pouvez cependant supprimer le serveur DNS de la connexion VPN après vous être connecté au site distant.
Vous pouvez le faire en émettant:
interface netsh ipv4 supprimer nom du serveur DNS = "nom du VPN" adresse = tout valider = non
Vous DEVEZ le faire chaque fois que vous vous connectez au réseau VPN.
Votre tunnel VPN est entre le client et le réseau client. On dirait qu'il n'utilise pas de tunneling fractionné, ce qui vous empêchera d'accéder aux ressources sur votre propre réseau pendant que le tunnel est en place.
Ainsi, vous (ou votre client) devez activer le tunneling fractionné, 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.
J'ai eu ce problème il y a quelques années et corrigé en modifiant le fichier de connexion VPN, créez simplement un fichier vpn.pbk (vous pouvez le trouver dans Google) ouvrez ce fichier via un éditeur de texte comme le bloc-notes et changez la valeur UseRasCredentials à zéro et votre problème est résolu. mais le seul problème est que vos connexions locales ont une priorité DNS supérieure à VPN DNS et que la résolution de nom prend plus de temps (si VPN est utilisé pour se connecter à Internet).
Je supprime simplement cette option de la configuration VPN client
setenv opt block-outside-dns
Il a résolu le problème
Bien que cette question ait été posée depuis longtemps, mais poster cette réponse car cela peut aider les autres. J'ai eu le même problème avec VPN où lorsque les utilisateurs se connectaient à un VPN distant, leur DNS externe s'arrêtait par exemple. google.com uniquement les domaines de l'entreprise utilisés auparavant qui étaient répertoriés sur split-dns.
Le problème était quand la machine locale utilisée le trafic de requête DNS va au tunnel vpn et si le DNS est autorisé dans le tunnel, il retombe. Quand il se repliait, il choisissait d'abord ipv6 comme résolution, puis ne revenait jamais à ipv4.
Donc, pour tester les résultats, nous avons d'abord désactivé l'ipv6 sur la machine locale, il a commencé à fonctionner. Pour le corriger définitivement pour tous les utilisateurs, nous avons activé client-bypass-protocol commande sur le pare-feu ASA qui a ignoré IPv6 s'il n'est pas configuré sur les pools vpn.
donc si vous ne pouvez pas contrôler le pare-feu et que le tunnel partagé et les DNS partagés sont en place mais qu'il échoue, vous pouvez essayer de désactiver ipv6 sur la machine locale et si vous pouvez la 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 aide les autres :)
Ouais quelque chose que j'ai vécu!
Définissez 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 adresse IP locale au réseau local VPN. Cela signifie que vous avez utilisé les serveurs DNS VPN pour résoudre la requête.
Ouvrez maintenant votre connexion LAN et définissez manuellement le DNS sur votre DNS local ou FAI. une Volia !!! utilisez la touche fléchée et répétez la requête nslookup. Vous recevrez une adresse IP publique, ce qui signifie que vous avez utilisé votre serveur DNS local/FAI pour résoudre la requête du domaine VPN. Bam !!!!