Zerwanie sesji VPN, throttling i blokady portów: sposoby obchodzenia ograniczeń operatorów

Jak operator „widzi” ruch VPN i skąd biorą się blokady

Co ISP faktycznie widzi w twoim ruchu

Szyfrowanie VPN ukrywa treść, ale nie zmienia faktu, że pakiety muszą przejść przez infrastrukturę operatora. Dostawca internetu (ISP) widzi otoczkę każdej transmisji, czyli metadane. I właśnie na podstawie tych metadanych wykrywa i ogranicza ruch VPN.

Typowo operator ma dostęp do takich informacji o twoim ruchu:

• Adres IP źródłowy i docelowy – wie, z jakiego twojego IP wychodzisz i do jakiego IP się łączysz (np. IP serwera VPN).
• Port źródłowy i docelowy – np. 1194/UDP dla OpenVPN, 500/UDP i 4500/UDP dla IPsec, 443/TCP dla ruchu TLS/HTTPS.
• Protokół transportowy – TCP, UDP, czasem ICMP; sam wybór protokołu bywa już sygnałem dla systemów wykrywania.
• Rozmiar pakietów – powtarzalne rozmiary, częste pakiety keep-alive, duże pakiety danych; to tworzy charakterystyczny fingerprint ruchu.
• Timing i kierunek – ile pakietów w jednostce czasu, w którą stronę przeważnie płynie ruch, jak wygląda rytm sesji.

Jeżeli nie używasz VPN i wchodzisz na klasyczne strony HTTPS, operator często widzi także SNI (Server Name Indication) w TLS – nazwę hosta, który odwiedzasz, np. example.com. Przy części metod obfuskacji VPN i przy niektórych implementacjach tunelowania przez TLS, SNI może wyglądać „dziwnie” lub wcale się nie pojawiać, co również jest sygnałem, że coś jest ukrywane.

Różnica między „treścią a wzorcem” jest kluczowa: operator nie wie, co konkretnie robisz wewnątrz VPN, ale dość łatwo zgaduje, że korzystasz z VPN. Dla wielu polityk to w zupełności wystarczy, żeby:

• oznaczyć połączenie jako „nieznane szyfrowanie” i nadać mu niższy priorytet,
• włączyć reguły throttlingu dla całego ruchu do danego IP lub o danej charakterystyce,
• całkowicie blokować niektóre sygnatury protokołów VPN.

Mechanizmy kontroli: QoS, throttling, DPI, blokady portów

Nowocześni operatorzy korzystają z kombinacji kilku warstw kontroli ruchu. Najprostszy, ale ciągle spotykany sposób to blokady portów. Przykład: port 1194/UDP lub 1723/TCP (PPTP) jest w części sieci mobilnych po prostu zamknięty na wyjściu. VPN nawet nie zaczyna handshaku – połączenie nie dochodzi do skutku.

Krok wyżej jest QoS i throttling. Operator może:

• przydzielać różne klasy ruchu – np. streaming wideo, VoIP, ruch HTTP/HTTPS, gry, „inne szyfrowanie”,
• ustawiać limity prędkości dla każdej klasy, np. 100 Mb/s dla standardowego HTTP, 10–20 Mb/s dla „niezidentyfikowanego szyfrowania”,
• degradować priorytet pakietów VPN w stanie przeciążenia sieci (szczególnie w sieciach mobilnych).

Najbardziej zaawansowany mechanizm to DPI – Deep Packet Inspection. Nie chodzi tu o łamanie szyfrowania, tylko o analizę nagłówków, sekwencji pakietów i ich zachowania. DPI potrafi:

• rozpoznać charakterystyczne handshaki OpenVPN, WireGuard, IPsec,
• zidentyfikować „dziwne” protokoły tunelowania (np. SSH tunneling, tunelowanie w DNS),
• wstrzykiwać resetujące pakiety (RST), zmieniać parametry, opóźniać lub „kroić” sesje.

DPI bywa używane nie tylko przez rządy w krajach z cenzurą. Wykorzystują je także komercyjni operatorzy do:

• egzekwowania polityk „fair use” w mobilnym internecie,
• ochrony przed DDoS i innymi nadużyciami,
• optymalizacji ruchu streamingowego (np. preferowanie popularnych platform).

Różnice między sieciami mobilnymi, stacjonarnymi i korporacyjnymi

Zachowanie wobec VPN mocno zależy od typu sieci. Sieci mobilne są zwykle najbardziej agresywne, bo mają ograniczoną przepustowość radiową i silną presję na zarządzanie ruchem. Typowe zjawiska:

• blokady portów używanych przez najpopularniejsze protokoły VPN,
• limitowanie ruchu szyfrowanego ponad standardowe HTTPS,
• ostrzejsze reguły w roamingu, szczególnie gdy działa polityka „nielimitowany internet”, ale z zastrzeżeniami w regulaminie.

Wielu użytkowników zauważa, że na mobilnym „nielimitowanym internecie” streaming z oficjalnych aplikacji (np. operatora, popularnych VOD) działa pełną prędkością, ale po włączeniu VPN do tych samych usług prędkość spada drastycznie. Różnica wynika z tego, że operator priorytetyzuje konkretną kategorię ruchu, a VPN „maskuje” ją jako ogólne szyfrowanie.

Łącza stacjonarne (światłowód, kabel) zazwyczaj są łagodniejsze, ale też napiętnują ruch VPN, gdy:

• klient masowo korzysta z P2P przez VPN i generuje stałe, wysokie obciążenie,
• wykorzystywany jest „internet domowy” do zastosowań pół-biznesowych, np. hostowanie wielu tuneli,
• polityka FUP (fair usage policy) odsiewa długotrwały, stały ruch szyfrowany.

Sieci korporacyjne i uczelniane często idą jeszcze dalej: wprost blokują cały ruch VPN, poza tym, który same udostępniają (np. własny IPsec do pracy zdalnej). Tu częściej pojawia się:

• pełne DPI z blokowaniem sygnatur znanych protokołów VPN,
• ścisłe reguły firewall z zakazem połączeń wychodzących do „nieznanych” adresów zagranicznych,
• monitoring anomalii – np. ostrzeżenia przy długich sesjach TCP trwających wiele godzin.

Wspólny mianownik: operator nie musi wiedzieć, co robisz w VPN. Wystarczy, że przypisze cię do klasy „tunel szyfrowany”, dla której zasady są mniej korzystne niż dla zwykłego ruchu HTTP/HTTPS.

Najczęstsze objawy problemów z VPN: jak rozpoznać, że to wina operatora

Zerwanie sesji, timeouty, dziwne restarty tunelu

Często powtarzające się rozłączenia to klasyczny sygnał, że coś po drodze „nie lubi” twojego VPN, ale nie zawsze oznacza to złą wolę operatora. Najpierw trzeba odróżnić problemy po stronie serwera, klienta i infrastruktury od celowego ograniczania sesji.

Charakterystyczne symptomy wskazujące na politykę ISP, a nie losową niestabilność:

• Cykliczne rozłączenia po stałym czasie, np. co 30 lub 60 minut, mimo dobrego zasięgu i braku obciążenia – to wygląda jak limit czasu sesji.
• Po rozłączeniu natychmiastowy brak możliwości zestawienia tunelu przez kilka–kilkanaście minut, potem nagła poprawa.
• Zerwanie sesji dokładnie przy przejściu w roaming lub z LTE na 3G/5G – nowa polityka po stronie sieci.

Dla porównania, problemy typowo po stronie serwera VPN lub internetu docelowego wyglądają inaczej:

• rozłączanie wielu użytkowników na raz (jeśli masz tę informację),
• brak odpowiedzi ping do serwera VPN nawet spoza twojej sieci,
• stabilne połączenie na innych serwerach tego samego operatora VPN.

Prosty test: po nieplanowanym rozłączeniu spróbuj szybko połączyć się z innym serwerem VPN:

• jeśli każdy serwer odrzuca połączenie – możliwe blokowanie całego ruchu VPN na poziomie ISP,
• jeśli problem dotyczy tylko jednego IP – częściej wada tego konkretnego serwera lub trasy do niego.

Drastyczny spadek prędkości tylko na VPN

Najbardziej drażniący objaw: bez VPN masz 100 Mb/s, z VPN – 5 Mb/s albo mniej. Tu pojawia się pokusa, by wszystko zrzucić na „throttling”, ale przyczyny bywają zaskakująco przyziemne. Trzeba przeprowadzić sensowne testy porównawcze.

Najpierw wyeliminuj klasyczne problemy lokalne:

• przetestuj połączenie na kablu, a nie na zatłoczonym Wi‑Fi,
• sprawdź prędkość na innym urządzeniu (telefon, laptop) z tym samym VPN,
• zrestartuj router – niektóre modele po dłuższym czasie pracy zaczynają „dusić” ruch szyfrowany przez słabe CPU.

Jeśli różnica między „gołym” łączem a VPN-em utrzymuje się przy różnych urządzeniach, porównaj zachowanie różnych serwerów i portów:

• serwer VPN w tym samym kraju kontra serwer za granicą,
• UDP vs TCP, różne porty (np. 443, 80, 53),
• różne protokoły (OpenVPN, WireGuard, IKEv2), jeśli masz wybór.

Gdy wszystkie serwery, protokoły i porty danego dostawcy VPN dają podobnie kiepski wynik, a inna sieć (np. internet z telefonu jako hotspot) pozwala na pełną prędkość z tym samym VPN, scenariusz „ISP narzuca throttling na ruch VPN” staje się bardzo prawdopodobny.

Dobrym, praktycznym testem jest też porównanie:

1. speedtest bez VPN do serwera możliwie blisko twojego operatora,
2. speedtest z VPN w tym samym kraju (nie zagranica),
3. download pliku testowego (np. z FTP lub HTTP) z i bez VPN na ten sam host.

Jeśli różnica jest dramatyczna na każdym z tych scenariuszy, a dodatkowo pingi rosną tylko po włączeniu VPN, problem ma charakter sieciowy, nie aplikacyjny.

Selektywne blokady: działa HTTP, padają gry i P2P

Częsty przypadek, szczególnie w sieciach mobilnych i korporacyjnych: VPN sam w sobie zestawia się poprawnie, strony WWW po HTTPS w przeglądarce działają, ale:

• gry online mają gigantyczne lagi albo w ogóle nie startują,
• aplikacje P2P nie widzą zewnętrznych peerów,
• wideokonferencje przez UDP (np. WebRTC, niektóre komunikatory) są praktycznie nieużywalne.

To wskazuje, że operator:

• ogranicza ruch o określonym wzorcu (stałe, intensywne sesje P2P),
• ma reguły przeciwko ruchowi UDP z dużym wolumenem,
• priorytetyzuje klasyczny ruch przeglądarkowy kosztem reszty.

Dobrym sposobem na diagnozę jest użycie prostego zestawu narzędzi: ping, traceroute (lub tracert) oraz testy portów. Przydatna jest checklista:

• ping do tego samego hosta z i bez VPN – porównaj opóźnienie i procent utraconych pakietów,
• traceroute z i bez VPN – sprawdź, czy różnica pojawia się już w twojej sieci, czy dopiero „dalej”,
• test połączenia UDP (np. narzędziami typu iperf z and bez VPN), jeśli masz dostęp do serwera testowego.

Selektywny throttling bywa „sprytny”: operator ogranicza segmenty ruchu rozpoznane jako gry czy P2P już w tunelu VPN, mimo że nie widzi treści. Wzorce pakietów są na tyle charakterystyczne, że DPI radzi sobie bez znajomości szczegółów.

Popularne porady z forów, które zawodzą w praktyce

„Zmień port na 443 i po sprawie”

Porada, która pojawia się niemal zawsze: „jak masz blokady VPN, przerzuć się na port 443, przecież to HTTPS, operator nie może go zamknąć”. Brzmi rozsądnie, ale w praktyce jest tylko częściowo prawdziwe.

Rzeczywiście, port 443/TCP jest krytyczny dla normalnego działania internetu i całkowita blokada byłaby radykalnym posunięciem. Tyle że:

• ruch VPN na 443 wcale nie wygląda jak zwykły HTTPS – handshake, sekwencja pakietów, brak SNI, inne długości pakietów, brak typowych wzorców HTTP/2, HTTP/3,
• DPI analizuje zachowanie sesji, a nie sam numer portu – port 443 nie jest świętym graalem.

W wielu krajach o silnej cenzurze ruch OpenVPN na 443 jest wykrywany i blokowany dokładnie tak samo jak na 1194/UDP. Proste przerzucenie portu bez zmiany charakterystyki ruchu nie robi większego wrażenia na nowocześniejszych rozwiązaniach.

Port 443 ma sens wtedy, gdy:

• przenosisz na niego VPN z warstwą TLS, który dobrze udaje zwykły HTTPS (np. OpenVPN over TLS z odpowiednimi opcjami, niektóre implementacje obfuskacji),
• operator nie stosuje dokładnego DPI, tylko proste reguły na porty i limity klas ruchu.

„Przełącz z UDP na TCP, będzie stabilniej”

Druga klasyka: jeśli VPN się rwie albo coś nie działa, „zmień protokół na TCP, bo jest pewniejszy”. W pewnych, bardzo konkretnych warunkach to się sprawdza, ale jako uniwersalna recepta potrafi bardziej zaszkodzić niż pomóc.

Kiedy przełączenie na TCP ma sens:

• operator <strongaktywnie filtruje UDP lub mocno je degraduje (gry, VoIP, P2P),
• masz tunel VPN przez sieć o dużym jitterze i utracie pakietów, a ruch wewnątrz tunelu i tak jest głównie TCP (WWW, poczta),
• VPN służy do krótkich, sporadycznych sesji – przeglądanie stron, logowanie do paneli, a nie do długich downloadów.

W takich scenariuszach TCP:
VPN (TCP) → Internet (TCP)
nie zabija jeszcze wydajności, a zyskujesz lepszą „przewidywalność” sesji. Niektóre sieci mobilne traktują TCP „delikatniej” niż UDP, bo pod większość aplikacji biznesowych wciąż podstawą jest TCP.

Problem zaczyna się przy intensywnym ruchu, zwłaszcza przy pobieraniu dużych plików, streamingu czy synchronizacji w chmurze. Pojawia się wtedy zjawisko TCP-over-TCP meltdown:

• wewnętrzna sesja TCP (np. przeglądarka → serwer) ma własny mechanizm kontroli przeciążeń i retransmisji,
• zewnętrzna sesja TCP (tunel VPN) ma drugi taki mechanizm,
• oba reagują na utracone pakiety i spadki, nakładając się i dramatycznie obniżając prędkość.

Efekt w praktyce: download, który na UDP w VPN leciałby 30 Mb/s, na TCP „dusi się” do kilku Mb/s przy tych samych warunkach radiowych, bo oba poziomy TCP cofają okno wysyłki.

Jeśli sieć mobilna „tnie” UDP na amen, a VPN w ogóle nie wstaje, przełączenie na TCP bywa jedyną realną opcją. Natomiast w sieci stacjonarnej, gdzie UDP przechodzi, wymuszanie TCP jako domyślnego ustawienia tylko dlatego, że „stabilniej”, zwykle jest krokiem w tył.

„Wystarczy zmienić serwer na bliższy”

Argument „im bliżej, tym lepiej” jest intuicyjny, ale w przypadku VPN i ingerencji operatora bliższy serwer niekoniecznie coś zmienia. Trasa logiczna pakietów przez sieć ISP bywa bardziej skomplikowana niż zwykłe „odległość w kilometrach”.

Są sytuacje, w których zmiana serwera na lokalny (kraj / ten sam AS) faktycznie przynosi poprawę:

• główne „wąskie gardło” leży za granicą (przepustowość łączy międzynarodowych, przeciążone trasy tranzytowe),
• VPN korzysta z peeringu bezpośrednio z twoim operatorem, co skraca ścieżkę,
• operator nie prowadzi specyficznej polityki anty-VPN, tylko oszczędza pasmo na wyjściach międzynarodowych.

Ale jeśli ISP throttluje kategorię ruchu „szyfrowany tunel” bez względu na adres docelowy, wybór serwera „najbliżej” nic nie zmienia. Wszystko i tak przechodzi przez te same rutery brzegowe, na których stoją reguły QoS i DPI.

Spotykany w praktyce paradoks: serwer VPN w innym kraju potrafi działać szybciej niż „lokalny”, bo:

• ma lepszą trasę do danego serwisu (np. platforma VOD, gra),
• współdzieli inny upstream, mniej przeciążony niż krajowy,
• nie wpada w tę samą klasę ruchu u operatora (np. inny port, inny typ tunelu).

Zmienianie serwerów „na chybił trafił” to w rezultacie strata czasu. Sens ma systematyczny test: kilka serwerów krajowych + kilka zagranicznych, o różnych protokołach, zmierzone w tych samych warunkach (pora dnia, to samo urządzenie, ta sama aplikacja). Dopiero potem można stwierdzić, czy „bliżej” naprawdę znaczy „lepiej” w twojej konfiguracji.

„Po prostu zmień dostawcę VPN, ten jest słaby”

Zmiana dostawcy bywa kuszącym skrótem myślowym: jak coś nie działa, na pewno „wina VPN”. Tymczasem coraz częściej to operator ma bardziej agresywną politykę niż kiedyś, a różni dostawcy VPN korzystają z tych samych upstreamów i są filtrowani identycznie.

Kiedy zmiana dostawcy VPN rzeczywiście pomaga:

• obecny dostawca ma słabą infrastrukturę w twoim regionie (za mało serwerów, przeciążone węzły),
• nie wspiera nowoczesnych metod obfuskacji lub „stealth VPN”,
• wykorzystuje adresacje IP znane i oznaczone przez ISP jako „VPN komercyjny” i wrzucane do gorszej klasy QoS.

Jeśli nowy dostawca oferuje inne protokoły (np. WireGuard, własne obfuskowane transporty, OpenVPN-over-HTTPS z realnym maskowaniem), szansa na poprawę jest konkretna. Gdy jednak dostawcy ograniczają się do tych samych „gołych” OpenVPN/WireGuard na standardowych portach, operator potraktuje ich praktycznie tak samo.

Zanim zainwestujesz w kolejny abonament, ma sens zrobienie krótkich testów na wersjach trial lub darmowych planach, ale nie na poziomie „sprawdzę, czy się łączy”, tylko:

• porównanie prędkości z i bez VPN w kilku godzinach dnia,
• sprawdzenie, czy nowy dostawca ma profile „stealth”, „obfuscated”, „TCP over TLS” i jak się zachowują,
• test kluczowych dla ciebie usług (gry, VOD, VoIP) pod kątem opóźnień i stabilności.

Jeżeli wszystkie testowane usługi VPN (różni dostawcy) na twoim łączu zachowują się tak samo źle, przy czym na innym łączu (np. hotspot z telefonu) działają bez problemu, źródło kłopotów jest dość oczywiste – polityka twojego ISP, a nie marka VPN.

Techniczne podstawy: które protokoły VPN są łatwe, a które trudne do blokowania

OpenVPN: klasyk, którego sygnaturę widać z daleka

OpenVPN to wciąż fundament wielu komercyjnych usług, ale z perspektywy operatora jest wdzięcznym celem. Jego ruch ma dość charakterystyczny handshake i przewidywalne wzorce pakietów, co sprawia, że przy braku obfuskacji DPI wyłapuje go bez większego wysiłku.

OpenVPN w trybie:

• UDP – mniej odporny na filtrację (łatwo go przycinać i zrzucać na zasadzie polityki dla UDP), ale szybki tam, gdzie jest „spokój”,
• TCP – nieco trudniejszy do przykręcenia samym filtrowaniem portów, ale nadal odróżnialny od typowego HTTPS.

Operator może:

• po sygnaturze TLS OpenVPN (brak SNI, nietypowe zestawy szyfrów, stały kierunek ruchu klient → serwer),
• po długościach i częstotliwości pakietów,
• po kombinacji: port + brak klasycznych cech HTTP/2/HTTP/3.

Dopiero dodanie warstwy obfuskacji (np. stunnel, obfsproxy, XOR, custom TLS) utrudnia rozpoznanie. Część usług VPN oferuje to jako osobne profile „stealth” czy „obfuscated”, ale często kosztem dodatkowego narzutu na CPU serwera i klienta.

WireGuard: nowoczesny, szybki, ale też rozpoznawalny

WireGuard zyskał popularność dzięki prostocie i wydajności. Na wielu łączach daje wyraźnie lepsze osiągi niż OpenVPN, zwłaszcza na słabym sprzęcie (routery z niskim CPU, telefony). Nie jest jednak „magicznie niewidzialny”.

Z perspektywy DPI, standardowy WireGuard:

• działa domyślnie po UDP na jednym porcie,
• ma specyficzne nagłówki i stałe długości pierwszych pakietów,
• utrzymuje względnie stały wzorzec keepalive.

To wystarcza, by systemy klasy operatorskiej rozpoznawały i klasyfikowały WireGuard jako oddzielny typ tunelu. W wielu sieciach mobilnych testy pokazują, że po krótkim czasie sesji pakiety WireGuard zaczynają być opóźniane lub ograniczane do określonej przepustowości.

Plus jest taki, że WireGuard dobrze znosi gorsze warunki radiowe i ma niski narzut protokołowy. Jeśli operator jeszcze nie wdrożył aktywnego DPI względem WireGuard, ten protokół potrafi „wycisnąć” maksimum z problematycznego LTE czy 5G. Gdy jednak polityka zostanie zaostrzona, sama zmiana OpenVPN → WireGuard nie zdziała cudów.

IPsec/IKEv2: stary koń roboczy, często w roli „ruchu korporacyjnego”

IPsec w trybie IKEv2 to ulubieniec wielu administratorów w sieciach firmowych. W kontekście ISP ma jedną ciekawą cechę: wielu operatorów traktuje IPsec jako ruch „biznesowy”, potrzebny do VPN-ów korporacyjnych, więc nie zawsze jest przycinany tak brutalnie jak OpenVPN.

Z drugiej strony, IPsec jest bardzo dobrze opisany w literaturze i ma przewidywalne nagłówki (ESP, IKE). Jeśli celem operatora jest blokada wszystkiego poza własnymi tunelami firmowymi, wprowadza on whitelisty na określone IP/AS i resztę IPsec-a może po prostu odrzucać lub dusić.

Na domowe użycie IPsec/IKEv2:

• dobrze sprawdza się w połączeniach telefon → serwer,
• bywa stabilniejszy od „kombinacji” typu OpenVPN over TCP na słabych łączach,
• jest stosunkowo łatwy do zestawienia na routerach z wbudowaną obsługą IPsec.

Natomiast w sieciach uczelnianych i korporacyjnych, które aktywnie blokują obce VPN-y, IPsec w pierwszej kolejności ląduje na czarnej liście – jest zbyt charakterystyczny i zbyt powszechnie stosowany w nieautoryzowany sposób.

„VPN w HTTPS”: gdy tunel chowa się w zwykłym ruchu TLS

Coraz popularniejsze rozwiązanie: opakowanie VPN w warstwę, która jak najwierniej udaje zwykłe połączenie HTTPS. To mogą być:

• OpenVPN over TLS z odpowiednio przygotowanym serwerem,
• tunel przez stunnel lub Hitch z prawdziwym certyfikatem domenowym,
• protokoły własne usług VPN (często marketingowo nazwane „stealth”, „camouflage”, „obfs”), bazujące na TLS 1.2/1.3.

Idea jest prosta: z zewnątrz ma to wyglądać tak, jakbyś łączył się z normalną stroną WWW po HTTPS. W ruchu widać:

• prawdziwe SNI z nazwą domeny,
• zwykłe ciphersuites TLS,
• wzorce wymiany kluczy typowe dla przeglądarek.

DPI ma wtedy trudniejsze zadanie – nie może już polegać na prostych sygnaturach „to jest OpenVPN/WireGuard”, bo handshake odpowiada profilowi zwykłego serwera www. Ruch nadal da się klasyfikować po innych cechach (np. długość trwania sesji, ilość transferowanych danych, brak klasycznych nagłówków HTTP/2), ale próg trudności rośnie.

Dlatego takie podejście jest szczególnie skuteczne tam, gdzie operator:

• nie chce ryzykować fałszywych alarmów i przypadkowego przycinania zwykłego ruchu WWW,
• stosuje średnio zaawansowane DPI, oparte na sygnaturach protokołów, a nie pełnej analizie zachowania sesji,
• bardziej boi się skarg o „uszkodzony internet” niż prywatnych VPN-ów.

Metody obchodzenia throttlingu: od prostych sztuczek po zaawansowane obejścia

Zmiana portu i protokołu: szybki test, który często wystarczy

Zanim sięgniesz po zaawansowaną obfuskację, sensowny jest prosty zestaw zmian konfiguracyjnych. Celem jest sprawdzenie, czy operator „łapie” tunel głównie po porcie/protokole, czy po głębszej analizie.

Kolejność kroków, która zwykle daje najszybszą informację zwrotną:

1. OpenVPN/WireGuard na domyślnym porcie UDP → zmiana na inny UDP (np. 53, 1194, 51820),
2. jeśli UDP jest zabijane – przełączenie na TCP (np. 443, 80),
3. próba innych protokołów, jeśli dostawca je oferuje (IKEv2, „stealth profiles”).

Po każdej zmianie nie patrz jedynie na to, czy VPN „wstaje”. Liczy się:

• prędkość w speedteście,
• ping i jitter do kilku hostów,
• zachowanie aplikacji wrażliwych na opóźnienia (gry, VoIP).

Wymuszenie „HTTPS‑owego” tunelu: OpenVPN/WireGuard za TLS

Gdy zmiana portu i przełączenie UDP/TCP niewiele zmieniają, kolejnym krokiem jest wciągnięcie VPN pod prawdziwą warstwę TLS. Chodzi o to, aby z perspektywy operatora wyglądało to jak zwykłe połączenie przeglądarka → serwer www, a nie jak „goły” tunel.

Są dwa główne podejścia:

• terminowanie TLS na osobnym wrapperze (np. stunnel, Hitch, nginx stream) i dopiero za nim OpenVPN/WireGuard,
• wbudowana warstwa „stealth” po stronie komercyjnego VPN, która sama robi podobny trik (własny protokół w TLS z prawdziwym certyfikatem).

Wariant z własnym serwerem wymaga:

• domeny z sensowną nazwą (nie typu vpn123.example.com, raczej coś „webowe”),
• certyfikatu TLS od powszechnie zaufanego CA (np. Let’s Encrypt),
• konfiguracji wrappera tak, aby handshake i parametry TLS przypominały zwykły serwer www.

Kiedy to działa? Gdy ISP:

• opiera blokady na sygnaturach protokołów (rozpoznaje OpenVPN/WireGuard, ale nie analizuje dogłębnie ruchu TLS),
• unika agresywnego dłubania w HTTPS z obawy przed uszkodzeniem normalnych stron i aplikacji webowych,
• ma politykę „dozwolony jest każdy ruch na 443/TCP, o ile wygląda sensownie webowo”.

Kiedy nie pomaga? Gdy sieć:

• robi analizę statystyczną strumieni (np. wykrywa bardzo długie, jednolite sesje TLS bez klasycznego HTTP/2, dużo danych w jednym kierunku),
• prowadzi whitelisting popularnych hostów / SNI, a resztę 443/TCP limituje do niskiej przepustowości,
• korzysta z proxy pośredniczących, które same inicjują swoje sesje TLS (twoje „udawane HTTPS” nie dociera w oryginalnej postaci).

Typowy scenariusz: użytkownik sieci LTE od operatora X obserwuje fatalne działanie „gołego” OpenVPN na 1194/UDP, słabo na 443/TCP, natomiast po przełączeniu na OpenVPN-over-TLS z prawdziwym certyfikatem i SNI ruchem webowym prędkości nagle wracają niemal do poziomu „bez VPN”. To sugeruje, że filtry były konfigurowane konkretnie pod OpenVPN, a nie pod pełne DPI dla TLS.

Użycie „kamuflażowych” profili komercyjnych VPN

Część większych dostawców VPN oferuje własne tryby maskowania, zwykle oznaczone hasłami typu Camouflage, Stealth, Obfuscated, NoBorders i podobne. Technicznie to różne wariacje:

• OpenVPN lub własny protokół w TLS 1.3 z „normalnymi” ciphersuites,
• protokoły zbliżone do Shadowsocks (stream szyfrowany, wyglądający jak przypadkowy, ale nie mający sygnatur OpenVPN/IPsec),
• hybrydy z dodatkową warstwą obfuskacji pakietów (np. XOR, modyfikacja rozmiarów ramek, losowe paddingi).

Na papierze wygląda to jak panaceum: „włącz stealth, masz spokój”. W praktyce:

• kiedy działa: gdy ISP ma proste DPI i klasyfikatory działające po sygnaturach popularnych protokołów, a nie jest nastawiony na aktywne polowanie na każdy tunel,
• kiedy nie robi różnicy: gdy provider jest już na etapie „jakikolwiek długi zaszyfrowany tunel do obcego DC = inna klasa QoS”,
• kiedy bywa gorzej: gdy tryb stealth korzysta z TCP-over-TCP lub agresywnego pakowania danych, co przy większych opóźnieniach sieci daje „pływającą” prędkość i lagi.

Rozsądne podejście: potraktować te tryby jako kolejną zmienną do testów, a nie jako automatyczną gwarancję obejścia blokad. Warto sprawdzić przynajmniej:

• zachowanie w godzinach szczytu vs późny wieczór,
• różne lokalizacje tego samego trybu stealth (różne kraje / regiony),
• jak reagują gry online i wideo 4K – one obnażają „gumowe” łącze szybciej niż speedtest.

Tunelowanie VPN przez SSH, Shadowsocks i narzędzia „proxy‑like”

Zamiast pełnego „VPN w VPN” można przenieść się poziom wyżej: użyć narzędzi typowo proxy, które z punktu widzenia ISP wyglądają inaczej niż klasyczne protokoły tunelujące cały IP.

Do najczęściej stosowanych należą:

• SSH tunel / SSHuttle – dla pojedynczej aplikacji lub pseudo‑VPN‑a na bazie SSH,
• Shadowsocks – lekki proxy szyfrowany, popularny w krajach z mocną cenzurą sieci,
• SOCKS5/HTTP CONNECT – klasyczne serwery proxy, przez które kieruje się ruch wybranych programów.

Zaleta takiego podejścia jest prosta: ISP często „gapi się” w znane mu protokoły VPN (OpenVPN, IPsec), a ruch wyglądający jak zwykłe TCP na 22/443 czy ruch do „jakiegoś” serwera proxy jest traktowany bardziej obojętnie. Dodatkowo można:

• tunelować tylko wymagające aplikacje (np. przeglądarka, klient gry),
• zostawić resztę ruchu poza tunelem, co zmniejsza objętość „podejrzanego” strumienia danych.

Minusem jest to, że:

• nie zawsze otrzymuje się pełne maskowanie IP na poziomie całego systemu (zależy od narzędzia),
• implementacje „kombinowane” (np. SSHuttle) potrafią generować nadmiarowy ruch i działają gorzej niż natywny VPN przy kiepskiej jakości łącza,
• coraz więcej operatorów profiluje także ruch do popularnych portów proxy, jeśli statystyki wyglądają „tunelowo”.

Ten kierunek ma sens głównie tam, gdzie:

• blokowane są specyficzne porty / protokoły VPN, ale ruch „proxy‑podobny” jest zostawiony w spokoju,
• potrzebne jest obejście ograniczeń tylko dla wybranych usług (np. VoIP, aplikacja biznesowa), a nie całego systemu.

Mosty, relay’e i hop‑pośredni: wstawienie dodatkowej warstwy

W silnie filtrowanych sieciach pojawia się inny rodzaj ograniczeń: nie tyle „ten protokół jest zły”, co „ten zakres IP / ten AS jest duszony”. Wtedy nawet idealnie zamaskowany tunel TLS nic nie da, jeśli kończy się w centrum danych, które ISP ma oznaczone jako „VPN/commercial hosting”.

Rozwiązaniem są różnego typu „mosty”:

• serwer pośredni (VPS, serwer domowy) w mniej podejrzanej lokalizacji, który dopiero dalej łączy się z docelowym VPN,
• chain dwóch tuneli: klient → (obfuskowany tunel do VPS) → (zwykły tunel VPN do komercyjnego dostawcy),
• korzystanie z usług typu „bridge” dostępnych w ekosystemie narzędzi antycenzurowych (np. mosty Tor, private bridge w Shadowsocks).

Z zewnątrz ISP widzi jedynie:

• ruch do twojego VPS‑a (który może być w chmurze oznaczonej jako „zwykły hosting”, a nie „fabryka VPN‑ów”),
• pojedynczy strumień TLS lub inny obfuskowany tunel z normalną domeną.

To podejście pomaga, gdy:

• operator dusi ruch do dużych AS‑ów znanych providerów VPN,
• gotowe aplikacje komercyjnych VPN tracą łącze po kilku minutach (prawdopodobnie heurystyka po IP/ASN),
• masz możliwość uruchomienia własnego serwera pośredniego w innej sieci (VPS, serwer u znajomego, maszyna w firmie).

Nie rozwiązuje problemu, gdy ISP przeszedł na „profilowanie klienta”: dowolny duży, długotrwały strumień szyfrowany do jednego hosta i tak ląduje w gorszej klasie QoS, niezależnie od tego, gdzie fizycznie leży ten host.

Podszywanie się pod popularne usługi (CDN, VoIP, gaming)

Niektórzy idą krok dalej i próbują, aby ruch tunelu wyglądał jak konkretny rodzaj aplikacji, który operator traktuje ulgowo. Chodzi o:

• serwowanie TLS z nazwą domeny przypominającą serwisy streamingowe/gamingowe,
• stosowanie wzorców wymiany pakietów podobnych do VoIP (małe, częste pakiety) przy niskim opóźnieniu,
• korzystanie z edge‑serwerów / CDN jako frontu (np. rozwiązania klasy CDN‑fronting, gdy dostawca VPN integruje się z chmurą CDN).

Tu pojawia się istotna pułapka: nielegalne lub nieetyczne podszywanie się pod konkretne domeny / certyfikaty (np. próby generowania „udawanych” certyfikatów dla cudzego serwisu) jest złym pomysłem – technicznie, prawnie i bezpieczeństwem. Rozsądna granica to:

• własna domena stylizowana na „zwykły serwis użytkowy”,
• fronting przez oficjalnie wspierane mechanizmy dostawców chmury (jeśli taki model oferują),
• profilowanie ruchu pod kątem wzorców (rozmiary, interwały), a nie udawanie konkretnych marek.

Takie techniki mają większy sens w miejscach, gdzie:

• operator ma pozytywne wyjątki dla kategorii „gaming”, „VoIP”, „VOD”,
• duża część ruchu i tak idzie przez CDNy, więc dodatkowy strumień TLS z podobnym profilem ginie w tłumie.

Split tunneling i selektywny routing: mniejszy ślad „podejrzanego” ruchu

Gdy każdy bajt przechodzący przez VPN powoduje, że ISP uznaje klienta za „twardego tunelowca”, rozsądniej bywa wybrać, co naprawdę musi iść tunelem. To rola mechanizmów typu split tunneling oraz zaawansowanych tablic routingu.

Można to zorganizować kilkoma sposobami:

• z poziomu aplikacji VPN (jeśli ma wbudowany split tunneling: wybór aplikacji lub adresów, które idą przez tunel),
• na routerze – osobne reguły ip rule / ip route z oznaczaniem pakietów (mangle),
• przez proxy: tylko ruch przeglądarki/gry idzie przez tunel SSH/Shadowsocks, reszta korzysta z bezpośredniego wyjścia ISP.

Efekt uboczny jest dwojaki:

• ilość ruchu w tunelu spada, więc profil „ciągły, ciężki strumień szyfrowany” jest mniej oczywisty,
• niektóre niekrytyczne usługi (aktualizacje gier, backup, chmury) korzystają z pełnej przepustowości oferowanej lokalnie przez ISP.

Problem pojawia się, gdy:

• ISP stosuje ograniczenia per użytkownik, a nie per flow – już sam fakt nawiązania długiej sesji VPN obniża „rating” klienta,
• split tunneling zostanie źle skonfigurowany i ruch, który miał być prywatny (np. logowanie do banku), wyleci poza tunel.

To narzędzie jest szczególnie przydatne dla osób, które:

• chcą ochrony tylko dla kilku wrażliwych aplikacji,
• korzystają z łącza mobilnego o ograniczonym pakiecie danych i nie chcą „przepalać” go na cały ruch przez VPN.

Zmiana „poziomu” tunelowania: L2 vs L3 i powyżej

Kiedy filtrowanie dotyka przede wszystkim klasycznych tuneli IP (L3), część osób eksperymentuje z przesunięciem tunelu w górę lub w dół stosu:

• L2TP, GRE – tunele warstwy 2, które przenoszą całe ramki Ethernet,
• tunel HTTP/2, WebSocket – tunelowanie na poziomie aplikacyjnym nad HTTP(S).

Tunel L2 (typowy przykład: gretap, L2TP over IPsec) potrafi wyglądać podejrzanie dla DPI (nietypowe nagłówki), ale są środowiska, w których tolerowane są one bardziej niż tunel IPsec, ponieważ trudno je pomylić z klasycznymi komercyjnymi VPN‑ami. Z kolei tunelowanie przez WebSocket/HTTP2 sprawia, że ruch integruje się lepiej z infrastrukturą webową (reverse proxy, CDNy).

Zastosowanie praktyczne:

• wewnętrzne mosty między lokalizacjami (dom → biuro, biuro → VPS), gdzie reguły ISP są bardziej liberalne wobec protokołów L2/gre,
• połączenia z aplikacjami webowymi/self‑hostowanymi, które naturalnie mówią HTTP(S) – tunel WebSocket można przemycić przez reverse proxy.

Najczęściej zadawane pytania (FAQ)

Skąd wiem, że to operator zrywa moją sesję VPN, a nie problem z serwerem?

Najbardziej charakterystyczny sygnał to powtarzalność. Jeśli rozłączenia pojawiają się po niemal identycznym czasie (np. co 30 lub 60 minut), przy dobrym zasięgu i stabilnym łączu, wygląda to na limit sesji po stronie sieci, a nie awarię serwera VPN.

Dobry test to szybka zmiana serwera lub nawet dostawcy VPN po zerwaniu połączenia. Jeżeli przez kilka–kilkanaście minut żaden serwer się nie zestawia, a „goły” internet działa normalnie, bardzo możliwe, że to filtracja lub tymczasowa blokada ruchu VPN przez ISP. Jeśli natomiast inne serwery łączą się od razu, problem leży raczej po stronie konkretnego punktu końcowego (serwera, trasy, przeciążenia).

Dlaczego internet na VPN jest dużo wolniejszy, skoro bez VPN mam pełną prędkość?

Spadek przepustowości na VPN nie zawsze oznacza „złośliwy throttling”. Częsty powód to ograniczenia po stronie sprzętu (słaby router, CPU w telefonie), kiepsko dobrany serwer albo trasa międzynarodowa. Szyfrowanie samo w sobie też kosztuje – na starszych routerach przejście z 200 Mb/s „gołego” internetu do 20–50 Mb/s na VPN to norma.

O throttlingu przez operatora można mówić dopiero, gdy: prędkość znacząco spada na różnych urządzeniach, przy wielu serwerach VPN i protokołach oraz w różnych porach dnia, a jednocześnie „goły” internet w tych samych warunkach działa szybko. Typowy scenariusz z sieci mobilnej: streaming z aplikacji VOD działa pełną rurą, ale ten sam serwis przez VPN utyka na kilku megabitach – to efekt niższego priorytetu dla „niezidentyfikowanego szyfrowania”.

Co mój operator faktycznie widzi, gdy używam VPN?

ISP nie widzi treści twojej komunikacji (konkretnych stron, haseł, filmów), ale widzi metadane pakietów. Dokładniej: adres IP źródłowy i docelowy (np. IP twojego serwera VPN), numery portów, używany protokół transportowy (TCP/UDP), wielkość pakietów, kierunek i rytm ruchu. To całkowicie wystarcza, żeby rozpoznać, że korzystasz z VPN, nawet jeśli konkretne dane są zaszyfrowane.

W przypadku „zwykłego” HTTPS operator często widzi też SNI, czyli nazwę hosta, do którego się łączysz. Przy niektórych formach tunelowania przez TLS SNI jest ukryte lub wygląda nienaturalnie, co samo w sobie jest sygnałem, że to nie typowe przeglądanie stron. ISP nie musi więc łamać szyfrowania – bazuje na wzorcach ruchu, a nie jego treści.

Czym jest DPI i jak wpływa na działanie VPN?

DPI (Deep Packet Inspection) to zaawansowana analiza ruchu, która zagląda głębiej niż zwykły firewall. Nie chodzi o odszyfrowywanie treści, ale o analizę nagłówków, sekwencji pakietów, ich wielkości i czasu. Dzięki temu urządzenia DPI potrafią z dużą skutecznością rozpoznawać sygnatury OpenVPN, WireGuard, IPsec czy tunelowania przez SSH lub DNS.

Po wykryciu takiego ruchu operator może: obniżyć mu priorytet (throttling), wstrzykiwać pakiety resetujące sesję (RST), rozcinać połączenia po określonym czasie albo całkowicie blokować znane wzorce. Popularna rada „użyj VPN na porcie 443/TCP jak HTTPS” przestaje działać właśnie przy silnym DPI – port 443 już nie wystarczy, gdy system rozpoznaje sam protokół po zachowaniu ruchu.

Dlaczego VPN działa gorzej w sieci mobilnej niż na łączu stacjonarnym?

Sieci mobilne mają znacznie bardziej ograniczony i współdzielony zasób – pasmo radiowe. Operatorzy agresywniej zarządzają ruchem, żeby utrzymać jako taką jakość dla wszystkich. Stąd częste blokady portów typowych dla VPN, osobne limity dla „nieznanego szyfrowania” i ostrzejsze reguły w roamingu, szczególnie przy „nielimitowanych” planach z drobnym druczkiem.

Na łączach stacjonarnych (światłowód, kabel) polityka jest z reguły łagodniejsza, ale VPN też bywa klasyfikowany jako ruch niższego priorytetu, zwłaszcza gdy generuje długotrwałe, stałe obciążenie (np. P2P 24/7). Różnica, którą wielu widzi w praktyce: ten sam VPN na światłowodzie działa niemal jak „gołe” łącze, podczas gdy w sieci LTE potrafi się rwać, zwalniać lub całkiem przestawać działać w godzinach szczytu.

Jak rozpoznać, czy mój VPN jest blokowany portami, a nie DPI?

Przy zwykłych blokadach portów połączenie w ogóle się nie zestawia – klient VPN nawet nie zaczyna prawidłowego handshaku. Jeśli zmiana portu na mniej oczywisty (np. 443/TCP zamiast 1194/UDP dla OpenVPN) nagle „magicznie” rozwiązuje problem, najprawdopodobniej operator jedynie filtrował konkretne numery portów.

Gdy w grę wchodzi DPI, sytuacja jest mniej przewidywalna. VPN może łączyć się na chwilę, po czym regularnie się zrywać, prędkość spada tylko dla niektórych typów ruchu w tunelu, albo port 443/TCP nie daje żadnej przewagi nad innymi portami. W skrajnych przypadkach wszystkie popularne protokoły VPN są rozpoznawane i ograniczane niezależnie od używanego numeru portu – wtedy samo „przestawienie portu” przestaje być skuteczną sztuczką.

Czy da się całkowicie ukryć przed operatorem, że używam VPN?

W praktyce – rzadko kiedy w 100%. Można jednak znacząco utrudnić wykrycie, korzystając z technik obfuskacji i tunelowania, które sprawiają, że ruch VPN wygląda jak zwykły HTTPS albo inny dozwolony protokół. Przykłady to: obfuskowane profile w OpenVPN/WireGuard, tunelowanie przez TLS z „normalnym” SNI, a w skrajnych sytuacjach tunelowanie w SSH czy nawet DNS.

Popularna rada „kup płatny VPN i problem znika” bywa prawdziwa tylko tam, gdzie operator stosuje proste filtry lub priorytety. W sieciach z mocnym DPI nawet komercyjny VPN bez obfuskacji będzie łatwy do sklasyfikowania jako „tunel szyfrowany”. Dlatego sensownie jest dobierać narzędzie do warunków: na łagodnym łączu stacjonarnym wystarczy standardowy VPN, natomiast w agresywnej sieci mobilnej lepiej od razu szukać rozwiązań z wbudowaną obfuskacją i możliwością imitowania zwykłego ruchu HTTPS.

Najważniejsze punkty

• VPN ukrywa treść, ale nie „niewidzialnia” ruchu – operator widzi metadane (IP, porty, protokół, rozmiary i rytm pakietów) i na ich podstawie dość dokładnie rozpoznaje, że korzystasz z tunelu szyfrowanego.
• Ograniczenia nie wymagają łamania szyfrowania: wystarczy przypisanie ruchu do klasy „inne/nieznane szyfrowanie”, dla której ustawione są niższe priorytety, limity prędkości albo wręcz blokady wybranych protokołów VPN.
• Najprostsze techniki operatorów to blokady portów popularnych protokołów (np. 1194/UDP, 1723/TCP); skuteczniejsze, ale bardziej „niewidoczne” dla użytkownika są QoS/throttling i DPI, które potrafią degradować lub resetować sesje bez jawnego komunikatu o błędzie.
• DPI nie musi rozumieć zaszyfrowanej treści, żeby zaszkodzić – rozpoznaje handshaki OpenVPN, WireGuarda czy IPsec, wyłapuje nienaturalne SNI lub tunelowanie w SSH/DNS i może celowo opóźniać, ciąć lub zrywać takie połączenia.
• Sieci mobilne są zwykle najbardziej agresywne wobec VPN: blokują porty, limitują „nadmiarowe” szyfrowanie i mocno premiują ruch do własnych aplikacji czy wybranych serwisów VOD, przez co po włączeniu VPN streaming nagle działa wolniej, choć teoretycznie „internet jest nielimitowany”.

Bibliografia i źródła

• RFC 4301: Security Architecture for the Internet Protocol. Internet Engineering Task Force (2005) – Architektura IPsec, metadane widoczne dla sieci, nagłówki i enkapsulacja
• RFC 3947: Negotiation of NAT-Traversal in the IKE. Internet Engineering Task Force (2005) – IPsec NAT-T, użycie portów UDP 500 i 4500, zachowanie w sieciach operatorów
• OpenVPN 2.6 Documentation. OpenVPN Technologies – Porty domyślne, charakterystyka ruchu OpenVPN, tryby TCP/UDP
• WireGuard Whitepaper. WireGuard – Opis protokołu WireGuard, fingerprint ruchu, wykorzystanie UDP
• Cisco Visual Networking Index: Forecast and Methodology. Cisco Systems – Zarządzanie ruchem, QoS, priorytetyzacja klas ruchu w sieciach operatorów
• ETSI TS 102 250-2: QoS aspects for popular services in mobile networks. European Telecommunications Standards Institute – Parametry QoS, klasyfikacja ruchu, praktyki operatorów mobilnych
• Sandvine Global Internet Phenomena Report. Sandvine – Praktyki DPI, throttling, klasyfikacja VPN i szyfrowanego ruchu
• B. Anderson, T. McGrew, "Machine Learning for Encrypted Traffic Analysis". IEEE (2016) – Analiza szyfrowanego ruchu po metadanych, fingerprinting VPN