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 для першого випадку.