Czy VPN zmienił mój DNS? Porównaj przed i po
Profil może celowo przenosić twoje zapytania. Porównaj politykę resolvera i rzeczywistą odpowiedź przed połączeniem VPN i po nim, utrzymując jedną zmienną.
Łączysz się z tunelem, otwierasz prywatny panel, a nazwa rozwiązuje się na adres, którego nigdy nie widziałeś. Albo dzieje się odwrotnie: przeglądarka nadal działa, a narzędzie wiersza poleceń nagle nic nie rozwiązuje. Oba wyniki pochodzą z tej samej zmiany, a ludzie zwykle tłumaczą to jednym zdaniem o VPN, który „używa własnego DNS”, co nie jest wystarczająco precyzyjne, by debugować czy weryfikować. W tym zdaniu kryją się dwa pytania: które zapytania ma przejąć ten profil i czy twoja maszyna rzeczywiście wysłała je do resolvera, który jej przydzielono? Trzymanie ich osobno to cała metoda, bo test, który je miesza, daje pewną siebie błędną odpowiedź w obu kierunkach.
Dlaczego profil w ogóle dostarcza resolver
Wewnątrz tunelu nazwy za dalekim końcem zwykle rozwiązują się na adresy istniejące tylko w tej sieci. Strefa prywatna taka jak corp.internal nie ma publicznej delegacji, więc resolver, który ją obsługuje, musi być osiągalny z wnętrza tunelu. Ten sam mechanizm służy drugiemu celowi: gdy zapytania inaczej wychodziłyby przez twojego dostawcę, resolver po drugiej stronie trzyma zapytanie w zaszyfrowanej ścieżce. Dlatego adres serwera DNS przychodzi jako część polityki połączenia, a nie jako globalne ustawienie wybrane raz dla maszyny.
Sam adres niczego nie rozstrzyga. Resolver może odpowiedzieć tylko wtedy, gdy istnieje do niego trasa, a najczęstszą awarią jest resolver osiągalny wyłącznie przy podniesionym tunelu. Gdy tunel pada, a polityka zostaje, zapytania idą na adres bez ścieżki, a objawem jest przekroczenie limitu czasu, a nie czysty błąd. Ta różnica ma znaczenie przy czytaniu kolejnego wyniku testu, bo przekroczenie limitu czasu kieruje ludzi do ustawień transportu, które nigdy nie były zaangażowane.
Porównaj oba projekty, zanim porównasz odpowiedzi
Pełny tunel i dzielony DNS dają przeciwne oczekiwania i żaden z nich nie jest awarią. W pełnym tunelu każde zapytanie może przejść do dostawcy lub do resolvera firmowego, więc inna odpowiedź nazw publicznych po połączeniu jest oczekiwana. W dzielonym DNS tylko wymienione domeny idą do prywatnego resolvera, a wszystko inne pozostaje lokalne; w Windows lista domen żyje w Name Resolution Policy Table, w macOS w pasujących domenach ustawień DNS, a na hoście systemd-resolved w domenach routingu na połączenie.
To porównanie trzeba wykonać najpierw, bo ono decyduje, co liczy się jako usterka. Przy dzielonym DNS publiczna nazwa odpowiadająca z nowego resolvera jest tym, co warto zbadać, podczas gdy poprawnie odpowiadająca nazwa wewnętrzna to system wykonujący swoją pracę. Przy pełnym tunelu anomalią jest publiczna nazwa, która nadal odpowiada z resolvera twojego dostawcy. Dokumentacja Microsoftu dotycząca rozwiązywania nazw VPN opisuje kolejność Windows dla tych reguł, w tym to, jak pasujący wpis polityki jest sprawdzany przed serwerami samego adaptera.
W pokoju jest też trzeci resolver, o którym łatwo zapomnieć. Bezpieczny DNS przeglądarki sam rozwiązuje nazwy i może nadal odpowiadać po tym, jak tunel zmienił politykę systemu operacyjnego, więc ładująca się strona dowodzi, że resolver przeglądarki działał, a nie że profil został zastosowany. Jeśli porównujesz tylko to, co pokazuje przeglądarka, przez połowę czasu testujesz niewłaściwą warstwę.
Zapisz linię bazową z tylko jedną zmienną
Zmień tunel. Nie zmieniaj jednocześnie nazwy, narzędzia ani sufiksu wyszukiwania w tym samym kroku. Wybierz nazwę, którą wolno ci odpytować, zanotuj, której aplikacji użyłeś, i zapisz albo zwrócony adres, albo dokładny błąd. W Windows Get-DnsClientServerAddress -AddressFamily IPv4 wypisuje serwery na adapter, a Get-DnsClientNrptPolicy wpisy polityki; w Linuksie z systemd-resolved resolvectl status pokazuje serwery DNS i domeny routingu na połączenie; w macOS scutil --dns wypisuje kolejność resolverów, której system rzeczywiście będzie przestrzegać.
Potem połącz się przez zwykłe elementy sterujące klienta i powtórz dokładnie te same polecenia. Zachowaj pierwsze wyjście, a nie wspomnienie o nim, bo porównanie jest całym sensem, a drugi odczyt po wyczyszczeniu pamięci podręcznej to już inny pomiar. Jeśli linię bazową pobrano z przeglądarką z przodu, a uruchomienie po połączeniu odbywa się w terminalu, porównujesz dwa resolvery, a nie dwa stany jednego resolvera.
Jawne zapytanie i wyszukanie aplikacji to różne testy
Zapytanie do jednego konkretnego serwera, przez nslookup name 10.20.0.1 lub dig @10.20.0.1 name, dowodzi jednej rzeczy: że wskazany serwer odpowiada, gdy można do niego dotrzeć. Omija całkowicie logikę wyboru, więc nie może powiedzieć, czy system wybrałby ten serwer dla tej nazwy. Używaj go do sprawdzania osiągalności przydzielonego resolvera, a nie do testowania polityki.
Wyszukanie przez lokalny resolver rzeczywiście ćwiczy wybór. resolvectl query name przechodzi te same reguły domen routingu i raportuje, który protokół odpowiedział, Resolve-DnsName w Windows przechodzi przez tabelę polityki i pamięć podręczną klienta, a scutil --dns pokazuje kolejność, której wyszukanie by przestrzegało. Uruchom oba rodzaje i trzymaj je w osobnych kolumnach notatek. Udane jawne zapytanie obok nieudanego wyszukania aplikacji to problem routingu lub wyboru, a nie resolver, który odmawia pracy.
Pamięć podręczna stoi między tobą a odpowiedzią. System operacyjny, lokalny resolver stub, przeglądarka i pamięć podręczna negatywna trzymają wyniki, więc wyszukanie może się udać bez jednego pakietu opuszczającego maszynę. Zapisz wynik, zanim cokolwiek wyczyścisz: ipconfig /flushdns, resolvectl flush-caches lub sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder w macOS. Pomiń szeroki reset sieci na tym etapie, bo niszczy dowody, które jeszcze zbierasz.
Co oznacza różnica
Porównaj dwa zapisane wiersze i sklasyfikuj zmianę, zanim dotkniesz choćby jednego ustawienia.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Jeden wiersz zasługuje na nacisk. Nazwa, która się rozwiązuje, nie jest działającą usługą, a sukces DNS mówi tylko, że znaleziono adres. Nie mówi nic o przekazywaniu, regułach firewalla ani o tym, czy twoje konto może w ogóle korzystać z usługi, więc zakończ testowaniem rzeczywistej aplikacji, zamiast zakładać, że usterka sama się wycofała.
Przywróć linię bazową i zweryfikuj ją
Rozłącz się przez własne elementy sterujące klienta, a nie zabijając proces, i przeczytaj ponownie te same trzy polecenia. Serwery na połączenie, wpisy polityki i odpowiedź dla nazwy testowej powinny wrócić do zapisanej wcześniej linii bazowej. Pozostały wpis polityki po czystym rozłączeniu to rzeczywisty defekt wart odnotowania, i właśnie dlatego ręczne edycje wygenerowanego pliku resolvera są złym nawykiem: plik jest przepisywany i edycja znika, albo edycja przetrwa i przypina resolver, który nie ma już trasy.
Przejdź tę listę raz, po kolei. Zdecyduj, który projekt realizuje profil, zanim ocenisz jakikolwiek wynik. Trzymaj nazwę, narzędzie i sufiks stałe w obu przebiegach. Oddziel jawne zapytanie od wyszukania aplikacji. Czytaj efektywną politykę, nie tylko odpowiedź. Wyczyść pamięci podręczne na końcu, po zapisaniu porównania. Zweryfikuj rzeczywistą aplikacją, potem uruchom ponownie raz i potwierdź, że stan po rozłączeniu jest nadal czysty.