Internetfreigabe gibt falsche DNS-Serveradresse aus

Der Artikel , auf den Sie verweisen, war in der Tat korrekt, als er veröffentlicht wurde, und so funktioniert er vor Mavericks. Unter Mountain Lion wird „named“ gestartet, wenn die Internetfreigabe mit /etc/com.apple.named.proxy.conf als Konfigurationsdatei aktiv ist. Dies ist alles unter Mountain Lion beobachtbar - ich habe es überprüft.

Die Auflösung von Domänennamen basiert jedoch nicht nur auf DNS unter OS X wie in anderen Betriebssystemen, sondern auf Verzeichnisdiensten, die DNS-Lookups aus Flatfiles, NIS, NetInfo, LDAP, ZeroConfig/Bonjour ermöglichen. .. und DNS -- und es ist mDNSResponder, der für die Auflösung dieser Namenswechsel verwendet wird. (Laut seiner Manpage mDNSResponder is also the system-wide Unicast DNS Resolver. Es macht (oder sollte) die DNS-Auflösung für Ihre Internet Shared Clients unter Mavericks. (Es war seltsam, dass sie namedunter Mt Lion gestartet wurden, anstatt damals mDNSResponder zu verwenden.)

Wenn die Internetfreigabe aktiviert ist, ist entweder der benannte (vor Mavericks) oder der mDNSResponder (Mavericks) der „DNS-Server“, der die Namensauflösung für die Internetfreigabe durchführen sollte, und der korrekterweise 192.168.2.1 zum DNS-Server für die NAPT-Clients des Internets macht Teilen. Die direkte und einfache Antwort auf Ihre Fragen lautet also, dass die "falsche DNS-Serveradresse" nicht weitergegeben wird.

Dies hat nachweislich funktioniert, als ich die Internetfreigabe eingerichtet habe, um meine WLAN-Verbindung über Ethernet zu teilen. Es wurde beobachtet, dass Clients, die von Internet Sharing bedient werden und DNS-Anforderungen an 192.168.2.1 gesendet haben, dort Abfragen von einem Browser und bei der Ausgabe von dig @192.168.2.1 apple.com; Ich habe dies in Aktion mit tcpdump zur Überprüfung beobachtet. Alles "funktioniert einfach", wie Sie es erwarten würden.

Ich stelle fest, dass ich in dieser Konfiguration vom Hosting-Mac aus auch in der Lage bin , mich telnet 192.168.2.1 53mit mDNSResponder zu verbinden. Ich stelle auch fest, dass ich den Serviceauftrag für die konfigurierten Netzwerke so eingestellt habe, dass WiFi Vorrang vor dem Ethernet hat.

Wenn Sie dies jedoch umgekehrt ausführen und die Ethernet-Verbindung über WLAN freigeben, ist anfangs das gleiche Problem aufgetreten, das Sie gesehen haben. Ich habe nämlich gesehen, dass die UDP-DNS-Anforderung gesendet wurde, aber keine Antwort zurück, genau wie Sie es beobachtet haben. Ping ging durch bis 8.8.8.8 und die Auflösung gegen 8.8.8.8 mit dig funktionierte auch gut. Ich war bereit, dies als Fehler aufzuschreiben, aber ich hatte später die Gelegenheit, mein MacBook Pro neu zu starten und versuchte es erneut, wobei ich diesmal auch sicherstellte, dass Ethernet Vorrang vor WiFi in der Service-Reihenfolge der Netzwerkeinstellungen hatte. Diesmal hat es "einfach funktioniert" und ich konnte das Problem nicht reproduzieren. Problem durch Neustart und Überprüfung der Servicereihenfolge gelöst.

Außerdem habe ich bestätigt, dass ich:

• Geben Sie eine dig @192.168.2.1 apple.comvon einem Client (zugewiesen 192.168.2.3) von Internet Sharing aus und erhalten Sie eine erfolgreiche Antwort. Ich habe auch die UDP-Abfrage und -Antwort mit tcpdump beobachtet:

01:01:05.620240 IP 192.168.2.3.58817 > 192.168.2.1.domain: 34923+ A? apple.com. (27) 01:01:06.051566 IP 192.168.2.1.domain > 192.168.2.3.58817: 34923 3/0/0 A 17.149.160.49, A 17.172.224.47, A 17.178.96.59 (75)

• Vom Hosting-Mac konnte telnet 192.168.2.1 53eine Verbindung hergestellt und empfangen werden.

Internet Sharing war schon immer ein bisschen zerbrechlich. Ich habe oft seltsames Verhalten gesehen und festgestellt, dass es am besten ist, neu zu starten, bevor Sie versuchen, Internet Sharing auszuführen oder zumindest in den Netzwerkeinstellungen für die betreffenden Schnittstellen "[den] Dienst deaktivieren" und sie dann wieder zu aktivieren. (Stellen Sie sicher, dass Sie auch „Anwenden“, wenn Sie solche Änderungen vornehmen.) Zusätzlich kann der Serviceauftrag (der die Standard-Gateways steuert) ebenfalls Auswirkungen haben (wie zu erwarten wäre). Sie sollten auch sicherstellen, dass Sie die verwenden Apple liefert Location "Automatic" (oder ein vernünftiges Faksimile) Denken Sie beim Debuggen auch daran, dass jede Netzwerkschnittstelle ihr eigenes Gateway und ihren bevorzugten DNS-Server haben kann, den sie verwenden können, seit etwa Leopard oder so.

Daher würde ich drei Dinge vorschlagen: (1) einen Neustart und bestätigen Sie die Priorität Ihrer Netzwerkdienstreihenfolge und/oder (2) eine Neuinstallation von Mavericks, um zu sehen, ob dies Ihre Probleme löst, sowie (3) überprüfen Sie, ob Sie Internet bekommen können Teilen funktioniert, wo Ethernet über WLAN verteilt wird und umgekehrt. Wenn Sie (3) nicht zum Laufen bringen können, müssen Sie sich etwas ansehen, das auf Ihrem Mac speziell falsch konfiguriert ist, und das schlägt erneut eine Neuinstallation vor.

Wenn Sie es für Ethernet -> WiFi und WiFi -> Ethernet zum Laufen bringen können, deutet dies auf etwas mit dem USB-Dongle hin - und möglicherweise muss die Servicereihenfolge so angepasst werden, dass eine höhere Priorität erforderlich ist.

Stellen Sie auch sicher, dass Sie keine Firewall-Regeln haben oder Little Snitch oder etwas anderes ausführen, das stören könnte.

Internet Sharing scheint auch einige Debugging-Optionen zu haben, wenn Sie Probleme haben

$ /usr/libexec/InternetSharing --help

Diese und ihre Protokolldatei können zusammen mit der Protokolldatei für mDNSResponder auch nützlich sein, wenn Sie weiterhin Probleme haben.

Aber als Antwort auf die Frage: Es wird nicht die falsche DNS-Serveradresse in DHCP ausgegeben, da 192.168.2.1 der "richtige" DNS-Server für die Internetfreigabe ist, der basierend auf seiner Funktionsweise zu verteilen ist. Und mDNSResponder sollte DNS auf dem Host handhaben, auf dem Internet Sharing unter Mavericks ausgeführt wird. Nein `namedist erforderlich.

Das Problem scheint an der Stelle zu liegen, an der Sie Ihre Suche eingegrenzt haben. obwohl es nicht darum geht, dass die Clients die falsche DNS-Serveradresse erhalten, sondern eher darum, dass die Clients 192.168.2.1 nicht als ihren DNS-Server verwenden können. Es ist unklar, wie Sie die DNS-Server auf dem System eingerichtet haben, das die Internetfreigabe durchführt, aber das Problem liegt wahrscheinlich in diesem Bereich. Damit ist die dchp_domain_name_serverIP-Adresse in bootpd.plistkorrekt (zumindest normalerweise).

Ich würde empfehlen, einige einfache Überprüfungen durchzuführen:

Öffnen Sie Systemeinstellungen > Freigabe und überprüfen Sie dann Folgendes:

1. Teilen Sie Ihre Verbindung von: Wi-Fi
2. An Computer mit: Wi-Fi, Ethernet

Wenn Sie Ethernet aktivieren, erhalten Sie möglicherweise einen Dialog:

Wenn Sie diesen Port aktivieren, beendet Ihr Internetdienstanbieter möglicherweise Ihren Dienst, um zu verhindern, dass Sie sein Netzwerk stören.

In einigen Fällen (z. B. wenn Sie ein Kabelmodem verwenden) können Sie unbeabsichtigt die Netzwerkeinstellungen Ihres ISP beeinflussen und gegen die Bedingungen Ihres Servicevertrags verstoßen.

Ich bin mir nicht ganz sicher, was das bedeutet (obwohl ich mich von meinem ISP verletzt fühle).

Systemeinstellungen > Netzwerkeinstellungen > Ethernet/WLAN :

1. IPv4 konfigurieren – DHCP verwenden
2. Dann unterAdvanced...
3. Konfigurieren Sie IPv6 – automatisch

Registerkarte DNS > DNS-Server :

(Normally this would be set to your Router IP from the previous TCP/IP Tab:
Router: ... (3G USB Dongle IP Address)

/etc/bootpd.list

1. Beenden Sie die Internetfreigabe.
2. Öffnen Sie /tmp/bootpd.plist
3. Suchen Sie diesen Schlüssel:

<key>reply_threshold_seconds</key> <integer>4</integer>

1. Ändern Sie den Wert 4 in 0
2. Starten Sie die Internetfreigabe.

*Wie Sie wissen, werden die Einstellungen gelöscht, wenn die Internetfreigabe beendet wird. Eine mögliche Lösung dafür wäre das Erstellen eines Cron-Jobs oder Launchagenten, der Ihre Einstellungen immer beibehält. Es gibt auch einige Optionen für bootpd , die über Terminal ausgeführt werden können, die Sie möglicherweise nicht kennen.

Andere Anmerkungen :

• Überprüfen Sie, ob die Geräte/Computer unter 192.168.2.2 usw. 192.168.2.1 nicht blockieren
• Wenn die interne Firewall von OS X aktiviert ist, leitet OS X möglicherweise Anfragen aus dem Internet an Geräte/Computer weiter, die die Internetfreigabe verwenden, aber leitet die Antworten möglicherweise nicht an sie weiter (DNS).
• Konfigurieren Sie Geräte/Computer so, dass sie eine statische IP und andere DNS-Server als 192.168.2.1 verwenden (dies ist jedoch möglicherweise keine optimale Lösung, wie Sie gesagt haben). Außerdem funktioniert das Festlegen statischer IPs unter bestimmten Umständen möglicherweise nicht (DHCP wird im Allgemeinen für die Internetfreigabe empfohlen und ist standardmäßig eingestellt).
• Einige 3G-USB-Dongles/Router haben eine Einstellung AP Isolation, die für die Internetfreigabe deaktiviert werden sollte.

Ich weiß, dass Sie kein n00b sind und wahrscheinlich schon viele dieser Dinge überprüft haben, aber es könnte nur eine Kleinigkeit sein, die Sie vielleicht auf dem Weg übersehen haben. Wenn keines dieser einfachen Dinge die Lösung des Problems zu beeinträchtigen scheint, gibt es außerdem spezifischere Befehle, die ich in Erwartung des Ergebnisses bereitstellen könnte.

Diese Zeile in Ihrem tcpdumpist die Antwort:

15:23:33.181528 IP 192.168.2.1 > 192.168.2.2: ICMP 192.168.2.1 udp port domain unreachable, length 36

Dies bedeutet, dass Ihre Firewalloder eine andere Software, die dieselbe Rolle spielt, oder Ihre manuelle Konfiguration /etc/pf.confIhre DNS-Anforderung daran gehindert hat, Ihren MBP zu erreichen.

Deaktivieren Sie nacheinander alle Filterfunktionen, um herauszufinden, welche blockiert. Sobald Sie es gefunden haben, konfigurieren Sie es richtig.