La connexion VPN oblige DNS à utiliser un mauvais serveur DNS

17

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 «Application Data» 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, 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 sur nos serveurs DNS locaux plutôt que sur nos clients ?

La sortie de ipconfig /alllorsqu'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 de destination 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:

entrez la description de l'image ici

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 envoyer une requête ping à 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.32suivis 192.168.0.16, mais la requête va 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 semble affecter uniquement les racines DFS du domaine. Si je référence le partage via le nom du serveur (c'est- \\server\shareà- dire 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 la disparition de mes lecteurs réseau (DFS), mais j'aimerais toujours la partie en gras de ma question (ci-dessus) ) répondre si quelqu'un a des idées.

— Bryan
source

Vous n'avez jamais mentionné le pare-feu que vous utilisez? C'est un facteur assez important de l'OMI, car je pense que c'est là que vous allez potentiellement trouver la réponse à cette question.

— Hanny

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

— Bryan

Si le VPN n'est pas géré par le pare-feu mais par Windows, cela présente un autre paramètre envoyé pour fonctionner, car le VPN Windows est assez limité selon mon expérience. Par exemple, avec un ASA 5505 - le tunneling fractionné est quelque chose de vraiment facile à dépanner et il y a beaucoup de configuration qui peut être faite, en particulier en ce qui concerne les problèmes DNS et l'attribution de DNS. C'est pourquoi j'ai demandé, merci d'avoir clarifié.

— Hanny

Pourriez-vous s'il vous plaît ajouter un route print(de la connexion vpn) au message?

— florianb

Il n'y a rien de mal avec le routage, car il est capable de se connecter via IP, mais pas

— via

12

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 de 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 de la connexion est supprimée

S'il existe 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 20 fois l'entrée GUID en bas de la liste

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é. Étant donné que le GUID est en bas, la résolution DNS sera effectuée localement pour le 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.

— ZnArK
source

Bonne trouvaille. 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, ce qui devrait être une excellente solution à ce qui ne devrait pas être un problème en premier lieu. Merci beaucoup. Je vais donner quelques tests supplémentaires.

— Bryan

3

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 VPN. Feu alors 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 exécutez également ce script une fois avant de vous connecter au VPN.

— Steve B

4

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, car l'ordonnance contraignante indique différemment. Selon cet article 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!

— ank
source

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

— Bryan

Mise à jour, vient de rouvrir le tunnel et toutes mes connexions aux lecteurs ont chuté, mais la table de routage n'est pas différente de celle ci-dessus. c'est-à-dire Metric 20 pour LAN, Metric 21 pour VPN.

— Bryan

1

@Bryan, cet article Microsoft ( support.microsoft.com/kb/299540 ), en quelque sorte, vérifie 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 en avez le temps. D'autres ont signalé les problèmes intermittents exacts que vous voyez et les ont résolus en câblant les métriques ( serverfault.com/questions/70792/… ). Malheureusement, je n'ai actuellement pas de configuration similaire pour faire des tests.

— ank

Merci beaucoup pour ça @ank, je vais certainement essayer la semaine prochaine quand je serai de retour au bureau. Article intéressant BTW. Merci.

— Bryan

1

Ça a fait l'affaire pour moi! La métrique dans les paramètres IPv4 de la carte réseau ne semble avoir rien à voir avec la métrique dans la table de routage! La modification de l'ordre du GUID dans HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind comme ZnArK l'a écrit n'a rien changé en ce qui concerne le NIC / DNS utilisé. Ceci est testé sur Windows 10

— MrCalvin

4

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, la sécurité informatique gestapo va vous arrêter.

2 - Approche du bureau virtualisé - P2V votre bureau existant et transformez-le en machine virtuelle. Utilisez la machine virtuelle à VPN pour le client. Vous gardez votre bureau et pouvez y basculer et en sortir au besoin.

3 - Approche du serveur virtualisé - P2V votre bureau existant et transformez-le en une VM, puis mettez-le sur une version gratuite d'ESXi. Vous conservez votre bureau et pouvez passer à la machine virtuelle au besoin via une console. Cela peut être lent ...

— Brennan
source

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

— Bryan

3

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 dnsservers nom = " nom du VPN " adresse = tout valider = non

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

— MichelZ
source

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

— MichelZ

Le problème est que, dès que le tunnel est en place, je souffre déjà du problème décrit dans ma question, donc la commande sera trop tardive. De plus, après avoir expérimenté cela, la commande ne semble pas faire de différence ( nslookuputilise toujours le serveur DNS distant, et ipconfigrépertorie toujours le serveur DNS distant). J'ai également modifié les paramètres DNS de la connexion du tunnel VPN pour utiliser mes propres paramètres DNS internes, mais cela est ignoré, tout mon trafic DNS semble toujours se diriger vers le serveur DNS distant.

— Bryan

1

J'avais essayé cela car j'avais le même problème, et cela a fonctionné ici. Avez-vous ajusté le " nom du VPN "? De plus, si vous êtes préoccupé par la plupart du temps ce un serveur sur lequel vos disques sont connectés, l' ajouter dans votre fichier hosts, et rien ne pourra l' ignorer

— MichelZ

Merci, j'ai essayé de changer le nom (couper et coller à partir de la ipconfigsortie, et quand je me suis trompé, j'ai eu l'erreur The filename, directory name, or volume label syntax is incorrect), donc je suis presque sûr d'avoir la bonne commande. Cela pourrait être quelque chose sur le serveur PPTP distant ne me permettant pas de remplacer le paramètre DNS. Je vais enquêter, mais j'aime l'idée d'entrée du fichier hôtes. Je vais essayer. Voir également ma modification de la question.

— Bryan

Je viens de réessayer la commande et elle a supprimé le serveur DNS de la connexion PPP. Pourriez-vous vérifier avec ipconfig /all? Je pense cependant que l'entrée des hôtes devrait être la solution la plus simple pour vous.

— MichelZ

2

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.

— dunxd
source

Pour info, je peux accéder aux ressources réseau pendant que le tunnel est en place, c'est juste la résolution DNS qui semble casser. split tunnellingPour être honnête, je ne connaissais pas le terme , mais pour autant que je sache, cela implique simplement de m'assurer que je n'utilise pas la passerelle par défaut sur le site distant, ce que je fais déjà, malgré que je ne le précise pas. Merci pour la réponse, je vais modifier ma question pour refléter cela.

— Bryan

1

Dans ce cas, il semble que le VPN du client ne soit pas configuré pour un DNS partagé. Avec le DNS fractionné, 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 à utiliser avec ces serveurs DNS; tous les autres utiliseraient le DNS par défaut de votre système.

— James Sneeringer

0

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.comseuls les domaines de l'entreprise utilisés auparavant étaient répertoriés split-dns.

Le problème était quand la machine locale utilisée le trafic de requête DNS va vers le 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é la client-bypass-protocolcommande sur le pare-feu ASA qui ignorait 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 les désactiver ipv6sur 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 aide les autres :)

— Rsingh
source

0

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

— Graham.Fraser
source

0

Je supprime simplement cette option de la configuration VPN client

setenv opt block-outside-dns

Il a résolu le problème

— Ismail
source

0

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 l'é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).

— Mohsen Bigdeli
source

-1

Pourquoi pensez-vous que son DNS?

Si vous perdez l'accès à vos partages réseau lorsque vous vous connectez au VPN - il semble presque certainement que votre ordinateur rencontre des problèmes avec WINS / NETBIOS.

Définissez un serveur WINS et testez à nouveau.

— Ben Lessani - Sonassi
source

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 doivent utiliser les serveurs DNS utilisés pour héberger AD, et ce n'est pas le cas. Comme le problème n'apparaît que lorsque j'établis une connexion VPN et que ma résolution DNS devient délicate en même temps, il semble que DNS soit le candidat probable. Quoi qu'il en soit, je ne souhaite pas utiliser le serveur DNS distant lorsque je me connecte à un autre réseau à l'aide d'un VPN.

— Bryan

Avez-vous défini un serveur WINS selon ma suggestion? Il n'est pas typique de Windows d'utiliser le serveur DNS sur un VPN à moins que celui-ci ne soit défini ou que "Utiliser la passerelle distante soit défini", ce que vous avez dit est désactivé. Vous utilisez également une adresse IP statique sur le tunnel VPN, alors pourquoi avez-vous défini des entrées DNS? Supprimez ces serveurs DNS (192.168.0.16-17) ou définissez un serveur WINS.

— Ben Lessani - Sonassi

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

— Bryan

Je ne ai pas besoin , ni envie d'utiliser le serveur DNS à distance, jamais, je veux toujours la résolution DNS à effectuer sur le serveur local, ce sera résoudre mon problème, d' où ma question se concentrant sur DNS. Je pourrais probablement utiliser une règle de pare-feu pour bloquer l'accès au serveur DNS distant, mais cela ne résout pas le problème de mauvaise configuration sous-jacent.

— Bryan

1

votre interprétation de ceci est incorrecte. L'adresse IP est attribuée par le serveur PPTP, qui n'utilise pas réellement DHCP. Le serveur PPTP possède un pool à partir duquel il peut allouer, mais ce n'est pas DHCP. J'obtiens cependant une IP différente chaque fois que je me connecte. De plus, je n'ai pas non plus coché la case pour utiliser la passerelle distante, comme vous pouvez le voir clairement dans la table de routage.

— Bryan