DNS w VPN działa, ale nazwy .local nadal zawodzą: kto je rozwiązuje?

Dwie maszyny w tej samej sieci VPN, ta sama nazwa hosta, a tylko jedna z nich ją rozwiązuje: różnica zwykle nie tkwi w tunelu, lecz w tym, który resolver odpowiedział. Na pulpicie Linux ta nazwa może przejść przez przełącznik usług nazw, przez stub systemd-resolved lub przez resolver przyniesiony przez aplikację, a każdy z nich stosuje własną regułę do tego samego sufiksu. To właśnie na sufiksie reguły się rozchodzą, ponieważ .local nie jest neutralną etykietą. Ustal, którą ścieżkę naprawdę obrać zawodzący program, zanim zmienisz kolejność, w jakiej cokolwiek działa.

Dwa resolvery, dwie różne odpowiedzi

Tradycyjne wyszukiwanie glibc przechodzi przez wiersz hosts: w nsswitch.conf i pyta każdy moduł po kolei, aż jeden odpowie. Klient, który rozmawia z systemd-resolved przez odbiornik stub, pyta zamiast tego jeden proces, a proces ten stosuje politykę dla każdego połączenia oraz własne przypadki specjalne. Aplikacja, która przynosi własny resolver lub linkuje bibliotekę, która to robi, może ominąć oba. Jedna nazwa hosta może więc mieć trzech właścicieli na jednej maszynie, a tylko jeden z nich wie, co zamierzał VPN.

Zidentyfikuj właściciela, zanim cokolwiek zmienisz, bo poprawka jest inna dla każdego z trzech. Przeglądarka i narzędzie wiersza poleceń na tym samym pulpicie mogą legalnie się nie zgadzać, a ta niezgodność jest wskazówką, nie błędem. Jeśli przeglądarka rozwiązuje nazwę, a narzędzie nie, debugujesz ścieżkę resolvera, a nie trasę VPN. Potwierdź trasę osobno, aby awaria routingu nie została pomylona z awarią usługi nazw. Gdy oba się zgadzają, awaria leży powyżej hosta i tutejsza konfiguracja resolvera nie jest warta kolejnej zmiany.

Które polecenie naprawdę zapytało twój resolver

Dwa polecenia tylko do odczytu odpowiadają na powiązane pytania, a ich porównanie lokalizuje problem szybciej niż czytanie konfiguracji. Użyj prawdziwej nazwy wewnętrznej i zachowaj poufność danych wyjściowych, bo rekordy wewnętrzne pozostają wewnętrzne. Uruchom oba w tej samej sesji, w której działa zawodzący program:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Pierwsze pyta przez skonfigurowane moduły, czego doświadcza typowy program. Drugie pyta bezpośrednio systemd-resolved i raportuje połączenie, protokół oraz serwer, który odpowiedział. Odpytywanie serwera firmowego po adresie dowodzi tylko, że serwer ma rekord, bo nie mówi nic o tym, czy aplikacja kiedykolwiek o niego zapytała. Przeczytaj połączenie, które niesie VPN, oraz domeny, które deklaruje, a następnie porównaj tę listę z sufiksem w zawodzącej nazwie.

Dlaczego .local pomija twoją strefę unicast

odwołanie systemd-resolved podaje, że nazwy wieloetykietowe kończące się na .local przy włączonym mDNS trafiają zwykle do DNS multicast, a nie do zwykłego DNS unicast. RFC 6762 rezerwuje tę przestrzeń nazw dla multicastu link-local, więc strefa firmowa może mieć poprawny rekord, o który nigdy nie pyta się dla tego sufiksu. Tunel może idealnie routować resolver i mimo to przegrać wyścig. Udany ping z pamięci podręcznej nie mówi nic o wyszukiwaniu, które właśnie się odbyło.

Istnieje udokumentowany wyjątek i rozstrzyga on większość takich przypadków: gdy połączenie deklaruje ten sufiks jako domenę wyszukiwania lub domenę routingu, demon trzyma go na ścieżce unicast i pomija specjalny przypadek multicastu. To polityka dla każdego połączenia, a nie preferencja globalna. Dwie maszyny z tym samym serwerem VPN mogą zachowywać się różnie, gdy jeden profil sieci deklaruje domenę, a drugi nie, więc czytaj aktywny profil, a nie ten, który pamiętasz jako edytowany.

Wąski wyjątek wygrywa z globalnym przestawieniem

Dla istniejącej strefy, której nie możesz zmienić nazwy, poproś właścicieli resolvera i VPN o zadeklarowanie domeny na połączeniu, które ją niesie. Wpis domeny routingu dla tego jednego sufiksu plus docelowy adres serwera to mała zmiana z nazwanym właścicielem, i żyje z połączeniem, a nie w pliku edytowanym ręcznie.

Przetrwa też rozłączenie, bo polityka połączenia jest stosowana ponownie, gdy połączenie wraca. Edycja wspólnego nsswitch.conf to kusząca i droższa alternatywa, bo zmienia zachowanie wyszukiwania dla każdej nazwy na maszynie, łącznie z odkrywaniem lokalnym. Wyłączenie demona multicastu też nie jest równoważne: usuwa lokalne zachowanie, nie ucząc żadnego resolvera strefy firmowej. Jeśli usługa jest nowa, a nie odziedziczona, umieść ją w subdomenie kontrolowanej przez organizację i całkowicie pomiń konkurencję. Wybierz wąski wyjątek, gdy nazwa jest utrwalona w firmware lub wydrukowana na etykiecie, a nową subdomenę, gdy nadal kontrolujesz klienta.

Co udowodnić po zmianie

Udowodnij poprawkę własnym wyszukiwaniem aplikacji, a nie narzędziem zainstalowanym do testów, i wyczyść każdą pamięć podręczną, która mogłaby odpowiedzieć w jej imieniu. Następnie potwierdź ścieżkę resolvera i połączenie, które dało odpowiedź. Na koniec sprawdź, czy odkrywanie lokalne zachowuje się jak przed zmianą, bo drukarka, która przestaje się pojawiać, to część, którą ludzie zauważają najpóźniej. Te trzy polecenia sprawdzają nazwę, ścieżkę i tożsamość TLS w tej kolejności:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Poprawny adres z błędnym certyfikatem nadal zawodzi u surowego klienta, więc sprawdź nazwę oczekiwaną przez aplikację, gdy rozwiązywanie zacznie działać. Potwierdź, że usługa przyjmuje połączenia z adresu VPN, a nie tylko z zakresu biurowego. Zapisz zakres domeny, serwer i właściciela w dokumentacji połączenia. Inaczej następna osoba, która trafi na tę awarię, sięgnie po tę samą globalną edycję, której właśnie uniknąłeś.