Test wycieku DNS: nazwa resolvera to nie trasa
Nazwa resolvera nie powie Ci, czy DNS ominął tunel. Zdecyduj, jakiej polityki chcesz, a potem porównaj odbiorcę, trasę i wyjątki.
Trzy układy uchodzą za poprawny DNS dla użytkownika VPN: zapytania do resolvera operatora, zapytania do wybranego przez Ciebie szyfrowanego resolvera oraz split DNS, który wysyła nazwy robocze do organizacji. Test wycieku zgłasza jeden resolver, a ta jedna etykieta nie powie Ci, który układ naprawdę masz. Najpierw zdecyduj o zamierzonej polityce, a potem testuj względem niej. Inaczej porównujesz liczbę z uczuciem.
Zdecyduj, czego chciałeś, zanim przeczytasz wynik
Nazwij politykę w jednym zdaniu: wszystkie nazwy do resolvera VPN, wszystkie nazwy do wybranego szyfrowanego resolvera albo split DNS z nazwami wewnętrznymi kierowanymi do organizacji. Każda jest obroniona dla innego użytkownika i każda daje inną oczekiwaną odpowiedź. Bez tego zdania każdy wynik odmienny od zrzutu ekranu z postu na forum wygląda alarmująco. Zapisz politykę przed pierwszym testem.
Test wykonany przed zdefiniowaniem polityki niczego nie mierzy. Daje nazwę resolvera bez żadnego punktu odniesienia.
Nazwa resolvera nie dowodzi ani ścieżki, ani odbiorcy
Liczą się dwa pytania: kto otrzymał zapytanie i która trasa je niosła. Do resolvera strony trzeciej można dotrzeć przez tunel, podczas gdy ekran ustawień pokazuje adres dostawcy. Etykieta na stronie testu wycieku opisuje widok obserwatora, a nie Twoją tablicę routingu.
Przeglądarka może używać własnego szyfrowanego DNS, gdy ruch witryny idzie przez tunel, a odpowiedzi z pamięci podręcznej mogą pozwolić stronie wczytać się bez nowego zapytania. Dlatego wynik publicznego IP nic nie mówi o DNS. DoH i DoT chronią zapytanie w drodze do resolvera, a ten resolver nadal widzi nazwy.
resolvectl status
resolvectl query example.com
dig +short example.com
Split DNS sprawia, że wiele resolverów jest poprawnych
Organizacja może wysyłać nazwy wewnętrzne do własnego DNS, a wszystko inne gdzie indziej. Dlatego test wymieniający kilka resolverów może opisywać zamierzoną politykę, a nie usterkę. Porównaj zaobserwowany zbiór z udokumentowanymi regułami split DNS, zanim cokolwiek wyłączysz. Wyłączenie wewnętrznego resolvera, by strona testu wyglądała czyściej, psuje nazwy prywatne.
Split tunneling i split DNS to różne wybory: jeden kieruje pakiety, drugi kieruje pytania. Zmiana trasy tunelu nie przesuwa wyszukiwania nazwy, a zmiana resolvera nie naprawia ścieżki witryny. IPv6 to trzecie pytanie, ponieważ niezamierzone połączenie IPv6 nie jest automatycznie wyciekiem DNS.
Zamień wynik w dochodzenie
Zapisz zamierzoną politykę i ustawienie bezpiecznego DNS przeglądarki przed testem. Przeprowadź test z aktywnym tunelem, zanotuj każdy wymieniony resolver i porównaj zbiór z polityką, a nie z jednym oczekiwanym adresem.
Powtórz po ponownym połączeniu, jeśli wtedy pojawia się objaw, ponieważ polityka zastosowana przy połączeniu może zostać później utracona. Dla wewnętrznych wyjątków DNS użyj dokumentacji klienta, zamiast zgadywać ustawienia.
Napraw znalezioną niezgodność: wybór przeglądarki, ustawienie DNS VPN lub regułę split DNS. Jeśli zapytania mają się zatrzymać, gdy tunel zawiedzie, kill switch jest osobnym ustawieniem, a sama konfiguracja DNS go nie zapewni. Specyfikacja RFC 8484 jest przydatna, gdy trzeba wyjaśnić, co szyfrowany resolver ukrywa, a czego nie.