Co dzieje się w chwili zerwania tunelu
Połączenie „otwiera się” po awarii. VPN dodaje trasy, które kierują ruch do wirtualnego interfejsu sieciowego. Gdy proces tunelu ginie albo przekracza limit czasu, te trasy znikają, a domyślna trasa przez Wi-Fi lub Ethernet zostaje — więc system dalej dostarcza pakiety, teraz bezpośrednio przez Twojego dostawcę. Aplikacje wznawiają swoje połączenia w kilka sekund, wysyłając ruch z Twojego prawdziwego IP, bez żadnego komunikatu błędu.
Zerwania to codzienność. Przejście z Wi-Fi na dane komórkowe, laptop budzący się z uśpienia, kapryśna hotelowa sieć czy restart serwera VPN — każde z nich na chwilę przerywa tunel. Ile ta chwila kosztuje, zależy od tego, czy cokolwiek może opuścić Twoje urządzenie, gdy tunel leży.
Co tak naprawdę robi kill switch
Kill switch to zestaw reguł zapory, nie magia. Wersja ścisła przepuszcza tylko dwa rodzaje ruchu wychodzącego: pakiety wchodzące do interfejsu tunelu i własne zaszyfrowane pakiety klienta VPN do serwera. Jeśli tunel padnie, ruch aplikacji po prostu nie ma dokąd pójść, dopóki tunel nie wróci.
To zmienia tryb awarii, a nie zapobiega awariom. Z kill switchem zerwanie staje się zauważalną pauzą w połączeniu; bez niego — ruchem z Twojego prawdziwego adresu, którego nie zauważasz. Sieci są niedoskonałe i tunel nadal będzie się rwał — fail-closed czyni te momenty nieszkodliwymi.
Systemowy kill switch a przełącznik w aplikacji
Różnica sprowadza się do tego, co się dzieje, gdy padnie sama aplikacja. Kill switch w aplikacji to kod wewnątrz klienta VPN, który obserwuje tunel i blokuje ruch przy zerwaniu. Działa tylko, póki klient działa: jeśli klient się wysypie albo zabije go optymalizator baterii, jego ochrona umiera razem z nim — dokładnie w chwili, gdy znika tunel.
Systemowy kill switch instaluje reguły w zaporze samego systemu operacyjnego, która sprawdza każdy wychodzący pakiet niezależnie od tego, jakie aplikacje działają. Android ma to wbudowane: „VPN zawsze włączony” plus „blokuj połączenia bez VPN” sprawiają, że sam system odmawia ruchu poza tunelem, jeszcze zanim aplikacja wystartuje po restarcie. Najprostszy sposób, by odróżnić jedno od drugiego: wymuś zabicie aplikacji VPN podczas przeglądania — jeśli strony wciąż się ładują, przełącznik mieszka w aplikacji.
Wycieki DNS: zapytania, które omijają tunel
Wyciek DNS oznacza, że tłumaczenie nazw idzie do resolvera przydzielonego przez lokalną sieć — zwykle Twojego dostawcy — mimo że sam ruch jedzie tunelem. Strony widzą adres VPN, ale resolver dostaje nazwę każdej otwieranej witryny, co składa się na dziennik przeglądania. Klasycznym winowajcą jest Windows: przy kilku aktywnych interfejsach potrafi pytać wszystkie równolegle i użyć tego, który odpowie pierwszy.
Naprawa ma dwie części i dobry klient robi obie: kieruje system na resolver wewnątrz tunelu oraz blokuje DNS na każdym innym interfejsie, żeby zbłąkane zapytanie nie miało dokąd pójść. Potem weryfikacja: uruchom test wycieków i sprawdź wypisane resolvery — jeśli którykolwiek należy do Twojego dostawcy, zapytania przeciekają.
Wycieki WebRTC: przeglądarka rozdaje adresy
WebRTC to technologia przeglądarkowa stojąca za wideorozmowami — i każda strona może ją wywołać kilkoma linijkami JavaScriptu. Aby zestawiać połączenia bezpośrednie, zbiera każdy adres, którym można dotrzeć do Twojej maszyny: adresy lokalne oraz — pytając serwer STUN — Twój publiczny. Strona może odczytać tych kandydatów bez Twojego udziału.
Przy tunelu obejmującym całe urządzenie zapytanie STUN jedzie wewnątrz tunelu, więc odkrywa adres VPN-a. Niebezpieczne są konfiguracje częściowe: proxy tylko w przeglądarce albo split tunneling zostawiający przeglądarkę na zewnątrz — tam pakiety UDP WebRTC wychodzą bezpośrednio i zdradzają Twoje prawdziwe IP.
Zamiast teoretyzować — przetestuj: nasz darmowy tester pod adresem /webrtc-leak-test/ pokazuje, jakie adresy Twoja przeglądarka ujawnia w tej chwili. Jeśli pojawia się prawdziwy, przejdź na tunel dla całego urządzenia albo wyłącz WebRTC w ustawieniach przeglądarki.
Wycieki IPv6: tunel obejmuje tylko IPv4
Wiele konfiguracji VPN przenosi wyłącznie IPv4. Jeśli Twój dostawca daje też IPv6 — a większość sieci komórkowych daje — system utrzymuje działającą trasę IPv6 poza tunelem, a nowoczesne systemy preferują IPv6, gdy strona oferuje oba protokoły. Efekt to wybiórcza ekspozycja: strony bez IPv6 widzą adres VPN-a, strony z IPv6 — Twój prawdziwy, a test sprawdzający tylko IPv4 raportuje, że wszystko gra.
Są dwie czyste naprawy. Lepsza to VPN poprawnie obsługujący IPv6 — tunelujący go obok IPv4 albo instalujący trasę blokującą, tak by pakiety IPv6 były odrzucane, a nie wysyłane bezpośrednio. Toporna rezerwa to wyłączenie IPv6 na urządzeniu lub routerze. Tak czy inaczej — zweryfikuj: test wycieków nie powinien pokazać żadnego adresu IPv6, który nie należy do VPN-a.
Jak porządnie przetestować swoją konfigurację
Wykonuj sprawdzenia w warunkach, w których naprawdę pracujesz — domowe Wi-Fi, telefon na danych komórkowych, sieć w kawiarni — bo wycieki zależą od konfiguracji DNS i dostępności IPv6 w każdej sieci. Cała rutyna zajmuje około pięciu minut:
- Zapisz swoje prawdziwe IP przy wyłączonym VPN, połącz się i potwierdź, że widoczne adresy IPv4 i IPv6 oba się zmieniły — nasz /data-leak-checker/ pokazuje IP, resolvery DNS i WebRTC za jednym przebiegiem
- Sprawdź listę resolverów: każdy pokazany serwer DNS powinien należeć do VPN-a, żaden do Twojego dostawcy
- Zerwij tunel celowo — przełącz Wi-Fi albo wymuś zabicie aplikacji — i patrz, czy strony ładują się, zanim się wznowi
- Powtórz po aktualizacjach systemu lub aplikacji VPN, bo obie potrafią po cichu zresetować ustawienia sieci