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 за първия случай.