OS X non richiede correttamente i nomi DNS locali

Nessuno dei nostri computer client OS X sul nostro posto di lavoro ha interrogato i nomi DNS locali dei nostri server dopo la connessione a VPN. Per altri computer client, inclusi Linux e Windows, funziona correttamente.

Solo alcuni contesti: i nostri server erano accessibili pubblicamente prima. Da quando abbiamo iniziato a proteggere tutto, procediamo a metterli dietro un firewall e sono accessibili solo tramite VPN. Poiché i nostri sviluppatori sono abituati ad accedere ai server tramite fqdn, abbiamo aggiunto un server DNS locale. Quindi, quando si collegano alla nostra VPN, le impostazioni DHCP + DNS vengono automaticamente passate alle loro macchine. Due IP server DNS, uno per la risoluzione locale e uno per la risoluzione pubblica. Sfortunatamente, tutti i nostri utenti di OS X stanno riscontrando questi problemi. Le macchine Linux e Windows non lo sono.

Server: riker.example.com

• 120.x.x.x (Public IP address)
• 10.20.1.28 (Local IP address)

Impostazioni DNS passate ai nostri utenti:

• 10.20.1.3 (for local)
• 8.8.8.8 (for public)

Abbiamo già controllato:

• Impostazioni del server DNS del nostro dispositivo Fortigate - siamo sicuri al 100% che sia corretto perché i nostri client Linux e Windows funzionano.
• Criteri firewall - ancora, sicuro al 100% perché funziona correttamente con Linux e Windows
• Controlla i file /etc/resolv.conf delle macchine OS X - correggi le impostazioni DNS fornite dal server DNS [modifica 6 giugno 2016]
• Cache DNS svuotata usando questo: sudo killall -HUP mDNSResponder
• Disattivato il firewall delle macchine OS X
• MDNSresponder riavviato

Dopo tutti questi passaggi di risoluzione dei problemi, non funziona ancora.

Se sono connesso a VPN, risolve ancora l'indirizzo IP pubblico e non l'indirizzo IP locale:

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$

Ma se faccio il ping dell'indirizzo locale:

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

Verifica di dig e nslookup (ancora connesso 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

Contenuto di /etc/resolv.conf della macchina locale (ancora connesso alla 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

Come puoi vedere sopra, eseguendo il ping sul dominio, l'indirizzo IP pubblico è ancora assegnato e non l'indirizzo IP locale. Ma con dig and nslookup, sta già fornendo l'indirizzo IP locale.

Poche altre cose che ho fatto:

• Ho provato le soluzioni presentate da qui: DNS non risolvibile su Mac OS X - ancora non ha funzionato per noi.
• Ho installato una macchina virtuale CentOS - all'interno di una macchina OS X e l'ho fatta per avere una connessione bridge. Stava risolvendo correttamente il dominio localmente.
  • Ciò significa che Forticlient può essere eliminato dall'equazione poiché OS X e CentOS VM condividono solo lo stesso adattatore.
• Supporto L3 ricercato da Fortigate
  • Abbiamo fatto un sacco di tcpdump sul dispositivo Fortigate per controllare il traffico.
    • Abbiamo scoperto che quando un computer Linux o Windows esegue il ping di un dominio, cerca prima la richiesta DNS dal dispositivo Fortigate.
    • Sfortunatamente per la macchina OS X, non esegue alcuna richiesta DNS dal dispositivo Fortigate. Quindi, ciò che accade è che risolve ancora il dominio pubblico.
  • Mi è stato consigliato da loro che il problema è localizzato sui dispositivi OS X perché, anche dopo aver svuotato la cache, non esegue alcuna query DNS durante il ping di riker.example.com. Quindi non possono più aiutarci.

Questo è stato testato su: Versioni di OS X: Yosemite 10.10.4, El Capitan 10.11.5 Versione Firmware di Fortigate 100D: v5.2.4, build688 (GA) Versione per Forticlient: 5.4.0.493

Qualche consiglio?