Split tunneling w VPN: wygoda czy ryzyko?

Masz szybkie łącze, a po włączeniu VPN wszystko zwalnia? I jeszcze nie działa drukarka w domu?

Typowy scenariusz: włączasz VPN, żeby chronić prywatność albo połączyć się z zasobami firmowymi. Nagle wideo 4K zaczyna się ładować, gra ma wyższy ping, a lokalny NAS czy drukarka przestają odpowiadać. Znasz to? To moment, w którym na horyzoncie pojawia się split tunneling w VPN – obietnica wygody, ale i potencjalne ryzyko wycieków.

Zanim klikniesz „włącz”, zadaj sobie kilka szybkich pytań: jaki masz cel? Chcesz zwiększyć prędkość streamingu, zostawiając przeglądarkę pod ochroną? Potrzebujesz dostępu do firmowego intranetu i jednocześnie do domowego smart TV? A może liczysz na niższy ping w grze bez rozłączania reszty aplikacji?

Split tunneling potrafi dokładnie to dostarczyć: część ruchu idzie przez VPN, a część „na wprost” przez Twój zwykły internet. Problem? Jedno nieuważne ustawienie i to, co miało zostać zaszyfrowane, nagle płynie otwartym kanałem. W firmach – to czasem złamanie polityki bezpieczeństwa, w domu – realne ryzyko deanonimizacji. Gdzie jest granica wygody, a gdzie zaczyna się ryzyko?

Skąd biorą się spowolnienia i blokady po włączeniu VPN?

Narzut szyfrowania i dodatkowa trasa pakietów

VPN dodaje warstwę szyfrowania, a ruch przechodzi przez serwer pośredniczący. To oznacza dodatkowe milisekundy opóźnienia i spadek przepustowości. Im dalej od Ciebie serwer i im bardziej obciążona jest sieć, tym większe skutki. Jeśli wszystko, łącznie ze streamami i aktualizacjami, idzie przez VPN, wąskim gardłem staje się serwer tunelu.

Konflikt lokalnych zasobów z trasami do VPN

Gdy VPN przejmuje trasę domyślną (full tunnel), urządzenia w Twojej sieci lokalnej (drukarka, NAS, odtwarzacz sieciowy) bywa, że przestają się wykrywać. Ruch zamiast trafić do 192.168.x.x lokalnie, czasem próbuje iść przez zdalny tunel, jeśli klient źle wdrożył routing albo kolidują prywatne podsieci (np. Ty: 192.168.1.0/24, firma: 192.168.1.0/24).

DNS, geolokalizacja i serwisy wrażliwe na region

Bank, serwis VOD czy sklepy internetowe reagują na adres IP i lokalizację DNS. VPN potrafi zmieniać region w niepożądany sposób. Dodatkowo ustawienia DNS w kliencie VPN mogą nadpisać Twoje, co wpływa na szybkość i rozwiązywanie nazw (split-horizon DNS w firmach, DoH w przeglądarce, własny resolver routera – to się może nieprzewidywalnie złożyć).

IPv6 i WebRTC – „boczne drzwi” dla wycieków

Jeśli dostawca VPN nie obsługuje IPv6 albo jest wyłączone w kliencie, ale aktywne w systemie, część ruchu (np. zapytania DNS lub połączenia P2P) może wyjść poza tunel IPv4. WebRTC w przeglądarce też potrafi wyeksponować lokalny i publiczny adres IP, jeśli nie zablokujesz odpowiednich interfejsów.

TCP w tunelu a wydajność

Gdy aplikacja używa TCP, a tunel też opiera się na TCP (np. OpenVPN na TCP), pojawia się zjawisko „TCP over TCP meltdown”. Retransmisje na jednej warstwie potrafią pogarszać drugą, co skutkuje irytującą niestabilnością. UDP (np. WireGuard, OpenVPN-UDP) zwykle lepiej radzi sobie z ruchem czasu rzeczywistego.

Split tunneling w VPN – o co w tym chodzi (bez akademickich definicji)

Prosty obraz: dwa pasy ruchu zamiast jednego

Split tunneling to ustawienie, w którym decydujesz: co idzie przez VPN, a co omija tunel. Nie musisz wybierać „wszystko albo nic”. Możesz np. przeglądarkę i klienta poczty wysłać przez VPN, a Netflix i grę – poza nim. Albo odwrotnie: tylko firmowe adresy 10.0.0.0/8 i 172.16.0.0/12 przez tunel, reszta – bezpośrednio.

Trzy praktyczne modele konfiguracji

• Per-aplikacja: wskazujesz konkretne programy, które mają używać VPN (lub które mają go omijać). Wygodne na desktopie i Androidzie.
• Per-trasa (subnet/IP): definiujesz adresy lub sieci, które mają iść przez tunel. Klasyka w firmach (tzw. split include/exclude routes).
• „Odwrócone” split tunneling (inverse): domyślnie wszystko poza VPN, a tylko lista wyjątków przez tunel – lub odwrotnie: wszystko przez VPN z kilkoma wyjątkami.

Co najczęściej „wynosisz” poza tunel?

Najczęstsze wyjątki to streamy wideo, gry, aktualizacje systemu, komunikacja z lokalnymi urządzeniami oraz serwisy bankowe wymagające lokalnego IP. Zawsze jednak pada pytanie: czy akurat te strumienie danych możesz bezpiecznie wypuścić poza warstwę ochrony?

Wygoda: kiedy split tunneling działa na Twoją korzyść

Domowe multimedia i urządzenia w LAN

Chcesz oglądać lokalne VOD na smart TV, a jednocześnie zachować prywatność przeglądarki? Rozsądne podejście to per-aplikacyjne split tunneling: przeglądarka i komunikatory przez VPN, aplikacje telewizyjne i protokoły DLNA poza nim. Drukowanie, skanowanie, przeglądanie plików na NAS – wszystko działa, bo ruch do 192.168.x.x nie ma po drodze do pokonania zdalnego tunelu.

Zapytaj siebie: które aplikacje faktycznie potrzebują maskowania IP i szyfrowania end-to-end poza HTTPS? Często są to: przeglądanie wrażliwych treści, zakupy, dyski w chmurze, logowania do kont. Muzyka i wideo (legalne serwisy) – zazwyczaj mniej krytyczne, o ile nie zależy Ci na ukrywaniu nawyków oglądania przed ISP.

Gry online i niski ping

Split tunneling pozwala wyprowadzić grę poza VPN, pozostawiając działanie VPN-u w aplikacjach, które nie tolerują wysokich opóźnień. To sensowne, jeśli serwery gier nie wymagają tunelu i nie chcesz ryzykować blokady konta za używanie VPN.

Zwróć uwagę na wyjątki: niektóre gry mają mechanizmy anty-cheat czułe na niestandardowe trasy ruchu. Sprawdź regulamin i przetestuj, czy rozdzielenie ruchu nie powoduje zrywania sesji czatu głosowego.

Praca zdalna – tylko zasoby firmowe przez VPN

W pracy zdalnej typowe jest włączanie tunelu tylko dla adresów prywatnych firmy i wybranych usług SaaS. Zmniejsza to obciążenie bramy VPN, poprawia prędkość i stabilność wideokonferencji. Jeśli organizacja stosuje split-horizon DNS (inne odpowiedzi DNS wewnątrz firmy), split tunneling z poprawnym routowaniem DNS to duża ulga dla użytkownika.

Łącza o ograniczonej przepustowości i hotspoty

Gdy dzielisz internet z telefonu albo masz limit transferu, logiczne jest odciążenie tunelu z ciężkich strumieni (np. aktualizacje Steam). Uważaj jednak na publiczne Wi-Fi – tam split tunneling może bezmyślnie odsłonić ruch na niezaufanej infrastrukturze.

Ryzyka i typowe błędy: gdzie split tunneling bywa niebezpieczny

Wyciek IP, DNS i WebRTC

Najczęstsza wpadka: wyjątki obejmują przeglądarkę albo jej komponenty (np. Widevine, helpery), a DNS dalej pyta poza VPN. Efekt: serwisy rozpoznają Twój prawdziwy adres IP lub region. Do tego WebRTC potrafi ujawnić lokalne adresy. Jeśli celem było ukrycie lokalizacji – split tunneling skonfigurowany błędnie całkowicie to niweczy.

Ominięcie polityki firmowej lub DLP

W wielu organizacjach split tunneling jest celowo wyłączony. Dlaczego? Bo pozwala ominąć kontrolę DLP, proxy, IDS/IPS i logowanie. Jeśli ruch „na wprost” obejmuje aplikacje biznesowe lub uploady do chmury, bezpieczeństwo i zgodność z regulacjami (np. RODO, PCI-DSS) może stanąć pod znakiem zapytania. Masz umowę? Sprawdź, co dopuszcza dział bezpieczeństwa.

Masz BYOD albo pracujesz na prywatnym laptopie? Split potrafi „wypchnąć” poza nadzór firmowe pliki przez zwykłe chmury

BYOD i chmury konsumenckie: cichy kanał wycieku

Używasz prywatnego laptopa do służbowych zadań? Zastanów się: jakie aplikacje synchronizują pliki w tle – i którędy? Split może wyrzucić ruch dysków w chmurze poza tunel. Skutek: dokumenty lądują na serwerach spoza nadzoru DLP, a audyt nie widzi transferu. Przyczyna bywa prosta: wyjątkiem objęto całe „katalogi użytkownika” lub aplikacje pomocnicze (updater, agent synchronizacji), które nie są oczywiste przy wyborze „per-aplikacja”.

Rozwiązanie? Jeśli dotykasz danych firmowych, trzymaj cały pakiet biurowy i narzędzia synchronizacji w tunelu. Jeżeli organizacja dopuszcza split, poproś o listę dozwolonych wyjątków i politykę DNS. Brzmi biurokratycznie? Lepiej tak, niż tłumaczyć się z nieświadomego transferu poza kontrolą.

Środowiska, w których split tunneling zwykle nie ma sensu

Zanim włączysz wyjątki, odpowiedz: gdzie i po co się łączysz?

• Publiczne Wi‑Fi i hotele – ruch poza VPN jest łatwym łupem. Priorytet: pełny tunel, w tym DNS i IPv6.
• Jurysdykcje z cenzurą lub wysokim ryzykiem nadzoru – split to proszenie się o korelację ruchu.
• Aplikacje regulowane (finanse, medycyna, dane klientów) – często wymagany jest pełny wgląd i rejestrowanie po stronie firmy.
• Brak wsparcia IPv6 u dostawcy VPN – jeśli nie wyłączysz IPv6, split skończy się wyciekiem adresu i zapytań.

Jak ustawić split tunneling bez kompromitowania bezpieczeństwa

Wariant domowy: priorytet prywatności

Cel: zostawić przeglądarkę, pocztę, komunikatory i chmury w tunelu, a „ciężary” i LAN poza.

• Per-aplikacja: dodaj przeglądarkę, klienta poczty, narzędzia chmurowe do listy „zawsze przez VPN”.
• Wyjątki: odtwarzacze VOD, gry, platformy aktualizacji – „poza VPN”.
• LAN: skonfiguruj, by ruch do 192.168.0.0/16, 10.0.0.0/8 i 172.16.0.0/12 omijał tunel; kolizje podsieci? Zmień adresację domową na mniej typową (np. 192.168.50.0/24).
• DNS: wymuś DNS przez VPN dla aplikacji w tunelu; w przeglądarce wyłącz własny DoH, jeśli omija systemowy resolver.

Kontrolne pytanie: czy Twój telewizor naprawdę musi mieć ruch szyfrowany? Jeśli jedynie strumieniuje legalne treści, zazwyczaj nie – pod warunkiem, że jesteś w zaufanej sieci domowej.

Wariant domowy: priorytet wydajności

Cel: maksymalnie odchudzić tunel, nie rezygnując z ochrony tam, gdzie ma to sens.

• Wybierz protokół VPN na UDP (np. WireGuard lub OpenVPN-UDP), unikaj TCP w tunelu dla ruchu czasu rzeczywistego.
• Wyprowadź poza tunel gry, platformy gier, aktualizacje systemu i sterowników.
• Pozostaw w tunelu logowania, bankowość (jeśli nie wymaga lokalnego IP), chmury i przeglądarki z sesjami kont.
• Zadbaj, by wideokonferencje działały stabilnie – przetestuj: z i bez tunelu. Która ścieżka daje mniej jittera?

Wariant firmowy: zgodność i kontrola

Masz polityki i MDM? Działaj według wytycznych. Najpierw: czego potrzebujesz – dostęp do prywatnych podsieci, czy pełny ruch przez SOC?

• Split „include”: wysyłaj do tunelu tylko prefiksy firmowe i aplikacje krytyczne; reszta przez internet. Warunek: DLP i proxy muszą być wymuszone na endpointach, inaczej tracisz widoczność.
• Split‑DNS: skonfiguruj rozwiązywanie nazw firmowych wyłącznie przez wewnętrzne serwery; publiczne domeny – przez resolver zgodny z polityką.
• BYOD: jeśli to możliwe, separuj profil pracy (kontener, osobna przeglądarka) i kieruj go w całości przez tunel.
• Nakładaj reguły zapory: blokuj ruch do adresów firmowych poza interfejsem VPN. To domyka lukę „przez przypadek poza tunelem”.

DNS i IPv6: domknięcie bocznych furtek

Co już próbowałeś w kwestii DNS? Jeśli nic – zacznij tutaj. Najczęstsze wycieki biorą się z niespójności:

• System używa DNS od VPN, ale przeglądarka włącza własny DoH – w efekcie zapytania idą poza tunel. Rozwiązanie: wyłącz DoH w przeglądarce albo skonfiguruj DoH na serwer operatora VPN.
• IPv6 działa w systemie, a VPN go nie obsługuje – część aplikacji wybierze IPv6 i ominie tunel. Rozwiązanie: włącz IPv6 w tunelu lub tymczasowo wyłącz IPv6 w systemie/interfejsie.
• mDNS/LLMNR dla urządzeń LAN – pozwól im iść poza tunel, inaczej drukarka znika z sieci. Dopilnuj jednak, by ten wyjątek nie obejmował całej przeglądarki.

Kill switch i reguły zapory: bez tego split jest kruchy

Czy sprawdziłeś, co dzieje się przy restarcie klienta VPN? Bez kill switcha aplikacje „wyślizgną się” na zwykły interfejs. Ustaw:

• Systemowy kill switch blokujący ruch spoza tunelu dla aplikacji oznaczonych jako „wymagają VPN”.
• Reguły firewall: deny do prefiksów firmowych na interfejsach innych niż VPN; deny do DNS spoza interfejsu VPN dla aplikacji w tunelu.
• Alerty: jeśli trasa do prefiksów wewnętrznych znika, klient powinien zerwać połączenie (fail‑closed).

Czego unikać przy konfiguracji wyjątków

• Wykluczania całej przeglądarki z tunelu, gdy celem jest anonimowość – zbyt duża powierzchnia ryzyka (wtyczki, WebRTC, helpery).
• Poleganiu na TCP‑w‑TCP – jeżeli musisz używać OpenVPN‑TCP, nie kieruj przez niego streamów i gier.
• Mieszania wielu „akceleratorów”: VPN + inteligentny proxy + „przyspieszacz” ISP – diagnoza staje się koszmarem.
• Kolizji adresacji: 192.168.1.0/24 w domu i w pracy – zmień domową podsieć, inaczej routing będzie losowy.
• Wyjątków „po domenie” bez kontroli DNS – CDN-y mają setki IP, jutro popłyniesz inną trasą niż myślisz.

Jak wybrać klienta i usługę VPN pod split

Jaki masz cel – prywatność, wydajność, czy zgodność z politykami? Pod to dobierz funkcje:

• Precyzyjny split per-aplikacja i per-trasa (include/exclude), także na macOS/iOS i Linuxie, nie tylko Windows/Android.
• Obsługa IPv6 w tunelu oraz wymuszanie DNS (z ochraną przed wyciekami i wsparciem DoH/DoT).
• Kill switch działający również przy split tunnelingu oraz możliwość dodania reguł firewall z poziomu klienta.
• Protokół UDP o niskim narzucie (np. WireGuard) i opcja wyboru serwera o niskiej latencji.
• Tryb „only LAN outside” – łatwe wykluczanie ruchu do lokalnych podsieci bez ruszania reszty.
• W środowiskach firmowych: integracja z MDM, polityki per‑grupa, split‑DNS i blokady kierunkowe.

Mini‑checklista bezpiecznego split tunnelingu

• Jaki masz cel? Zdefiniuj aplikacje, które muszą być w tunelu, i te, które mogą go ominąć.
• DNS i IPv6: wymuś DNS przez VPN; włącz IPv6 w tunelu albo wyłącz systemowo.
• LAN: wyklucz tylko lokalne podsieci; unikaj wykluczania całej przeglądarki.
• Firewall i kill switch: zablokuj ruch aplikacji „wymagających VPN” poza tunelem.
• Test: sprawdź IP/DNS/WebRTC w przeglądarce i trasę do zasobów firmowych (tracert/tracepath).
• Środowisko: publiczne Wi‑Fi? Zrezygnuj ze splitu lub ogranicz go do ruchu LAN.
• Polityki: w firmie działaj według wytycznych security; BYOD trzymaj w odseparowanym profilu.

Jak testować i monitorować split w praktyce

Masz już wyjątki? Sprawdź, czy działają tak, jak myślisz. Najpierw prosty test, potem szczegóły tras i DNS. Co już próbowałeś – tylko „sprawdź IP w przeglądarce”, czy też trasy i zapytania?

• Adres IP: dla aplikacji „w tunelu” sprawdź, czy widzisz IP serwera VPN; dla wyłączonych – IP twojego ISP. W przeglądarce użyj dwóch profili lub okna prywatnego, aby nie mieszać sesji.
• Trasa do zasobów firmowych: tracert/tracepath na adresy wewnętrzne powinien iść przez interfejs VPN.
• DNS: porównaj, dokąd idą zapytania w aplikacjach w tunelu i poza nim. Użyj nslookup/dig – dla domen firmowych odpowiedzi muszą pochodzić z wewnętrznych resolverów.
• Wycieki WebRTC: w przeglądarce w tunelu sprawdź, czy nie ujawnia lokalnego/ISP IP; wtyczki „WebRTC leak prevent” bywają pomocne, jeśli klient VPN nie filtruje STUN.

Potrzebujesz narzędzi? Kilka szybkich tropów:

• Windows: route print, Get-NetRoute, ipconfig /all, Resolve-DnsName -Server <ip_vpn_dns>.
• macOS: netstat -rn, scutil --dns, networksetup -listnetworkserviceorder.
• Linux: ip route, ip rule, resolvectl status lub systemd-resolve --status.
• Android: tryb „Zawsze włączony VPN” + „Blokuj bez VPN” dla aplikacji, które muszą być w tunelu; sprawdź IP i DNS w mobilnej przeglądarce oraz w wyłączonych grach/VOD.
• iOS/iPadOS: split per‑app zwykle przez MDM; testuj profile pracy osobno od prywatnych.

Automatyzacja: inny split w domu, inny w terenie

Chcesz w domu drukować i streamować, a w hotelu mieć pełny tunel bez wyjątków? Zapytaj siebie: co ma się stać, gdy zmienisz sieć – profil ma przełączyć się sam czy wolisz ręczny przełącznik?

• Warunkowe profile: skonfiguruj dwa zestawy reguł – „Dom” (split dopuszczalny) i „Publiczna” (pełny tunel). Kryterium: SSID, adresacja LAN lub obecność zaufanego resolvera.
• Systemowe wyzwalacze:
  • Windows: Harmonogram zadań + PowerShell (wykryj SSID i zastosuj profil klienta VPN).
  • macOS: scselect lub profile sieci + launchd (przełączaj serwis VPN i reguły firewall).
  • Linux: skrypty NetworkManager Dispatcher (w oparciu o interfejs/SSID włącz inny zestaw tras).
• Domyślne zachowanie: do czasu załadowania reguł traktuj połączenie jako „pełny tunel” (fail‑closed). Inaczej przez kilka sekund po starcie złapiesz wyciek.
• Alerty: jeśli klient VPN wspiera, ustaw powiadomienia o zmianie profilu i błędach rozwiązywania DNS.

Unikaj jednego błędu: wykrywanie „po SSID” bez dodatkowej weryfikacji. Zduplikowane nazwy sieci w hotelach są normą – sprawdzaj także prefiks podsieci lub bramę.

Lokalizacja i geoblokady: pogodzenie z wyjątkami

Masz konflikt: serwis VOD wymaga lokalnego IP, a bank nie lubi węzłów VPN? Co jest priorytetem – wygoda treści czy spójność lokalizacji dla wszystkich kart w przeglądarce?

• Oddziel konteksty: osobna przeglądarka albo profil „VOD/gry” poza tunelem; profil „bank/zakupy” w tunelu lub z dedykowanym IP od dostawcy VPN.
• Per‑site ≠ per‑app: unikaj routingu „po domenie” bez kontrolowanego DNS – CDN-y zmieniają IP. Lepiej wydzielić aplikację/instancję przeglądarki.
• Sesje i ciasteczka: nie mieszaj logowań między profilami; różne trasy zwiększają ryzyko blokad i CAPTCH.
• Gdy musisz mieć wszystko w tunelu: rozważ dedykowane IP VPN w docelowym kraju (mniej false‑positives w bankach i SSO).

Kiedy split bywa najlepszym wyborem

Zastanów się: jaki masz cel i ryzyko środowiska?

• Domowe, zaufane LAN, brak obcych gości w sieci; chcesz drukować/NAS i odciążyć tunel – split pomaga.
• Ciężkie aktualizacje i gry oparte na UDP, a jednocześnie stała ochrona przeglądarki – podziel aplikacjami.
• Środowisko firmowe z wymuszonym DLP na endpointach i split‑DNS – sensowny „include split” na prefiksy wewnętrzne.
• Warunek wspólny: pełna kontrola DNS i działający kill switch. Bez tego korzyści zjadają wycieki.

Przykład z praktyki: NAS i spotkanie wideo bez rwania

Scenariusz: w domu kopiujesz backup na NAS i masz za 5 minut wideokonferencję. Cel? Transfer na LAN poza tunelem, stabilne wideo bez wycieków z przeglądarki.

1. Routing LAN: wyklucz 192.168.50.0/24 (lub swoją podsieć) z tunelu. Sprawdź tracepath 192.168.50.10 – ma iść lokalnie.
2. Przeglądarka do spotkań: zostaw w tunelu i wyłącz jej DoH lub ustaw na resolver VPN.
3. Aplikacja konferencyjna: przetestuj obie ścieżki – jeśli poza tunelem ma mniejszy jitter, wyłącz ją z VPN, ale zatrzymaj przeglądarkę w tunelu.
4. Kill switch: przypnij do przeglądarki w tunelu; restart klienta nie może wyrzucić ruchu na zwykły interfejs.
5. Test końcowy: IP/DNS w przeglądarce to VPN, kopiowanie na NAS nie dotyka internetu, a konferencja nie „pikuje” opóźnieniami.

Mini‑checklista testów po wdrożeniu

• IP: aplikacje w tunelu widzą IP VPN, wyjątki – IP ISP.
• DNS: zapytania z tunelu trafiają do resolvera VPN; brak DoH omijającego tunel.
• IPv6: włączone w tunelu lub wyłączone systemowo; brak ruchu v6 poza VPN.
• Trasy: route/ip route pokazuje prefiksy firmowe przez interfejs VPN; LAN poza tunelem.
• Fail‑closed: przy zerwaniu połączenia ruch „wymaga VPN” jest blokowany.
• Środowisko: profil „Publiczna” przełącza się na pełny tunel bez wyjątków.

Split DNS w praktyce: gdzie naprawdę płynie ruch

Problemy z logowaniem do intranetu? Albo w przeglądarce pojawiają się dziwne CAPTCHA, mimo że „wszystko w tunelu”? Często winny jest DNS. Jaki masz cel – pełna prywatność, czy dostęp do wewnętrznych domen przy zachowaniu szybkości? Od tego zależy ustawienie resolverów i polityk.

• Windows: auto‑upgrade DoH potrafi ominąć split‑DNS. Rozwiązanie: wymuś DNS przez interfejs VPN (klient z opcją „force DNS in tunnel”), w GPO wyłącz automatyczne DoH lub ustaw zaufany resolver tylko w tunelu. Dla domen firmowych dodaj reguły NRPT wskazujące wewnętrzne DNS i zweryfikuj Get-DnsClientNrptPolicy.
• macOS: kolejność resolverów bywa myląca – profil VPN powinien ustawić „Scoped DNS” dla konkretnych domen. Sprawdź scutil --dns, czy domeny korporacyjne idą do serwerów z interfejsu tunelu. W Chrome/Firefox wyłącz DoH dla profilu pracy lub skonfiguruj go na resolver dostawcy VPN.
• Linux (systemd‑resolved): skonfiguruj „routing domains” dla split‑DNS i upewnij się, że zapytania do wewnętrznych DNS mają trasę i regułę ip rule/fwmark przez tunel. Zajrzyj w resolvectl dns/resolvectl domain; wyłącz fallback w aplikacjach (np. flagi wyłączające 8.8.8.8).
• Android/iOS: tryb „Prywatny DNS” (DoT) na Androidzie może ominąć tunel – dla profilu pracy wyłącz lub ustaw na resolver VPN. Na iOS split per‑app i split‑DNS zwykle przez MDM; sprawdź, czy profil wyłączył DoH w przeglądarce służbowej.
• WebRTC/STUN: niektóre aplikacje negocjują połączenie bez klasycznych zapytań DNS. Jeśli klient VPN nie filtruje STUN, użyj polityk przeglądarki lub dodatków blokujących WebRTC poza tunelem.

Co już próbowałeś – tylko przełącznik „blokuj wycieki DNS”, czy też per‑domena z wymuszonym resolverem? Jeśli masz wątpliwość, uruchom równolegle tcpdump/Wireshark i zobacz, którym interfejsem lecą porty 53/853/443 (DoH).

Split na routerze czy na urządzeniu?

Chcesz, żeby TV i konsola omijały VPN, a laptop miał pełną ochronę? Decyzja: split na routerze (PBR) czy per‑urządzenie. Co jest ważniejsze – centralna kontrola, czy precyzja i kill switch na endpointzie?

• Router (OpenWrt/Asus/MikroTik):
  • Zalety: jedna konfiguracja dla całego domu, wygodne PBR per‑IP/VLAN, łatwe wyłączenie IoT z tunelu.
  • Ryzyka: trudniejszy kill switch per‑aplikacja, mieszane środowiska (laptop służbowy) łamią polityki, IPv6 potrafi „wyciec” przez RA ISP.
  • Praktyka: segmentuj sieć (VLAN „IoT/VOD” bez VPN, „Praca” z pełnym tunelem). W PBR trzymaj reguły po źródłowym IP/MAC, nie po domenie. IPv6: albo tuneluj (WireGuard/OVPN v6), albo wyłącz RA na interfejsach objętych VPN.
• Urządzenie (klient VPN):
  • Zalety: dokładny split per‑aplikacja, solidny kill switch, łatwiej wymusić DNS i kontrolować DoH/WebRTC.
  • Ryzyka: więcej konfiguracji na wielu hostach; trzeba spiąć z profilami „Dom/Publiczna”.

Jakie masz wymagania? Jeśli priorytetem jest zgodność służbowego laptopa – trzymaj VPN na urządzeniu, a router użyj tylko do wydzielenia VLAN bez tunelu dla TV/konsoli. Dla czysto domowych instalacji: router z PBR plus prosty split „LAN outside” na laptopie zwykle wystarcza.

Środowisko firmowe: kiedy split łamie polityki

Masz BYOD czy zarządzany endpoint? DLP, SIEM i ZTNA nie wybaczają „sprytnego wyjątku”. Co jest celem – dostęp do intranetu i chmury, czy zwiększenie przepustowości gier po pracy?

• Model „include‑only”: tuneluj wyłącznie prefiksy firmowe i domeny serwisów korporacyjnych (split‑DNS), reszta idzie zwykłym łączem, ale pod kontrolą EDR/DLP. Zaleta: przewidywalność i zgodność z audytem.
• Per‑app zamiast per‑site: aplikacje biznesowe (SSO, CRM, komunikatory) przypięte do tunelu polityką MDM. Przeglądarka prywatna – poza tunelem, w odseparowanym profilu użytkownika.
• Kontrola i logowanie: enforce DNS przez wewnętrzne resolvery, logi z klienta VPN do SIEM, alerty na przerwanie tunelu. Wymuś „block outside” dla aplikacji klasyfikowanych jako „wymaga VPN”.

Czego unikać w firmie:

• Wyjątków po domenie bez split‑DNS i pinningu resolvera – CDN zmieni IP i dane popłyną bokiem.
• Mieszania profili – ten sam Edge/Chrome do banku, intranetu i platform VOD z różnymi trasami.
• Routerowego VPN dla całej sieci, gdy w domu jest laptop zarządzany przez IT – to proszenie się o incydent.

Masz wątpliwość, czy reguła jest zgodna? Zadaj jedno pytanie: czy ruch opuszczający tunel jest nadal objęty tymi samymi kontrolami (DLP/EDR/Proxy)? Jeśli nie – zrezygnuj ze splitu lub przenieś go na poziom ZTNA/SDP.

Szybka sekwencja wdrożenia bez bólu

1. Cel: wypisz 3 aplikacje „muszą być w tunelu” i 3 „mogą wyjść poza”. Bez tego reszta to