Twój VPN wypycha trzy serwery DNS: który odpowiada?

Po połączeniu otwórz stronę ustawień, a zobaczysz trzy adresy DNS; pytanie audytu brzmi, który z nich obsłużył twoje ostatnie zapytanie. Sama liczba niczego nie rozstrzyga, bo wypchnięcie przez klienta, interfejs fizyczny i zasada dla domeny piszą do tego samego widoku. Te wpisy mają różne zakresy, a o tym, kto odpowiada, decyduje zakres, nie pozycja. Zacznij od rozdzielenia źródeł, potem sprawdź to, które posiada nazwę, na której ci zależy.

Dlaczego lista jest dłuższa niż twój profil

Klient VPN wypycha adresy resolvera dla łącza tunelu, a system operacyjny trzyma je obok tego, co interfejs fizyczny już miał. Router, firmowy leasing DHCP, drugi VPN i zasada dla domeny dokładają własny wpis. Dlatego trzy adresy na stronie mogą oznaczać trzy zakresy, a nie trzech kandydatów do jednego zadania. Czytanie liczby jako dowodu wycieku to pierwszy błąd tego audytu.

W obrębie jednego interfejsu klient rzeczywiście próbuje swoich serwerów po kolei, więc uporządkowana lista nie jest bezsensowna. Kolejką nie jest natomiast widok scalony, w którym wpisy z profilu, z łącza fizycznego i z reguł dla domen stoją obok siebie bez jednego rankingu. Ta różnica decyduje, co testujesz: kolejność wyjaśnia zachowanie w obrębie jednego zakresu, a zakres wyjaśnia wszystko inne.

Szyfrowane DNS psuje obraz od środka aplikacji. Przeglądarka lub klient czatu z własnym resolverem DNS-over-HTTPS wysyła zapytania całkowicie poza listę systemu operacyjnego, więc adresy na stronie ustawień opisują ruch, którego aplikacja nigdy nie wygenerowała. Sprawdź własne ustawienie resolvera aplikacji, zanim obwinisz profil o nazwę, która wyszła błędnie.

Co mówi każda z trzech kontroli

Każde źródło zostawia ślad w innym miejscu i żadne pojedyncze polecenie nie pokazuje wszystkich. Oto mapowanie, które warto trzymać obok strony ustawień:

W systemie z systemd-resolved wiążąca jest resolvectl status, ponieważ raportuje DNS dla każdego łącza razem z domenami routingu. macOS odpowiada przez scutil --dns, które wymienia resovery z zakresem w kolejności prób. Windows dzieli się na dwie połowy: Get-DnsClientServerAddress dla serwerów interfejsów i Get-DnsClientNrptPolicy dla reguł sufiksów. Uruchom polecenie odpowiadające resolverowi faktycznie używanemu, bo maszyna z środowiskiem kontenerów i resolverem pulpitu może mieć zainstalowany więcej niż jeden.

Zapasowy resolver, który nie potrafi odpowiedzieć za twoją strefę

Drugi wpis zwykle istnieje dla dostępności, a dostępność działa tylko wtedy, gdy zapas zna nazwy. Zapytaj publiczny resolver o wewnętrzną nazwę hosta, a zwróci NXDOMAIN albo odpowiedź z wieloznacznikiem z domeny wyszukiwania, która nie ma z tobą nic wspólnego. Niesprawdzony failover powoduje wtedy awarię dokładnie w momencie, gdy jest potrzebny.

Split DNS istnieje, aby temu zapobiec: sufiksy firmy idą do resolvera, który trzyma strefę, a nazwy publiczne zostają na ścieżce domyślnej. Projekt jest solidny i zależy od tego, czy lista sufiksów jest pełna. Microsoft dokumentuje zasadę resolvera dla każdego sufiksu, która steruje tym w Windows, a ten sam pomysł pojawia się jako domeny routingu w systemd-resolved i jako resovery z zakresem w macOS.

Porównaj strefy, za które zapas może odpowiadać, z sufiksami obecnymi w zasadzie. To porównanie znajduje lukę, zanim użytkownik zgłosi, że jedna wewnętrzna witryna przestała się rozwiązywać po zmianie tunelu.

Pytaj przez zasadę, nie obok niej

Pytaj przez resolver systemu operacyjnego, bo bezpośrednie zapytanie do serwera omija zasadę i raportuje tylko to, co powiedziałby ten serwer. Różnica między dwiema odpowiedziami to cały sens:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Jeśli zapytanie systemowe zwraca adres prywatny, a bezpośrednie zwraca NXDOMAIN, zasada działa, a słabym punktem jest zapas. Jeśli oba zwracają tę samą odpowiedź publiczną, nazwa jest rozwiązywana poza zamierzonym zakresem, a lista sufiksów jest miejscem, w które trzeba patrzeć. Zachowaj oba wyniki, bo spór o resolver rozstrzyga się szybciej dwiema liniami niż zrzutem ekranu strony ustawień.

Potem przećwicz ścieżkę awarii, bo zapas, którego nikt nie testował, jest założeniem. Zrób z preferowanego resolvera czarną dziurę dla jednego zapytania i patrz, który adres wraca:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Usuń tę trasę od razu po zakończeniu zapytania, inaczej następna osoba odziedziczy zagadkę. Jeśli nazwy wewnętrzne nadal się rozwiązują w tym oknie, odpowiedziało na nie coś spoza zamierzonego zakresu. Jeśli zamiast tego kończą się przekroczeniem czasu, brakuje zapasu albo jest poprawnie ograniczony, a własny log resolvera mówi, które z tych dwóch to było.

Zdecyduj: zachować, ograniczyć czy usunąć

Zachowaj drugi resolver, gdy odpowiada na potrzebną przestrzeń nazw i pozostaje osiągalny w ramach profilu. Ogranicz go, gdy powinien widzieć jeden sufiks i nic więcej, a usuń, gdy nie ma ani zakresu, ani udokumentowanego celu. Wpis bez zadania to przyszły wyciek bez korzyści, a wartość domyślna dostawcy nie jest celem.

Zapisz wynik w czterech kolumnach: sufiks, resolver, interfejs i właściciel. Ta linia odpowiada na następne pytanie audytu szybciej niż jakikolwiek zrzut ekranu i przetrwa aktualizację klienta, która cicho przestawia listę.