Dlaczego nslookup rozwiązuje przez VPN, a przeglądarka nie

nslookup wysyła zapytanie do wskazanego serwera i wypisuje odpowiedź, dlatego może się udać, gdy każda karta przeglądarki zawodzi. Przeglądarka prosi system operacyjny o rozwiązanie, a system waży resolvery poszczególnych interfejsów, reguły zasad rozwiązywania nazw i położenie sieciowe adaptera. Następnie przeglądarka może dołożyć własny szyfrowany DNS. Trzy różne ścieżki, jeden objaw, a tunel zwykle nie jest zepsutą częścią.

Poniższe kontrole podążają tymi ścieżkami od systemu na zewnątrz. Nie edytuj profilu VPN, dopóki nie wiesz, która ścieżka odpowiedziała, a która zawiodła.

O odpowiedzi decydują trzy zasady

Każdy interfejs ma własną listę resolverów i sufiksy wyszukiwania. Adapter VPN dodaje serwery, podczas gdy adapter fizyczny zachowuje swoje, a system może wziąć ten, który odpowie pierwszy, więc wyszukiwanie może zostać obsłużone poza tunelem, choć nikt tego nie wybrał. Reguły tabeli zasad rozwiązywania nazw mogą kierować wybrane domeny do wybranych serwerów, tak zwykle wyraża się split DNS w Windows. A klient lub brama VPN mogą wepchnąć adres resolvera, który istnieje tylko w sieci prywatnej.

Te trzy współdziałają w sposób, który z przeglądarki wygląda dowolnie. Wepchnięty resolver pod adresem prywatnym bez trasy przez tunel dzielony sprawia, że każde wyszukiwanie się zawiesza, a potem zawodzi. Reguła zasad obejmująca wewnętrzny sufiks i wskazująca wyłączony serwer daje ten sam widoczny błąd co brakująca trasa. Brakujący sufiks wyszukiwania na adapterze VPN zamienia krótką nazwę w publiczne zapytanie o niewłaściwą domenę. Każdy z nich wymaga innej naprawy.

Dlaczego przeglądarka zadaje inne pytanie

nslookup wysyła własne zapytanie do wybranego serwera i nie stosuje ani zasad przestrzeni nazw, ani ustawienia szyfrowanego DNS przeglądarki. Dlatego ręczne zapytanie do publicznego resolvera odpowiada, gdy przeglądarka zgłasza, że witryna nie istnieje. Porównujesz dwa programy, a nie dwa stany jednego programu.

Preferencja rodziny adresów wyjaśnia opóźnienie, a nie awarię. Przeglądarka, która w tunelu przenoszącym tylko IPv4 najpierw pyta o rekordy IPv6, czeka na upływ limitu czasu, zanim się wycofa. Firefox miał taką preferencję właśnie po to, a jej wyłączenie jest krokiem diagnostycznym, nie naprawą.

Przeczytaj listę resolverów i reguły

W Windows wypisz to, co trzyma system, zanim zaczniesz teoretyzować. Get-DnsClientServerAddress pokazuje serwery na interfejs, Get-DnsClientNrptRule wymienia reguły przestrzeni nazw, a Resolve-DnsName odpowiada na dokładną nazwę ścieżką systemową. Porównaj tę odpowiedź z bezpośrednim zapytaniem do serwera VPN po adresie. Gdy Resolve-DnsName zawodzi, a bezpośrednie zapytanie się udaje, podejrzanym jest lista resolverów lub reguła przestrzeni nazw.

Sprawdź też samą nazwę. Wewnętrzna krótka nazwa może wymagać prywatnego sufiksu, który zapewnia tylko adapter VPN, podczas gdy nazwa w pełni kwalifikowana rozwiązuje się dobrze. Ostrzeżenie o certyfikacie po udanym wyszukaniu należy do innego problemu.

Nieosiągalny wepchnięty resolver

Brama lub klient mogą wepchnąć adres resolvera, a ten adres musi być osiągalny przez tunel. W tunelu dzielonym prywatny zakres zawierający resolver może nie być na dołączonych trasach, co daje wyszukiwanie, które nigdy nie otrzymuje odpowiedzi. Potwierdź, że trasa istnieje, a następnie zapytaj dokładnie o ten adres przez tunel. To jest awaria stojąca za błędem domeny w przeglądarce, gdy publiczny resolver wciąż odpowiada.

Jeśli resolver jest nieosiągalny, naprawą jest trasa lub dołączona podsieć, a nie inny serwer DNS.

Szyfrowany DNS omija całą ścieżkę

Przeglądarki z DNS-over-HTTPS same rozwiązują nazwy przez połączenie HTTPS z wybranym dostawcą. Gdy to jest włączone, resolver systemowy i reguły split DNS są całkowicie omijane dla tych wyszukiwań, więc nazwy wewnętrzne zawodzą w przeglądarce, podczas gdy system operacyjny rozwiązuje je poprawnie. Zdarza się też odwrotnie: nazwy wewnętrzne udają się w przeglądarce przez dostawcę, który nigdy nie powinien ich widzieć, a to problem zasad, nie łączności.

Świadomie zdecyduj, czy szyfrowany DNS jest dozwolony na urządzeniach zarządzanych, a następnie skonfiguruj go przez powierzchnię zarządzania przeglądarki, aby wybór był widoczny. Pozostawienie tego indywidualnym preferencjom tworzy flotę, w której ten sam VPN zachowuje się inaczej na każdym laptopie.

Naprawy dopasowane do awarii

Jeśli VPN wepchnął swój resolver, spraw, by tunel niósł ruch do niego i by to samo ustawienie było widoczne na adapterach uczestniczących w rozwiązywaniu. Jeśli lokalne witryny przestają się rozwiązywać po połączeniu, dodaj jawne wyjątki przestrzeni nazw lub przekazywanie warunkowe zamiast wymieniać resolver w całości. Jeśli szyfrowany DNS przeglądarki omija zasady, to jest ustawienie do zmiany. Nigdy nie dodawaj publicznego resolvera, aby naprawić nazwę wewnętrzną: wycieka prywatne zapytania i nie rozwiązuje nazwy.

Następnie oddziel wyszukiwanie od połączenia. Nazwa, która rozwiązuje się na właściwy adres, ale odmawia połączenia, to problem usługi, zapory lub certyfikatu, a zmiany DNS tego nie naprawią.

Zapisz, która ścieżka odpowiedziała, która zawiodła i co zmieniłeś. Następne zgłoszenie tego samego objawu zajmie wtedy jedno polecenie zamiast popołudnia.