Najczęstsze błędy przy VPN: wycieki, złe DNS, słabe protokoły i jak je wyeliminować raz na zawsze

Scenka startowa: „VPN mam włączony, a i tak mnie namierzyli”

Wyjazd służbowy, hotelowe Wi‑Fi, szybkie logowanie do poczty i kilku narzędzi firmowych. Ikonka VPN świeci się na zielono, wszystko niby gra. Dwa dni później na YouTube i Facebooku zaczynają wyskakiwać reklamy lokalnych restauracji dokładnie z miasta, w którym byłeś, choć VPN ustawiony był na zupełnie inny kraj.

To typowy moment, w którym kończy się wiara w magiczną moc VPN, a zaczynają pytania: „Skoro miałem włączony VPN, to jakim cudem ktoś znał moją lokalizację?”, „Czy mój VPN nie działa?”, „Czy coś źle ustawiłem?”. W większości takich przypadków nie chodzi o awarię samej usługi, ale o wycieki IP, błędną konfigurację DNS, słabe protokoły lub lukę w ustawieniach przeglądarki i aplikacji. Technicznie: tunel działa, ale obok tunelu wciąż płynie odsłonięty ruch lub zdradzające Cię metadane.

Szybki wniosek: samo „włączenie VPN” niczego nie gwarantuje. Żeby faktycznie zyskać prywatność, trzeba wiedzieć, co VPN realnie robi, gdzie kończą się jego możliwości i jakich błędów konfiguracyjnych bezwzględnie unikać. Inaczej ikona w trayu daje jedynie poczucie bezpieczeństwa, nie bezpieczeństwo w praktyce.

Czym VPN faktycznie jest, a czym nigdy nie będzie

Co dokładnie szyfruje VPN

VPN tworzy zaszyfrowany tunel między Twoim urządzeniem a serwerem VPN. Wszystko, co przechodzi przez ten tunel, jest nieczytelne dla pośredników: operatora internetu, właściciela hotspotu Wi‑Fi czy osób podsłuchujących ruch w tej samej sieci. W praktyce oznacza to szyfrowanie:

• zapytań HTTP/HTTPS do stron i usług,
• ruchu aplikacji (komunikatory, klient poczty, gry, o ile korzystają z tunelu),
• części metadanych, np. docelowego IP widocznego dopiero po stronie serwera VPN.

Po połączeniu z VPN zmienia się też Twoje widoczne IP. Z perspektywy odwiedzanych stron wychodzisz z adresu IP serwera VPN, a nie z IP przypisanego Ci przez dostawcę internetu. To pozwala omijać blokady regionalne i utrudniać powiązanie konkretnej aktywności z Twoją fizyczną lokalizacją lub abonamentem.

Jednocześnie VPN nie usuwa wszystkich śladów. Operator wciąż wie, że łączysz się z konkretnym serwerem VPN (widzi ruch zaszyfrowany, ale zna IP serwera). Serwer VPN z kolei widzi Twój adres IP, czas połączenia i ruch wychodzący z tunelu do internetu. Dlatego tak istotne jest, czy dostawca VPN faktycznie dba o prywatność i jakie ma praktyki logowania.

Dla wielu scenariuszy użytkowych (kawiarniane Wi‑Fi, podróże, korzystanie z zasobów firmowych) to szyfrowanie i maskowanie IP wystarcza, by podnieść poziom bezpieczeństwa radykalnie w stosunku do „gołego” połączenia. Problem zaczyna się, gdy oczekuje się od VPN rzeczy, których technicznie zapewnić nie może.

Czego VPN nie ukryje

VPN nie jest filtrem na zdrowy rozsądek. Jeżeli dobrowolnie wpisujesz dane w formularz, podajesz numer karty, logujesz się na konto Google czy Facebooka – VPN tego nie „odanonimizuje”. Serwis jednoznacznie przypisze tę aktywność do Twojego konta, a więc do Ciebie jako osoby.

VPN nie jest też automatyczną ochroną przed złośliwym oprogramowaniem, chyba że dostawca dodaje osobny moduł anty-malware lub filtr treści. Kliknięcie w phishingowy link, pobranie podejrzanego pliku czy instalacja fałszywego „aktualizatora” może skończyć się infekcją tak samo z VPN, jak i bez. Tunel szyfruje ruch, ale nie zmienia zachowania użytkownika ani nie weryfikuje treści po stronie urządzenia.

Do tego dochodzi śledzenie przeglądarkowe: ciasteczka, localStorage i zaawansowane techniki typu browser fingerprinting. Jeżeli jesteś zalogowany na konto w przeglądarce, masz te same rozszerzenia, ten sam język systemu, rozdzielczość i ustawienia – wiele systemów analitycznych i reklamowych połączy Twoją aktywność mimo zmiany IP. VPN może utrudnić budowanie profilu, ale go nie unieważnia.

Wreszcie: VPN nie cofa historii. Jeżeli wcześniej korzystałeś z internetu bez ochrony, istniejące logi operatora, dane trackingowe w przeglądarce czy profil reklamowy pozostają takie, jakie były. VPN ma wpływ na to, co dzieje się od momentu jego użycia.

Granica możliwości: gdzie kończy się moc tunelu

Po jednej stronie masz ruch sieciowy szyfrowany w tunelu do serwera VPN. Po drugiej – wszystko, co dzieje się na Twoim urządzeniu i w aplikacjach. VPN działa na poziomie sieci, nie dotyka logiki działania aplikacji, ich uprawnień czy luk bezpieczeństwa.

Jeżeli przeglądarka umożliwia WebRTC, ma włączony geolokalizator, jest zalogowana na to samo konto Google od lat – serwisy zyskują dodatkowe kanały identyfikacji niezależnie od IP. Podobnie aplikacje na telefonie: klient poczty, komunikatory, bankowość mobilna – jeśli korzystają z innych ścieżek sieci (np. nie przechodzą przez VPN na poziomie systemu), mogą wysyłać ruch z prawdziwym IP.

Dlatego realne bezpieczeństwo wymaga spojrzenia szerzej niż „czy ikona VPN jest włączona?”. Trzeba łączyć:

• poprawny wybór protokołu i szyfrów,
• dobrą konfigurację DNS i ochronę przed wyciekami,
• rozsądne ustawienia przeglądarki i aplikacji,
• nawyki: co, gdzie i komu się udostępnia.

Wniosek z tego etapu jest prosty: VPN to solidny element układanki, ale nie cała układanka. Świadomość jego ograniczeń pozwala realnie ocenić zagrożenia i nie szukać „magicznej opcji” w ustawieniach, która zrobi więcej, niż to możliwe.

Najczęstsze typy wycieków przy VPN – mapa ryzyka

Wyciek adresu IP (publicznego i lokalnego)

Wyciek IP oznacza, że pomimo aktywnego tunelu jakaś usługa lub strona poznaje Twoje prawdziwe IP (publiczne lub lokalne w sieci LAN). Skutki są różne: od dopasowania reklam po możliwość precyzyjnego powiązania aktywności online z Twoją lokalizacją, a nawet konkretnym łączem domowym czy służbowym.

Do wycieku IP dochodzi najczęściej w kilku scenariuszach:

• Niepełny tunel (split tunneling nieświadomie aktywny) – część ruchu idzie przez VPN, a część bezpośrednio do internetu. Z perspektywy użytkownika „VPN działa”, ale np. komunikator lub gra łączy się poza tunelem.
• Aplikacja VPN obsługuje tylko przeglądarkę – typowe dla prostych rozszerzeń browserowych. Inne programy (poczta, klient chmury, aktualizatory) łączą się z siecią „po staremu”.
• Awaria lub zerwanie tunelu bez kill switcha – gdy połączenie z serwerem VPN padnie, a system automatycznie wróci do zwykłego połączenia.

Wyciek lokalnego IP (np. 192.168.x.x, 10.x.x.x) jest mniej groźny pod kątem geolokalizacji, ale może mieć znaczenie przy atakach wewnątrz sieci (np. w dużych biurach, akademikach czy na publicznych Wi‑Fi). Dla wielu użytkowników kluczowy jest jednak publiczny IP – ten, który dostajesz od ISP i który identyfikuje Twoje łącze na zewnątrz.

IP potrafi też „wyskoczyć” bokiem przez funkcje przeglądarki. Tu pojawia się WebRTC, różnego rodzaju rozszerzenia, a także błędy w implementacji samego klienta VPN (rzadziej, ale się zdarzają, zwłaszcza w darmowych i egzotycznych rozwiązaniach).

Wyciek DNS – zdradliwe zapytania o domeny

DNS to książka telefoniczna internetu – tłumaczy przyjazne nazwy domen (np. przyklad.pl) na adresy IP. Przy każdym wejściu na stronę Twoje urządzenie wysyła zapytanie DNS, a serwer odpowiada, pod jaki adres IP ma się połączyć przeglądarka.

Jeżeli używasz VPN, a zapytania DNS wciąż trafiają do serwera DNS Twojego operatora, pojawia się wyciek DNS. Strony mogą widzieć IP serwera VPN, ale ISP i inne podmioty z dostępem do logów DNS widzą listę domen, które odwiedzasz, związaną z Twoim prawdziwym IP.

Konsekwencje:

• operator wie, jakie serwisy odwiedzasz (i może profilować lub blokować ruch),
• rekordy DNS mogą być wykorzystane jako materiał dowodowy lub do analizy zachowań,
• część systemów reklamowych i analitycznych korzysta z danych DNS do korelacji ruchu.

Wyciek DNS pojawia się najczęściej przy:

• ręcznie wpisanych DNS w systemie (np. 8.8.8.8), które ignorują ustawienia aplikacji VPN,
• niepoprawnej konfiguracji VPN na routerze (tunel jest, ale DNS wciąż „po staremu”),
• słabych klientach VPN, które nie wymuszają własnych serwerów DNS lub nie robią tzw. DNS leak protection.

DNS jest o tyle zdradliwy, że wszystko wizualnie wygląda poprawnie: strona pokazuje IP serwera VPN, lokalizacja się zgadza, a jednocześnie każde zapytanie o domenę ląduje poza tunelem. Stąd określenie „cichy zabójca prywatności”.

Wyciek przez WebRTC i inne interfejsy przeglądarki

WebRTC to technologia pozwalająca na bezpośrednią komunikację audio/wideo i wymianę danych między przeglądarkami, często z pominięciem tradycyjnych serwerów pośredniczących. W praktyce umożliwia m.in. rozmowy wideo w przeglądarce czy webowe aplikacje konferencyjne.

Problem zaczyna się wtedy, gdy WebRTC próbuje ustalić możliwe ścieżki komunikacji i ujawnia przy tym prawdziwe IP (publiczne lub lokalne) do skryptów JS uruchamianych na odwiedzanej stronie. W efekcie serwis może poznać Twoje IP, mimo że przeglądarka działa w tunelu VPN.

Różne przeglądarki mają odmienne domyślne ustawienia:

• Chrome – historycznie podatny na wycieki WebRTC, obecnie część zachowań jest łagodzona, ale wiele zależy od rozszerzeń i ustawień,
• Firefox – daje większą kontrolę (możliwość pełnego wyłączenia WebRTC w about:config),
• Edge / Opera – bazują na Chromium, więc mają podobne mechanizmy i podobne ryzyka,
• Mobilne przeglądarki – część implementuje WebRTC inaczej, ale generalny problem pozostaje: funkcja może ujawniać IP.

Wycieki WebRTC bywają szczególnie irytujące przy serwisach, które starają się wykryć użycie VPN i blokują dostęp, gdy wykryją rozbieżności między IP z tunelu a IP zgłoszonym przez WebRTC. Efekt: „mam VPN, a strona i tak wie, że coś kombinuję”.

Wyciek przez aplikacje poza przeglądarką

Przeglądarka to tylko jedna z wielu aplikacji korzystających z internetu. Komunikatory, klient pocztowy, gry online, aplikacje do backupu, chmury dyskowe, narzędzia firmowe – wszystkie mogą wysyłać ruch równolegle. Jeśli VPN nie obejmuje całego systemu lub jest źle skonfigurowany, część z tych aplikacji połączy się poza tunelem.

Źródła problemu:

• VPN jako rozszerzenie przeglądarki – chroni wyłącznie ruch w danej przeglądarce, reszta aplikacji używa starego IP.
• Split tunneling – celowo lub przypadkiem ustawione, że np. gry idą poza VPN, bo tak „szybciej”. Użytkownik potem zapomina o tej regule.
• Niestandardowe aplikacje firmowe – używają dedykowanych portów lub tuneli, których klient konsumencki VPN nie obejmuje domyślnie.

Efektem jest „dziurawy” model ochrony: część aktywności jest maskowana, a część nie. To wystarczy, by wiele systemów identyfikacji i śledzenia złożyło puzzle w całość. Dla przeciwnika technicznie zaawansowanego wystarczy jeden nieosłonięty kanał z prawdziwym IP, żeby całą resztę ruchu skojarzyć z Tobą.

Szersza perspektywa na wycieki

Dotychczasowe przykłady pokazują, że „wyciek VPN” to nie tylko sytuacja, w której klient VPN się zepsuł. Zazwyczaj to suma:

• luk w protokołach i technologiach przeglądarki (WebRTC, geolokalizacja),
• błędnych ustawień systemu (DNS, split tunneling),
• ograniczeń samego klienta (tylko przeglądarka, brak kill switcha),
• decyzji użytkownika (wybór słabych protokołów, „przyspieszanie” kosztem bezpieczeństwa).

Żeby faktycznie „uszczelnić” VPN, trzeba zidentyfikować wszystkie możliwe ścieżki ucieczki: IP, DNS, WebRTC, ruch poza przeglądarką i aplikacje systemowe. Dopiero spojrzenie na całość pozwala zrozumieć, czemu reklamy „widzą” lokalizację mimo świecącej ikonki.

Wyciek przez geolokalizację przeglądarki i fingerprinting

Ktoś zmienił IP na „Szwecję” przez VPN, wchodzi na serwis VOD, a ten i tak pokazuje ofertę z jego kraju. IP się zgadza, testy VPN świecą na zielono, a mimo to system wie, skąd jest użytkownik. Tutaj na scenę wchodzą geolokalizacja przeglądarki i fingerprinting.

Przeglądarka udostępnia kilka kanałów informacji, które pozwalają stronom z dużą precyzją oszacować Twoją lokalizację i tożsamość techniczną, nawet jeśli IP jest ukryte:

• Geolokalizacja HTML5 – prośba o „dostęp do lokalizacji” często oznacza wykorzystanie Wi‑Fi, BT, sieci komórkowej i innych źródeł, a nie tylko IP.
• Fingerprinting przeglądarki – zbieranie setek drobnych parametrów (czcionki, rozdzielczość, strefa czasowa, język, wtyczki, zachowanie JS) w unikalny profil.
• Identyfikatory aplikacji i kont – zalogowanie na to samo konto Google, Apple czy Facebook w różnych miejscach scala tożsamość niezależnie od IP.

Geolokalizacja może „przebić” VPN w prosty sposób: użytkownik łączy się z serwerem w Holandii, a przeglądarka przekazuje serwisowi lokalizację z modułu Wi‑Fi, który mówi jasno „Warszawa”. System antyfraudowy lub anty-VPN natychmiast widzi niezgodność i traktuje takiego użytkownika podejrzliwie.

Fingerprinting działa bardziej pośrednio. Nawet jeśli nie podajesz lokalizacji, serwis może:

• porównać Twój obecny „odcisk” z wcześniejszymi wizytami bez VPN i uznać, że to ta sama osoba,
• połączyć dane z wielu partnerów reklamowych i analitycznych, którzy na podstawie fingerprintu stworzą spójny profil aktywności.

Ochrona przed tym typem wycieków wymaga wyjścia poza sam VPN. Przydają się:

• kontenery lub profile przeglądarki – rozdzielanie tożsamości (inne loginy, inne zestawy cookies, osobny profil „pod VPN”),
• ograniczenie geolokalizacji – domyślne blokowanie próśb o lokalizację i ręczne zezwalanie tylko tam, gdzie naprawdę jest potrzebna (np. mapy),
• przeglądarki „utwardzone” pod prywatność – Firefox z rozszerzeniami ograniczającymi fingerprinting, Brave lub konfiguracje typu „privacy hardened”.

VPN rozwiązuje problem IP, ale jeśli w tle działa pełna geolokalizacja HTML5 i agresywne fingerprinting, przeciwnik może Cię rozpoznać „po sylwetce”, a nie po adresie.

Wyciek przez IPv6 – gdy stary świat spotyka nowy

Użytkownik testuje VPN na stronie „jakie mam IP” – pokazuje ładny adres z innego kraju. Jest spokojny. Nie widzi tylko, że ma również w pełni widoczny adres IPv6, nad którym jego VPN nie panuje.

Wiele starszych lub gorzej zaprojektowanych usług VPN skupia się głównie na IPv4. Tymczasem:

• coraz więcej operatorów przydziela użytkownikom unikalne, stałe prefiksy IPv6, które są jeszcze bardziej charakterystyczne niż dynamiczne IPv4,
• część systemów i aplikacji preferuje IPv6, jeśli jest dostępne, a VPN tuneluje jedynie IPv4,
• przeglądarka lub aplikacja może próbować najpierw połączyć się po IPv6, a dopiero potem po IPv4.

Efekt bywa zaskakujący: strona widzi IP serwera VPN (IPv4), ale równolegle loguje Twoje prawdziwe IPv6. Przy analizie logów lub w systemach antyfraudowych taka rozbieżność to czerwone światło.

Żeby nie strzelić sobie w stopę, trzeba jasno odpowiedzieć na kilka pytań:

• czy klient VPN obsługuje IPv6 i tuneluje go tak samo jak IPv4,
• jeśli nie – czy wyłącza IPv6 na interfejsie sieciowym podczas działania,
• czy system (Windows, Linux, macOS, Android) nie ma ręcznie ustawionych tras IPv6 omijających tunel.

W wielu przypadkach najprostszym rozwiązaniem jest całkowite wyłączenie IPv6 na poziomie systemu lub routera, jeśli VPN nie radzi sobie z nim poprawnie. To proteza, ale lepsza niż pozostawienie otwartej autostrady obok bezpiecznego tunelu.

Słabe protokoły VPN i przestarzałe szyfrowanie – jak nie strzelać sobie w stopę

„Bo tak kiedyś ustawiliśmy w firmie” – czyli pułapka starej konfiguracji

W wielu firmach wciąż spotyka się konfiguracje typu: PPTP z domyślnymi ustawieniami sprzed dekady, bo „kiedyś działało” i nikt nie chciał tego dotykać. Użytkownik czuje się bezpiecznie, bo „przecież jest VPN”, a w praktyce ruch można podsłuchać relatywnie niewielkim kosztem.

Historia protokołów VPN to ciągły wyścig między wygodą, zgodnością a bezpieczeństwem. Część rozwiązań, które były sensowne kilkanaście lat temu, dziś są de facto dziurawe z założenia:

• PPTP – szyfrowanie oparte na MS-CHAPv2, które można łamać przy użyciu tanich usług w chmurze; nie nadaje się do ochrony wrażliwego ruchu.
• L2TP/IPsec z słabymi ustawieniami – sam IPsec może być bezpieczny, ale w praktyce często spotyka się przestarzałe algorytmy (np. 3DES, MD5) i klucze o zbyt małej długości.
• OpenVPN z „domyślnymi, byle działało” – brak PFS (Perfect Forward Secrecy), słabe krzywe eliptyczne, nieaktualne biblioteki OpenSSL.

Jeśli konfiguracja została kiedyś „ustawiona i zapomniana”, istnieje spora szansa, że dzisiejsze standardy bezpieczeństwa wyglądają już zupełnie inaczej.

Bezpieczniejsze protokoły i ustawienia – co dziś ma sens

Współczesne, sensowne wdrożenie VPN zwykle kręci się wokół kilku technologii. Nie są idealne, ale w dobrze skonfigurowanej formie trzymają solidny poziom:

• WireGuard – nowoczesny, lekki protokół, mały kod źródłowy, domyślnie silne algorytmy (Curve25519, ChaCha20, Poly1305). Dobrze sprawdza się zarówno w komercyjnych VPN, jak i w samodzielnie stawianych tunelach.
• OpenVPN – wciąż bardzo popularny, pod warunkiem użycia mocnych ustawień: AES‑GCM, TLS 1.2/1.3, PFS, aktualne biblioteki kryptograficzne.
• IPsec/IKEv2 – sensowna opcja, zwłaszcza w środowiskach mobilnych i korporacyjnych, pod warunkiem rezygnacji z archaicznych algorytmów i stosowania silnych zestawów szyfrów.

Przy ocenie protokołu i jego implementacji nie liczy się tylko nazwa, ale też konkretny zestaw parametrów:

• rodzaj szyfru (AES‑GCM / ChaCha20 vs 3DES/RC4),
• długość klucza (256 bit vs 128 lub mniej przy wątpliwych algorytmach),
• sposób wymiany kluczy (PFS czy brak PFS),
• wersja TLS używana w kanale sterującym (1.2/1.3 vs stare 1.0/1.1).

Jeśli korzystasz z komercyjnego VPN, część z tych decyzji podejmuje dostawca. Wciąż możesz jednak sprawdzić, czy klient nie pozwala przypadkiem przełączyć się na „tryb zgodności” ze słabszymi szyframi tylko po to, żeby działał na bardzo starych urządzeniach.

„VPN, który przyspiesza internet” – kiedy marketing gryzie się z fizyką

Niektóre usługi kuszą hasłami w stylu „VPN, który przyspiesza połączenie”. Technicznie tunel szyfrujący zawsze dodaje trochę narzutu: pakiety są większe, trzeba je przetworzyć kryptograficznie, często trasa jest dłuższa. Żeby zniwelować ten koszt (lub ukryć go w wynikach testów), część dostawców sięga po różne skróty.

Najczęstsze sztuczki to:

• obniżenie poziomu szyfrowania – np. krótsze klucze, słabsze algorytmy, brak PFS,
• kompresja przed szyfrowaniem – potencjalne ryzyka typu CRIME/BREACH w specyficznych scenariuszach, jeśli kompresja nie jest dobrze ogarnięta,
• optymalizacja pod konkretne benchmarki – np. lepsza trasa do serwerów testujących prędkość, ale już niekoniecznie do realnych serwisów używanych na co dzień.

W testach szybkości wygląda to imponująco, ale z perspektywy bezpieczeństwa nie zawsze jest to dobry kompromis. Tunel, który można złamać lub podsłuchać, bo „chodzi szybciej”, traci swój sens.

Rozsądne podejście to akceptacja, że kilka–kilkanaście procent spadku wydajności to naturalna cena za silne szyfrowanie. Jeśli ktoś obiecuje „zero spadku” albo „przyspieszanie” bez bardzo konkretnych, technicznych wyjaśnień (np. lepsze peeringi, optymalizacja tras), warto mieć z tyłu głowy, że cena może być ukryta w bezpieczeństwie.

Aktualizacje klienta VPN – cichy element bezpieczeństwa kryptografii

Nie każdy łączy kwestię wycieków czy słabych szyfrów z prostą rzeczą: aktualizacjami. Tymczasem klient VPN to kod, który:

• implementuje złożone protokoły kryptograficzne,
• komunikuje się z siecią na niskim poziomie (sterowniki, kernel, NDIS, TUN/TAP),
• często używa bibliotek kryptograficznych, w których co jakiś czas odkrywane są luki.

Jeśli klient VPN nie aktualizuje się regularnie, może używać:

• starej wersji OpenSSL z publicznie znanymi podatnościami,
• wadliwego sterownika sieciowego powodującego losowe rozłączenia i chwilowe wycieki,
• nieoptymalnej implementacji protokołu (np. podatnej na ataki typu downgrade).

Dobry dostawca reaguje na takie problemy szybko: wydaje poprawki, aktualizuje biblioteki, migruje na nowsze standardy. Po stronie użytkownika pozostaje jeden obowiązek – nie ignorować aktualizacji. Ustawienie klienta na automatyczne aktualizacje i ich faktyczne instalowanie często eliminuje całe klasy problemów, o których przeciętny użytkownik nigdy się nie dowie.

Błędna konfiguracja DNS – cichy zabójca prywatności

„Ustawiłem kiedyś 8.8.8.8 i było szybciej” – czyli DNS, który wychodzi bokiem

Typowy scenariusz: ktoś lata temu usłyszał, że „DNS Google jest szybszy”, ustawił 8.8.8.8 w systemie lub na routerze i zapomniał. Dzisiaj instaluje VPN, wszystko zdaje się działać, ale zapytania DNS dalej lecą w świat poza tunelem.

Ręcznie ustawione serwery DNS mają pierwszeństwo przed tym, co próbuje wymusić klient VPN, zwłaszcza jeśli ten jest prostą nakładką, a nie pełnoprawnym klientem systemowym. W rezultacie:

• VPN tuneluje ruch HTTP/HTTPS,
• DNS idzie do Google, dostawcy, Cloudflare lub innego usługodawcy ustawionego „na sztywno”,
• profil aktywności po domenach wciąż jest czytelny i przypisany do prawdziwego IP użytkownika.

Na poziomie doświadczenia użytkownika nic nie wskazuje na problem: strony się ładują, IP na testach się zgadza. Tymczasem ktoś inny ogląda logi DNS i widzi listę odwiedzanych domen z dokładnymi znacznikami czasu.

DNS na routerze vs DNS w systemie – dwa równoległe światy

Domowe sieci często mają dwa poziomy konfiguracji DNS:

• DNS na routerze – to, co router ogłasza urządzeniom w sieci (np. przez DHCP),
• DNS na urządzeniu – to, co ręcznie lub automatycznie ustawione jest w samym systemie (Windows, Android, iOS, Linux).

Pomieszanie tych poziomów prowadzi do ciekawych efektów. Przykładowo:

• na routerze ustawiony jest DNS operatora,
• na laptopie ręcznie wpisany jest DNS Google,
• VPN uruchomiony jest tylko na laptopie, ale nie na routerze.

W takiej konfiguracji:

• laptop pyta o DNS Google (poza tunelami routera, bo ma własne ustawienia),
• router wysyła te zapytania dalej w świat, zgodnie ze swoimi regułami routingu,
• VPN nie ma pełnej kontroli nad tym strumieniem, jeśli nie wymusza własnego DNS.

Do tego dochodzą urządzenia IoT, telewizory, konsole, które często w ogóle nie znają pojęcia VPN. One zawsze użyją DNS z routera lub fabrycznie zaszytego w firmware, co tworzy kolejny kanał metadanych o Twojej aktywności domowej.

Split-DNS, VPN firmowy i domowy – konflikt interesów

Coraz częściej użytkownicy łączą się jednocześnie z VPN-em firmowym i korzystają z własnego komercyjnego VPN do prywatnych celów. Tu pojawia się problem split-DNS – część domen ma być rozwiązywana przez serwery firmowe, część przez publiczne.

Typowe problemy w takiej konfiguracji:

Kiedy firmowy split-DNS gryzie się z prywatnym VPN

Klasyczna sytuacja z pracy zdalnej: na jednym monitorze Teamsy i CRM przez VPN korporacyjny, na drugim film na prywatnym VPN-ie, „żeby operator nie widział”. Z pozoru eleganckie rozwiązanie, w praktyce potrafi wygenerować taką plątaninę routingu i DNS, że połowa ruchu jedzie inną drogą, niż zakłada użytkownik.

Firmowe konfiguracje bardzo często korzystają ze split-DNS i split-tunelingu:

• adresy typu *.firma.local lub wewnętrzne hosty (intranet, ERP, systemy HR) rozwiązują się przez prywatne DNS-y korporacyjne i jadą tunelem,
• reszta ruchu DNS i HTTP/HTTPS wychodzi „normalnie”, poza VPN-em firmowym.

Do tego użytkownik dokłada prywatny VPN, który też próbuje przejąć DNS-y. Efekt uboczny bywa taki, że:

• część zapytań DNS trafi do DNS firmowych,
• część do serwerów prywatnego VPN,
• część w ogóle poleci otwartym kanałem do DNS operatora lub Google/Cloudflare.

Rzadko kiedy widać to gołym okiem – kończy się na „czasem mi nie działają firmowe strony, czasem prywatny VPN się rozłącza”. W tle jednak dzieje się coś znacznie istotniejszego: spójność modelu prywatności się rozpada. Operator i tak widzi część Twoich domen, firma widzi ruch, który miał iść tylko przez prywatny VPN, a logi DNS stają się mozaiką z wielu źródeł.

Typowe pułapki DNS przy nakładających się VPN-ach

Kiedy dwa różne VPN-y próbują jednocześnie „zarządzać” DNS, pojawiają się powtarzalne schematy błędów. Dobrze je znać, bo wtedy wystarczy rzut oka na konfigurację, żeby przewidzieć, gdzie zrobi się dziura.

Najczęstsze problemy przy dwóch aktywnych VPN-ach:

• konflikt reguł routingu – oba klienty próbują dorzucić własne trasy dla serwerów DNS; system operacyjny wybiera „któryś”, zgodnie z priorytetami interfejsów, niekoniecznie ten, którego się spodziewasz,
• wyłączony lub dziurawy kill-switch – gdy jeden tunel się sypie, ruch DNS potrafi natychmiast skoczyć na zwykły interfejs sieciowy, bo drugi VPN pilnuje tylko „swojego” zakresu adresów,
• domyślne bramy na wielu interfejsach – oba VPN-y ustawiają się jako domyślny gateway; system próbuje zbalansować ruch, przez co część zapytań DNS może wypadać poza tunele.

Na maszynach Windows dodatkowym utrudnieniem jest sposób, w jaki system wybiera „preferowany” interfejs. Jeśli klient firmowy ustawi swój interfejs jako bardziej priorytetowy, prywatny VPN może szyfrować ruch HTTP, ale DNS-y i tak skończą w innej sieci. Na Linuxie i macOS problem wygląda inaczej technicznie, ale wniosek jest podobny: przy dwóch VPN-ach nie ma już założeń, są tylko fakty z tablicy routingu.

Jak sprawdzić, którędy naprawdę idzie DNS

Nawet rozbudowana konfiguracja przestaje być zagadką, jeśli poprzeć ją krótkim testem. Zamiast wierzyć aplikacji VPN „DNS leak: OK”, lepiej spojrzeć na to samodzielnie, choćby raz na jakiś czas.

Najprostsze podejścia, które da się wykonać na większości systemów:

• narzędzia online – serwisy typu DNS leak test pokazują, z jakich adresów IP przychodzą do nich zapytania. Jeśli widzisz DNS-y operatora, Google lub lokalnego ISP, a nie serwery VPN, to znak, że coś wycieka,
• konsolowe narzędzia sieciowe – nslookup, dig czy drill; przy zapytaniu o domenę często pokazują, do jakiego serwera DNS poszło zapytanie i jaki adres IP odpowiedział,
• podgląd tablicy routingu – route print na Windows, ip route na Linuxie, netstat -rn na macOS; na tej podstawie da się zobaczyć, przez który interfejs wychodzi ruch do serwerów DNS.

Jeżeli przy aktywnym VPN dalej widzisz jako serwery DNS IP operatora, routera domowego lub publiczne 8.8.8.8 / 1.1.1.1 (a nie adresy z puli VPN), nie ma co się oszukiwać – tunel DNS jest niepełny. Szyfrowany jest tylko ruch do konkretnych serwerów, natomiast informacja „jakie domeny odwiedzasz” wciąż ląduje u kogoś innego.

Wymuszanie DNS przez VPN – kiedy pomaga, a kiedy przeszkadza

Niektórzy dostawcy VPN idą w skrajność i wymuszają swoje serwery DNS „twardo”, nadpisując ustawienia systemowe i ignorując konfigurację routera. Dla przeciętnego użytkownika często jest to zbawienie – ma po prostu mniej sposobów na przypadkowe zepsucie prywatności.

Ten mechanizm jednak ma też ciemniejszą stronę, szczególnie w połączeniu z infrastrukturą firmową lub bardziej wyrafinowanymi setupami domowymi:

• przestają działać wewnętrzne domeny zdefiniowane na lokalnym serwerze DNS (np. nas.dom, media.lan),
• zapytania o lokalne urządzenia (drukarki, NAS-y, kontrolery) zaczynają latać do serwerów VPN, które i tak nie znają tych nazw,
• niektóre aplikacje, szczególnie biznesowe, wymagają dokładnie określonego DNS (firmowego) do poprawnego działania – wymuszony DNS VPN potrafi im odciąć dostęp do zasobów.

Na granicy tych dwóch światów stoi funkcja, którą niektórzy producenci nazywają „smart DNS” lub „split DNS” w ramach klienta VPN. Jej zadanie jest proste: część domen rozwiązywać przez serwery VPN, a część przez lokalne lub firmowe DNS-y. Jeśli dostawca udostępnia taką funkcję, można ją wykorzystać do sensownego pogodzenia prywatności z lokalną infrastrukturą.

Praktyczne strategie na okiełznanie DNS przy VPN

Przy całym bogactwie możliwości sensowna konfiguracja DNS zaczyna się od prostych decyzji. Zamiast kombinować z pięcioma równoległymi źródłami informacji o domenach, lepiej narzucić sobie prosty, powtarzalny schemat.

Sprawdzone podejścia, które działają w realnych domowych i małych firmowych sieciach:

• jedno „źródło prawdy” dla DNS – albo klient VPN w systemie, albo router; mieszanki typu „po trochę tu, po trochę tam” prawie zawsze kończą się niespodziankami,
• VPN na routerze dla urządzeń, które nie mają własnego klienta – telewizory, dekodery, IoT; wtedy to router przejmuje DNS i tuneluje go dalej,
• konsekwencja w ręcznych ustawieniach – jeśli już ręcznie wpisujesz DNS (np. 1.1.1.1), zrób to w jednym miejscu: albo na routerze, albo na konkretnym urządzeniu, a nie na obu poziomach różne wartości,
• oddzielenie pracy od prywatnego VPN – na maszynie służbowej tylko VPN firmowy, na prywatnej – komercyjny; równoczesne używanie obu na jednej stacji kończy się nie tylko bałaganem DNS, ale i problemami z polityką bezpieczeństwa firmy.

Czasem najrozsądniejszym ruchem jest krok w tył: rezygnacja z „kombinowania” i przyjęcie prostej reguły – jedno urządzenie, jeden aktywny VPN, jedna świadomie wybrana konfiguracja DNS.

IPv6 – ukryty kanał dla wycieków DNS i ruchu

Niektórzy użytkownicy myślą o sieci wyłącznie w kategoriach IPv4. Tymczasem operator „po cichu” włączył IPv6, system dostał od niego nowe adresy, a klient VPN tuneluje tylko IPv4. W efekcie część ruchu, w tym zapytań DNS, leci bokiem, poza wszystkie misternie ułożone reguły.

Typowy scenariusz wygląda tak:

• przeglądarka próbuje połączyć się zarówno po IPv4, jak i IPv6,
• DNS zwraca adres IPv6 strony,
• połączenie IPv6 wychodzi bezpośrednio do internetu, z pominięciem tunelu VPN, który „nie ogarnia” tego protokołu.

Jeśli klient VPN nie obsługuje IPv6 lub robi to wybiórczo, pojawia się klasyczny IPv6 leak. Testy zwykle pokazują tylko adres IPv4 „schowany” za VPN-em, więc użytkownik czuje się bezpiecznie, podczas gdy równolegle jego prawdziwy adres IPv6 komunikuje się z tymi samymi usługami.

Najprostsze podejścia do tematu IPv6 przy VPN-ach są dwa:

• pełna obsługa IPv6 przez VPN – tunelowanie zarówno ruchu IPv4, jak i IPv6, z pełną kontrolą nad DNS (w idealnym scenariuszu),
• czasowe wyłączenie IPv6 na interfejsie – jeśli VPN nie wspiera IPv6, a prywatność jest ważniejsza niż korzyści z nowego protokołu, lepiej świadomie go wyłączyć niż pozwolić, by działał poza kontrolą.

Szukanie opcji „Disable IPv6 leak” lub podobnych w ustawieniach klienta VPN to dziś nie fanaberia, tylko podstawowa higiena. Brak tego typu zabezpieczeń w 2020+ roku mówi sporo o dojrzałości usługodawcy.

Aplikacje, które omijają systemowy DNS i VPN

Nawet przy poprawnie skonfigurowanym systemowym DNS niektóre aplikacje chodzą własnymi ścieżkami. Przeglądarki, komunikatory czy klienty gier potrafią korzystać z własnych resolverów, DNS-over-HTTPS (DoH) lub DNS-over-TLS (DoT), wysyłając zapytania w szyfrowanym kanale do zewnętrznych dostawców.

Na pierwszy rzut oka brzmi to korzystnie: szyfrowany DNS, brak podsłuchu na lokalnym łączu. Problem pojawia się, gdy:

• DoH/DoT omija lokalne reguły (w tym te wprowadzone przez VPN),
• aplikacja wysyła DNS do konkretnego dostawcy (np. Cloudflare, Google), niezależnie od tego, co ustawiono w systemie,
• VPN nie przechwytuje tego kanału, bo dla niego to po prostu zwykły HTTPS do obcego serwera.

W praktyce oznacza to, że:

• dostawca DoH/DoT widzi listę odwiedzanych domen,
• VPN nie ma realnego wpływu na to, kto te dane zbiera,
• tracisz część korzyści z kontroli DNS na poziomie systemu czy routera.

W niektórych narzędziach da się to wyłączyć (np. w przeglądarkach możliwość wyłączenia DoH lub ustawienia własnego serwera zgodnego z polityką VPN). To kolejny element układanki: samo „włączenie VPN” nie rozwiązuje problemu, jeśli pojedyncze aplikacje grają według własnych zasad.

DNS w środowiskach hybrydowych – gdy lokalny serwer spotyka komercyjny VPN

Domowe laby, małe firmy, koledzy „od sieci”, którzy zrobili własny serwer DNS na Raspberry Pi – to wszystko tworzy środowiska, w których komercyjny VPN nie jest już „jedynym mądrym w pokoju”. Pojawiają się własne rekordy, strefy split-horizon, filtrowanie reklam na poziomie DNS. Włączenie VPN-a bez zastanowienia potrafi to wszystko zdemolować.

Typowe scenariusze z życia:

• użytkownik ma Pi-hole lub inny filtr DNS na lokalnym serwerze; po włączeniu VPN filtrowanie przestaje działać, bo cały DNS leci przez serwery dostawcy VPN,
• wewnętrzne hosty (np. backup.dom, git.lab) przestają się rozwiązywać, bo aplikacja VPN nadpisuje lokalny DNS, a przy tym nie stosuje split-DNS dla prywatnych stref,
• firmowe zasoby dostępne przez IPsec/IKEv2 z lokalnym DNS-em mieszają się z komercyjnym WireGuardem na tej samej maszynie – każdy próbuje „przepchnąć” swoje ustawienia.

Rozwiązaniem przestaje być proste „włącz/wyłącz VPN”, a bardziej świadome podejście:

• na głównej stacji roboczej – profil pracy (firmowy VPN, firmowy DNS) i osobny profil prywatny (komercyjny VPN, DNS dostawcy),
• na serwerze domowym – lokalny DNS jako nadrzędny, a VPN od filtrowania ruchu tylko „na zewnątrz”,
• w ekstremalnych przypadkach – osobna maszyna lub VM tylko pod firmowy VPN, żeby nie mieszać światów.

Tego typu układ ma jedną zaletę: gdy coś nie działa lub pojawiają się wycieki, dokładnie wiadomo, gdzie szukać przyczyny, bo granice między strefami odpowiedzialności są wyraźnie zaznaczone.