Mac OS X Mountain Lion: la resolución de DNS utiliza un orden incorrecto en VPN a través de una conexión de acceso telefónico

Estoy usando una MacBook con Mac OS X 10.8.2 y me conecto a la red de mi empresa a través de VPN. Todo funciona muy bien al establecer la conexión VPN a través de LAN o WLAN. Sin embargo, cuando utilizo una conexión de acceso telefónico (Huawei HSDPA USB Stick), los nombres de host no se resuelven correctamente en las aplicaciones (por ejemplo, navegador web). Las herramientas de línea de comandos como host nameresolverán correctamente la dirección IP, ping nameno se resolverán.

Utilizando scutil --dnsvolqué la configuración de DNS cuando me conecté a través de WLAN vs. Hay una diferencia notable en el orden de búsqueda:

connecting using WLAN:

resolver #1
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 6 (ppp0)
  reach    : Reachable,Transient Connection
  order    : 100000

resolver #2
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 6 (ppp0)
  reach    : Reachable,Transient Connection
  order    : 200000

resolver #3
  domain   : local
  options  : mdns
  timeout  : 5
  order    : 300000

resolver #4
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  order    : 300200

resolver #5
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300400

resolver #6
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300600

resolver #7
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300800

resolver #8
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 192.168.1.1
  if_index : 4 (en0)
  flags    : Scoped
  reach    : Reachable,Directly Reachable Address

resolver #2
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 6 (ppp0)
  flags    : Scoped
  reach    : Reachable,Transient Connection

La conexión ppp0 es la conexión VPN. Como puede ver, dos servidores están conectados y responden correctamente en la línea de comandos y en las aplicaciones.

Connecting via UMTS:

resolver #1
  nameserver[0] : 139.7.30.126
  nameserver[1] : 139.7.30.125
  if_index : 6 (ppp0)
  reach    : Reachable,Transient Connection
  order    : 100000

resolver #2
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 7 (ppp1)
  reach    : Reachable,Transient Connection
  order    : 100000

resolver #3
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 7 (ppp1)
  reach    : Reachable,Transient Connection
  order    : 200000

resolver #4
  domain   : local
  options  : mdns
  timeout  : 5
  order    : 300000

resolver #5
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  order    : 300200

resolver #6
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300400

resolver #7
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300600

resolver #8
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300800

resolver #9
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 192.168.80.10
  nameserver[1] : 192.168.80.24
  if_index : 7 (ppp1)
  flags    : Scoped
  reach    : Reachable,Transient Connection

resolver #2
  nameserver[0] : 139.7.30.126
  nameserver[1] : 139.7.30.125
  if_index : 6 (ppp0)
  flags    : Scoped
  reach    : Reachable,Transient Connection

Esta vez, ppp1 es la conexión VPN y ppp0 es la conexión UMTS. A partir de los tiempos de respuesta de los comandos (usando el nombre de host no existente foo.bar.local) deduzco que pingusa la primera cadena de resolución, donde hostusa la configuración de consulta con ámbito. pingtarda 5 segundos en devolver "Host desconocido", hostvuelve inmediatamente. Supongo que ping se ejecuta en el tiempo de espera de 5 segundos del solucionador mdns.

Para solucionar mi problema con las búsquedas de DNS dañadas al marcar a través de VPN a través de módem, necesito cambiar el orden de los solucionadores. Hasta ahora no he encontrado una manera de hacer esto.

Cualquier idea bienvenida.

Tuve el mismo problema en mi Mac, y después de solucionarlo, descubrí que fue causado por FortiClient (cliente VPN). Incluso cuando FortiClient se desconectó, su DNS aún apareció en scutil.

La solución para mí fue:

scutil
> list ".*DNS"

Esto le mostrará una lista de todas las configuraciones de DNS, que se verá más o menos así:

subKey [0] = State:/Network/Global/DNS <br>
subKey [1] = State:/Network/MulticastDNS<br>
subKey [2] = State:/Network/OpenVPN/DNS<br>
subKey [3] = State:/Network/OpenVPN/OldDNS<br>
subKey [4] = State:/Network/PrivateDNS<br>
subKey [5] = State:/Network/Service/forticlientsslvpn/DNS <br>

Para verificar cada una de ellas, ejecute: (hasta que encuentre la problemática)

> get key_name
> d.show

... y para solucionarlo, ejecuta:

> get key_name
> d.remove ServerAddresses
> set key_name

Así es como se veía en mi máquina:

> get State:/Network/Service/forticlientsslvpn/DNS 
> d.show
<dictionary> {
  ServerAddresses : <array> {
    0 : 192.168.30.6
    1 : 192.168.30.15
  }
  SupplementalMatchDomains : <array> {
    0 :
  }
  SupplementalMatchOrders : <array> {
    0 : 100000
  }
}
> d.remove ServerAddresses
> d.show
<dictionary> {
  SupplementalMatchDomains : <array> {
    0 :
  }
  SupplementalMatchOrders : <array> {
    0 : 100000
  }
}
> set State:/Network/Service/forticlientsslvpn/DNS
> exit

Intente cambiar el orden de las entradas DNS en el panel de preferencias Red:

1. Abra Preferencias del sistema → Red .

2. Seleccione su servicio de red en la lista de la izquierda.

3. Desbloquee el panel de preferencias utilizando el bloqueo en la esquina inferior izquierda.

4. Haga clic en Avanzado ... y elija la pestaña DNS .

5. Cambie el orden de los servidores DNS arrastrándolos hacia arriba / abajo.

   

Encontré una solución: su DNS VPN aún será ignorado, y solo se usará un DNS de dongle 3G, pero solo agregar su DNS VPN a la lista en la interfaz 3G es el truco ... El problema principal es que el administrador de conectividad 3G sobrescribe la configuración cada vez hace clic en conectar y necesita un administrador de conectividad para habilitar Radio en el dispositivo 3G ... así que mezclé ambas soluciones en una:

1. Conéctese a su VPN y escriba su DNS (tengo 2 en la lista). Puede verificarlo en Preferencias de red → Avanzado → pestaña DNS. Desconecta la VPN. Debe conectarse a VPN porque el DNS se asigna dinámicamente al conectarse ...

2. Conéctese a su 3G y haga lo mismo: escriba el DNS en papel. Luego desconecta 3G.

3. Vaya a Preferencias de red → haga clic en la interfaz 3G → Avanzado → Pestaña DNS, y debajo de la tabla DNS (que normalmente estará vacía ya que no está conectado) haga clic en '+'. Agregue todos los servidores DNS (los de 3G primero y luego agregue VPN después). Haga clic en Aceptar y aplicar.

4. De ahora en adelante , para conectarse a 3G, simplemente conecte su USB y espere hasta que tenga cobertura 3G (necesitará abrir el administrador de conectividad 3G), pero no use el administrador de conectividad suministrado para conectarse. Y si se conecta automáticamente, vaya a las preferencias y desactive esa marca. Es necesario que el gerente única para convertir la radio en el USB Dongle, nada más.

   Si hace clic en "conectar" en su administrador 3G, sobrescribirá la configuración en su interfaz 3G y deberá repetir el paso 3 nuevamente.

5. Vaya a Red → Preferencias y haga clic en la interfaz 3G. Luego haga clic en conectar. Se conectará a su 3G utilizando los servidores DNS configurados (en lugar de recibidos dinámicamente), que incluyen tanto el DNS "público" como su DNS VPN.

6. Conéctate a tu VPN. Funcionará como se esperaba.

Solo ten en cuenta que:

• Si su DNS VPN cambia, debe cambiarlo manualmente. Esto se puede verificar fácilmente en Red → Interfaz VPN w Avanzado → pestaña DNS ya que su DNS VPN todavía se asigna dinámicamente a la interfaz (aunque OS X lo ignora).

• Si su DNS 3G cambia (poco probable), también debe cambiarlo manualmente. Si algo sale mal y no puede navegar, debe pasar por el administrador de conectividad 3G, hacer clic en "Conectar" y ver qué DNS se asignan dinámicamente ... Eso requerirá que vuelva al paso 3 y lo reconfigure.

Tuve el mismo problema durante mucho tiempo, pero ahora tuve tiempo de encontrar una solución que funcione para mí. No cambié el orden del servidor DNS, pero estoy usando el servidor DNS detrás de la VPN de forma permanente.

1. Conéctese mediante acceso telefónico.

2. Conecte la conexión VPN y copie las direcciones IP del servidor DNS y el dominio de búsqueda de Conexión VPN → Avanzado → DNS.

3. Desconecta la conexión VPN.

4. Ping <name>o <hostname>de su servidor VPN y escriba la dirección IP.

5. Desconecte la conexión de acceso telefónico.

6. Duplique la conexión de acceso telefónico (p. Ej., Asígnele el nombre "3G para VPN").

7. Ingrese las IP y el dominio de búsqueda en la pestaña DNS de la conexión de acceso telefónico. Serán almacenados y utilizados permanentemente.

8. Conéctese a través de la nueva conexión de acceso telefónico.

9. Ahora no tiene acceso a los servidores de nombres (porque están protegidos por la VPN): debe editar la dirección del servidor de la conexión VPN. Reemplace el host por la IP.

10. Conéctese a través de una conexión VPN y debería poder usarlo.

Nota: En general, los nombres de host no cambian, pero las IP sí. Entonces, si algún día no funciona, repita los pasos ...

lo que dijiste me dio una pista, así que agregué el dns ip en la conexión vpn a la lista dns en la conexión principal (nada lujoso, solo usando la interfaz gráfica para las preferencias de red). No estoy seguro de qué tratar es diferente, pero funcionó conmigo.

Esto sigue sucediendo en 10.13.0

He abierto un informe de error con Apple. No es normal que "ping internalhostname" funcione pero "host internalhostname" o "nslookup internalhostname" falla con VPN de túnel dividido (Cisco IPSec basado o IKEv2).

Además, como algunos han notado, las conexiones Cisco IPsec y las conexiones IKEv2 no pueden priorizarse con "Establecer orden de servicio" a diferencia de L2TP / IPsec que sí puede.

Otro punto que me gustaría mencionar es que las VPNs Cisco IPSec o IKEv2 de túnel dividido no muestran ningún servidor DNS o Dominios de búsqueda en su configuración Avanzada, aunque esta información aparece con "scutil --dns". Las VPN L2TP / IPsec muestran esta información muy bien.

Algo tiene que ceder y Apple necesita proporcionar alguna explicación / solución.

No funciona en Lion / Mountain Lion, debido a un error que hace que el servidor DNS local siempre se use en lugar del servidor DNS de la red remota, incluso cuando el DNS dividido está configurado correctamente en el enrutador VPN.

Sin embargo, si usa un enrutador Cisco ASA IPSEC, puede forzar el uso de los servidores DNS remotos cada vez que establezca una conexión VPN:

Si usa Cisco ASDM, vaya a Configuración> Acceso a la red (cliente)> Políticas de grupo> (su grupo vpn para OSX / iPhones)> Avanzado> Túnel dividido

Se establece: Nombres DNS (desmarque "heredar" y defina los nombres de dominio DNS internos, por ejemplo, myoffice.local) Enviar todas las búsquedas DNS a través del túnel: establecer en SÍ (esta es la configuración importante)

Guárdelo y no olvide guardarlo en la memoria flash para usarlo en el futuro.

Si usa la línea de comando IOS, establezca:

group-policy <your-tunnel-group-name> attributes
 split-dns value myoffice.local
 split-tunnel-all-dns enable`

Puede solucionar esto ajustando el orden de servicio de las conexiones de red. Mueva VPN a la parte superior de la lista y seguirá el orden de resolución.

http://support.apple.com/kb/PH14006