Общий доступ к Интернету выдает неверный адрес DNS-сервера

Я использую MacBook Pro с OS X Mavericks 10.9.2. Он подключается к Интернету через USB-ключ 3G, и я хочу поделиться этим подключением к Интернету через Wi-Fi. Однако на устройствах, которые подключаются к созданной точке доступа Wi-Fi, поиск DNS не будет работать (хотя я могу нормально пинговать 8.8.8.8). Если я статически настрою устройства для использования 8.8.8.8, все будет работать, но не каждое устройство поддерживает это (или только если вы также хотите настроить статический IP-адрес и шлюз).

Похоже, проблема в том, что OS X настраивает bootp (сервер DHCP) для выдачи адреса DNS-сервера самого MacBook:

$ cat /etc/bootp.list
...
            <key>dhcp_domain_name_server</key>
            <array>
                <string>192.168.2.1</string>
            </array>
...

Это действительно IP-адрес самой машины:

$ ifconfig
...
bridge100: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=3<RXCSUM,TXCSUM>
    ether 02:26:bb:66:19:64
    inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
...

И это то, что клиенты получают в ответе DHCP:

$ sudo tcpdump -vv
15:26:07.265635 IP (tos 0x0, ttl 255, id 9846, offset 0, flags [none], proto UDP (17), length 328)
    192.168.2.1.bootps > 192.168.2.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x4e0988af, Flags [none] (0x0000)
      Your-IP 192.168.2.2
      Server-IP 192.168.2.1
      Client-Ethernet-Address 10:bf:48:cc:49:7d (oui Unknown)
      sname "ip-77-24-232-37.web.vodafone.de"
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.2.1
        Lease-Time Option 51, length 4: 85536
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 192.168.2.1
        Domain-Name-Server Option 6, length 4: 192.168.2.1

Это было бы прекрасно, если бы это действительно работало так, как написано здесь , т.е. OS X запускает namedсам сервер bind(), который просто пересылает DNS-запросы и ответы на серверы провайдера.

Однако... с помощью tcpdumpя вижу, что клиент получает ответ об ошибке при поиске DNS:

$ sudo tcpdump
15:23:33.181447 IP 192.168.2.2.57291 > 192.168.2.1.domain: 32713+ A? google.com. (28)
15:23:33.181528 IP 192.168.2.1 > 192.168.2.2: ICMP 192.168.2.1 udp port domain unreachable, length 36

Действительно, ни один namedсервер не запущен и, кажется, даже не установлен:

$ ps aux | grep named
thomas           2175   0.0  0.0  2423368    188 s000  R+    3:14pm   0:00.00 grep named
$ which named
$

Ничто другое также не прослушивает UDP-порт 53, хотя на 5353 есть штука, называемая mDNSResponder:

$ sudo lsof -i -P | grep 53
mDNSRespo   47 _mdnsresponder    8u  IPv4 0x4dcb7c0f075daa1d      0t0    UDP *:5353
mDNSRespo   47 _mdnsresponder    9u  IPv6 0x4dcb7c0f075da835      0t0    UDP *:5353
natpmpd   1664           root    4u  IPv4 0x4dcb7c0f064b6f15      0t0    UDP 192.168.2.1:5351

Теперь я могу придумать два способа исправить это, ни один из них не очень практичен:

  1. Запустите какой-нибудь DNS-сервер на UDP-порту 53. К сожалению, ни один из них не установлен.
  2. Скажите DHCP, чтобы он выдал адрес DNS-сервера, который действительно работает, например, 8.8.8.8. К сожалению, InternetSharingприложение перезаписывает /etc/bootp.plistкаждый раз, когда включается общий доступ к Интернету, поэтому, даже если бы я добавил туда IP-адрес и даже если бы он работал, он не работал бы вечно.

Но что-то мне подсказывает, что это должно (и обычно работает) корректно работать из коробки... что я упускаю?

У меня есть работающий доступ в Интернет на моем MacBook середины 2010 года под управлением OS X 10.9.2. У меня нет namedзапущенной службы, но у меня работает 53. Примечание. Я удалил шестнадцатеричное значение из lsof.mDNSRespo 42 _mdnsresponder 8u IPv4 0t0 UDP *:5353 mDNSRespo 42 _mdnsresponder 9u IPv6 0t0 UDP *:5353 mDNSRespo 42 _mdnsresponder 64u IPv4 0t0 UDP *:53 mDNSRespo 42 _mdnsresponder 65u IPv6 0t0 UDP *:53 mDNSRespo 42 _mdnsresponder 66u IPv4 0t0 TCP *:53 (LISTEN) mDNSRespo 42 _mdnsresponder 67u IPv6 0t0 TCP *:53 (LISTEN)
Интересный. Я начинаю думать, что с конфигурацией может работать какое-то программное обеспечение, не принадлежащее Apple.
Да, после того, как я проверил свою систему на наличие работающей «именованной» службы, у меня был быстрый поиск в Google, и различные программные проекты запускали ответчик DNS. Удачи в поиске. Кстати, вы восстановили разрешения на жестком диске?
Только что запустил проверку в Дисковой утилите. Ничего, что бросается мне в глаза.
Что произойдет, если вы попытаетесь узнать, что находится nameв мониторе активности?
По-видимому, в Mavericks общий доступ к Интернету должен включать возможность прокси-сервера DNS в процессе mDNSResponder (предыдущие версии использовали BIND/named, но это не установлено в Mav). К сожалению, я не вижу, как должен быть включен прокси-сервер DNS или что может ему помешать...

Ответы (3)

Статья , на которую вы ссылаетесь, действительно была правильной, когда она была опубликована , и так она работала до Mavericks. В Mountain Lion 'named' get запускается, когда активен общий доступ к Интернету с /etc/com.apple.named.proxy.conf в качестве файла конфигурации. Все это можно наблюдать под горным львом — я проверил.

Однако разрешение доменных имен основано не только на DNS в OS X, как в других OSen, но и на службах каталогов, которые разрешают поиск DNS из плоских файлов, NIS, NetInfo, LDAP, ZeroConfig/Bonjour. .. и DNS -- и именно mDNSResponder используется для разрешения этих поворотов имен. (Согласно его справочной странице mDNSResponder is also the system-wide Unicast DNS Resolver. Это то, что (или должно) выполнять разрешение DNS для ваших общих клиентов Интернета в Mavericks. (Было странно, что они namedзапускались под Mt Lion, а не использовали тогда mDNSResponder.)

Когда общий доступ к Интернету активирован, либо named (до Mavericks), либо mDNSResponder (Mavericks) является «DNS-сервером», который должен выполнять разрешение имен для общего доступа к Интернету, и это правильно делает 192.168.2.1 DNS-сервером для NAPT-клиентов Интернета. Обмен. Таким образом, прямой и простой ответ на ваши вопросы заключается в том, что он не выдает «неправильный адрес DNS-сервера».

Это наглядный пример сработал для меня при настройке общего доступа к Интернету для совместного использования моего WiFi-соединения через Ethernet. Было замечено, что клиенты, обслуживаемые Internet Sharing, отправляли DNS-запросы на адрес 192.168.2.1, корректно получали туда запросы из браузера и при выдаче dig @192.168.2.1 apple.com; Я наблюдал это в действии с помощью tcpdump для проверки. Все «просто работает», как и следовало ожидать.

Отмечу, что в этой конфигурации с хостинга Mac я также могу telnet 192.168.2.1 53подключиться к mDNSResponder. Я также отмечаю, что у меня есть Service Order для настроенных сетей, в которых WiFi имеет приоритет над Ethernet.

Однако при выполнении этого в обратном порядке, совместном использовании Ethernet-соединения через WiFi, я сначала столкнулся с той же проблемой, что и вы. А именно, я видел, что запрос UDP DNS был отправлен, но не ответил, как вы заметили. Пинг прошел до 8.8.8.8, и разрешение 8.8.8.8 с помощью dig тоже сработало нормально. Я был готов записать это как ошибку, но позже у меня была возможность перезагрузить свой MacBook Pro и попробовать это снова, также убедившись, что на этот раз у меня Ethernet имеет приоритет над WiFi в порядке обслуживания панели предпочтений сети. На этот раз это «просто сработало», и я не смог воссоздать проблему. Проблема решается перезагрузкой и проверкой порядка обслуживания.

Кроме того, я убедился, что могу:

  • Выполните dig @192.168.2.1 apple.comзапрос от клиента (назначенного 192.168.2.3) общего доступа к Интернету и получите успешный ответ. Я также наблюдал UDP-запрос и ответ с помощью tcpdump:

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)

  • С хостинга Mac удалось telnet 192.168.2.1 53и получить соединение.

Совместное использование Интернета всегда было немного хрупким. Я часто видел странное поведение и обнаружил, что лучше всего перезапустить, прежде чем пытаться запустить общий доступ к Интернету, или, по крайней мере, «сделать [] службу неактивной» в сетевых настройках для рассматриваемых интерфейсов, а затем снова активировать их. (Не забудьте также «Применить» при внесении таких изменений».) Кроме того, заказ на обслуживание (который управляет шлюзами по умолчанию) также может иметь влияние (как и следовало ожидать). Вы также можете убедиться, что используете Apple предоставила местоположение «Автоматически» (или разумное факсимиле).Помните при отладке также, что каждый сетевой интерфейс может иметь свой собственный шлюз и предпочитаемый DNS-сервер для использования после Leopard или около того.

Поэтому я бы предложил три вещи: (1) перезагрузка и подтверждение приоритета вашего сетевого сервиса и/или (2) чистая установка Mavericks, чтобы посмотреть, решит ли это ваши проблемы, а также (3) убедиться, что вы можете получить доступ к Интернету. Совместное использование, когда Ethernet используется совместно через WiFi, и наоборот. Если вы не можете заставить (3) работать, вам нужно посмотреть на что-то специально неправильно настроенное на вашем Mac, и снова это предлагает чистую установку.

Если вы можете заставить его работать для Ethernet -> WiFi и WiFi -> Ethernet, это предполагает что-то с USB-ключом - и, возможно, может потребоваться настройка порядка обслуживания, чтобы он имел более высокий приоритет.

Также убедитесь, что у вас нет правил брандмауэра, запущен Little Snitch или чего-то еще, что может помешать.

Общий доступ к Интернету также имеет некоторые параметры отладки, если вы

$ /usr/libexec/InternetSharing --help

Они и файл журнала вместе с файлом журнала для mDNSResponder также могут быть полезны, если у вас все еще есть проблемы.

Но как ответ на вопрос: это не раздача неправильного адреса DNS-сервера в DHCP, поскольку 192.168.2.1 — это «правильный» DNS-сервер для общего доступа в Интернете, который будет раздаваться в зависимости от того, как он предназначен для работы. А mDNSResponder — это то, что должно обрабатывать DNS на узле, на котором запущен общий доступ к Интернету под управлением Mavericks. Нет `namedне нужен.

Я столкнулся с той же проблемой, и я не могу понять, как заставить ее работать. В конце концов я установил свой DNS-сервер на 8.8.8.8.

Проблема, кажется, в том месте, где вы сузили свой поиск; хотя дело не в том, что клиенты получают неправильный адрес DNS-сервера, а в том, что клиенты не могут использовать 192.168.2.1 в качестве своего DNS-сервера. Неясно, как вы настроили DNS-серверы в системе, выполняющей общий доступ к Интернету, но проблема, вероятно, связана с этой областью. Таким образом, dchp_domain_name_serverIP-адрес bootpd.plistправильный (по крайней мере, обычно).

Я бы рекомендовал сделать несколько простых проверок:

Откройте «Системные настройки» > «Общий доступ» и проверьте следующее:

  1. Поделитесь своим подключением из: Wi-Fi
  2. К компьютерам, использующим: Wi-Fi, Ethernet

Если вы отметите Ethernet, вы можете получить диалоговое окно:

Если вы включите этот порт, ваш интернет-провайдер может отключить вашу услугу, чтобы вы не могли нарушить работу его сети.

В некоторых случаях (например, если вы используете кабельный модем) вы можете непреднамеренно повлиять на сетевые настройки вашего интернет-провайдера и нарушить условия вашего соглашения об обслуживании.

Я не совсем уверен, что это значит (хотя я чувствую, что мой провайдер нарушает правила).

Системные настройки > Настройки сети > Ethernet/Wi-Fi :

  1. Настройка IPv4 — использование DHCP
  2. Затем подAdvanced...
  3. Настройка IPv6 — автоматически

Вкладка DNS > DNS-серверы :

(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. Остановить общий доступ к Интернету.
  2. Откройте /tmp/bootpd.plist
  3. Найдите этот ключ:

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

  1. Измените значение 4 на 0
  2. Запустите общий доступ к Интернету.

* Как вы знаете, когда общий доступ к Интернету останавливается, он стирает настройки. Одним из возможных решений этого было бы создание задания cron или агента запуска, который всегда сохранял бы ваши настройки. Есть также довольно много опций для bootpd , которые можно запустить через Терминал, о которых вы могли не знать.

Другие примечания :

  • Убедитесь, что устройства/компьютеры по адресу 192.168.2.2 и т. д. не блокируют 192.168.2.1.
  • Это возможно, если внутренний брандмауэр OS X включен, OS X перенаправляет и получает запросы из Интернета на устройства/компьютеры, использующие общий доступ к Интернету, но может не пересылать на них ответы (DNS).
  • Настройте устройства/компьютеры для использования статического IP-адреса и DNS-серверов, отличных от 192.168.2.1 (но это может быть неоптимальным решением, как вы сказали). Кроме того, при определенных обстоятельствах установка статических IP-адресов может не работать (DHCP обычно рекомендуется для общего доступа к Интернету и используется по умолчанию).
  • Некоторые USB-ключи/маршрутизаторы 3G имеют настройку AP Isolation, которая должна быть отключена для общего доступа к Интернету.

Я знаю, что вы не n00b и, вероятно, уже проверили многие из этих вещей, однако это может быть просто одна незначительная вещь, которую вы, возможно, пропустили по пути. Кроме того, если ни одна из этих простых вещей не поможет решить проблему, я могу предоставить более конкретные команды в ожидании результата.

Эта строка внутри вас tcpdumpявляется ответом:

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

Это означает, что ваше Firewallили другое программное обеспечение, играющее ту же роль, или ваша ручная настройка /etc/pf.confзаблокировали ваш DNS-запрос от доступа к вашему MBP.

Отключите любую функцию фильтрации по одной, чтобы определить, какая из них блокирует. Найдя, настройте его правильно.