Tailscale MagicDNS virker, men nslookup fejler på macOS

På en Mac opløser ping et tailnet-maskinnavn, mens nslookup returnerer en fejl, og begge kommandoer taler sandt. Programmer opløser via systemopløseren, som Tailscale konfigurerer pr. grænseflade, mens nslookup og host læser en statisk fil, som MagicDNS aldrig rører. De to veje kan være uenige, uden at en enkelt pakke går tabt. Afgør, hvilken vej din fejlende applikation tog, før du ændrer nogen DNS-indstilling.

To opløsningsveje, to forskellige svar

Programtrafik på macOS går gennem systemopløseren, og grænsefladebundne opløserposter afgør, hvilken server der svarer for hvilket domæne. Tailscale installerer sin MagicDNS-post der, og derfor finder Safari og ssh tailnet-navne. nslookup, host og dig læser i stedet /etc/resolv.conf eller tager en server på kommandolinjen, og den fil nævner normalt stadig routeren eller en kontorserver. Et tailnet-navn sendt til den fil har ikke noget autoritativt svar, der venter på det, så værktøjet rapporterer fejl, mens systemvejen lykkes.

Ingen af værktøjerne opfører sig forkert. De spørger forskellige servere, og kun én af disse servere kender din tailnet.

Test det samme navn gennem systemvejen

Brug systemets opslagsfremkaldelse som den første test, og sammenlign den derefter med en forespørgsel rettet direkte mod MagicDNS-opløseren. Hold stavemåden identisk i begge, inklusive tailnet-domænet, fordi et kort navn og et fuldt kvalificeret navn er forskellige spørgsmål med forskellige svar.

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

Disse tre output besvarer tre spørgsmål: hvad systemet returnerer, hvilke opløsere der er konfigureret til hvilke domæner, og hvad MagicDNS selv ved. Et navn, der findes i det andet og tredje, men mangler i det første, peger på lokal konfiguration og ikke på tailnet.

Når navnet er opløst, test tjenesten

Et korrekt DNS-svar beviser kun, at et navn peger på en adresse. Tjenesten bag det kan være stoppet, porten kan være filtreret af en adgangsregel, og et certifikat kan navngive en anden vært end den, du skrev.

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

Behold den oprindelige fejltekst, fordi en certifikatadvarsel, en forbindelsestimeout og et ikke-fundet navn fører hver til noget forskelligt. At ændre navneservere reparerer det tredje og spilder en eftermiddag på de to første.

MagicDNS er ikke en erstatning for kontor-DNS

Et navn i en kontorzone er ikke et tailnet-enhedsnavn, selv når den samme klient kan nå begge. Når destinationen ligger bag en subnet-router, har klienten brug for split DNS for den zone, der peger på den interne opløser, hvilket er en anden indstilling end MagicDNS og dokumenteres ved siden af den.

Søgedomæner betyder også noget. Et ikke-kvalificeret kort navn får hvert konfigureret suffiks tilføjet i rækkefølge, så en bærbar computer, der for nylig er kommet på et andet netværk, kan opløse via et forældet suffiks. Kontroller, hvilket suffiks der blev anvendt, før du erklærer zonen i stykker.

Når begge veje fejler, afgør tailnet-fakta

Hvis både systemopslaget og den direkte forespørgsel fejler for en enhed, du mener findes, ligger problemet oven for Mac’ens opløser.

Bekræft maskinnavnet og tailnet-domænet i administrationskonsollen, bekræft at enheden er online og godkendt, og bekræft at klientens DNS-indstillinger ikke er deaktiveret lokalt. En enhed, der er offline, beholder sit navn og har simpelthen ingen adresse at returnere.

Vælg derefter ud fra beviser. Et navn, der opløses på systemvejen og fejler i nslookup, er en forskel i værktøjsvejen; et navn, der opløses, mens tjenesten afviser, er et adgangs- eller certifikatproblem; et navn, der ikke opløses nogen steder, er et tailnet- eller DNS-konfigurationsproblem. Tre ejere, tre rettelser, og MagicDNS-dokumentationen dækker macOS-særhederne ved det første tilfælde.