На моем Mac я могу выполнить “nslookup hostname”, но не могу его пропинговать?

Вопрос или проблема

Mac OS Ventura 13.3.1

Я прочитал другие вопросы относительно “Можно пинговать IP, но не hostname” и ответы все касаются DNS. В моем случае я полагаю, что мой DNS настроен правильно. Также я использую проводное соединение роутера вместо WiFi.

ПРИМЕЧАНИЕ: Проблема возникает только на внутренних серверах моей компании (в VPN). Я могу пинговать внешние серверы, например, www.google.com.

Я сбросил кеш DNS

% sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Я подключен к VPN моей компании, и в настройках сетевого интерфейса я использую DNS-серверы, которые мне предоставил ИТ-отдел. Я могу сделать это

% nslookup dc1-main.company.com
Сервер:     10.227.10.4
Адрес:    10.227.10.4#53

Имя:   dc1-main.company.com
Адрес: 10.227.25.17

После этого я могу сделать

% ping 10.227.25.17
PING 10.227.25.17 (10.227.25.17): 56 байт данных
64 байта от 10.227.25.17: icmp_seq=0 ttl=125 время=41.206 мс
64 байта от 10.227.25.17: icmp_seq=1 ttl=125 время=41.698 мс
64 байта от 10.227.25.17: icmp_seq=2 ttl=125 время=41.714 мс
^C
--- 10.227.25.17 статистика пинга ---
3 пакета отправлено, 3 пакета получено, 0.0% потеря пакетов
время в пути мин./ср./макс./стандартное отклонение = 41.206/41.539/41.714/0.236 мс

Но это не удается

% ping dc1-main.company.com
ping: не удается разрешить dc1-main.company.com: Неизвестный хост

Вот трассировка. Для IP скачок с #4 на #64 был просто * * *

% traceroute 10.227.25.17 
traceroute к 10.227.25.17 (10.227.25.17), 64 скачка max, 52 байта пакетов
 1  192.168.40.14 (192.168.40.14)  25.321 мс  24.286 мс  24.585 мс
 2  172.16.25.1 (172.16.25.1)  24.737 мс  24.578 мс  25.052 мс
 3  192.168.150.20 (192.168.150.20)  44.081 мс  44.232 мс  43.149 мс
 4  * * *
 5  * * *
...
64  * * *

% traceroute dc1-main.company.com
traceroute: неизвестный хост dc1-main.company.com

Почему это происходит? Заранее спасибо!

Я вижу Почему ‘ping’ не может разрешить имя, когда ‘nslookup’ работает нормально?, но это касается Windows, и рекомендации не имеют смысла для Mac.

ОБНОВЛЕНИЕ
Кто-то запросил эту информацию

% nslookup -q=AAAA dc1-main.company.com
Сервер:     10.227.10.4
Адрес:    10.227.10.4#53

*** Не могу найти dc1-main.company.com: Нет ответа

Потратив часы на эту проблему, я наконец нашел решение. Мой DHCP сервер выдает сначала внутренний DNS, затем внешний в качестве вторичного. Этот внешний указывает на Google’s 8.8.8.8.

Например:

10.0.1.232
10.0.2.232
8.8.8.8

Я удалил 8.8.8.8 из списка DNS-серверов, назначенных DHCP, и вуаля, теперь я могу пинговать, ssh, traceroute и т.д. внутренние ресурсы. Кажется, Apple решила блокировать системы, не использующие DNSSEC, когда в списке есть та, которая использует DNSSEC. DNSSEC, или Расширения безопасности системы доменных имен, представляет собой набор расширений для DNS, который обеспечивает аутентификацию данных DNS. Так что наш внутренний DNS-сервер (которому на самом деле не требуется DNSSEC) не запрашивался, потому что 8.8.8.8 по своей природе использует его. Не понимаю, почему Apple считает это проблемой безопасности.

Это работает:

10.0.1.232
10.0.2.232

Тогда мой внутренний DNS-сервер просто отправляет неизвестные запросы на 8.8.8.8 вместо клиентских систем.

Если у вас возникла эта проблема с разрешением имен хостов для вашего внутреннего домена, вы можете создать каталог /etc/resolver. Затем создайте файл с именем для каждого домена, для которого вы хотите указать конкретный nameserver. Например:

sudo mkdir /etc/resolver
sudo chmod 755 /etc/resolver
sudo vi /etc/resolver/mydomain.example.com
sudo chmod 644 /etc/resolver/mydomain.example.com

Где содержимое mydomain.example.com выглядит так:

nameserver 10.0.0.123

А 10.0.0.123 – это IP-адрес nameserver, который будет использоваться для домена mydomain.example.com.

Если у вас есть несколько внутренних доменов, создайте несколько таких файлов.

Эта техника, похоже, заменяет список серверов доменов, возвращаемый через DHCP.

MacOSx основан на Linux, поэтому вы найдете файл с именем /etc/resolv.conf со списком DNS-серверов, которые система должна использовать. Но MacOSx не ведет себя точно так же, как дистрибутив Linux, и поэтому в файле resolv.conf вы найдете примечание:

” Этот файл не используется для разрешения имен хостов DNS, адресов или механизма маршрутизации DNS-запросов, используемого большинством процессов в этой системе. “

В результате, если вы не получаете адрес DNS-сервера от сервера DHCP или если вы не настроили его в случае статической конфигурации, система может вести себя, казалось бы, бесreasonно.

Я имею в виду, что Google Chrome будет разрешать имена, но Safari нет. Используя CLI, команда ‘ping’ не будет разрешать имена, в то время как команда ‘nslookup’ будет. Почтовое приложение также не будет работать.

В моем случае MacBook Sequoia не получает конфигурацию DNS, несмотря на то, что в resolv.conf настроен DNS. Вот что происходит:

gianrico@Gianrico-MacBook-Air ~ % scutil –dns
Конфигурация DNS

resolver #1
search domain[0] : itesys.local
nameserver[0] : 8.8.8.8 <— он видит это, но не использует
if_index : 11 (en0)
flags : Запрос A записей
reach : 0x00000000 (Недоступно) <— обратите внимание на это (он доступен)
order : 5000

Несомненно, все приложения Apple не смогут разрешать имена, но некоторые “независимые” приложения будут использовать этот DNS (как nslookup) или другие методы.

Наконец, если ping не разрешает имена или если браузеры ведут себя иррационально, проверьте, что у вас настроен работающий DNS на сетевой карте.

Ответ или решение

Почему на вашем Mac не удается "ping" в корпоративные серверы по имени, хотя "nslookup" работает?

Проблема, с которой вы столкнулись, заключается в том, что вы можете успешно выполнить команду nslookup для разрешения имен внутреннего сервера, но команда ping не может разрешить это имя в IP-адрес. Давайте подробно рассмотрим возможные причины и решения этой ситуации.

1. Объяснение проблемы

Ваши результаты показывают, что:

  • nslookup dc1-main.company.com успешно возвращает IP-адрес (10.227.25.17).
  • ping dc1-main.company.com не может разрешить имя хоста, сообщая "Unknown host".

2. Анализ DNS и конфигураций

Согласно вашему описанию, вы используете VPN для доступа к внутренним ресурсам компании. При этом вы настроили DNS-серверы, предоставленные вашим IT-отделом. Однако, важным критерием является то, что DNS-сервер, с которым вы работаете, должен правильно обрабатывать запросы за пределами вашей локальной сети.

Возможные причины проблемы:

  • Проблемы с приоритетом DNS-серверов: Убедитесь, что DNS-серверы ваш IT-отдела находятся выше в списке (приоритизированы) по сравнению с другими DNS-серверами, такими как 8.8.8.8 (Google).
  • Настройки VPN: Убедитесь, что ваш VPN не блокирует DNS-запросы или неправильно маршрутизирует их.
  • Конфигурация /etc/hosts: Проверьте, нет ли конфликтов в файле /etc/hosts, который может приводить к неправильному разрешению имен.

3. Решение проблемы

Поиск и настройка DNS

  1. Удалите внешние DNS-серверы из конфигурации:
    Убедитесь, что внешний DNS-сервер (например, 8.8.8.8) не добавлен в DHCP. Это может повлиять на способ разрешения имен. Удаление его из списка часто решает проблему, как вы уже выяснили.

  2. Используйте /etc/resolver для указания специфичных серверов:
    Как вы указали, создание директории /etc/resolver и файлов для указания конкретных DNS-серверов может помочь в разрешении имен для внутренних ресурсов:

    sudo mkdir /etc/resolver
    sudo vi /etc/resolver/company.com

    Внутри файла укажите:

    nameserver 10.227.10.4
  3. Проверка настроек сетевого интерфейса:
    Убедитесь, что в системных настройках сети правильно указаны DNS-серверы и что у вашего сетевого интерфейса (Ethernet или VPN) активен доступ к интернету.

4. Проверка конфигураций через команду scutil

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

5. Тестирование

После внесения изменений, выполните следующие команды для проверки:

ping dc1-main.company.com
traceroute dc1-main.company.com

Если проблема сохраняется, попробуйте перезагрузить ваш Mac и повторить тестирование.

Заключение

Если вы последовали всем приведенным шагам, но проблема не решилась, возможно, стоит связаться с вашим IT-отделом для дополнительных проверок конфигураций на сервере DNS и VPN. Обратитесь к документации вашей компании или используйте внутренние ресурсы для получения поддержки.

Эта проблема может быть вызвана комплексом факторов, поэтому помните, что выполнение точной диагностики и последующих операций — ключ к ее разрешению.

Оцените материал
Добавить комментарий

Капча загружается...