Tailscale MagicDNS funguje, ale nslookup na macOS selhává

Na Macu ping přeloží název stroje v tailnetu, zatímco nslookup vrátí chybu, a oba příkazy říkají pravdu. Aplikace překládají přes systémový resolver, který Tailscale konfiguruje pro každé rozhraní, zatímco nslookup a host čtou statický soubor, který MagicDNS nikdy neopraví. Obě cesty se mohou rozejít, aniž by se ztratil jediný paket. Určete, kterou cestou se vydala vaše selhávající aplikace, než změníte jakékoli nastavení DNS.

Dvě cesty překladu, dvě různé odpovědi

Provoz aplikací na macOS jde přes systémový resolver a záznamy resolveru omezené na rozhraní rozhodují, který server odpovídá za kterou doménu. Tailscale tam instaluje svůj záznam MagicDNS, a proto Safari a ssh nacházejí názvy tailnetu. nslookup, host a dig místo toho čtou /etc/resolv.conf nebo převezmou server z příkazového řádku, a tento soubor obvykle stále uvádí router nebo kancelářský server. Název tailnetu odeslaný do tohoto souboru nemá žádnou autoritativní odpověď, která by na něj čekala, takže nástroj hlásí selhání, zatímco systémová cesta uspěje.

Ani jeden z nástrojů se nechová špatně. Ptají se různých serverů a jen jeden z těchto serverů o vašem tailnetu ví.

Otestujte stejný název systémovou cestou

Použijte systémové vyhledávací volání jako první test a poté jej porovnejte s dotazem mířeným přímo na resolver MagicDNS. Zachovejte v obou stejný pravopis včetně domény tailnetu, protože krátký název a plně kvalifikovaný název jsou různé otázky s různými odpověďmi.

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

Tyto tři výstupy odpovídají na tři otázky: co systém vrací, které resolvery jsou nakonfigurovány pro které domény a co ví sám MagicDNS. Název přítomný ve druhém a třetím, ale chybějící v prvním, ukazuje na místní konfiguraci, nikoli na tailnet.

Jakmile se název přeloží, otestujte službu

Správná odpověď DNS dokazuje jen to, že název odpovídá adrese. Služba za ním může být zastavená, port může být filtrován přístupovým pravidlem a certifikát může uvádět jiný hostitel, než jste zadali.

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

Uchovejte původní text chyby, protože upozornění na certifikát, vypršení času připojení a nenalezený název vedou každé jinam. Změna jmenných serverů opraví třetí a promarní odpoledne na první dvě.

MagicDNS nenahrazuje kancelářské DNS

Název v kancelářské zóně není název zařízení v tailnetu, i když se stejný klient dostane na obojí. Když cíl leží za routerem podsítě, klient potřebuje split DNS pro tuto zónu ukazující na interní resolver, což je jiné nastavení než MagicDNS a je zdokumentováno vedle něj.

Na doménách hledání také záleží. Nekvalifikovanému krátkému názvu se v pořadí přidává každá nakonfigurovaná přípona, takže notebook, který se nedávno připojil k jiné síti, může přeložit přes zastaralou příponu. Zkontrolujte, která přípona byla použita, než zónu prohlásíte za rozbitou.

Když obě cesty selžou, rozhodují fakta o tailnetu

Pokud systémové hledání i přímý dotaz selžou pro zařízení, o kterém se domníváte, že existuje, problém je výše než resolver Macu.

Potvrďte název stroje a doménu tailnetu v administrátorské konzoli, potvrďte, že zařízení je online a schválené, a potvrďte, že nastavení DNS klienta nebylo místně vypnuto. Zařízení, které je offline, si ponechá název a prostě nemá adresu, kterou by vrátilo.

Poté vybírejte podle důkazů. Název, který se přeloží systémovou cestou a selže v nslookup, je rozdíl v cestě nástroje; název, který se přeloží, zatímco služba odmítá, je problém přístupu nebo certifikátu; název, který se nepřeloží nikde, je problém tailnetu nebo konfigurace DNS. Tři vlastníci, tři opravy a dokumentace MagicDNS pokrývá specifika macOS prvního případu.