Wyciek DNS podczas korzystania z VPN – jak go wykryć i usunąć

Włączasz VPN, wybierasz serwer w Amsterdamie i sprawdzasz publiczny adres IP. Wszystko wygląda prawidłowo – witryny widzą adres holenderskiego serwera, a połączenie jest szyfrowane. Tymczasem zapytania DNS nadal trafiają do serwera polskiego operatora internetu, na przykład przez domowy router. Ruch internetowy przechodzi przez tunel VPN, ale informacje o wyszukiwanych domenach wydostają się poza niego.

To właśnie DNS leak, czyli wyciek zapytań DNS. Problem nie musi powodować błędów ani spowalniać przeglądarki, dlatego łatwo go przeoczyć. Sam test lokalizacji IP nie wystarczy do jego wykrycia. Trzeba sprawdzić, który serwer rozwiązuje nazwy domen, jaką trasą docierają do niego zapytania i czy konfiguracja VPN obejmuje również IPv6.

Czym jest DNS leak i skąd się bierze

DNS (Domain Name System) tłumaczy nazwy domen, takie jak example.com, na adresy IP wykorzystywane do nawiązywania połączeń. Zanim przeglądarka otworzy stronę, zwykle musi ustalić adres jej serwera. Odpowiada za to resolver DNS, który może należeć do operatora internetu, dostawcy VPN, firmy albo niezależnej usługi.

Przy prawidłowo skonfigurowanym VPN typu full tunnel zapytania DNS objęte polityką połączenia powinny przechodzić przez tunel. Wyciek pojawia się wtedy, gdy system lub aplikacja wysyła je inną trasą, na przykład bezpośrednio do routera obsługującego lokalną sieć Wi-Fi.

Typowy przypadek wygląda następująco: komputer z Windows 11 korzysta z domowego internetu, a router pod adresem 192.168.1.1 obsługuje DNS. Użytkownik uruchamia VPN, lecz system nadal wysyła pakiety UDP na port 53 routera przez fizyczną kartę Wi-Fi. Operator VPN obsługuje ruch do stron, natomiast router otrzymuje zapytania o domeny i może przekazywać je dalej.

Najczęstsze przyczyny wycieków DNS to pozostawione ustawienia DNS z DHCP, błędna konfiguracja interfejsu wirtualnego, niepełna obsługa IPv6 oraz aplikacje korzystające z własnych resolverów. Znaczenie mają też dwie funkcje:

• Split tunneling – pozwala określonym aplikacjom omijać VPN. Jeśli wyjątek obejmuje przeglądarkę, jej zapytania DNS również mogą wychodzić poza tunel.
• Split DNS – kieruje zapytania dotyczące wybranych domen do określonych resolverów. W firmowym VPN domena wewnętrzna może być obsługiwana przez serwer przedsiębiorstwa, a domeny publiczne przez inny serwer.

Nie każde takie zachowanie jest błędem. W sieci firmowej selektywne kierowanie DNS bywa celowe, ponieważ pozwala korzystać z wewnętrznych usług bez przekierowywania całego internetu przez centralę.

Istotna jest również różnica między protokołami. Klasyczny DNS wykorzystuje zwykle UDP lub TCP na porcie 53, DNS over TLS (DoT) standardowo korzysta z TCP 853, a DNS over HTTPS (DoH) przesyła zapytania przez HTTPS, zwykle na porcie 443.

Jeżeli Firefox używa resolvera Cloudflare przez DoH, nie oznacza to automatycznie wycieku. Połączenie z Cloudflare może przecież przechodzić wewnątrz VPN. O naruszeniu założonej ochrony decyduje rzeczywista trasa zapytania, nie sama nazwa dostawcy DNS.

Konsekwencją wycieku tradycyjnego, nieszyfrowanego DNS jest możliwość obserwowania nazw odpytywanych domen przez lokalną sieć lub operatora. Nie oznacza to automatycznie dostępu do treści komunikacji HTTPS ani pełnych adresów odwiedzanych podstron, ale może ujawniać zainteresowania i wykorzystywane usługi.

Jak przeprowadzić wiarygodny test

Najczęstszy błąd podczas diagnostyki to uruchomienie jednej strony testowej i uznanie wyniku za ostateczny. Test DNS leak powinien obejmować porównanie stanu przed połączeniem VPN i po jego uruchomieniu, a w razie wątpliwości także analizę ruchu sieciowego.

Praktyczna procedura wygląda tak:

1. Sprawdź połączenie bez VPN. Otwórz ipleak.net, zapisz publiczny adres IPv4, ewentualny IPv6 oraz wykryte resolvery DNS. Zanotuj, czy przeglądarka korzysta z funkcji bezpiecznego DNS.
2. Uruchom VPN i powtórz pomiar. Adres IP powinien odpowiadać oczekiwanej trasie połączenia. Jeżeli test nadal pokazuje publiczny IPv6 operatora przy deklarowanej ochronie całego ruchu, problem może obejmować nie tylko DNS, lecz także sam ruch IPv6.
3. Wykonaj kilka niezależnych prób DNS. Wykorzystaj dnsleaktest.com z testem Extended oraz ipleak.net. Powtórz pomiary z nowymi zapytaniami, najlepiej również po ponownym połączeniu VPN. Zwróć uwagę na resolvery powiązane z lokalnym operatorem.
4. Porównaj wyniki z konfiguracją systemu. Sprawdź, które serwery DNS przypisano interfejsom fizycznym i wirtualnym. Jeśli wyniki pozostają niejednoznaczne, przeanalizuj ruch wychodzący przez kartę Wi-Fi lub Ethernet.

W Windows listę skonfigurowanych serwerów wyświetla polecenie PowerShell Get-DnsClientServerAddress. W Linuksie korzystającym z systemd-resolved podobnych informacji dostarcza resolvectl status.

To jednak informacje o konfiguracji, nie dowód rzeczywistej trasy pakietów. Serwer może być wpisany w ustawieniach, ale nieobsługiwany, a aplikacja może korzystać z innej ścieżki.

Znaczenie ma również pamięć podręczna DNS. Powtarzanie zapytania o tę samą domenę nie zawsze generuje nowy ruch sieciowy. Najlepiej używać kolejnych, niepowtarzalnych nazw przygotowanych przez narzędzie testowe lub subdomen własnej, kontrolowanej domeny. W Windows można dodatkowo wyczyścić pamięć systemową poleceniem Clear-DnsClientCache, ale nie usuwa ono wszystkich możliwych pamięci podręcznych aplikacji.

Dokładniejszą kontrolę zapewnia Wireshark. Na własnym komputerze wybierz fizyczny interfejs sieciowy, rozpocznij przechwytywanie ruchu, a następnie wygeneruj nowe zapytania DNS. W filtrze wyświetlania wpisz:

udp.port == 53 || tcp.port == 53 || tcp.port == 853

Jeżeli podczas aktywnego VPN widzisz nieszyfrowane zapytania DNS kierowane bezpośrednio przez Wi-Fi do lokalnego routera, masz konkretny dowód wyjścia tych zapytań poza tunel.

Ten filtr ma jednak ograniczenie: nie wykryje DNS over HTTPS na porcie 443. Przy podejrzeniu DoH trzeba dodatkowo sprawdzić ustawienia aplikacji, adres docelowy szyfrowanego połączenia i jego trasę. Sama obecność HTTPS do zewnętrznego resolvera nie wystarcza, ponieważ połączenie może być tunelowane.

Nie należy też wyciągać wniosków wyłącznie z kraju lub numeru ASN resolvera. Usługi DNS wykorzystują infrastrukturę rozproszoną, a adres obserwowany przez test nie musi wskazywać miejsca rozpoczęcia zapytania.

Przykładowo serwer VPN może działać w Niemczech, a wykryty resolver mieć adres przypisany do innego kraju. Dopiero potwierdzenie, że zapytania omijają VPN, uzasadnia zmianę konfiguracji.

Konfiguracja klienta VPN, systemu, IPv6 i własnych serwerów DNS

Usuwanie wycieku najlepiej rozpocząć od ustawień klienta VPN, a nie od ręcznej wymiany wszystkich adresów DNS w systemie. W aplikacji sprawdź tryb full tunnel, ochronę przed DNS leak, obsługę IPv6 oraz reguły split tunnelingu. Po zmianach rozłącz i ponownie zestaw połączenie.

Wbudowany kill switch jest przydatny, ponieważ ogranicza ruch poza VPN po utracie tunelu. Nie zastępuje jednak poprawnej konfiguracji DNS podczas aktywnego połączenia. Funkcje te trzeba oceniać osobno.

W przypadku OpenVPN dostępne są mechanizmy przekazywania konfiguracji DNS klientowi. Opcja dhcp-option DNS nadal występuje w konfiguracjach, a OpenVPN 2.6 udostępnia również dyrektywy dns. Na Linuksie zastosowanie ustawień zależy od integracji z systemowym resolverem.

Na Windows OpenVPN oferuje także block-outside-dns, który blokuje ruch DNS po TCP i UDP na porcie 53 poza tunelem. To użyteczna ochrona przed klasycznym wyciekiem, ale nie jest uniwersalną blokadą DoH na porcie 443.

W konfiguracji WireGuard obsługiwanej przez wg-quick można wskazać resolver przez DNS = 10.8.0.1, jeśli taki adres rzeczywiście udostępnia serwer VPN. Trasy wynikają natomiast z AllowedIPs. W Linuksie wg-quick korzysta przy konfiguracji DNS z mechanizmu resolvconf, dlatego integracja z systemd-resolved wymaga sprawdzenia.

Przykładowo przy pełnym tunelowaniu system z systemd-resolved może kierować zapytania przez interfejs VPN wykorzystujący domenę routingu ~.. Przy firmowym split DNS właściwe będą węższe reguły dotyczące konkretnych domen. Wymuszenie wszystkich zapytań na jednym serwerze mogłoby uniemożliwić dostęp do zasobów przedsiębiorstwa.

Osobnej kontroli wymaga IPv6. Konfiguracja WireGuard obejmująca tylko trasę 0.0.0.0/0 nie zapewnia automatycznie tunelowania całego ruchu IPv6. Dla tego protokołu odpowiednikiem trasy domyślnej jest ::/0, ale jej zastosowanie wymaga prawidłowej obsługi IPv6 przez VPN i odpowiedniej konfiguracji interfejsu.

Nie należy więc bez sprawdzenia dopisywać ::/0 ani wyłączać IPv6 globalnie. Najpierw wybierz usługę obsługującą IPv6 lub mechanizm klienta, który bezpiecznie blokuje jego ruch poza tunelem. Globalne wyłączenie protokołu może utrudnić dostęp do niektórych sieci i usług, nie usuwając pozostałych błędów DNS.

A co z własnym resolverem? Cloudflare 1.1.1.1, firmowy DNS lub domowy Pi-hole mogą być rozsądnym wyborem, ale pod jednym warunkiem: zapytania muszą przechodzić zamierzoną trasą.

Jeżeli użytkownik ma Pi-hole pod adresem 192.168.1.10 w domowej sieci, to korzystanie z tego adresu poza domem wymaga właściwego dostępu przez VPN. Wpisanie go na stałe w ustawieniach laptopa nie zapewnia takiej łączności i może prowadzić do konfliktów adresacji w obcych sieciach.

Podobnie ręczne ustawienie publicznego DNS nie naprawia wycieku, jeśli system nadal kieruje zapytania poza tunel. Zmienia się jedynie odbiorca danych. W przypadku własnego serwera dochodzą obowiązki aktualizacji, zabezpieczania usługi i kontroli logów.

Po każdej modyfikacji powtórz test DNS, IPv4 i IPv6. Sprawdź również zachowanie po uśpieniu komputera, zmianie Wi-Fi i ponownym zestawieniu VPN. To właśnie przy takich przełączeniach potrafią ujawnić się błędy niewidoczne podczas pierwszego połączenia.

FAQ

Czy wykrycie serwera DNS innego niż DNS dostawcy VPN oznacza wyciek?
Nie. Resolver zewnętrzny może być osiągany wewnątrz tunelu. Decydują rzeczywista trasa oraz założona polityka DNS.

Czy DNS over HTTPS całkowicie eliminuje DNS leak?
Nie. DoH szyfruje zapytania między klientem a resolverem, ale nie gwarantuje ich przesyłania przez VPN. Szyfrowane połączenie również może omijać tunel.

Czy czyszczenie pamięci DNS usuwa problem?
Nie. Clear-DnsClientCache usuwa zapisane odpowiedzi z systemowej pamięci DNS w Windows, lecz nie zmienia tras ani ustawień resolverów. To narzędzie diagnostyczne, nie naprawcze.

Czy wyciek DNS może wystąpić na smartfonie?
Tak. Android i iOS również korzystają z konfiguracji DNS oraz mechanizmów VPN. Na Androidzie należy dodatkowo skontrolować Prywatny DNS, a na obu platformach ustawienia tunelowania aplikacji.

Czy po usunięciu DNS leak VPN zapewnia anonimowość?
Nie. Nadal możliwa jest identyfikacja przez konta użytkownika, pliki cookie, charakterystykę przeglądarki czy dane przechowywane przez dostawcę usług. Usunięcie wycieku ogranicza konkretny kanał ujawniania informacji.

Od czego zacząć naprawę?
Najpierw porównaj adres IP i resolvery DNS przed uruchomieniem VPN oraz po połączeniu. Jeżeli potwierdzisz zapytania kierowane poza tunel do lokalnego routera, w pierwszej kolejności popraw politykę DNS klienta VPN i wyłącz niezamierzone wyjątki split tunnelingu. Dopiero później zmieniaj serwery DNS, konfigurację IPv6 lub zaawansowane reguły routingu. Najpierw usuń błędną trasę – sama zamiana adresu resolvera nie rozwiązuje problemu.