Prywatny DNS a VPN: co naprawdę obejmuje każda warstwa

Twój telefon ma jednocześnie ustawiony prywatny DNS na nazwę hosta dostawcy i uruchomioną aplikację VPN. Rozsądnie jest założyć, że jedna z nich odpowiada teraz za wyszukiwanie nazw. Żadna tego nie robi, w sensie, który sugeruje to zdanie, a najszybszym sposobem, by zobaczyć dlaczego, jest prześledzenie jednego zapytania od chwili, gdy dotkniesz linku.

Te dwie funkcje leżą w różnych punktach tej samej podróży. Prywatny DNS szyfruje pytanie, które zadajesz resolverowi. VPN zmienia trasę, którą podąża połączenie z odpowiedzią.

Przejdź więc przez to po kolei na urządzeniu, na którym oba są włączone, i zanotuj, co każda warstwa może jeszcze zobaczyć.

Krok pierwszy: wyszukiwanie opuszcza aplikację

Dotykasz linku. Zanim cokolwiek się połączy, aplikacja potrzebuje adresu dla tej nazwy hosta. W Androidzie odpowiedni ekran to Ustawienia, Sieć i internet, Prywatny DNS. Wybranie Nazwa hosta dostawcy prywatnego DNS przełącza urządzenie w tryb ścisły: wykonuje DNS przez TLS do tej nazwy hosta na porcie 853, a jeśli szyfrowana wymiana się nie powiedzie, wyszukiwanie kończy się niepowodzeniem, zamiast po cichu wracać do zwykłego tekstu na porcie 53.

To istotna różnica względem Automatycznego, który stosuje szyfrowanie oportunistyczne i chętnie użyje nieszyfrowanego resolvera, gdy sieć przeszkadza. Jeśli twoim celem jest, aby wyszukiwania nigdy nie odbywały się jawnie, tryb ścisły z nazwą hosta dostawcy jest ustawieniem, które temu odpowiada.

Oto pierwsza rzecz, którą ujawnia przejście: wyszukiwanie jest chronione przed siecią lokalną, a resolver nadal poznaje nazwę. Szyfrowanie obejmuje przeskok. Operator tego resolvera widzi zapytanie, bo odpowiadanie na nie jest jego zadaniem.

Krok drugi: połączenie obiera inną trasę

Resolver zwraca adres, a aplikacja łączy się z nim. Ten krok nie zależy od tego, jak zaszyfrowano wyszukiwanie. Bez tunelu połączenie wychodzi z twojego zwykłego publicznego adresu, a docelowe IP i uzgadnianie TLS zwykle i tak czynią nazwę hosta widoczną dla sieci, z szyfrowanym DNS czy bez.

Włącz VPN i to jest ten krok, który się zmienia. Ruch zgodny z polityką routingu klienta przechodzi przez tunel, sieć lokalna widzi połączenie z punktem końcowym VPN, a witryna zazwyczaj widzi adres wyjściowy. Rozwiązywanie nazw może też podróżować wewnątrz tunelu, w zależności od tego, co przekaże klient.

To rozdzielenie to całe porównanie w jednym zdaniu. Szyfrowanie DNS odpowiada, kto może przeczytać pytanie. VPN odpowiada, dokąd zmierza rozmowa.

Krok trzeci: w tunelu DNS staje się kwestią polityki

Teraz obie funkcje oddziałują na siebie, a przeglądarka jest zwykłym źródłem niespodzianek. Przeglądarka z własnym ustawieniem bezpiecznego DNS może wysyłać wyszukiwania do wybranego resolvera przez HTTPS, zamiast pytać system operacyjny. Ustawienie prywatnego DNS w Androidzie nie sięga do tej decyzji.

W Firefoksie przełącznik jest w Ustawienia, Prywatność i bezpieczeństwo, Włącz bezpieczny DNS. W Chrome jest w Ustawienia, Prywatność i bezpieczeństwo, Użyj bezpiecznego DNS. Oba można ustawić na konkretnego dostawcę albo pozostawić wyłączone, a gdy są włączone, konfiguracja DNS tunelu jest omijana dla tych wyszukiwań, choć ruch strony nadal korzysta z tunelu.

Jeśli VPN przekaże własny resolver, a przeglądarka upiera się przy swoim, dostajesz podział: nazwy się rozwiązują, strony się ładują, a wyszukiwania, które miały przejść przez tunel, wyszły bezpośrednio. Adres resolvera inny niż punkt końcowy VPN nie jest sam w sobie dowodem wycieku, ale ścieżka wyszukiwania sprzeczna z zadeklarowanym zamiarem jest warta naprawienia.

Krok czwarty: nazwy wewnętrzne są miejscem, w którym się to psuje

Połącz się z firmowym VPN i otwórz host intranetowy. Jeśli bezpieczny DNS przeglądarki jest włączony i wskazuje publiczny resolver, ta nazwa nie istnieje z punktu widzenia przeglądarki. Tunel jest podniesiony, wszystko inne działa, a jedna nazwa hosta zawodzi z błędem, który wygląda, jakby witryna była niedostępna.

Ten sam błąd pojawia się odwrotnie w Androidzie. Ścisły prywatny DNS z publicznym dostawcą nie rozwiąże nazw, które zna tylko wewnętrzny resolver, a tryb ścisły nie ma żadnego rozwiązania zapasowego. Dzielenie DNS telefonu między publiczny szyfrowany resolver a resolver firmowy nie jest ustawieniem; to kwestia polityki routingu, na którą musi odpowiedzieć ten, kto zarządza VPN.

Sprawdź to, zanim obwinisz tunel: odpytał nazwę wewnętrzną, a potem tę samą nazwę przy wyłączonym bezpiecznym DNS przeglądarki. Jeśli się rozwiązuje, problemem był wybór resolvera, a nie połączenie.

Co przejście mówi ci zmienić

Cztery ekrany kryją prawie wszystko. Przyjrzyj się im w tej kolejności i zapisz, co mówi każdy, bo odpowiedź zwykle widać w kombinacji:

1. Ustawienia Androida, Sieć i internet, Prywatny DNS: Automatyczny lub nazwa hosta dostawcy, i która nazwa hosta.
2. Ustawienie bezpiecznego DNS przeglądarki: wyłączone albo przypięte do konkretnego resolvera.
3. Polityka DNS klienta VPN: czy przesyła resolver, a tunel dzielony wyklucza coś, co nadal potrzebuje nazw?
4. Test wewnętrznej nazwy hosta przy podniesionym tunelu, wykonany dwa razy, raz z włączonym DNS przeglądarki, raz z wyłączonym.

Dopasuj potem poprawkę do wymagania, a nie odwrotnie. Jeśli wymaganiem jest, by wyszukiwania wychodziły zaszyfrowane i trafiały do wybranego przez ciebie resolvera, ustaw ścisły prywatny DNS i doprowadź przeglądarkę do zgody. Jeśli wymaganiem jest, by ruch wychodził gdzie indziej, skonfiguruj tunel i przestań oczekiwać, że ustawienie DNS przesunie twój adres.

I miej granice na uwadze. Żadna z tych funkcji nie czyni wrogiego celu bezpiecznym, a żadna nie usuwa tożsamości, z którą się zalogowałeś. Szyfrowanie zmienia, kto może przeczytać pytanie; tunel zmienia, dokąd zmierza połączenie; nic z tego nie anonimizuje konta.