OS X fragt lokale DNS-Namen nicht richtig ab

Keiner unserer OS X-Client-Computer an unserem Arbeitsplatz fragt die lokalen DNS-Namen unserer Server ordnungsgemäß ab, nachdem er sich mit dem VPN verbunden hat. Für andere Client-Rechner – einschließlich Linux und Windows – funktioniert es ordnungsgemäß.

Nur etwas Kontext: Unsere Server waren vorher öffentlich zugänglich. Da wir begonnen haben, alles zu sichern, stellen wir sie hinter eine Firewall und sie sind nur über VPN zugänglich. Da unsere Entwickler den Zugriff auf die Server über fqdn gewohnt sind, haben wir einen lokalen DNS-Server hinzugefügt. Wenn sie sich also mit unserem VPN verbinden, werden die DHCP- und DNS-Einstellungen automatisch an ihre Maschinen weitergegeben. Zwei DNS-Server-IPs, eine für die lokale Auflösung und eine für die öffentliche Auflösung. Leider haben alle unsere OS X-Benutzer diese Probleme. Linux- und Windows-Rechner sind es nicht.

Server: riker.example.com

• 120.xxx (öffentliche IP-Adresse)
• 10.20.1.28 (lokale IP-Adresse)

DNS-Einstellungen, die an unsere Benutzer weitergegeben werden:

• 10.20.1.3 (für lokal)
• 8.8.8.8 (für die Öffentlichkeit)

Wir haben bereits geprüft:

• DNS-Servereinstellungen unseres Fortigate-Geräts – wir sind 100 % sicher, dass sie korrekt sind, da unsere Linux- und Windows-Clients funktionieren.
• Firewall-Richtlinien - wieder 100% sicher, weil es mit Linux und Windows richtig funktioniert
• Überprüfen Sie /etc/resolv.conf-Dateien der OS X-Maschinen - Korrekte DNS-Einstellungen, die vom DNS-Server angegeben werden [Bearbeiten 6. Juni 2016]
• DNS-Cache geleert mit:sudo killall -HUP mDNSResponder
• Firewall von OS X-Rechnern ausgeschaltet
• mDNSresponder neu gestartet

Nach all diesen Schritten zur Fehlerbehebung funktioniert es immer noch nicht.

Wenn ich mit VPN verbunden bin, wird immer noch die öffentliche IP-Adresse und nicht die lokale IP-Adresse aufgelöst:

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$

Aber wenn ich die lokale Adresse pinge:

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

Überprüfung durch dig und nslookup (noch mit VPN verbunden):

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

Inhalt von /etc/resolv.conf des lokalen Rechners (noch mit VPN verbunden):

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

Wie Sie oben sehen können, gibt die Domain beim Pingen immer noch die öffentliche IP-Adresse und nicht die lokale IP-Adresse aus. Aber mit dig und nslookup gibt es bereits die lokale IP-Adresse aus.

Noch ein paar Sachen, die ich gemacht habe:

• Versuchte die hier vorgestellten Lösungen: DNS wird unter Mac OS X nicht aufgelöst - hat bei uns immer noch nicht funktioniert.
• Ich habe eine virtuelle Maschine CentOS - innerhalb einer OS X-Maschine installiert und eine Bridge-Verbindung hergestellt. Es löste die Domäne lokal korrekt auf.
  • Dies bedeutet, dass Forticlient aus der Gleichung eliminiert werden kann, da die OS X- und CentOS-VM nur denselben Adapter gemeinsam nutzen.
• L3-Support von Fortigate gesucht
  • Wir haben viel tcpdump auf dem Fortigate-Gerät durchgeführt, um den Datenverkehr zu überprüfen.
    • Wir haben festgestellt, dass ein Linux- oder Windows-Computer, wenn er eine Domain anpingt, zuerst nach einer DNS-Anfrage vom Fortigate-Gerät sucht.
    • Unglücklicherweise führt der OS X-Computer keine DNS-Anfrage vom Fortigate-Gerät aus. Was also passiert, ist, dass es immer noch in die Public Domain aufgelöst wird.
  • Ich wurde von ihnen darauf hingewiesen, dass das Problem auf den OS X-Geräten lokalisiert ist, da selbst nach dem Leeren des Caches beim Pingen von riker.example.com keine DNS-Abfrage durchgeführt wird. Sie können uns also nicht mehr helfen.

Dies wurde getestet auf: OS X-Versionen: Yosemite 10.10.4, El Capitan 10.11.5 Fortigate 100D Firmware-Version: v5.2.4, build688 (GA) Forticlient-Version: 5.4.0.493

Irgendein Rat?