Jak wykryć wyciek DNS? 4 kroki diagnostyki proxy DNS

Najważniejsze: pomyślny test IP oznacza tylko, że zmienił się punkt wyjścia połączenia, a nie to, że zapytania DNS również idą tą samą drogą. Proxy i DNS obsługują dwa różne etapy: proxy decyduje, przez który punkt wyjścia sieci wychodzi połączenie, a DNS tłumaczy nazwy domen na adresy IP. Jeśli zapytania resolucji idą nieoczekiwaną ścieżką, to właśnie wyciek DNS. Wykrycie go zajmuje cztery kroki, a zrozumienie wyników jest ważniejsze niż samo uruchomienie testu.

Konfigurujesz proxy, otwierasz stronę do testu IP, a strona pokazuje adres proxy, więc uznajesz, że środowisko sieciowe jest w porządku. Kilka dni później, przy wyjaśnianiu problemów z kontami, okazuje się, że zapytania DNS cały czas szły przez sieć lokalną.

Problem nie musi leżeć w proxy; zapytania DNS mogły nigdy nim nie iść.

Po co sprawdzać DNS, skoro proxy jest włączone

Proxy i DNS to dwa osobne etapy; włączenie proxy nie oznacza przejęcia DNS. Proxy decyduje, przez który punkt wyjścia sieci wychodzi połączenie, a DNS odpowiada za tłumaczenie domen. Dotyczą różnych elementów sieci, więc poprawne działanie proxy nie gwarantuje, że zapytania DNS przebiegają zgodnie z oczekiwaniami.

W samym żądaniu sieciowym: otwierając stronę, klient albo najpierw uzyskuje przez zapytanie DNS adres IP docelowej domeny, albo przekazuje domenę do obsługi po stronie proxy, co zależy od protokołu proxy, implementacji klienta i ustawień DNS przeglądarki. Włączenie proxy nie oznacza automatycznie, że wszystkie zapytania resolucji idą oczekiwaną ścieżką. Ocena wymaga rzeczywistego testu; samo „połączono” w proxy nie wystarczy.

Warto też oddzielić dwie rzeczy: wyciek DNS to nie to samo, co ujawnienie prawdziwego publicznego adresu IP. Przecieka ścieżka zapytań o domeny, przez co dostawca resolucji lub sieć lokalna może zobaczyć, jakich domen szukałeś. Czy prawdziwy IP jest ukryty, rozstrzyga osobny test IP. Cybersecurity Agency of Singapore w zaleceniach dotyczących bezpieczeństwa VPN traktuje test wycieku DNS i test ujawnienia adresu IP jako dwa niezależne sprawdzenia, właśnie dlatego, że weryfikują one różne problemy (zobacz wytyczne CSA dotyczące bezpieczeństwa VPN).

Jak zwykle dochodzi do wycieku DNS

Najczęstsze są trzy źródła, a wszystkie wynikają z konfiguracji, nie z awarii proxy. Po kolei.

Proxy obsługuje tylko część ruchu

Niektóre konfiguracje proxy przejmują tylko żądania WWW z przeglądarki, a resolucję wykonuje dalej system lokalny, co zależy od protokołu proxy i sposobu obsługi w kliencie. Gdy żądania WWW idą przez proxy, a zapytania resolucji lokalnie, w wynikach testu pojawi się resolver sieci lokalnej.

Przeglądarka ma włączone własne bezpieczne DNS

Chrome i Firefox obsługują DNS over HTTPS (DoH). Po jego włączeniu zapytania resolucji trafiają do wybranego dostawcy resolucji przez szyfrowane połączenie HTTPS, co ogranicza możliwość bezpośredniej obserwacji zapytań w sieci lokalnej. Szyfrowanie nie oznacza jednak, że zapytania przechodzą przez proxy, ani że wybrany dostawca resolucji pasuje do bieżącego środowiska. Tę funkcję Firefoksa można włączać i wyłączać osobno; zobacz oficjalną dokumentację Mozilli.

System, przeglądarka i klient proxy mają każdy własny

Najbardziej podstępny przypadek. System używa jednego resolvera, przeglądarka przez DoH drugiego, a klient proxy jeszcze trzeciego. Nałożone na siebie sprawiają, że ścieżka resolucji staje się czarną skrzynką. Samo „połączono” w programie proxy nic nie mówi: trzeba zobaczyć, którą ścieżkę faktycznie biegnie działająca przeglądarka.

Gdy ścieżka resolucji trafia do lokalnego ISP, zapytania przechodzą przez jego usługę resolucji; dla porównania posłuży zasada działania i zastosowania proxy ISP.

Jak wykryć wyciek DNS? Cztery kroki

Sam test nie jest trudny; kluczem jest oczekiwanie przed testem i odniesienie wyniku po nim. Dopiero po czterech krokach wniosek się broni.

Krok 1: Najpierw zapisz oczekiwany wynik. Przed testem spisz trzy rzeczy: w jakim regionie jest wyjście obecnego proxy, kto powinien przejąć resolucję domen i czy przeglądarka ma włączone DoH. Bez oczekiwań nie ocenisz nawet tego, co zobaczysz.

Krok 2: Uruchom test przy włączonym proxy. Skorzystaj ze strony obsługującej wykrywanie wycieku DNS, na przykład dnsleaktest.com, i kliknij test rozszerzony (Extended test), aby strona pokazała więcej resolverów; możesz też użyć strony testowej DNS BrowserLeaks, by zobaczyć, do jakiej organizacji należą resolvery. Zapisz nazwy resolverów, organizacje i regiony.

Krok 3: Porównaj wyniki z oczekiwaniami. Sprawdź, czy resolvery w wynikach odpowiadają konfiguracji bieżącego systemu, przeglądarki i proxy. Jeśli resolvery należą do oczekiwanej usługi DNS i nie ma nieoczekiwanych lokalnych ścieżek resolucji, wstępnie można uznać test za zgodny z oczekiwaniami. Gdy pojawi się lokalny ISP lub obca usługa resolucji, najpierw ustal, czy na pewno nie wynika to z przewidzianej konfiguracji, a potem po kolei sprawdź obsługę DNS w kliencie proxy, bezpieczne DNS przeglądarki i ustawienia sieciowe systemu — nie doszukuj się od razu awarii proxy. Pojedynczy test odzwierciedla tylko warunki danego sprawdzenia i nie gwarantuje, że wszystkie żądania są bez zarzutu.

Krok 4: Zmień jedno ustawienie i przetestuj ponownie. Jeśli coś poprawiać, to jedno naraz: obsługę DNS w kliencie proxy, przełącznik DoH w przeglądarce albo ustawienia sieciowe systemu, a po zmianie test i porównanie. Przy kilku zmianach naraz nie rozróżnisz, która zadziałała.

Jak czytać wyniki testu

Ten sam wynik to wskazówka przy właściwej interpretacji i błędny wyrok przy błędnej. Pięć typowych wyników i sposób postępowania:

Pułapka Anycast: lokalizacja resolvera to nie zawsze faktyczne wyjście.

Czym różnią się wyciek DNS, wyciek WebRTC i odcisk przeglądarki

Cztery testy dotyczą czterech różnych informacji; przejście jednego nie oznacza przejścia pozostałych. Granice najlepiej widać, gdy zestawi się je razem:

DNS i WebRTC najłatwiej pomylić, bo oba mają w nazwie słowo „wyciek”. Ich zasada działania i sposób postępowania różnią się całkowicie; wykrywanie i ustawienia wycieku WebRTC omówiliśmy osobno, więc tu nie wracamy do tematu. Ponadto wyciek IPv6 to kolejny człon tej rodziny: sprawdza, czy adresy IPv6 omijają proxy; metodę opisuje poradnik wykrywania wycieku IPv6.

Te cztery testy pokazują różne informacje i nie zastępują nawzajem. Przy diagnozowaniu środowiska proxy sugerujemy najpierw potwierdzić publiczny IP, potem sprawdzić DNS i WebRTC, a na końcu zweryfikować odcisk i konfigurację środowiska; konkretne testy dobierz do scenariusza.

Jak wpisać te testy w proces pracy z MostMate

Sugerowana kolejność: najpierw wyjście, potem resolucja, dalej WebRTC, na końcu konfiguracja środowiska. Zarządzając wieloma środowiskami przeglądarek w MostMate, warto oddzielić test łączności proxy od testu wycieku DNS.

Pierwszy punkt to konfiguracja proxy. Po przypisaniu proxy do środowiska sprawdź stan połączenia testem proxy w produkcie, a przy okazji zweryfikuj typ protokołu (HTTP, HTTPS, SOCKS5, SSH) i dane uwierzytelniające. Pamiętaj: pomyślny test proxy nie zastępuje testu wycieku DNS, bo rzeczywista ścieżka zapytań DNS zależy nadal od konfiguracji klienta proxy, przeglądarki i systemu.

Potem otwórz stronę testu DNS w środowiskach z przypisanym tym proxy, przejdź cztery kroki jak wyżej i zobacz, czy właściciele resolverów odpowiadają oczekiwaniom.

Drugim punktem jest izolacja samego środowiska. Przy wielu kontach proxy, cookies i parametry odcisku każdego środowiska powinny być niezależne i niepożyczone; szczegóły izolacji opisuje zakres i konfiguracja izolacji środowiska przeglądarki. Gdy środowisko ma złe proxy albo współdzieli konfigurację, wyniki testu tracą wartość porównawczą. Izolacja pomaga zarządzać sesjami i konfiguracjami, ale nie oznacza, że ścieżka DNS jest automatycznie poprawna, i nie zastępuje testu zewnętrznego.

Trzeci punkt: pamiętaj o granicach. Fingerprint browser dba o to, by środowisko było uporządkowane, ale to, czy proxy działa i czy DNS idzie oczekiwaną ścieżką, nadal weryfikuje się zewnętrznym testem. Pomyślny test też nie zwalnia na zawsze; po zmianie konfiguracji lub aktualizacji systemu warto powtórzyć test.

Częste pytania

Proxy jest włączone, a test DNS pokazuje lokalny resolver. Czy to znaczy, że proxy przestało działać?

Niekoniecznie. Proxy może przejmować tylko żądania WWW, a resolucję obsługują osobno system lub przeglądarka. Sprawdź po kolei obsługę DNS w kliencie proxy i ustawienia DoH przeglądarki, zmieniając po jednym elemencie i testując.

Czy wyciek DNS ujawnia mój prawdziwy IP?

Nie można tego utożsamiać. Wyciek DNS pokazuje ścieżkę zapytań o resolucję domen, a to, co faktycznie się ujawni, zależy od konfiguracji sieci i scenariusza testu. Czy prawdziwy publiczny IP jest ukryty, potwierdza osobny test IP, a ścieżkę resolucji sprawdza się niezależnie.

Czy z fingerprint browserem nadal może dojść do wycieku DNS?

Tak, może. Fingerprint browser zarządza izolacją środowisk i parametrami odcisku, podczas gdy zachowanie DNS zależy od protokołu proxy oraz konfiguracji systemu i przeglądarki; testu nie wolno pomijać.

Co jeszcze sprawdzić po pomyślnym teście DNS?

Zostają jeszcze wyciek WebRTC i odcisk przeglądarki, każdy weryfikowany właściwym narzędziem. Dopiero gdy wszystkie przejdą, warstwa sieciowa środowiska jest w pełni sprawdzona.

Podsumowanie

Wartość testu wycieku DNS nie polega na uzyskaniu werdyktu „pozytywny” lub „negatywny”, lecz na potwierdzeniu, że żądania sieciowe bieżącego środowiska przebiegają zgodnie z oczekiwaniami. Publiczny IP, DNS, WebRTC i odcisk przeglądarki mają swoje osobne metody sprawdzenia i wynik jednego nie może zastąpić weryfikacji pozostałych. Niezależnie od używanego fingerprint browsera zalecamy ponowny test po każdej zmianie proxy lub konfiguracji sieci.

Jeśli potrzebujesz zarządzać wieloma środowiskami przeglądarek, zacznij od poznania konfiguracji środowisk i zarządzania proxy w MostMate, a potem zweryfikuj wszystko krok po kroku według tego artykułu; jeśli chcesz mieć stabilniejszą warstwę proxy, możesz pobrać MostMate — wersja darmowa oferuje dwa środowiska, więc najpierw przeprowadź cały proces testowy w pierwszym z nich.