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.
- Hicimos un montón de tcpdump en el dispositivo Fortigate para verificar el tráfico.
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?