VPN połączony, ale nazwy nie działają: gdzie naprawdę łamie się DNS

Tunel jest podniesiony, ikona zielona, a każda karta przeglądarki zgłasza błąd rozwiązywania nazw. Ten obraz tworzą trzy różne mechanizmy: resolver może być nieosiągalny, klient może pytać resolver, którego nie oczekiwałeś, albo mogą zawieść tylko nazwy prywatne. Rozdziel je, zanim zmienisz cokolwiek w protokole tunelu, ponieważ każdy naprawia się w innym miejscu. Poniższa kolejność zaczyna się od obserwacji, które rozdzielają te trzy przypadki.

Czego naprawdę potrzebuje zapytanie

Zapytanie potrzebuje trzech rzeczy: adresu resolvera, trasy do tego adresu i odpowiedzi zgodnej z pytaniem. Każda z nich może zawieść osobno, a widocznym objawem jest ta sama strona, która się nie ładuje. Dlatego strona błędu nie mówi prawie nic, dopóki nie wiesz, która z trzech się zepsuła.

Klient poznaje swój resolver z profilu VPN, z DHCP na tunelu albo z własnej konfiguracji, a to, które źródło wygra, zależy od platformy. W systemie Windows ipconfig /all wyświetla serwery DNS dla każdego adaptera, więc widzisz, czy wysłana wartość rzeczywiście dotarła. Wysłana wartość, która nigdy nie dotarła do systemu operacyjnego, to cichy i częsty błąd. Przeczytaj skonfigurowaną wartość, zanim dotkniesz profilu.

Linux i macOS odpowiadają na to samo pytanie innymi poleceniami, a odpowiedź zasługuje na takie samo czytanie: resolvectl status i scutil --dns oba wymieniają serwery według interfejsu. Porównaj tę listę z adresem, który profil twierdzi, że wysyła. Niezgodność tutaj wyjaśnia wszystko dalej, więc rozstrzygnij ją, zanim zaczniesz testować nazwy.

Sprawdź jedną nazwę publiczną i jedną prywatną

Zapytaj o zwykłą publiczną nazwę hosta i udokumentowaną prywatną nazwę hosta z tej samej maszyny i zapisz, który serwer odpowiedział na każdą. Jeśli zawiodą obie, resolver lub jego trasa są zepsute. Jeśli zawiedzie tylko nazwa prywatna, resolver odpowiedział, a pytanie staje się strefą lub routingiem. Uruchom oba zapytania w odstępie minuty, aby zmiana trasy nie mogła wyjaśnić różnicy.

Trzymaj nazwy wewnętrzne poza publicznymi zrzutami ekranu i poza publicznymi resolverami. Limit czasu i odpowiedź o nieistniejącej domenie to różne obserwacje: pierwsza mówi, że nic nie wróciło, druga, że autorytet odpowiedział, iż nazwa nie istnieje. Traktowanie ich jako jednego błędu prowadzi do złej warstwy, a ostrzeżenie o certyfikacie to znów trzecia rzecz, nie awaria DNS.

nslookup wypisuje zarówno serwer, o który pytano, jak i otrzymaną odpowiedź, i to jest dokładnie ta para, której potrzebujesz. Uruchom go dwa razy w tej samej powłoce i zapisz odpowiadający adres obok każdej odpowiedzi.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Potwierdź, że klient rzeczywiście dociera do tego serwera

Prywatny resolver wysyłany przez profil jest przydatny tylko wtedy, gdy klient może do niego dotrzeć przy podniesionym tunelu. Adres, który wygląda poprawnie, ale nie ma trasy, daje limit czasu, a stan połączenia tunelu nic nie mówi o tej trasie. Sprawdzenie to wyszukanie trasy skierowane na sam resolver, a nie na punkt końcowy VPN.

Każda platforma odpowiada na to jedną linią, a interfejs wymieniony w wyniku to cała odpowiedź. Jeśli wskazuje adapter fizyczny, podczas gdy resolver znajduje się za tunelem, profil nie wysyła prefiksu, który go obejmuje.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

W profilu z dzielonym tunelem resolver może znajdować się poza wysyłanymi trasami, co jest problemem profilu, a nie serwera. Porównaj adres resolvera z wysyłanymi prefiksami i potwierdź, że jeden z nich go obejmuje. Ta sama niezgodność wyjaśnia, dlaczego DNS działa w jednej sieci, a zawodzi w innej z identycznym profilem.

Pamiętaj, że przeglądarki mogą omijać resolver systemowy

Przeglądarka z włączonym bezpiecznym DNS może wysyłać zapytania przez HTTPS do wybranego przez siebie dostawcy i całkowicie ignorować resolver systemu operacyjnego. Wtedy system wygląda poprawnie, a przeglądarka zawodzi, albo odwrotnie. To kwestia polityki przeglądarki, a nie tunelu.

Sprawdź ustawienie bezpiecznego DNS w przeglądarce i wszelkie zarządzane zasady, które je kontrolują, a następnie wypróbuj drugą aplikację lub przeglądarkę przy niezmienionym tunelu. Jeśli zawodzi tylko jedna aplikacja, poprawka należy do tej aplikacji. Okno prywatne nie jest czystym porównaniem, ponieważ w jednej przeglądarce może domyślnie wyłączać rozszerzenia, a w innej nie, i nigdy nie omija zarządzanych zasad. Użyj zamiast tego drugiego profilu przeglądarki lub innej aplikacji.

Wyczyść pamięć podręczną i ponownie przetestuj prawdziwe zadanie

Po poprawieniu ustawienia wyczyść lokalną pamięć podręczną resolvera, aby stara odpowiedź nie przetrwała poprawki. Krótkie ożywienie, po którym następuje nowa awaria, oznacza, że przyczyna nadal istnieje, a nie że czyszczenie się nie powiodło. Wybierz wiersz pasujący do maszyny, na której jesteś, ponieważ trzy pamięci podręczne są osobne.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Następnie powtórz pierwotne zadanie zamiast syntetycznego zapytania, ponieważ to zadanie jest tym, na czym zależy użytkownikowi. Połącz się też jeszcze raz, aby ponowny test objął stan, w którym użytkownik naprawdę będzie. Dokumentacja nslookup firmy Microsoft to strona, którą warto zachować dla argumentów zapytania.

Jeśli nazwy zawodzą dopiero po rozłączeniu, klient nie przywrócił poprzedniej konfiguracji, co jest błędem cyklu życia do zgłoszenia, a nie serwerem DNS do wymiany. Działające zapytanie nie jest też testem wycieku, ponieważ kraj wyjścia nie mówi, który resolver odpowiedział.