OS X no consulta correctamente los nombres DNS locales

4

Ninguna de nuestras máquinas cliente OS X en nuestro lugar de trabajo consulta correctamente los nombres DNS locales de nuestros servidores después de conectarse a VPN. Para otras máquinas cliente, incluidos Linux y Windows, funciona correctamente.

Solo un poco de contexto: nuestros servidores eran accesibles públicamente antes. Desde que empezamos a proteger todo, procedemos a ponerlos detrás de un firewall y solo se puede acceder a ellos a través de VPN. Dado que nuestros desarrolladores están acostumbrados a acceder a los servidores a través de fqdn, agregamos un servidor DNS local. Por lo tanto, cuando se conecten a nuestra VPN, la configuración de DHCP + DNS se pasará a sus máquinas automáticamente. Dos IP de servidor DNS, una es para resolución local y otra para resolución pública. Desafortunadamente, todos nuestros usuarios de OS X están experimentando estos problemas. Las máquinas Linux y Windows no lo son.

Servidor: riker.example.com

  
  • 120.x.x.x (dirección IP pública)
  •   
  • 10.20.1.28 (dirección IP local)
  •   

Configuración de DNS que se pasa a nuestros usuarios:

  
  • 10.20.1.3 (para local)
  •   
  • 8.8.8.8 (para público)
  •   

Ya hemos comprobado:

  • Configuración del servidor DNS de nuestro dispositivo Fortigate: estamos 100% seguros de que es correcta porque nuestros clientes de Linux y Windows están funcionando.
  • Políticas de firewall: otra vez, 100% seguro porque funciona correctamente con Linux y Windows
  • Verifique los archivos /etc/resolv.conf de las máquinas OS X - corrija la configuración de DNS proporcionada por el servidor DNS [edición 6 de junio de 2016]
  • Se vació la memoria caché de DNS usando esto: sudo killall -HUP mDNSResponder
  • Desactivado el cortafuegos de las máquinas OS X
  • mDNSresponder reiniciado

Después de todos estos pasos de solución de problemas, todavía no funciona.

Si estoy conectado a una VPN, todavía se está resolviendo la dirección IP pública y no la dirección IP local:

heineken:~ heineken$ ping riker.example.com
PING riker.example.com (120.x.x.x): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- riker.example.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
heineken:~ heineken$

Pero si hago ping a la dirección local:

heineken:~ heineken$ ping 10.20.1.28
PING 10.20.1.28 (10.20.1.28): 56 data bytes
64 bytes from 10.20.1.28: icmp_seq=0 ttl=63 time=62.714 ms
64 bytes from 10.20.1.28: icmp_seq=1 ttl=63 time=83.162 ms
^C
--- 10.20.1.28 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 62.714/72.938/83.162/10.224 ms

Comprobación por excavación y nslookup (todavía conectado a VPN):

heineken:~ heineken$ dig @10.20.1.3 riker.example.com

; <<>> DiG 9.8.3-P1 <<>> @10.20.1.3 riker.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64601
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;riker.example.come. IN A

;; ANSWER SECTION:
riker.example.com. 3600 IN A 10.20.1.28

;; Query time: 58 msec
;; SERVER: 10.20.1.3#53(10.20.1.3)
;; WHEN: Fri Jun 10 11:33:00 2016
;; MSG SIZE  rcvd: 52

heineken:~ heineken$ nslookup riker.example.com
Server: 10.20.1.3
Address: 10.20.1.3#53

Non-authoritative answer:
Name: riker.example.com
Address: 10.20.1.28

Contenido de /etc/resolv.conf de la máquina local (todavía conectado a VPN):

heineken:~ heineken$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 10.20.1.3
nameserver 8.8.8.8

Como puede ver arriba, al hacer ping en el dominio aún se da la dirección IP pública y no la dirección IP local. Pero con dig y nslookup, ya está dando la dirección IP local.

Pocas cosas más que hice:

  • Probé las soluciones presentadas desde aquí: DNS no se resuelve en Mac OS X : aún no funcionó para nosotros.
  • Instalé una máquina virtual CentOS - dentro de una máquina OS X y la hice para tener una conexión de puente. Estaba resolviendo correctamente el dominio localmente.
    • Esto significa que Forticlient puede eliminarse de la ecuación ya que OS X y CentOS VM simplemente comparten el mismo adaptador.
  • Se buscó el soporte L3 de Fortigate
    • Hicimos un montón de tcpdump en el dispositivo Fortigate para verificar el tráfico.
      • Descubrimos que cuando una máquina con Linux o Windows hace ping a un dominio, busca primero una solicitud de DNS desde el dispositivo Fortigate.
      • Desafortunadamente para la máquina OS X, no realiza ninguna solicitud de DNS desde el dispositivo Fortigate. Entonces, lo que sucede es que aún se resuelve en el dominio público.
    • Ellos me informaron que el problema está localizado en los dispositivos OS X porque incluso después de vaciar la memoria caché, no realiza ninguna consulta de DNS al hacer ping a riker.example.com. Así que ya no pueden ayudarnos.

Esto fue probado en: Versiones de OS X: Yosemite 10.10.4, El Capitán 10.11.5 Versión de firmware de Fortigate 100D: v5.2.4, build688 (GA) Versión para el cliente: 5.4.0.493

¿Algún consejo?

    
pregunta Kenan Virtucio 10.06.2016 - 06:42

1 respuesta

1

Creo que la clave de su problema podría ser que su DNS interno es "no autoritario" (vea el resultado de nslookup), sugerido en la respuesta a esta pregunta: DNS resuelve servidores IP externos en lugar de IP internos

Si ejecuta nslookup -type = soa riker.example.com, ¿es el servidor de "origen" su servidor DNS local o público?

    
respondido por el moneyt 25.05.2017 - 05:40

Lea otras preguntas en las etiquetas