Tailscale MagicDNS работает, но nslookup не работает в macOS

На Mac команда ping разрешает имя машины tailnet, а nslookup возвращает ошибку, и обе команды говорят правду. Приложения разрешают имена через системный резолвер, который Tailscale настраивает для каждого интерфейса, а nslookup и host читают статический файл, которого MagicDNS никогда не касается. Два пути могут расходиться без потери ни одного пакета. Прежде чем менять любой параметр DNS, определите, каким путём пошло ваше сбойное приложение.

Два пути разрешения, два разных ответа

Трафик приложений в macOS идёт через системный резолвер, и записи резолвера, ограниченные интерфейсом, определяют, какой сервер отвечает за какой домен. Tailscale устанавливает там свою запись MagicDNS, поэтому Safari и ssh находят имена tailnet. nslookup, host и dig вместо этого читают /etc/resolv.conf или берут сервер из командной строки, и этот файл обычно всё ещё указывает на роутер или офисный сервер. Имя tailnet, отправленное в этот файл, не имеет ожидающего авторитетного ответа, поэтому инструмент сообщает об ошибке, тогда как системный путь завершается успешно.

Ни один из инструментов не ведёт себя неправильно. Они спрашивают разные серверы, и только один из этих серверов знает о вашем tailnet.

Проверьте то же имя системным путём

Используйте системный вызов поиска как первую проверку, затем сравните его с запросом, направленным напрямую в резолвер MagicDNS. Сохраняйте одинаковое написание в обоих, включая домен tailnet, потому что короткое имя и полное квалифицированное имя — разные вопросы с разными ответами.

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

Эти три вывода отвечают на три вопроса: что возвращает система, какие резолверы настроены для каких доменов и что знает сам MagicDNS. Имя, присутствующее во втором и третьем, но отсутствующее в первом, указывает на локальную конфигурацию, а не на tailnet.

Как только имя разрешилось, проверьте службу

Правильный ответ DNS доказывает лишь то, что имя соответствует адресу. Служба за ним может быть остановлена, порт может фильтроваться правилом доступа, а сертификат может указывать на другой хост, отличный от введённого.

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

Сохраните исходный текст ошибки, потому что предупреждение о сертификате, истечение времени соединения и ненайденное имя ведут каждое в другое место. Смена серверов имён исправляет третье и тратит полдня на первые два.

MagicDNS не заменяет офисный DNS

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

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

Когда оба пути терпят неудачу, решают факты о tailnet

Если и системный поиск, и прямой запрос терпят неудачу для устройства, которое, по вашему мнению, существует, проблема находится выше резолвера Mac.

Подтвердите имя машины и домен tailnet в консоли администрирования, подтвердите, что устройство онлайн и одобрено, и подтвердите, что параметры DNS клиента не были отключены локально. Устройство не в сети сохраняет своё имя и просто не имеет адреса, который можно вернуть.

Затем выбирайте по доказательствам. Имя, которое разрешается системным путём и терпит неудачу в nslookup, — это разница путей инструмента; имя, которое разрешается, пока служба отказывает, — это проблема доступа или сертификата; имя, которое нигде не разрешается, — это проблема tailnet или конфигурации DNS. Три владельца, три исправления, и документация MagicDNS описывает особенности macOS для первого случая.