Tailscale MagicDNS funkcias, sed nslookup malsukcesas en macOS

En Mac, ping solvas tailnet-maŝinnomon dum nslookup redonas eraron, kaj ambaŭ komandoj diras la veron. Aplikoj solvas per la sistema solvilo, kiun Tailscale agordas por ĉiu interfaco, dum nslookup kaj host legas senŝanĝan dosieron, kiun MagicDNS neniam tuŝas. La du vojoj povas malkonsenti sen perdi eĉ unu paketon. Determinu, kiun vojon via malsukcesanta aplikaĵo prenis, antaŭ ol ŝanĝi ajnan DNS-agordon.

Du solvaj vojoj, du malsamaj respondoj

Aplikaĵa trafiko en macOS iras tra la sistema solvilo, kaj interfacaj limigitaj solvilaj enskriboj decidas, kiu servilo respondas por kiu domajno. Tailscale instalas sian MagicDNS-enskribon tie, tial Safari kaj ssh trovas tailnet-nomojn. nslookup, host kaj dig anstataŭe legas /etc/resolv.conf aŭ prenas servilon en la komandlinio, kaj tiu dosiero kutime ankoraŭ nomas la enkursigilon aŭ oficejan servilon. Tailnet-nomo sendita al tiu dosiero havas neniun aŭtoritatan respondon atendante ĝin, do la ilo raportas malsukceson dum la sistema vojo sukcesas.

Neniu el la du iloj miskondutas. Ili demandas malsamajn servilojn, kaj nur unu el tiuj serviloj scias pri via tailnet.

Testu la saman nomon per la sistema vojo

Uzu la sisteman serĉvokon kiel unuan teston, poste komparu ĝin kun demando direktita rekte al la MagicDNS-solvilo. Tenu la literumadon identa en ambaŭ, inkluzive de la tailnet-domajno, ĉar mallonga nomo kaj plene kvalifikita nomo estas malsamaj demandoj kun malsamaj respondoj.

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

Tiuj tri eligoj respondas tri demandojn: kion la sistemo redonas, kiuj solviloj estas agorditaj por kiuj domajnoj, kaj kion MagicDNS mem scias. Nomo ĉeestanta en la dua kaj tria sed mankanta en la unua indikas lokan agordon, ne la tailnet.

Post kiam la nomo solviĝas, testu la servon

Ĝusta DNS-respondo pruvas nur, ke nomo mapas al adreso. La servo malantaŭ ĝi povas esti haltigita, la pordo povas esti filtrita per alira regulo, kaj atestilo povas nomi alian gastiganton ol tiu, kiun vi tajpis.

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

Konservu la originalan erartekston, ĉar atestila averto, konekta tempolimo kaj ne-trovita nomo kondukas ĉiu aliloken. Ŝanĝi nomservilojn riparas la trian kaj malŝparas posttagmezon por la du unuaj.

MagicDNS ne anstataŭas oficejan DNS

Nomo en oficeja zono ne estas tailnet-aparata nomo eĉ kiam la sama kliento povas atingi ambaŭ. Kiam la celo situas malantaŭ subreta enkursigilo, la kliento bezonas split DNS por tiu zono montrantan al la interna solvilo, kio estas alia agordo ol MagicDNS kaj estas dokumentita apud ĝi.

Ankaŭ serĉdomajnoj gravas. Al nekvalifikita mallonga nomo aldoniĝas ĉiu agordita sufikso laŭ ordo, do tekkomputilo, kiu lastatempe aliĝis al alia reto, povas solviĝi per eksmoda sufikso. Kontrolu, kiu sufikso aplikiĝis, antaŭ ol deklari la zonon rompita.

Kiam ambaŭ vojoj malsukcesas, decidas la faktoj pri la tailnet

Se kaj la sistema serĉo kaj la rekta demando malsukcesas por aparato, kiun vi kredas ekzisti, la problemo situas supre de la Mac-solvilo.

Konfirmu la maŝinnomon kaj tailnet-domajnon en la administra konzolo, konfirmu, ke la aparato estas enreta kaj aprobita, kaj konfirmu, ke la DNS-agordoj de la kliento ne estis loke malŝaltitaj. Aparato, kiu estas senreta, konservas sian nomon kaj simple ne havas adreson por redoni.

Poste elektu laŭ pruvoj. Nomo, kiu solviĝas en la sistema vojo kaj malsukcesas en nslookup, estas diferenco de ila vojo; nomo, kiu solviĝas dum la servo rifuzas, estas alira aŭ atestila problemo; nomo, kiu solviĝas nenie, estas problemo de tailnet aŭ DNS-agordo. Tri posedantoj, tri riparoj, kaj la MagicDNS-dokumentaro kovras la macOS-specifaĵojn de la unua kazo.