VPN - co to jest i jak działa tunel VPN?

VPN to mechanizm tworzenia szyfrowanego tunelu między urządzeniem albo siecią a bramą VPN. Ruch jest kierowany do interfejsu tunelowego, pakiety są enkapsulowane, szyfrowane i przesyłane do pośredniego punktu, który routuje je dalej do internetu albo sieci prywatnej.

VPN zmienia trasę ruchu i punkt zaufania. Lokalna sieć i operator internetu widzą połączenie z bramą VPN, serwer docelowy zwykle widzi adres tej bramy, a operator VPN staje się elementem pośrednim w ścieżce komunikacji. Tor działa inaczej: rozdziela wiedzę o źródle i celu przez wielohopowy obwód w sieci onion routing.

Co to jest VPN?

VPN, czyli Virtual Private Network, to logiczna sieć prywatna tworzona przez cudzą albo publiczną infrastrukturę. Nie jest to wyłącznie aplikacja z przyciskiem „connect”, lecz zestaw mechanizmów: interfejs tunelowy, routing, szyfrowanie, brama VPN, DNS, polityka tras i reguły dostępu.

Klient VPN tworzy w systemie dodatkowy interfejs sieciowy. System operacyjny decyduje, które pakiety mają trafić do tego interfejsu, a które mają wyjść zwykłą trasą. O tej decyzji przesądza tablica routingu, konfiguracja klienta i tryb pracy: full tunnel albo split tunnel.

W typowym scenariuszu brama VPN odbiera zaszyfrowany ruch od klienta, odszyfrowuje pakiet wewnętrzny i przekazuje go dalej. Jeśli celem jest internet, serwer docelowy widzi zwykle adres bramy VPN. Jeśli celem jest sieć firmowa, VPN działa jako kontrolowany punkt wejścia do prywatnej infrastruktury.

Jak działa tunel VPN?

Rdzeniem VPN jest tunel. Oryginalny pakiet danych zostaje opakowany w dodatkowy pakiet zewnętrzny, zaszyfrowany i przesłany do bramy VPN. Taki mechanizm opisuje też pojęcie tunelu VPN: pakiet wewnętrzny nie idzie bezpośrednio do celu, tylko przechodzi przez warstwę transportu, enkapsulacji i szyfrowania.

Etap	Co się dzieje?	Co to zmienia?
Aplikacja tworzy pakiet	Program generuje ruch TCP, UDP albo inny ruch IP do serwera.	Aplikacja nie musi wiedzieć, że pakiet zostanie wysłany przez VPN.
System sprawdza routing	Tablica tras decyduje, czy pakiet trafi do tunelu, czy zwykłą drogą.	Tu rozstrzyga się full tunnel, split tunnel i wyjątki tras.
Klient enkapsuluje pakiet	Pakiet wewnętrzny dostaje zewnętrzne opakowanie tunelu.	Rośnie narzut nagłówków i spada efektywne MTU.
Klient szyfruje ruch	Pakiet tunelowy jest chroniony kryptograficznie.	Lokalna sieć nie widzi treści pakietu wewnętrznego.
Brama VPN routuje dalej	Brama odszyfrowuje pakiet i przekazuje go do celu.	Serwer docelowy widzi adres bramy VPN.

Ten sam mechanizm może służyć do wyjścia do internetu albo do dostępu do sieci prywatnej. Różnica leży w polityce tras: tunel może przejąć cały ruch domyślny albo tylko ruch do wybranych podsieci, usług i aplikacji.

VPN a routing: full tunnel, split tunnel i wyjątki tras

Ikona „VPN connected” nie oznacza automatycznie, że każdy pakiet w systemie przechodzi przez tunel. Decydują o tym trasy, wyjątki lokalne, polityka klienta VPN, DNS i moment zestawienia połączenia.

Tryb	Co idzie przez VPN?	Co idzie poza VPN?	Główne ryzyko
Full tunnel	Domyślnie cały ruch IP.	Wyjątki techniczne, lokalne trasy, czasem captive portal.	Błędne wyjątki tras albo wyciek przed pełnym zestawieniem tunelu.
Split tunnel po IP	Wybrane podsieci, np. firmowe zakresy adresów.	Reszta internetu.	Ruch spoza zdefiniowanych tras nie jest objęty tunelem.
Split tunnel po aplikacji	Wybrane programy albo procesy.	Pozostałe aplikacje.	Trudna kontrola DNS, WebRTC, proxy i ruchu pomocniczego.
Start VPN / captive portal	Ruch po pełnym zestawieniu tunelu.	Ruch potrzebny do logowania Wi-Fi albo wykrywania sieci.	Pakiety mogą wyjść przed uruchomieniem polityki VPN.

Ataki opisane jako TunnelCrack pokazały, że wyjątki w tablicach routingu mogą być użyte do omijania tunelu. To nie jest problem hasła „VPN” jako takiego, tylko konkretnej logiki tras, priorytetów interfejsów i reguł klienta.

Co widzi ISP, operator VPN, sieć lokalna i serwer docelowy?

VPN zmienia widoczność ruchu, ale nie usuwa metadanych z całego łańcucha komunikacji. Każdy obserwator znajduje się w innym miejscu ścieżki i widzi inny fragment połączenia.

Obserwator	Co zwykle widzi przy VPN?	Czego nie widzi, jeśli tunel działa poprawnie?
Lokalna sieć Wi-Fi	Połączenie do bramy VPN, czas, wolumen i metadane transmisji.	Treści pakietów wewnątrz tunelu.
ISP	Adres bramy VPN, czas połączenia i ilość przesyłanych danych.	Docelowe adresy i zapytania DNS, jeśli nie wychodzą poza tunel.
Operator VPN	Adres klienta, czas połączenia, wolumen, potencjalnie DNS i metadane ruchu.	Treści HTTPS, jeśli aplikacja używa poprawnego szyfrowania end-to-end.
Serwer docelowy	Adres wyjściowy bramy VPN i zachowanie aplikacji.	Bezpośredni adres IP klienta, jeśli nie ma wycieku.
Strona WWW	Konto, cookies, fingerprint przeglądarki, JavaScript, WebRTC.	Nie jest ograniczona wyłącznie do adresu IP.

Najważniejsza zmiana polega na przesunięciu zaufania. Bez VPN więcej metadanych widzi lokalna sieć i ISP. Z VPN część tej widoczności przejmuje operator bramy.

Protokoły VPN: WireGuard, OpenVPN, IPsec/IKEv2

Protokoły VPN różnią się architekturą, sposobem negocjacji kluczy, transportem i modelem routingu. Nie warto opisywać ich tylko jako „szybszy” albo „bezpieczniejszy”, bo o zachowaniu tunelu decydują także trasy, DNS, MTU, firewall i polityka dostępu.

Protokół	Model	Warstwa / transport	Co warto wiedzieć?
WireGuard	Peer-to-peer, cryptokey routing.	Zwykle UDP.	Prosty model peerów, kluczy publicznych i AllowedIPs.
OpenVPN	Tunel oparty o TLS.	UDP albo TCP.	Rozdziela kanał kontrolny i kanał danych.
IPsec/IKEv2	Architektura IPsec + negocjacja IKE.	ESP/IKE na warstwie IP.	Security Associations, SPD/SAD, tryb transportowy i tunelowy.
L2TP/IPsec	L2TP chroniony przez IPsec.	UDP/IPsec.	Starszy wariant, nadal spotykany w części środowisk.
PPTP	PPP/GRE.	GRE/TCP.	Historyczny protokół, którego nie należy traktować jako bezpiecznego wyboru.

WireGuard: AllowedIPs i cryptokey routing

WireGuard opisuje połączenia przez peerów. Peer jest powiązany z kluczem publicznym, endpointem i listą AllowedIPs. Ta lista nie jest tylko opisem „dozwolonych adresów”; pełni też funkcję wyboru peera dla ruchu wychodzącego.

Jeżeli przy peerze znajduje się 0.0.0.0/0, klient może potraktować go jako domyślną trasę dla IPv4. Analogicznie ::/0 dotyczy IPv6. W konfiguracji site-to-site AllowedIPs mogą wskazywać konkretne podsieci za drugą bramą, np. 10.10.0.0/16.

AllowedIPs działa również jako kontrola przy ruchu przychodzącym: pakiet od danego peera powinien mieć źródłowy adres zgodny z zakresem przypisanym temu peerowi. Błędna konfiguracja może dać brak routingu, zbyt szeroki tunel albo konflikt z lokalną siecią.

OpenVPN: kanał kontrolny i kanał danych

OpenVPN rozdziela kanał kontrolny i kanał danych. Kanał kontrolny odpowiada za uwierzytelnienie, negocjację parametrów, wymianę kluczy i konfigurację sesji. Kanał danych przenosi właściwe pakiety tunelu.

OpenVPN może działać przez UDP albo TCP. UDP jest częsty dla tuneli, bo pozwala uniknąć nakładania mechanizmów kontroli TCP na drugi tunel TCP. TCP bywa używany wtedy, gdy sieć przepuszcza tylko wybrane porty albo ruch podobny do HTTPS, ale przy stratach pakietów może pogarszać zachowanie transmisji.

IPsec/IKEv2: SA, ESP i tryb tunelowy

IPsec jest architekturą ochrony ruchu na warstwie IP. IKE odpowiada za negocjację parametrów i kluczy, a ESP chroni pakiety. Zamiast jednego prostego „połączenia VPN” pojawiają się polityki bezpieczeństwa, Security Associations oraz bazy SPD i SAD.

W trybie tunelowym cały wewnętrzny pakiet IP zostaje chroniony i opakowany w zewnętrzny pakiet IP. To odróżnia tryb tunelowy od transportowego, w którym chroniona jest komunikacja między końcowymi hostami. W VPN-ach site-to-site tryb tunelowy jest naturalnym wyborem, bo bramy łączą całe podsieci.

DNS leak, split DNS, IPv6 leak i WebRTC leak

DNS nie musi iść tą samą trasą co reszta ruchu. Jeśli zapytania o domeny wychodzą do lokalnego resolvera zamiast do resolvera przypisanego przez VPN, powstaje DNS leak. Split DNS może być celową konfiguracją, np. gdy domeny firmowe są rozwiązywane przez DNS VPN, a reszta przez zwykły resolver.

W Windows istotne są NRPT i Smart Multi-Homed Name Resolution. NRPT pozwala wymuszać reguły rozwiązywania nazw dla określonych przestrzeni nazw, np. domen firmowych. Smart Multi-Homed Name Resolution może natomiast odpytywać wiele interfejsów, aby szybciej uzyskać odpowiedź, co przy złej konfiguracji VPN sprzyja wyciekom zapytań DNS poza tunel.

IPv6 leak to osobny problem. Jeżeli tunel obejmuje tylko IPv4, a system nadal ma natywną łączność IPv6, część ruchu może wyjść poza VPN. W środowisku dual-stack trzeba kontrolować zarówno trasy IPv4, jak i IPv6, zamiast zakładać, że tunel IPv4 automatycznie obejmuje cały ruch.

WebRTC leak pochodzi z warstwy aplikacyjnej. Przeglądarka może ujawniać adresy sieciowe przez mechanizmy WebRTC/ICE, niezależnie od tego, że sam tunel VPN działa poprawnie na poziomie IP.

MTU, MSS i fragmentacja w VPN

Tunel VPN dodaje nagłówki i dane kryptograficzne. Pakiet wewnętrzny musi zmieścić się w pakiecie zewnętrznym, więc efektywne MTU po stronie tunelu jest mniejsze niż na zwykłym interfejsie sieciowym.

Źle dobrane MTU daje charakterystyczne objawy: ping działa, ale strony ładują się częściowo; SSH się łączy, ale większy transfer zawiesza; małe zapytania przechodzą, a większe odpowiedzi znikają. Problem dotyczy głównie większych pakietów, bo to one przekraczają realny limit ścieżki.

Path MTU Discovery próbuje ustalić największy rozmiar pakietu dla danej ścieżki. Jeśli komunikaty ICMP są blokowane, może powstać black-hole MTU: pakiety są za duże, ale nadawca nie dostaje poprawnej informacji, że powinien je zmniejszyć. W ruchu TCP często pomaga MSS clamping, czyli ograniczenie rozmiaru segmentów tak, żeby nie wymuszać fragmentacji w tunelu.

VPN a firewall, kill switch i dostęp do sieci firmowej

VPN daje łączność, ale nie zastępuje kontroli dostępu. Po zestawieniu tunelu użytkownik może znaleźć się logicznie bliżej sieci firmowej, dlatego o realnym zakresie dostępu decydują reguły firewalla, ACL, segmentacja, MFA i polityka urządzeń końcowych.

Kill switch jest szczególnym przypadkiem takiej polityki. Technicznie powinien działać jak zestaw reguł blokujących ruch na fizycznym interfejsie, np. eth0 albo wlan0, jeśli celem nie jest adres IP bramy VPN albo ruch nie wychodzi przez interfejs tunelowy. Dzięki temu po zerwaniu tunelu pakiety nie wracają automatycznie na zwykłą trasę domyślną.

Błędny model to „kto ma VPN, ten ma dostęp do wszystkiego”. Lepszy model to dostęp tylko do konkretnych podsieci, usług i portów, zgodnie z rolą użytkownika. Sam tunel jest kanałem transportu, nie kompletną polityką bezpieczeństwa.

VPN a Tor — dwa różne modele prywatności

VPN i Tor rozwiązują inne problemy. VPN tworzy tunel do jednej bramy, a Tor buduje wielohopowy obwód w sieci przekaźników. W VPN punkt zaufania skupia się u operatora bramy. W Tor wiedza o źródle i celu ma być rozdzielona między różne relay’e.

Cecha	VPN	Tor
Model	Tunel do jednej bramy.	Wielohopowa sieć overlay.
Punkt zaufania	Operator VPN.	Rozdzielenie wiedzy między relayami.
Adres widoczny dla celu	IP bramy VPN.	IP exit relay.
Wydajność	Zwykle wyższa.	Zwykle niższa.
Główny cel	Tunel, routing, dostęp zdalny.	Anonimizacja źródła ruchu.
Typowy klient	Klient systemowy albo aplikacja VPN.	Tor Browser albo Tor daemon.

Jak działa obwód Tor?

Tor buduje obwód przez kilka przekaźników. Warstwowe szyfrowanie sprawia, że każdy relay zna tylko sąsiedni element ścieżki, a nie całą trasę od użytkownika do serwera docelowego.

Element	Rola	Co wie?	Czego nie powinien wiedzieć samodzielnie?
Guard / entry relay	Pierwszy przekaźnik w obwodzie.	Adres IP użytkownika.	Docelowego serwera.
Middle relay	Przekaźnik pośredni.	Poprzedni i następny hop.	Źródła i celu jednocześnie.
Exit relay	Wyjście z sieci Tor do internetu.	Cel połączenia.	Prawdziwego IP użytkownika.
Serwer docelowy	Odbiorca ruchu.	Adres IP exit relay.	Adresu IP użytkownika, jeśli nie ma innego wycieku.

Exit relay jest szczególnie ważny. Jeśli aplikacja nie używa szyfrowania end-to-end, exit może obserwować nieszyfrowaną treść wychodzącą z Tora. Dlatego Tor nie zastępuje HTTPS ani poprawnej kryptografii aplikacyjnej.

Ograniczenia Tora: exit node, timing i routing attacks

Tor nie usuwa wszystkich metadanych. Silny obserwator może analizować czas, kierunek i rozmiary ruchu. Badania nad atakami routingowymi pokazują też, że poziom AS/BGP może mieć znaczenie dla prywatności obwodów Tor.

Tor nie ukrywa również samego faktu łączenia się z siecią Tor przed każdym obserwatorem. Jeśli ktoś widzi połączenie do publicznych relayów, może rozpoznać użycie Tora, choć nie musi znać celu komunikacji.

Tor przez VPN i VPN przez Tor

Tor standalone oznacza połączenie bezpośrednio z guard relay albo bridge. W układzie Tor over VPN użytkownik najpierw zestawia VPN, a dopiero potem uruchamia Tora. ISP widzi wtedy połączenie do VPN, operator VPN widzi połączenie klienta z siecią Tor, a Tor buduje własny obwód.

VPN over Tor odwraca kolejność: ruch VPN próbuje przejść przez sieć Tor. To rzadszy i trudniejszy model, który łatwo źle skonfigurować. Nie należy traktować połączenia VPN + Tor jako automatycznego wzmocnienia prywatności, bo kolejność warstw zmienia punkt zaufania, widoczność metadanych i możliwe błędy aplikacji.

Czy VPN zapewnia anonimowość?

VPN może ukryć treść ruchu przed lokalną siecią, zmienić adres IP widoczny dla serwera i zapewnić dostęp do prywatnej sieci. Nie usuwa jednak cookies, logowania na konto, fingerprintingu przeglądarki, telemetrii aplikacji, metadanych czasowych ani zaufania do operatora bramy VPN.

To, czy VPN rozwiązuje dany problem, zależy od modelu zagrożeń. Dla pracownika łączącego się z siecią firmową istotne są dostęp, firewall i segmentacja. Dla użytkownika obawiającego się lokalnej sieci ważny jest tunel do bramy. Dla scenariuszy wymagających rozdzielenia wiedzy o źródle i celu właściwszym punktem odniesienia jest Tor.

Podsumowanie

VPN to tunel, routing i brama pośrednia. Daje określone własności techniczne: szyfrowanie ruchu między klientem a bramą, zmianę trasy, dostęp do sieci prywatnej i zmianę adresu widocznego dla serwera docelowego.

Tor to inny model: wielohopowa sieć onion routing, która rozdziela wiedzę o źródle i celu. Bez określenia modelu zagrożeń nie da się uczciwie powiedzieć, czy właściwszy jest VPN, Tor, oba mechanizmy razem, czy zupełnie inna kontrola bezpieczeństwa.