DNS VPN kontra DoH przeglądarki: czego nie powie ci test wycieku

Strona testu wycieku mówi, że twoje DNS jest w porządku, odznaka przeglądarki mówi bezpieczne, a wewnętrzna wiki nadal się nie ładuje. Wszystkie trzy mogą być prawdziwe jednocześnie, bo adres resolvera to nie to samo co polityka, która go wybrała, ani ścieżka, którą przeszło zapytanie. To, co ludzie nazywają wyciekiem DNS, to właściwie jedno pytanie: który resolver otrzymał nazwę i czy ten wybór był zamierzony? Uporządkowanie tego wymaga trzech kontroli, a tylko ostatnia wiąże się ze zmianą ustawienia.

Mit pierwszy: odznaka nazywa twój resolver

Test wycieku rozwiązuje nazwę próbną i zgłasza adres, który odpowiedział. Nie zgłasza polityki, która wybrała ten resolver, a gdy zapytanie jest owinięte w DNS przez HTTPS, pośrednik na ścieżce w ogóle nie widzi nazwy. Dwie bardzo różne maszyny dają tę samą uspokajającą odznakę: jedna, w której VPN wepchnął 10.8.0.1 i przeglądarka go używa, i druga, w której przeglądarka zignorowała listę systemową i wysłała nazwę przez tunel do własnego zaszyfrowanego dostawcy.

Ta różnica ma znaczenie w chwili, gdy prywatna nazwa zawodzi. W pierwszym układzie resolver VPN odpowiada za strefę firmową; w drugim przeglądarka nigdy go nie zapytała, więc krótka nazwa hosta się nie rozwiązuje, a awaria wygląda jak zepsuty VPN. Ta kontrola nie jest kolejnym testem wycieku, to wyszukanie nazwy, którą zna tylko jeden resolver.

Mit drugi: przeglądarka opuszcza tunel

DNS wybiera adres, routing niesie połączenie, i to są dwie osobne warstwy. Zapytanie wysłane do publicznego dostawcy DoH to nadal TCP port 443 do adresu routowalnego. Jeśli twoja tablica routingu wysyła trasę domyślną do tunelu, to zapytanie też przechodzi przez tunel. Marka resolvera nie decyduje o ścieżce.

To, co zmienia DoH przeglądarki, to odbiorca nazw. To prawdziwa decyzja o prywatności i prawdziwa decyzja polityczna, ale nie obejście routingu. Jeśli twoim wymaganiem jest, aby nazwy zostawały u operatora VPN, to zaszyfrowane zapytanie do kogoś innego tego wymagania nie spełnia, choć nadal korzysta z tunelu przy rzeczywistym połączeniu.

Mit trzeci: każdy VPN nadpisuje każdą przeglądarkę

Bezpieczny DNS w przeglądarce ma tryby, a nie przełącznik: wyłączony, domyślny dostawca z rezerwą, własny szablon albo polityka narzucona przez system operacyjny lub organizację. To właśnie przypadek rezerwowy generuje sporadyczne raporty. Gdy zaszyfrowany punkt końcowy jest nieosiągalny, przeglądarka może wrócić do resolvera systemowego, więc ten sam laptop w poniedziałek poprawnie rozwiązuje prywatną nazwę, a we wtorek nie.

Jednocześnie większość klientów VPN ustawia resolver systemowy przy podnoszeniu połączenia i przywraca poprzedni przy jego spadku. Przeglądarka trzymająca własny zaszyfrowany resolver w ogóle tego przywrócenia nie zauważa. Dlatego ten sam profil zachowuje się inaczej na dwóch laptopach i dlatego resolv.conf wygląda poprawnie, podczas gdy przeglądarka nadal pyta kogoś innego.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Uruchom je, będąc połączonym, zanotuj, które domeny rości sobie każdy resolver, i porównaj z tym, co przeglądarka zgłasza o swoim trybie. Dokumentacja DoH Mozilli to rozsądny opis tego, jak powinno działać domyślne i rezerwowe zachowanie przeglądarki.

Decyzja ma trzy wejścia, a nie jedno

Prywatne nazwy, zaufanie do operatora i osiągalność decydują o właściwym układzie. Nazwy, które zna tylko resolver VPN, wymuszają dzielony DNS: prywatny sufiks idzie do wepchniętego resolvera, a wszystko inne podlega polityce wybranej dla nazw publicznych. Zaufanie do operatora decyduje, czy nazwy publiczne też mają iść do tego resolvera, czy do osobnej usługi. Osiągalność decyduje, czy wybrany zaszyfrowany resolver jest w ogóle użyteczny w tej sieci.

Żaden z tych wierszy nie jest uniwersalnym zaleceniem. Resolver obsługiwany przez VPN koncentruje obserwacje u tego operatora; osobna usługa dodaje kolejnego odbiorcę odpytywanych nazw. Żaden układ nie dowodzi niczego o przechowywaniu, chyba że przeczytasz politykę.

Zapisz decyzję dla każdego profilu, bo te ustawienia dryfują. Profil, który w zeszłym miesiącu wepchnął resolver, dziś może nie wepchnąć żadnego, a przeglądarka chętnie zachowa stary własny punkt końcowy, który nadal odpowiada. W notatce powinny być adres resolvera, sufiksy, które posiada, i tryb przeglądarki, a nie marka usługi.

Sprawdź politykę, którą sądzisz, że skonfigurowałeś

Sprawdzaj po nazwie, nie po odznace. Rozwiąż nazwę publiczną i prywatną przez resolver systemowy, a potem powtórz to w przeglądarce z jej własnym ustawieniem bezpiecznego DNS w trybie, który zamierzasz używać. Jeśli prywatna nazwa zawodzi tylko w przeglądarce, znalazłeś niezgodność odbiorcy, nie dotykając ani jednego ustawienia VPN.

Potem połącz się ponownie i sprawdź przywrócenie, bo tam żyją błędy przekazania: rozłącz się, potwierdź, że poprzedni resolver wrócił, połącz się ponownie, potwierdź, że wepchnięty wrócił. Na koniec sprawdź przeglądarkę z zarządzaną polityką, jeśli taką masz, bo ten tryb może całkowicie odrzucić twoją zmianę i po cichu zachować poprzedni resolver.

Zacznij od pytania o przestrzeń nazw i unikniesz większości tego. Jeśli maszyna musi docierać do nazw wewnętrznych, zaszyfrowany resolver przeglądarki jest decyzją tylko o połowie publicznej, a połowa prywatna zostaje przy tym, co wepchnął VPN.