Tailscale MagicDNS virker, men nslookup feiler på macOS

På en Mac løser ping et tailnet-maskinnavn mens nslookup returnerer en feil, og begge kommandoene taler sant. Apper løser via systemoppløseren, som Tailscale konfigurerer per grensesnitt, mens nslookup og host leser en statisk fil som MagicDNS aldri rører. De to veiene kan være uenige uten at en eneste pakke går tapt. Avgjør hvilken vei den feilende applikasjonen din tok, før du endrer noen DNS-innstilling.

To oppløsningsveier, to forskjellige svar

Apptrafikk på macOS går gjennom systemoppløseren, og grensesnittbundne oppløseroppføringer avgjør hvilken server som svarer for hvilket domene. Tailscale installerer sin MagicDNS-oppføring der, og derfor finner Safari og ssh tailnet-navn. nslookup, host og dig leser i stedet /etc/resolv.conf eller tar en server på kommandolinjen, og den filen nevner vanligvis fortsatt ruteren eller en kontorserver. Et tailnet-navn sendt til den filen har ikke noe autoritativt svar som venter på det, så verktøyet rapporterer feil mens systemveien lykkes.

Ingen av verktøyene oppfører seg feil. De spør forskjellige servere, og bare én av disse serverne kjenner tailnetet ditt.

Test det samme navnet gjennom systemveien

Bruk systemets oppslagskall som den første testen, og sammenlign det deretter med en forespørsel rettet direkte mot MagicDNS-oppløseren. Hold stavemåten identisk i begge, inkludert tailnet-domenet, fordi et kort navn og et fullt kvalifisert navn er forskjellige spørsmål med forskjellige 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 utdataene svarer på tre spørsmål: hva systemet returnerer, hvilke oppløsere som er konfigurert for hvilke domener, og hva MagicDNS selv vet. Et navn som finnes i det andre og tredje, men mangler i det første, peker på lokal konfigurasjon og ikke på tailnetet.

Når navnet er oppløst, test tjenesten

Et korrekt DNS-svar beviser bare at et navn peker på en adresse. Tjenesten bak kan være stoppet, porten kan være filtrert av en tilgangsregel, og et sertifikat kan navngi en annen vert enn den du skrev.

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

Ta vare på den opprinnelige feilteksten, fordi en sertifikatadvarsel, en tilkoblingstidsavbrudd og et ikke-funnet navn fører hver til noe forskjellig. Å endre navneservere reparerer det tredje og kaster bort en ettermiddag på de to første.

MagicDNS erstatter ikke kontor-DNS

Et navn i en kontorsone er ikke et tailnet-enhetsnavn selv når den samme klienten kan nå begge. Når målet ligger bak en subnett-ruter, trenger klienten split DNS for den sonen som peker på den interne oppløseren, som er en annen innstilling enn MagicDNS og er dokumentert ved siden av den.

Søkedomener betyr også noe. Et ikke-kvalifisert kort navn får hvert konfigurerte suffiks lagt til i rekkefølge, så en bærbar datamaskin som nylig ble med i et annet nettverk, kan løse via et utdatert suffiks. Sjekk hvilket suffiks som ble brukt, før du erklærer sonen ødelagt.

Når begge veiene feiler, avgjør tailnet-fakta

Hvis både systemoppslaget og den direkte forespørselen feiler for en enhet du tror finnes, ligger problemet over Mac-ens oppløser.

Bekreft maskinnavnet og tailnet-domenet i administrasjonskonsollen, bekreft at enheten er online og godkjent, og bekreft at klientens DNS-innstillinger ikke er deaktivert lokalt. En enhet som er frakoblet, beholder navnet sitt og har rett og slett ingen adresse å returnere.

Velg deretter ut fra bevis. Et navn som løses på systemveien og feiler i nslookup, er en forskjell i verktøyveien; et navn som løses mens tjenesten avviser, er et tilgangs- eller sertifikatproblem; et navn som ikke løses noe sted, er et tailnet- eller DNS-konfigurasjonsproblem. Tre eiere, tre rettelser, og MagicDNS-dokumentasjonen dekker macOS-spesialitetene ved det første tilfellet.