La conexión VPN hace que DNS use un servidor DNS incorrecto

17

Tengo una PC con Windows 7 en la red de nuestra empresa (que es miembro de nuestro Active Directory). Todo funciona bien hasta que abro una conexión VPN al sitio de un cliente.

Cuando me conecto, pierdo el acceso de red a los recursos compartidos en la red, incluidos los directorios como 'Datos de aplicación' para los que tenemos una política de redireccionamiento de carpetas. Como puede imaginar, esto hace que trabajar en la PC sea muy difícil, ya que los accesos directos de escritorio dejan de funcionar, el software deja de funcionar correctamente debido a que se extraen los 'Datos de la aplicación'.

Nuestra red está enrutada (10.58.5.0/24), con otras subredes locales existentes dentro del alcance de 10.58.0.0/16. La red remota está en 192.168.0.0/24.

He rastreado el problema hasta estar relacionado con DNS. Tan pronto como abro el túnel VPN, todo mi tráfico DNS pasa a través de la red remota, lo que explica la pérdida de recursos locales, pero mi pregunta es, ¿cómo puedo forzar las consultas DNS locales para que vayan a nuestros servidores DNS locales en lugar de a nuestros clientes? ?

La salida de ipconfig /allcuando no está conectado a la VPN es la siguiente:

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

Esta es la salida del mismo comando con el túnel VPN conectado:

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

Tabla de ruteo

Red Destino Netmask Gateway Interfaz Métrica

          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

El orden de enlace para las interfaces es el siguiente:

ingrese la descripción de la imagen aquí

No he configurado el túnel VPN para usar la puerta de enlace predeterminada en el extremo remoto, y las comunicaciones de red a los nodos en ambas redes están bien. (es decir, puedo hacer ping a cualquier nodo en nuestra red o en la red remota).

He modificado las propiedades de conexión PPTP para usar los servidores DNS 10.58.3.32seguidos 192.168.0.16, pero la consulta todavía va a 192.168.0.16.

Editar:

Los recursos locales que desaparecen se alojan en raíces DFS de dominio, que pueden (o no) ser relevantes.

Edición adicional:

Esto solo parece estar afectando las raíces del dominio DFS. Si hago referencia al recurso compartido a través del nombre del servidor (es decir, en \\server\sharelugar de \\dfsroot\share), puedo acceder a los recursos compartidos.

Según mi comentario en contra de esta respuesta , descubrí que puedo agregar el nombre DNS del dominio a mi archivo de hosts, lo que impide que mis unidades de red (DFS) desaparezcan, pero aún me gustaría la parte en negrita de mi pregunta (arriba ) respondiendo si alguien tiene alguna idea.

— Bryan
fuente

¿Nunca mencionaste qué firewall estás usando? Ese es un factor IMO bastante importante, ya que creo que allí es donde potencialmente encontrarás la respuesta a esta pregunta.

— Hanny

@hanny el firewall es proporcionado por la traducción de direcciones de red en los módems ADSL en ambos sitios. Probablemente pueda proporcionar números de modelo si realmente los necesito, pero serán simplemente módems ADSL NATing estándar. Dado que estamos hablando de AD con DNS integrado, no considero que estos dispositivos sean relevantes, ya que los problemas son puramente DNS.

— Bryan

Si el cortafuegos no maneja la VPN sino Windows, entonces eso presenta un envío diferente de parámetros para trabajar dentro, ya que la VPN de Windows es bastante limitada en mi experiencia. Por ejemplo, con un ASA 5505: la tunelización dividida es algo realmente fácil de solucionar y hay una gran cantidad de configuración que se puede hacer, especialmente con respecto a los problemas de DNS y la asignación de DNS. Por eso pregunté, gracias por aclarar.

— Hanny

¿Podría agregar un route print(desde la conexión vpn) a la publicación?

— florianb

No hay nada malo con el enrutamiento, ya que puede conectarse a través de IP, pero no a través de DNS

— MichelZ

12

OK, encontré un gran recurso aquí: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

No es perfecto, pero podría funcionar.

El orden de enlace se almacena en el registro en la siguiente ubicación: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. La lista incluye todos los GUID de dispositivo para adaptadores de red y conexiones activas en el orden de prioridad de enlace.

Cuando se trabaja con la clave de registro, surgen los siguientes hechos:

Cambiar el orden de los GUID en el registro impacta el orden de enlace, incluso para las conexiones VPN

Cualquier cambio en la clave surte efecto inmediatamente

Cuando se completa una conexión VPN, el GUID para la conexión se agrega a la parte superior del orden de enlace si aún no existe

Cuando se cierra una conexión VPN, se elimina la entrada GUID para la conexión

Si hay varias entradas GUID para la conexión, solo se elimina una cuando se cierra la conexión

Este mecanismo crea la posibilidad de la siguiente solución:

Examine la clave de registro Bind

Conéctese a su conexión VPN

Verifique nuevamente la clave de enlace y copie el GUID que se agregó al principio de la lista

Pegue la entrada GUID al final de la lista 20 veces

Exporte la clave y limpie el archivo exportado para incluir solo la clave de enlace

El resultado es una clave que respaldará el comportamiento deseado. Cada vez que se establece una conexión VPN, ya que el GUID está presente, no se agregará. Como el GUID está en la parte inferior, la resolución de DNS se realizará localmente para el cliente. Cuando se desconecta la conexión, se eliminará una entrada de GUID. Después de 20 conexiones VPN, el archivo de registro exportado se puede usar para volver a importar la clave.

Por supuesto, puede pegar el GUID más veces para reducir la frecuencia con la que tiene que volver a importar la clave.

También es importante recordar rehacer este procedimiento si hay algún cambio en los adaptadores de red.

— ZnArK
fuente

Buen descubrimiento. Eso funciona muy bien, junto con un script de inicio de la computadora para restablecer el valor de la clave de registro en cada arranque, eso debería ser una gran solución a lo que no debería ser un problema en primer lugar. Muchas gracias. Le daré algunas pruebas adicionales.

— Bryan

3

Recomiendo crear una tarea programada. Supervise el evento ID 20226, que corresponde al evento de desconexión de VPN. A continuación, disparar un pequeño script de PowerShell ( powershell -File c:\scripts\fixdnsbind.ps1) que contiene:

$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

. (no olvide adaptar la ID del adaptador). También ejecuta este script una vez antes de conectarse a la VPN.

— Steve B

4

Me parece que el túnel VPN de alguna manera tiene prioridad sobre la interfaz de área local que dirige el tráfico DNS a los servidores DNS VPN (puede verificar la solicitud en estos servidores para verificar este comportamiento si tiene acceso a ellos o alguien puede verificar este comportamiento para tú).

Eso no puedo explicarlo por completo, ya que el orden vinculante indica lo contrario. De acuerdo con esta publicación aquí (vea la respuesta de mayor puntuación) Windows tiene una percepción diferente cuando se trata de esto, eligiendo un canal de mayor prioridad dependiendo de la velocidad de la conexión NO en el orden de enlace del adaptador. Entonces, por el bien de las pruebas, intente lo siguiente para cambiar este comportamiento automático: 1) vaya a Conexiones de red y para cada una haga 2) Propiedades de IP v4 3) Avanzado 4) Deshabilite "Métrica automática" 5) Coloque manualmente una métrica de 1 para su local conexión y una métrica de 2 en su conexión VPN (PPP). De esa forma, conectará de forma rígida la ruta a los servidores DNS locales como se prefiere sobre el DNS remoto.

¡Espero que esto ayude!

— ank
fuente

Interesante, mirando mi tabla de enrutamiento anterior, la métrica en la interfaz LAN es la más baja (20), la conexión VPN tiene una métrica de 21. Dicho esto, este problema puede ser algo intermitente y con la tabla de enrutamiento como se muestra arriba , todo está funcionando correctamente actualmente. Intentaré recrear el problema y volver a verificar la tabla de enrutamiento.

— Bryan

Actualización, acabo de volver a abrir el túnel, y todas mis conexiones a unidades han caído, pero la tabla de enrutamiento no es diferente a la anterior. es decir, Metric 20 para LAN, Metric 21 para VPN.

— Bryan

1

@Bryan, este artículo de Microsoft ( support.microsoft.com/kb/299540 ) verifica lo que dije anteriormente. Sería interesante ver qué sucede si sigues el procedimiento que escribí anteriormente cuando tienes tiempo. Otros han informado de los problemas intermitentes exactos que ve y lo han resuelto conectando las métricas ( serverfault.com/questions/70792/… ). Desafortunadamente, actualmente no tengo una configuración similar para hacer algunas pruebas.

— ank

Muchas gracias por ese @ank, sin duda lo intentaré la próxima semana cuando vuelva a la oficina. Interesante artículo por cierto. Gracias.

— Bryan

1

¡Hizo el truco para mí! ¡La metrix en la configuración de IPv4 para la NIC no parece tener nada que ver con la metrix en la tabla de enrutamiento! Cambiar el orden de GUID en HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind como ZnArK escribió sobre no cambió nada con respecto a qué NIC / DNS se utiliza. Esto se prueba en Windows 10

— MrCalvin el

4

Como se dijo, este es un problema de túnel dividido.

Tres soluciones, recomiende # 2 porque es fácil y tendrá un buen rendimiento si usa una buena caja con VMware Workstation 8

1 - Habilite el túnel dividido: inseguro y puede requerir trabajo del lado del cliente. No es probable que suceda, la gestapo de seguridad de TI lo va a cerrar.

2 - Enfoque de escritorio virtualizado - P2V su escritorio existente y convertirlo en una VM. Use la VM a VPN para el cliente. Mantiene su escritorio y puede cambiarlo dentro y fuera de él según sea necesario.

3 - Enfoque de servidor virtualizado: ponga P2V en su escritorio existente y conviértalo en una VM, luego póngalo en una versión gratuita de ESXi. Mantiene su escritorio y puede cambiar a la VM según sea necesario a través de una consola. Esto puede ser lento ...

— Brennan
fuente

+1; Me gusta la idea de tener un sistema virtualizado dedicado para la tarea, sin embargo, no veo que funcione bien aquí en este momento por varias razones. Sin embargo, esta será definitivamente una buena solución en el futuro. Gracias.

— Bryan

3

Desafortunadamente, Windows VPN no puede hacer "DNS dividido". Sin embargo, puede eliminar el servidor DNS de la conexión VPN después de haberse conectado al sitio remoto.

Puede hacer esto emitiendo:

netsh interface ipv4 delete dnsservers name = " nombre de la VPN " address = all validate = no

DEBE hacer esto cada vez que se conecte a la red VPN.

— MichelZ
fuente

FYI ... esto le impide usar el DNS remoto (VPN).

— MichelZ

El problema es que, tan pronto como el túnel esté arriba, ya estoy sufriendo el problema descrito en mi pregunta, por lo que el comando será demasiado tarde. Además, después de experimentar con esto, el comando en realidad no parece hacer ninguna diferencia ( nslookuptodavía usa el servidor DNS remoto, y ipconfigaún así enumera el servidor DNS remoto). También he editado la configuración de DNS para la conexión del túnel VPN para usar mi propia configuración de DNS interna, pero esto se ignora, todo mi tráfico de DNS todavía parece dirigirse al servidor DNS remoto.

— Bryan

1

Había intentado esto porque tenía el mismo problema, y funcionó aquí. ¿Has ajustado el " nombre de la VPN "? Además, si usted se refiere sobre todo acerca de este uno servidor donde sus unidades están conectadas a, agregarlo en su archivo de hosts, y nada será capaz de anularlo

— MichelZ

Gracias, intenté cambiar el nombre (cortar y pegar desde la ipconfigsalida, y cuando me equivoqué, obtuve el error The filename, directory name, or volume label syntax is incorrect), así que estoy bastante seguro de que obtuve el comando correcto. Podría ser algo en el servidor PPTP remoto que no me permite anular la configuración de DNS. Investigaré, pero me gusta la idea de entrada del archivo de hosts. Voy a intentarlo. También vea mi edición de la pregunta.

— Bryan

Acabo de probar el comando nuevamente y eliminó el Servidor DNS de la conexión PPP. ¿Podrías verificar con ipconfig /all? Sin embargo, creo que la entrada de hosts debería ser la solución más fácil para usted.

— MichelZ

2

Su túnel VPN está entre el cliente y la red del cliente. Parece que no está usando un túnel dividido, lo que le impedirá acceder a los recursos en su propia red mientras el túnel esté activo.

Por lo tanto, usted (o su cliente) necesita habilitar el túnel dividido, o necesita una conexión de red adicional y una tabla de ruta personalizada para acceder a ambas redes al mismo tiempo.

— dunxd
fuente

Para obtener información, puedo acceder a los recursos de la red mientras el túnel está activo, es solo la resolución DNS que parece romperse. No estaba familiarizado con el término split tunnellingpara ser honesto, pero por lo que puedo decir, eso solo implica asegurarse de que no estoy usando la puerta de enlace predeterminada en el sitio remoto, que a pesar de no especificar, ya lo estoy haciendo. Gracias por la respuesta, editaré mi pregunta para reflejar esto.

— Bryan

1

En ese caso, parece que la VPN del cliente no está configurada para DNS dividido. Con DNS dividido, el concentrador VPN le da a su cliente VPN una lista de servidores DNS (como lo hace actualmente), y también una lista de dominios que son los únicos dominios que deben usarse con esos servidores DNS; todos los demás usarían el DNS predeterminado de su sistema.

— James Sneeringer

0

Aunque esta pregunta se hizo hace mucho tiempo, pero publicar esta respuesta ya que esto puede ayudar a otros. Tuve el mismo problema con VPN donde cuando los usuarios solían conectarse a VPN remota, sus DNS externos solían detenerse, por ejemplo. google.comsolo los dominios de la empresa solían funcionar en los que se enumeraron split-dns.

El problema era cuando la máquina local utilizada hacía el tráfico de consulta de dns va al túnel vpn y si el dns está permitido en el túnel, retrocede. Cuando retrocedía, solía elegir primero ipv6 como resolución y luego nunca volver a ipv4.

Entonces, para probar los resultados, primero deshabilitamos el ipv6 en la máquina local, comenzó a funcionar. Para solucionarlo permanentemente para todos los usuarios, habilitamos el client-bypass-protocolcomando en el firewall ASA que ignoraba IPv6 si no está configurado en los grupos vpn.

así que si no puede controlar el cortafuegos y sabe que el túnel dividido y el dns dividido están en su lugar, pero está fallando, puede intentar deshabilitar ipv6en la máquina local y si puede controlarlo, puede habilitar el comando anterior siempre que no use ipv6 en tu red remota.

Esto me ha ayudado, espero que esto ayude a otros :)

— Rsingh
fuente

0

¡Yay algo con lo que tengo experiencia!

Establezca la conexión VPN con el servidor DNS local y conéctese a la VPN utilizada nslookup para consultar el nombre de dominio VPN. Debería obtener una respuesta con una IP local a la LAN VPN. Esto significa que usó los servidores DNS VPN para resolver la consulta.

Ahora abra su conexión LAN y configure manualmente el DNS a su DNS local o ISP. una Volia !!! use la tecla de flecha y repita la consulta nslookup. Recibirá una IP pública, lo que significa que utilizó su servidor DNS local / ISP para resolver la consulta del dominio VPN. Bam !!!!

— Graham.Fraser
fuente

0

Simplemente elimino esta opción de la configuración de VPN del cliente

setenv opt block-outside-dns

Se resolvió el problema.

— Ismail
fuente

0

Tuve este problema hace unos años y lo solucioné editando el archivo de conexión VPN. Simplemente haga un archivo vpn.pbk (puede encontrarlo en google) abra ese archivo a través del editor de texto como el bloc de notas y cambie el valor de UseRasCredentials a cero y su problema se resuelve. pero el único problema es que la prioridad de DNS de las conexiones de área local es mayor que la VPN DNS y la resolución de nombre lleva más tiempo (si se usa VPN para conectarse a Internet).

— Mohsen Bigdeli
fuente

-1

¿Por qué crees que es DNS?

Si pierde el acceso a sus recursos compartidos de red cuando se conecta a la VPN, parece casi seguro que su máquina está teniendo dificultades con WINS / NETBIOS.

Defina un servidor WINS y vuelva a probar.

— Ben Lessani - Sonassi
fuente

No estoy seguro de que esta sea la causa de mis problemas, pero lo que sí sé es que los clientes de AD deberían usar los servidores DNS que se usan para alojar AD, y este no es el caso. Como el problema solo aparece cuando hago una conexión VPN, y mi resolución de DNS se vuelve incorrecta al mismo tiempo, parece que DNS es el candidato probable. De todos modos, no quiero usar el servidor DNS remoto cuando me conecto a otra red usando VPN.

— Bryan

¿Definió un servidor WINS según mi sugerencia? No es típico de Windows usar el servidor DNS en una VPN a menos que el uso de uno esté definido o "Usar la puerta de enlace remota esté configurada", lo que usted dijo está deshabilitado. También está utilizando una IP estática en el túnel VPN, entonces, ¿por qué ha configurado las entradas de DNS? Elimine esos servidores DNS (192.168.0.16-17) o configure un servidor WINS.

— Ben Lessani - Sonassi

No, no lo he intentado ya que no tenemos un servidor WINS para señalar a los clientes. No estoy convencido de que WINS ayude a ser honesto, así que no estoy interesado en instalar un servidor WINS en nuestra red porque podría ayudar. Sin embargo, tendré en cuenta la idea, así que gracias. La IP es asignada por el servidor VPN y es dinámica. Si no asigno un servidor DNS para la conexión VPN, el servidor lo asigna dinámicamente. Incluso he codificado mis propios servidores DNS en las propiedades de conexión VPN, pero todavía usa los servidores DNS en el sitio remoto.

— Bryan

No necesito ni quiero utilizar el servidor DNS remoto, siempre, siempre quiero resolución de DNS que se realiza en el servidor local, esto va a solucionar mi problema, por lo tanto, mi pregunta se centra en DNS. Probablemente podría usar una regla de firewall para bloquear el acceso al servidor DNS remoto, pero esto no soluciona el problema de configuración incorrecta subyacente.

— Bryan

1

Su interpretación de esto es incorrecta. La dirección IP es asignada por el servidor PPTP, que en realidad no usa DHCP. El servidor PPTP tiene un grupo desde el que puede asignar, pero este no es DHCP. Sin embargo, obtengo una IP diferente cada vez que me conecto. Además, tampoco he marcado la casilla para usar la puerta de enlace remota, como se puede ver claramente en la tabla de enrutamiento.

— Bryan