Czym jest split tunneling? 

Kiedy użytkownik łączy się z koncentratorem VPN, ruch sieciowy może być kierowany na dwa sposoby. Albo wszystko idzie przez tunel do firmowej infrastruktury, albo ruch jest dzielony: część przez tunel VPN, reszta bezpośrednio przez lokalny Gateway sieci użytkownika do Internetu lub lokalnych zasobów w jego sieci. To drugie to właśnie split tunneling. W praktyce wygląda to tak: pracownik łączy się z VPN i trafia do zasobów firmowych przez szyfrowany tunel, ale jednocześnie YouTube, Spotify czy Teams Video lecą bezpośrednio z jego łącza domowego, omijając koncentrator VPN.  

Decyzja o tym, który ruch idzie tunelem, opiera się na tablicy routingu zainstalowanej przez klienta VPN. W klasycznym rozwiązaniu cały ruch wypychany jest na domyślną trasę 0.0.0.0/0 przez interfejs wirtualny. Split tunneling zamiast tego wstrzykuje tylko konkretne trasy – na przykład 10.0.0.0/8 dla sieci firmowych – a reszta zostaje na lokalnej bramie. 

Split tunneling w kontekście bezpieczeństwa 

Decyzja o tym, czy stosować split tunneling czy nie, uzależniona jest od kwestii bezpieczeństwa, prywatności oraz technicznych aspektów realizacji połączenia VPN. Kiedy ruch omija tunel VPN, opuszcza kontrolowane środowisko organizacji. To nie jest teoretyczne ryzyko. To konkretna zmiana modelu zagrożeń, którą trzeba świadomie zaakceptować albo odrzucić. Przesyłanie całości ruchu przez tunel daje jedno założenie: wszystko, co wysyła stacja robocza, przechodzi przez infrastrukturę firmy. Można to monitorować, filtrować, logować. Split tunneling to założenie rozbija.  

Bezpieczeństwo zaczyna się od widoczności. Czego nie widzisz, tego nie możesz kontrolować. Przy split tunnelingu SOC traci wgląd w część aktywności użytkownika. Ruch do zewnętrznych serwisów, zapytania DNS do publicznych resolverów, połączenia z aplikacjami SaaS – to wszystko znika z radarów SIEM-a i NDR-a. W praktyce oznacza to, że jeśli stacja robocza nawiąże połączenie z infrastrukturą botnetu przez Internet, a ta komunikacja nie przechodzi przez tunel, nie zobaczysz tego w logach firewalla ani proxy. Jedynym miejscem, gdzie możesz to złapać, jest EDR bezpośrednio na endpoincie. To właśnie dlatego Microsoft Defender for Endpoint, CrowdStrike Falcon i podobne rozwiązania są przy split tunnelingu nie opcją, a koniecznością. 

DNS w kontekście split tunnelingu to temat, który jest regularnie zaniedbywany. Jeśli polityka split tunnel nie obejmuje wymuszenia firmowego DNS dla wszystkich zapytań, użytkownik wysyła zapytania do publicznych resolverów. ISP może te zapytania logować. Publiczne resolvery takie jak 8.8.8.8 budują na tej podstawie profile ruchu. Odwrotna sytuacja też jest problematyczna. Kiedy firmowy DNS dostaje zapytania o domeny zewnętrzne, wiesz, co odwiedza użytkownik. Po włączeniu split tunnelingu bez wymuszenia DNS te dane znikają z Twoich logów. 

DNS over HTTPS dodatkowo komplikuje sprawę. Przeglądarka Firefox czy Chrome z włączonym DoH może kompletnie ominąć zarówno firmowy DNS, jak i lokalne ustawienia resolverów, nawet jeśli polityka VPN stara się to wymuszać. 

Split tunneling w kontekście prywatności 

O jednym z aspektów prywatności wspomniałem przed chwilą – brak split tunnelingu powoduje, że w logach firmowych pozostaje wszystko, o co odpytywane były serwery DNS. Co więcej, pracodawca widzi cały ruch użytkownika, włącznie z aktywnością prywatną. Przeglądanie bankowości, prywatna korespondencja, zakupy online – to wszystko przechodzi przez firmowy DNS i może być logowane. A jeżeli stosowane są dodatkowe mechanizmy zaglądania do zaszyfrowanego połączenia (Man-in-the-Middle SSL Proxy), to mamy także potencjalny dostęp na firmowym proxy do danych, przesyłanych plików, loginów czy haseł.  

Z perspektywy RODO i regulacji o prywatności pracowników jest to obszar regulowany, ale w praktyce wiele organizacji loguje ruch bez szczegółowej analizy, co jest zgodne z prawem, a co nie. W przypadku komputerów służbowych najczęściej stosowane są zapisy, że pracownik nie może wykorzystywać sprzętu służbowego do celów prywatnych. A co w przypadku wystąpienia sytuacji wyjątkowej w rodzinie lub po prostu zwykłej pomyłki?  

Jeszcze bardziej czujne muszą być osoby takie jak ja, pracujące na kontraktach i ze swojego komputera, wykonujące zlecenia dla różnych podmiotów. Niedopilnowanie tego, aby split tunneling w połączeniach do sieci klientów był włączony, może powodować ujawnienie tego, dla kogo pracujemy. W takim przypadku najbezpieczniejszym rozwiązaniem zawsze będą dedykowane maszyny wirtualne tworzone na potrzeby wykonania połączeń VPN, niezbędnych do wykonania konkretnego zlecenia czy podłączenia się do zasobów klienta. 

Split tunneling chroni prywatność użytkownika, bo ruch prywatny idzie bezpośrednio przez internet. Pracodawca nie widzi, co pracownik robi poza zasobami firmowymi. To nie jest tylko etyczne – w niektórych jurysdykcjach europejskich masowe logowanie ruchu pracowników wymaga spełnienia konkretnych wymagań i poinformowania pracownika. Split tunneling naturalnie ogranicza zakres zbieranych danych. 

Są scenariusze, w których split tunneling nie powinien być rozważany. Dostęp do danych szczególnie chronionych – danych medycznych, danych płatniczych, dokumentacji niejawnej. Jeśli stacja robocza przetwarza tego typu dane, model bezpieczeństwa oparty na pełnym tunelu jest podstawą. Kolejne to środowiska z wysokimi wymaganiami compliance – PCI-DSS, HIPAA, ISO 27001 z rygorystyczną interpretacją. Audytorzy coraz częściej pytają wprost o split tunneling jako o wektor wycieku danych. Także użytkownicy z podwyższonym ryzykiem – administratorzy systemów, członkowie zarządu, osoby mające dostęp do strategicznych danych. Dla tych grup pełne tunelowanie z dodatkową warstwą inspekcji jest właściwym podejściem niezależnie od wpływu na wydajność. 

Jeśli split tunneling jest wymagany, model bezpieczeństwa musi być zbudowany wokół endpointu, a nie perymetru sieci. EDR z pełną widocznością procesów i połączeń sieciowych to podstawa. Warto też wymusić DNS split. Zapytania do domen wewnętrznych idą przez firmowy DNS, przez tunel. Reszta może iść publicznie, ale z wymuszonym resolverem, który logujesz. Na Cisco AnyConnect robisz to przez split-dns, na FortiClient przez DNS suffix mapping. Całość warto dopełnić konfiguracją Host-based firewalla, czyli tego znajdującego się na urządzeniu końcowym. Powinien on wymuszać, aby konkretne aplikacje mogły komunikować się tylko przez interfejs VPN, a inne tylko przez interfejs lokalny. Na Windowsie osiągniemy to przez Windows Firewall z regułami per-aplikacja i per-interfejs. 

Diagnozowanie problemów ze split tunnelingiem 

Najczęstszym problemem we wdrażaniu split tunnelingu są konflikty routingu. Użytkownik ma sieć domową 192.168.1.0/24, firma używa tego samego zakresu. Klient VPN instaluje trasę 192.168.1.0/24 przez tunel, użytkownik traci dostęp do routera lokalnego i drukarki. Trasa bardziej szczegółowa wygrywa, ale tu oba prefiksy są identyczne – zależy od metryki i kolejności instalacji tras. Problem mogą też stanowić trasy ręcznie skonfigurowane przez użytkownika, które kolidują z tymi „wstrzykiwanymi” przez VPN. Windows i macOS różnie traktują priorytety interfejsów i metryki. Dodatkowo, w środowiskach z NAT lub zaawansowanym routingiem po stronie firmy, ruch wychodzący przez VPN, a powracający inną ścieżką, powoduje problemy z sesjami TCP. 

Kolejnym wyzwaniem to problemy z DNS, czyli „DNS leak”. Split tunneling kieruje zapytania DNS użytkownika do jego ISP zamiast do firmowego DNS. W efekcie nie rozwiązuje on nazw wewnętrznych. Odwrotny scenariusz to „reverse DNS leak” – firmowy DNS przechwytuje zapytania, które powinny iść publicznie. Rozwiązanie to split-dns lub odpowiednia konfiguracja DNS search domain. 

W konfiguracji administratorzy bardzo często zapominają o protokole IPv6. Skonfigurowana przez nich polityka split tunneling dotyczy IPv4, a IPv6 jest pomijany. Ruch IPv6 wysyłany jest bezpośrednio, co w praktyce tworzy dziurę w polityce bezpieczeństwa.