Tailscale MagicDNS działa, ale nslookup zawodzi na macOS

Na Macu ping rozwiązuje nazwę maszyny tailnet, podczas gdy nslookup zwraca błąd, i oba polecenia mówią prawdę. Aplikacje rozwiązują przez resolver systemowy, który Tailscale konfiguruje dla każdego interfejsu, a nslookup i host czytają statyczny plik, którego MagicDNS nigdy nie dotyka. Obie ścieżki mogą się różnić bez utraty choćby jednego pakietu. Zanim zmienisz jakiekolwiek ustawienie DNS, ustal, którą ścieżką poszła twoja zawodząca aplikacja.

Dwie ścieżki rozwiązywania, dwie różne odpowiedzi

Ruch aplikacji na macOS przechodzi przez resolver systemowy, a wpisy resolvera ograniczone do interfejsu decydują, który serwer odpowiada za którą domenę. Tailscale instaluje tam swój wpis MagicDNS, dlatego Safari i ssh znajdują nazwy tailnet. nslookup, host i dig zamiast tego czytają /etc/resolv.conf albo biorą serwer z wiersza poleceń, a ten plik zwykle nadal wskazuje router lub serwer biurowy. Nazwa tailnet wysłana do tego pliku nie ma żadnej oczekującej odpowiedzi autorytatywnej, więc narzędzie zgłasza błąd, podczas gdy ścieżka systemowa kończy się sukcesem.

Żadne z narzędzi nie zachowuje się źle. Pytają różnych serwerów, a tylko jeden z tych serwerów zna twój tailnet.

Przetestuj tę samą nazwę ścieżką systemową

Użyj wywołania wyszukiwania systemowego jako pierwszego testu, a następnie porównaj je z zapytaniem skierowanym bezpośrednio do resolvera MagicDNS. Zachowaj identyczną pisownię w obu, łącznie z domeną tailnet, ponieważ krótka nazwa i nazwa w pełni kwalifikowana to różne pytania z różnymi odpowiedziami.

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

Te trzy wyjścia odpowiadają na trzy pytania: co zwraca system, jakie resolvery są skonfigurowane dla jakich domen i co wie sam MagicDNS. Nazwa obecna w drugim i trzecim, ale nieobecna w pierwszym, wskazuje na konfigurację lokalną, a nie na tailnet.

Gdy nazwa zostanie rozwiązana, przetestuj usługę

Poprawna odpowiedź DNS dowodzi tylko, że nazwa wskazuje adres. Usługa za nią może być zatrzymana, port może być filtrowany regułą dostępu, a certyfikat może wskazywać inny host niż wpisany.

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

Zachowaj oryginalny tekst błędu, ponieważ ostrzeżenie o certyfikacie, przekroczenie czasu połączenia i nieznaleziona nazwa prowadzą każde gdzie indziej. Zmiana serwerów nazw naprawia trzeci przypadek i marnuje popołudnie na dwa pierwsze.

MagicDNS nie zastępuje DNS biurowego

Nazwa w strefie biurowej nie jest nazwą urządzenia tailnet, nawet gdy ten sam klient dociera do obu. Gdy cel znajduje się za routerem podsieci, klient potrzebuje split DNS dla tej strefy wskazującego na wewnętrzny resolver, co jest innym ustawieniem niż MagicDNS i jest udokumentowane obok niego.

Domeny wyszukiwania też mają znaczenie. Do niekwalifikowanej krótkiej nazwy dodawany jest po kolei każdy skonfigurowany sufiks, więc laptop, który niedawno dołączył do innej sieci, może rozwiązać nazwę przez nieaktualny sufiks. Sprawdź, który sufiks zastosowano, zanim uznasz strefę za zepsutą.

Gdy obie ścieżki zawodzą, decydują fakty o tailnecie

Jeśli wyszukiwanie systemowe i bezpośrednie zapytanie zawiodą oba dla urządzenia, które według ciebie istnieje, problem leży powyżej resolvera Maca.

Potwierdź nazwę maszyny i domenę tailnet w konsoli administracyjnej, potwierdź, że urządzenie jest online i zatwierdzone, oraz potwierdź, że ustawienia DNS klienta nie zostały wyłączone lokalnie. Urządzenie offline zachowuje swoją nazwę i po prostu nie ma adresu do zwrócenia.

Następnie wybierz na podstawie dowodów. Nazwa, która rozwiązuje się ścieżką systemową i zawodzi w nslookup, to różnica ścieżki narzędzia; nazwa, która rozwiązuje się, gdy usługa odmawia, to problem dostępu lub certyfikatu; nazwa, która nie rozwiązuje się nigdzie, to problem tailnetu lub konfiguracji DNS. Trzech właścicieli, trzy poprawki, i dokumentacja MagicDNS omawia specyfikę macOS pierwszego przypadku.