En un Mac, ping resol un nom de màquina del tailnet mentre nslookup retorna un error, i totes dues ordres diuen la veritat. Les aplicacions resolen pel resolutor del sistema, que Tailscale configura per interfície, mentre que nslookup i host llegeixen un fitxer estàtic que MagicDNS no toca mai. Els dos camins poden discrepar sense que es perdi cap paquet. Decidiu quin camí ha seguit la vostra aplicació que falla abans de canviar cap paràmetre DNS.

Dos camins de resolució, dues respostes diferents

El trànsit de les aplicacions a macOS passa pel resolutor del sistema, i les entrades de resolutor limitades per interfície decideixen quin servidor respon per quin domini. Tailscale hi instal·la la seva entrada de MagicDNS, i per això Safari i ssh troben noms del tailnet. nslookup, host i dig, en canvi, llegeixen /etc/resolv.conf o prenen un servidor a la línia d’ordres, i aquest fitxer normalment encara anomena el router o un servidor d’oficina. Un nom del tailnet enviat a aquest fitxer no té cap resposta autoritativa esperant-lo, així que l’eina informa d’un error mentre el camí del sistema té èxit.

Cap de les dues eines no es comporta malament. Pregunten a servidors diferents, i només un d’aquests servidors coneix el vostre tailnet.

Proveu el mateix nom pel camí del sistema

Feu servir la crida de cerca del sistema com a primera prova i, després, compareu-la amb una consulta adreçada directament al resolutor de MagicDNS. Manteniu l’ortografia idèntica en tots dos, inclòs el domini del tailnet, perquè un nom curt i un nom completament qualificat són preguntes diferents amb respostes diferents.

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

Aquestes tres sortides responen tres preguntes: què retorna el sistema, quins resolutors estan configurats per a quins dominis i què sap el mateix MagicDNS. Un nom present a la segona i a la tercera però absent a la primera assenyala una configuració local i no el tailnet.

Quan el nom es resolgui, proveu el servei

Una resposta DNS correcta només demostra que un nom s’assigna a una adreça. El servei que hi ha darrere pot estar aturat, el port pot estar filtrat per una regla d’accés i un certificat pot nomenar un amfitrió diferent del que heu escrit.

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

Conserveu el text original de l’error, perquè un avís de certificat, un temps d’espera de connexió i un nom no trobat porten cadascun a un lloc diferent. Canviar els servidors de noms repara el tercer i malbarata una tarda amb els dos primers.

MagicDNS no substitueix el DNS d’oficina

Un nom dins d’una zona d’oficina no és un nom de dispositiu del tailnet encara que el mateix client pugui arribar als dos. Quan la destinació és darrere d’un encaminador de subxarxa, el client necessita DNS dividit per a aquesta zona apuntant al resolutor intern, que és un paràmetre diferent de MagicDNS i es documenta al costat d’aquest.

Els dominis de cerca també importen. A un nom curt no qualificat se li afegeix cada sufix configurat en ordre, així que un portàtil que fa poc s’ha connectat a una altra xarxa pot resoldre a través d’un sufix obsolet. Comproveu quin sufix s’ha aplicat abans de declarar la zona trencada.

Quan tots dos camins fallen, decideixen els fets del tailnet

Si la cerca del sistema i la consulta directa fallen totes dues per a un dispositiu que creieu que existeix, el problema és aigües amunt del resolutor del Mac.

Confirmeu el nom de la màquina i el domini del tailnet a la consola d’administració, confirmeu que el dispositiu està en línia i aprovat, i confirmeu que els paràmetres DNS del client no s’han desactivat localment. Un dispositiu que està fora de línia conserva el seu nom i simplement no té cap adreça per retornar.

Aleshores trieu segons les proves. Un nom que es resol pel camí del sistema i falla a nslookup és una diferència de camí d’eina; un nom que es resol mentre el servei refusa és un problema d’accés o de certificat; un nom que no es resol enlloc és un problema del tailnet o de la configuració DNS. Tres responsables, tres correccions, i la documentació de MagicDNS cobreix els detalls de macOS del primer cas.

Articles relacionats