WireGuard jest szybki, OpenVPN dojrzały i wszędzie obsługiwany, ale oba mają problem, który staje się istotny w sieciach z agresywnym filtrowaniem: ich ruch można rozpoznać jako VPN. TrustTunnel próbuje rozwiązać właśnie ten problem. Zamiast tworzyć charakterystyczny strumień pakietów własnego protokołu, przesyła ruch przez TLS oraz HTTP/2 lub HTTP/3, czyli technologie używane przez zwykłe strony HTTPS.

Nie oznacza to magicznej niewidzialności. Administrator sieci nadal widzi adres IP serwera, domenę używaną podczas zestawiania połączenia i metadane transmisji. Może też stosować analizę statystyczną albo aktywnie sprawdzać podejrzane hosty. Różnica polega na czym innym: zablokowanie TrustTunnela wyłącznie po prostym podpisie protokołu jest znacznie trudniejsze niż rozpoznanie klasycznego OpenVPN czy WireGuarda, bo warstwa transportowa wygląda jak normalny ruch webowy.

TrustTunnel powstał na bazie protokołu używanego wcześniej przez AdGuard VPN i został udostępniony jako projekt open source na licencji Apache 2.0. We wrześniu 2026 r. jest już czymś więcej niż demonstracją: istnieje oficjalny endpoint, klient CLI, aplikacje mobilne, obsługa TCP, UDP i ICMP, split tunneling, kill switch oraz możliwość postawienia własnego serwera.

Co TrustTunnel robi inaczej niż WireGuard i OpenVPN

Najłatwiej zrozumieć TrustTunnel przez porównanie tego, co widzi urządzenie znajdujące się pomiędzy klientem a serwerem VPN.

WireGuard korzysta z własnego protokołu transportowanego przez UDP. Jest niewielki, szybki i ma bardzo elegancką architekturę kryptograficzną, ale ruch WireGuarda nie próbuje udawać przeglądarki. Jeśli sieć chce przepuszczać HTTPS, a blokować znane protokoły VPN, WireGuard znajduje się w stosunkowo niekorzystnej pozycji.

OpenVPN można uruchomić na UDP albo TCP, również na porcie 443. Sam numer portu nie wystarcza jednak do kamuflażu. Port 443 nie zamienia automatycznie dowolnego protokołu w HTTPS. Charakterystyczne sekwencje pakietów, długości wiadomości oraz zachowanie serwera pozwalają klasyfikować połączenia znacznie dokładniej.

TrustTunnel schodzi poziom głębiej. Sesja jest zestawiana jako:

• HTTP/2 przez TLS, albo
• HTTP/3 przez QUIC.

W wariancie HTTP/2 klient zestawia normalne połączenie TLS, negocjuje przez ALPN protokół h2, a następnie wykorzystuje strumienie HTTP/2 do tunelowania właściwego ruchu.

W wariancie HTTP/3 transportem jest QUIC, czyli protokół oparty na UDP używany obecnie przez normalne strony internetowe i duże platformy CDN.

To ważna różnica. Zamiast ukrywać VPN poprzez dołożenie osobnej warstwy obfuskacji, TrustTunnel buduje tunel bezpośrednio na protokołach typowych dla współczesnego WWW.

Dla TCP każda tunelowana sesja dostaje własny strumień HTTP i korzysta z metody CONNECT. Przykładowo połączenie klienta z serwerem WWW może wewnątrz sesji wyglądać logicznie jak:

CONNECT example.com:443

Po odpowiedzi 200 OK strumień staje się dwukierunkowym kanałem danych.

UDP rozwiązano inaczej. Datagrama nie da się po prostu potraktować jak zwykłego strumienia TCP, dlatego cały ruch UDP klienta jest multipleksowany przez specjalny strumień HTTP. Podobnie obsługiwany jest ICMP, czyli między innymi ping.

W praktyce oznacza to obsługę:

• TCP,
• UDP,
• ICMP,
• IPv4,
• IPv6,
• pełnego tunelu systemowego przez interfejs TUN,
• trybu SOCKS5,
• split tunnelingu.

HTTP/2 daje jeszcze jedną korzyść: wiele połączeń może funkcjonować w ramach jednej sesji transportowej. TrustTunnel nie musi więc dla każdej aplikacji od początku budować osobnego ciężkiego tunelu.

HTTP/3 usuwa część ograniczeń charakterystycznych dla TCP. QUIC obsługuje wiele niezależnych strumieni, a utrata pakietu dotyczącego jednego z nich nie musi zatrzymywać wszystkich pozostałych. Na szybkiej, ale niestabilnej sieci mobilnej potrafi to mieć znaczenie.

Nie znaczy to, że TrustTunnel będzie zawsze szybszy od WireGuarda. WireGuard pozostaje punktem odniesienia pod względem prostoty i niewielkiego narzutu. Jeśli używasz VPN w domu, firmie albo między własnymi serwerami i nikt nie próbuje aktywnie wykrywać protokołu, przejście na TrustTunnel tylko dla prędkości nie ma szczególnego sensu.

TrustTunnel ma przewagę przede wszystkim wtedy, gdy problemem jest rozpoznawanie i ograniczanie VPN, a nie samo szyfrowanie.

Są też koszty tej konstrukcji. HTTP/2, HTTP/3 i TLS tworzą większy oraz bardziej skomplikowany stos niż WireGuard. Dochodzi obsługa certyfikatów, domeny, serwera HTTP i większa liczba parametrów. Diagnozowanie problemów jest przez to mniej przyjemne. W WireGuardzie zwykle sprawdzamy klucz, endpoint, routing i firewall. Tutaj dochodzą jeszcze SNI, ALPN, certyfikat, HTTP/2, QUIC oraz zachowanie konkretnej sieci wobec UDP.

Kiedy ruch rzeczywiście trudniej wykryć, a kiedy kamuflaż przestaje pomagać

Największym błędem byłoby interpretowanie TrustTunnela jako „VPN, którego nie da się wykryć”. Takiej gwarancji nie daje żaden protokół.

TrustTunnel utrudnia przede wszystkim klasyfikację na podstawie prostego fingerprintu protokołu.

To nie jest drobna różnica. Badania nad OpenVPN pokazały, że połączenia można identyfikować między innymi na podstawie wzorców bajtów, wielkości pakietów oraz charakterystycznej reakcji serwera. W jednym z dużych eksperymentów wykrywano ponad 85 proc. badanych strumieni OpenVPN przy bardzo małej liczbie fałszywych trafień. Skuteczne okazało się także rozpoznawanie wielu konfiguracji reklamowanych jako obfuskowane.

TrustTunnel próbuje pozbyć się właśnie tak łatwego identyfikatora.

Nie oznacza to jednak, że obserwator niczego nie widzi.

Po pierwsze: pozostaje adres IP.

Jeżeli jeden konkretny VPS jest używany wyłącznie jako serwer VPN i jego adres trafi na listę blokowanych endpointów, zastosowany protokół przestaje mieć większe znaczenie. Firewall może odrzucić wszystkie pakiety kierowane pod ten adres.

Dlatego własny serwer ma jednocześnie zaletę i wadę. Publiczne adresy dużych dostawców VPN są łatwiejsze do katalogowania, natomiast prywatny VPS używany przez jedną lub kilka osób jest mniej oczywistym celem. Z drugiej strony wystarczy zablokować dokładnie jego adres, żeby połączenie przestało działać.

Po drugie: widoczna może być nazwa domeny.

W HTTP/2 używany jest TLS, a klient wysyła SNI potrzebne do wyboru właściwego certyfikatu. QUIC również nie oznacza automatycznie, że wszystkie informacje z fazy zestawiania połączenia stają się niewidoczne. Systemy cenzurujące potrafią analizować również początkowe pakiety QUIC.

Dlatego nazwanie serwera vpn-mojserwer.example nie jest szczególnie subtelnym pomysłem. Technicznie zadziała. Operacyjnie samemu przyklejamy do hosta etykietę.

Po trzecie: istnieje analiza zachowania.

Szyfrowanie ukrywa treść, ale nie usuwa:

• czasu przesyłania pakietów,
• ich długości,
• kierunku transmisji,
• czasu trwania sesji,
• wolumenu danych,
• liczby równoległych połączeń.

Długotrwała transmisja HTTP/2 do jednego VPS-a, przez którą przez kilka godzin płynie cały ruch telefonu albo laptopa, nie musi statystycznie przypominać pięciominutowej wizyty na stronie sklepu internetowego.

Nowoczesne systemy klasyfikacji potrafią korzystać właśnie z takich cech.

Po czwarte: serwer można aktywnie sondować.

Zaawansowany filtr nie musi ograniczać się do biernego oglądania pakietów. Może zauważyć podejrzany endpoint i spróbować połączyć się z nim samodzielnie, sprawdzając odpowiedzi na nietypowe żądania.

TrustTunnel ma mechanizmy ograniczające ryzyko takich testów. Serwer obsługuje reguły filtrujące i może wiązać dostęp z określonym prefiksem pola TLS Client Random. Eksport konfiguracji klienta potrafi wygenerować taki prefiks i automatycznie dopisać odpowiednią regułę.

To rozwiązanie jest ciekawsze niż wystawienie publicznego serwera, który odpowiada charakterystycznie każdemu przypadkowemu skanerowi.

Endpoint może również pracować jako reverse proxy dla zwykłego serwera HTTP. Można więc sprawić, że host obsłuży normalny ruch WWW zamiast zachowywać się jak urządzenie istniejące wyłącznie po to, żeby terminować VPN.

Nie eliminuje to aktywnego fingerprintingu, ale podnosi koszt jego wykonania.

Po piąte: HTTP/3 można po prostu wyłączyć po drodze.

QUIC korzysta z UDP, zwykle na porcie 443. Niektóre sieci firmowe, hotelowe czy publiczne blokują UDP/443 albo traktują je bardziej restrykcyjnie niż TCP/443.

Dlatego praktyczna konfiguracja nie powinna opierać się wyłącznie na HTTP/3. Klient TrustTunnel może próbować HTTP/3, a następnie przejść na HTTP/2, jeśli QUIC nie zadziała. Specyfikacja przewiduje domyślne opóźnienie fallbacku rzędu 1000 ms.

To ważne szczególnie w podróży. Hotelowe Wi-Fi, hotspot na lotnisku i firmowy firewall potrafią zachowywać się zupełnie inaczej niż domowy światłowód.

Wnioski są więc dość konkretne.

Jeżeli celem jest maksymalna wydajność w przyjaznej sieci, najpierw wybrałbym WireGuarda.

Jeżeli priorytetem jest zgodność ze starszym sprzętem i ogromny ekosystem, OpenVPN nadal ma mocne argumenty.

Jeżeli podstawowym problemem jest DPI, filtrowanie protokołów VPN albo ograniczanie charakterystycznego ruchu tunelowego, TrustTunnel staje się znacznie ciekawszą opcją.

Nie gwarantuje niewykrywalności. Zmusza jednak filtr do stosowania bardziej kosztownych metod niż sprawdzenie prostego podpisu WireGuarda czy OpenVPN.

Jak uruchomić własny serwer TrustTunnel i nie zepsuć kamuflażu konfiguracją

Najrozsądniejsza konfiguracja na własny użytek to niewielki VPS z publicznym adresem IPv4, domeną i Linuxem. Nie trzeba kupować mocnej maszyny.

Dla jednej–kilku osób spokojnie wystarczą:

• 1–2 vCPU,
• 1–4 GB RAM,
• około 20–40 GB SSD,
• publiczny IPv4,
• port TCP/443,
• najlepiej również UDP/443,
• Ubuntu 24.04 LTS albo aktualny Debian.

Koszt jest niewielki. We wrześniu 2026 r. najtańsze europejskie VPS-y zaczynają się mniej więcej od 20–30 zł miesięcznie brutto, choć cena mocno zależy od tego, czy dostawca osobno liczy IPv4. Przykładowe małe instancje Hetznera kosztują około 5–6 euro miesięcznie netto przed dodatkami, a podstawowy VPS OVHcloud kosztuje w Polsce około 20 zł brutto miesięcznie.

Do tego dochodzi domena. Zwykle będzie to kilkadziesiąt złotych rocznie.

Nie oszczędzałbym natomiast na lokalizacji. Dla użytkownika w Polsce serwer we Frankfurcie, Norymberdze, Warszawie, Pradze czy Amsterdamie zwykle ma więcej sensu niż VPS w Stanach Zjednoczonych. Każde dodatkowe 30–50 ms RTT odczujesz podczas otwierania wielu małych zasobów znacznie szybciej niż brak kolejnego gigabajta RAM.

Na początku trzeba ustawić rekord DNS, na przykład:

edge.example.net → 203.0.113.20

Nie nazywałbym subdomeny vpn, wireguard, proxy ani trusttunnel. Nie daje to kryptograficznej przewagi, ale nie ma sensu ułatwiać klasyfikacji człowiekowi lub automatycznemu systemowi analizującemu DNS.

Na świeżym Debianie lub Ubuntu instalacja endpointu może sprowadzić się do oficjalnego instalatora:

curl -fsSL https://raw.githubusercontent.com/TrustTunnel/TrustTunnel/refs/heads/master/scripts/install.sh | sh -s -

Binaria trafiają domyślnie do:

/opt/trusttunnel

Gotowe paczki serwera są przygotowywane dla Linux x86_64 i ARM64. Projekt udostępnia również build dla macOS, ale do produkcyjnego endpointu wybrałbym Linuksa. Jest prostszy w utrzymaniu jako VPS, lepiej pasuje do systemd i łatwiej automatyzować na nim firewall oraz certyfikaty.

Następnie:

cd /opt/trusttunnel

i uruchamiamy kreator:

sudo ./setup_wizard

Kreator poprosi między innymi o:

• adres nasłuchiwania,
• nazwę użytkownika,
• hasło,
• plik reguł,
• domenę,
• sposób dostarczenia certyfikatu TLS.

Dla standardowego serwera wybór jest prosty:

0.0.0.0:443

Port 443 nie jest obowiązkowy z punktu widzenia samego protokołu, ale jeśli całym celem jest wtopienie się w normalny ruch HTTPS, uruchamianie endpointu na 8443, 10443 czy losowym wysokim porcie bez konkretnej przyczyny jest strzałem w stopę.

Druga ważna decyzja dotyczy certyfikatu.

TrustTunnel pozwala użyć:

• certyfikatu z Let’s Encrypt,
• własnego istniejącego certyfikatu,
• certyfikatu self-signed.

Do normalnego użytkowania wybrałbym Let’s Encrypt.

Self-signed zostawiłbym do testów. Publicznie zaufany certyfikat lepiej pasuje do założenia, że endpoint ma zachowywać się jak normalna usługa HTTPS. Dodatkowo część klientów GUI ma lub miała ograniczenia związane z certyfikatami podpisanymi samodzielnie.

Dla automatycznego wydania certyfikatu domena musi wskazywać serwer, a przy typowym wyzwaniu HTTP-01 potrzebny jest dostęp z Internetu do portu 80. Alternatywą jest DNS-01.

Tutaj pojawia się jedna z bardziej irytujących rzeczy w obecnym TrustTunnelu: kreator potrafi uzyskać certyfikat Let’s Encrypt, ale trzeba samemu zadbać o jego późniejsze odnawianie i przeładowanie usługi. Do serwera, który ma pracować miesiącami bez zaglądania, lepiej od razu skonfigurować Certbota oraz automatyczny restart albo reload po odnowieniu.

Po konfiguracji endpoint można uruchomić jako usługę systemową. Projekt dostarcza szablon systemd:

cd /opt/trusttunnel/

sudo cp trusttunnel.service.template /etc/systemd/system/trusttunnel.service

sudo systemctl daemon-reload

sudo systemctl enable --now trusttunnel

Stan sprawdzamy:

sudo systemctl status trusttunnel

A logi:

journalctl -u trusttunnel -f

Jeżeli serwer nie startuje, kolejność diagnostyki powinna być zawsze taka sama:

1. sprawdź, czy coś innego nie używa TCP/443;
2. sprawdź, czy domena wskazuje prawidłowy adres;
3. zweryfikuj certyfikat;
4. sprawdź firewall dostawcy VPS;
5. sprawdź lokalny nftables/iptables/ufw;
6. dopiero później grzeb w parametrach HTTP/2 i QUIC.

Na firewallu potrzebne będzie przede wszystkim:

• TCP/443 dla HTTP/2,
• UDP/443 dla HTTP/3,
• ewentualnie TCP/80 do wystawiania lub odnawiania certyfikatu metodą HTTP-01.

SSH powinien pozostać dostępny tylko tam, gdzie faktycznie go potrzebujesz. Jeżeli masz stały adres administracyjny, ograniczenie TCP/22 do własnego IP jest prostą i sensowną zmianą.

TrustTunnel przechowuje użytkowników w osobnym pliku credentials. Nie używałbym jednego konta dla pięciu osób. Osobne dane uwierzytelniające ułatwiają odebranie dostępu jednemu urządzeniu i korzystanie z limitów połączeń per użytkownik.

Od wersji 1.1.0 serwer potrafi również wystawiać metryki per użytkownik, obejmujące sesje, liczbę bajtów oraz adres klienta. Funkcja jest domyślnie wyłączona i tak powinno pozostać, jeśli nie jest potrzebna. Włączenie jej oznacza generowanie dodatkowych danych dotyczących użytkowników, dlatego endpoint metryk musi pozostać niedostępny publicznie.

Po stronie klienta konfigurację najwygodniej wygenerować bezpośrednio na endpointcie:

cd /opt/trusttunnel

./trusttunnel_endpoint vpn.toml hosts.toml -c NAZWA_UZYTKOWNIKA -a edge.example.net

Domyślnie powstaje link w formacie:

tt://?...

Można go zaimportować do klienta. Dla klienta CLI można zamiast tego wygenerować plik TOML.

Jeżeli chcesz utrudnić proste skanowanie endpointu, sensowne jest użycie generowanego TLS Client Random Prefix:

./trusttunnel_endpoint vpn.toml hosts.toml -c NAZWA_UZYTKOWNIKA -a edge.example.net --generate-client-random-prefix

Serwer wygeneruje wartość klienta, dopisze odpowiadającą jej regułę i umieści informację w eksportowanej konfiguracji.

Na kliencie warto włączyć kill switch, jeśli tunel ma zapewniać zmianę publicznego IP również podczas chwilowych awarii. Bez kill switcha klient podczas problemów może dopuścić ruch poza VPN, zależnie od konfiguracji.

Drugim ustawieniem, które ma realne znaczenie, jest DNS. Zapytania DNS powinny iść przez tunel do wybranego resolvera, na przykład przez DoH, DoT albo DoQ. Klient TrustTunnel obsługuje wszystkie te warianty.

Po uruchomieniu nie kończyłbym konfiguracji na sprawdzeniu jednej strony „what is my IP”. Trzeba zrobić cztery testy:

• sprawdzić publiczny IPv4 i IPv6,
• sprawdzić wycieki DNS,
• odłączyć endpoint i zobaczyć zachowanie kill switcha,
• przetestować połączenie w innej sieci, najlepiej LTE/5G oraz publicznym Wi-Fi.

Dopiero wtedy wiadomo, że routing zachowuje się tak, jak zakładaliśmy.

Jeżeli podstawowy TrustTunnel działa, dopiero później ma sens eksperymentowanie z reverse proxy i bardziej zaawansowanymi regułami antyskaningowymi. Najpierw poprawny TLS, HTTP/2, routing i fallback. Kamuflaż drugiego rzędu dopiero potem.

FAQ

Czy TrustTunnel jest szybszy od WireGuarda?
Nie ma takiej reguły. WireGuard ma bardzo mały narzut i w normalnej, nieograniczanej sieci często będzie szybszym i prostszym rozwiązaniem. TrustTunnel należy wybierać przede wszystkim wtedy, gdy znaczenie ma kamuflaż ruchu oraz odporność na filtrowanie VPN, a nie po to, by wycisnąć kilka dodatkowych procent przepustowości.

Czy operator internetu może zobaczyć, że korzystam z TrustTunnela?
Nie widzi treści tunelu, ale widzi połączenie z adresem IP endpointu i część jego metadanych. Może analizować domenę, czas trwania sesji, objętość i charakter ruchu. TrustTunnel utrudnia jednoznaczne rozpoznanie protokołu, lecz nie zapewnia anonimowości ani niewykrywalności.

Czy TrustTunnel ukrywa mój adres IP przed odwiedzanymi stronami?
Tak. Strony widzą publiczny adres IP endpointu TrustTunnel, podobnie jak w klasycznym VPN. Administrator samego endpointu pozostaje jednak elementem zaufanym: serwer wie, skąd przychodzi klient i dokąd wysyłany jest ruch. HTTPS używany wewnątrz tunelu nadal chroni treść połączeń z witrynami.

Czy potrzebuję własnej domeny?
Do prostych testów można pracować z adresem IP i odpowiednią konfiguracją certyfikatu, ale dla normalnego serwera domena i publicznie zaufany certyfikat TLS są zdecydowanie lepszą konfiguracją. Ułatwiają Let’s Encrypt i lepiej odpowiadają modelowi zwykłej usługi HTTPS.

Czy można używać tylko HTTP/3?
Można, ale nie jest to dobry pomysł na serwer używany w różnych sieciach. UDP/443 bywa blokowany. Najpraktyczniejsza konfiguracja pozwala używać HTTP/3 tam, gdzie działa, i zachowuje HTTP/2 jako drogę awaryjną.

Czy TrustTunnel zastąpi WireGuarda w domowej sieci?
Technicznie może, ale najczęściej nie ma powodu. Do dostępu do NAS-a, Home Assistanta czy serwera między dwoma własnymi łączami WireGuard jest prostszy. TrustTunnel zaczyna mieć przewagę wtedy, gdy sieć pośrednia aktywnie filtruje lub ogranicza VPN.

Ile kosztuje własny serwer?
Dla jednej lub kilku osób wystarczy mały VPS. Sensowny budżet to około 20–40 zł miesięcznie plus domena rzędu kilkudziesięciu złotych rocznie. Większa maszyna nie poprawi automatycznie szybkości — przy VPN znacznie częściej ograniczeniem jest przepustowość portu, routing operatora i odległość od centrum danych.

Od czego zacząć?
Od małego VPS-a w pobliskim europejskim centrum danych, domeny, portów TCP/443 i UDP/443 oraz certyfikatu Let’s Encrypt. Uruchom najpierw czysty endpoint HTTP/2/HTTP/3, sprawdź IPv4, IPv6, DNS i kill switch. Dopiero gdy to działa bezbłędnie, dodawaj reverse proxy i reguły utrudniające aktywne skanowanie. W praktyce właśnie zbyt szybkie dokładanie „anty-DPI” do źle działającego routingu powoduje najwięcej niepotrzebnych problemów.