Router z obsługą VPN: test WireGuard, OpenVPN i wydajności na łączu 1 Gb/s

Kontekst testu: po co router z VPN na łączu 1 Gb/s

Scenariusze, w których router z obsługą VPN naprawdę ma sens

Gigabitowe łącze jest dziś standardem w wielu mieszkaniach i małych biurach. Samo „1 Gb/s w umowie” nie oznacza jednak, że taką przepustowość da się wykorzystać po VPN. Router z obsługą VPN wchodzi do gry wtedy, kiedy tunelowanie ruchu staje się częścią codziennej pracy, a nie tylko dodatkiem używanym raz w miesiącu.

Najczęstsze scenariusze, w których VPN na routerze robi różnicę:

• Praca zdalna do firmowej sieci – stały tunel VPN między domem a biurem, który zapewnia dostęp do serwerów, systemów księgowych, ERP czy drukarek, bez konieczności ręcznego włączania aplikacji VPN na każdym komputerze.
• Dostęp do domowego NAS / serwera plików – gdy poza domem trzeba szybko ściągnąć z NAS-a kilka dużych plików, backup lub projekt wideo, a opóźnienia i słaba przepustowość VPN potrafią zabić produktywność.
• Zdalne biuro / mała firma – połączenie kilku lokalizacji (dom–biuro, dwa biura, biuro–magazyn) w jedną sieć przy wykorzystaniu tuneli site-to-site. Tu przepustowość i stabilność tunelu bezpośrednio wpływa na pracę całej firmy.
• Gry i usługi domowe – gdy chce się hostować serwer gry, własny serwer multimediów czy domową automatykę dostępną na zewnątrz, ale bez wystawiania ich bezpośrednio do internetu.

W tych zastosowaniach VPN na routerze oznacza mniej klikania, mniej błędów użytkownika i wyższy komfort. Jednocześnie ujawnia wszystkie słabości tanich urządzeń, które mają „VPN” w specyfikacji, ale realnie nie są w stanie obsłużyć szybkiego tunelu na łączu 1 Gb/s.

VPN w routerze vs VPN na komputerze

VPN klient zainstalowany na komputerze ma jedną zaletę: nie trzeba zmieniać routera. W wielu przypadkach to wystarczy, ale ma też kilka podstawowych wad, które ujawniają się wraz ze wzrostem przepustowości i liczby urządzeń.

Klient VPN na komputerze oznacza, że:

• każde urządzenie musi mieć własną konfigurację, dostęp i utrzymany aktualny klient,
• ruch z innych urządzeń (np. TV, konsola, drukarka, IoT) nie jest tunelowany,
• przepustowość zależy od mocy danego komputera i jego obciążenia,
• trudniej centralnie wymusić polityki bezpieczeństwa (np. tylko wybrane adresy przez VPN).

VPN w routerze działa na całej sieci lokalnej. W praktyce oznacza to:

• jedno miejsce konfiguracji i jeden zestaw logów,
• możliwość tunelowania części ruchu (policy routing) – np. tylko sieć biurowa przez VPN, reszta bezpośrednio do internetu,
• serwery w domu/biurze (NAS, kamera, serwer gry) dostępne przez VPN bez dodatkowych kombinacji z portami,
• mniej problemów z aktualizacjami klientów VPN na różnych systemach.

Minus jest oczywisty: cały ruch VPN przechodzi przez jeden punkt – router. Jeśli CPU jest słabe, staje się wąskim gardłem i z gigabitowego łącza zostaje 100–200 Mb/s w tunelu, niezależnie od tego, jak szybki jest serwer po drugiej stronie.

Dlaczego słaby router „dusi” łącze gigabitowe w VPN

Szyfrowanie i deszyfrowanie ruchu VPN to praca procesora. Na zwykłym połączeniu WAN–LAN ruch jest często obsługiwany przez wyspecjalizowany silnik NAT i przełącznik sprzętowy, co pozwala tanim routerom dobijać do 1 Gb/s. Przy włączeniu VPN ten ruch przechodzi przez dodatkową warstwę: szyfrowanie, enkapsulacja pakietów, obsługa protokołów, często w przestrzeni użytkownika (user-space).

Przy łączu 1 Gb/s, nawet jeśli serwer VPN jest bardzo szybki, router może osiągnąć granicę wydajności swojego CPU przy dużo niższej przepustowości. Objawia się to typowo w dwóch formach:

• Limit przepustowości tunelu – prędkość rośnie do pewnego poziomu (np. 150–300 Mb/s) i dalej nie idzie, mimo że łącze fizyczne oraz serwer mają zapas.
• Wysokie pingi i „szarpany” transfer – CPU dobija do 100%, rośnie opóźnienie, pojawia się jitter, rozmowy VoIP i wideokonferencje zaczynają przycinać.

Różnica jest szczególnie odczuwalna przy dużych plikach i wielu jednoczesnych strumieniach. Gigabit bez VPN potrafi ściągać plik z NAS-a w kilka–kilkanaście sekund. Ten sam plik przez przeciążony tunel VPN może transferować się kilka minut.

Ile z gigabita da się realnie wykorzystać w tunelu VPN

Przy domowo-biurowym użyciu nie zawsze jest potrzebne „pełne 1 Gb/s w VPN”. Kluczowe jest zderzenie oczekiwań z tym, co oferuje konkretna technologia i sprzęt.

Praktyczne progi przepustowości, przy których użytkownik widzi różnicę:

• Do ~100 Mb/s – do typowego RDP, pracy w przeglądarce, maila i lekkich plików to wystarcza, ale większe kopie zapasowe i sync dysków zaczynają trwać odczuwalnie długo.
• 200–300 Mb/s – komfortowa prędkość do pracy zdalnej, prostych kopii zapasowych, przesyłania średnich plików w rozsądnym czasie.
• 500+ Mb/s – poziom, przy którym praktycznie przestaje się myśleć o ograniczeniach VPN przy wielu domowych zastosowaniach, nawet z kilkoma użytkownikami.
• 700–900 Mb/s – zakres, gdzie tunel VPN zaczyna zbliżać się do możliwości łącza i staje się realną alternatywą dla bezpośredniego ruchu, np. przy kopiowaniu dużych repozytoriów, backupów, plików multimedialnych.

Na osiągnięcie ostatnich dwóch poziomów szansę mają głównie wydajniejsze routery z nowoczesnym protokołem (WireGuard) i sensownym CPU. OpenVPN, zwłaszcza w tradycyjnej konfiguracji, zazwyczaj „ścina się” znacznie wcześniej.

Krótkie wprowadzenie do protokołów: WireGuard vs OpenVPN

Najważniejsze cechy WireGuard – prostota i wydajność

WireGuard zaprojektowano od zera z myślą o prostocie, wydajności i małej powierzchni ataku. Implementacja jest niewielka, kod łatwiej audytować, a konfiguracja sprowadza się do kilku kluczowych parametrów: kluczy publicznych/prywatnych, adresów IP w tunelu i list dozwolonych sieci.

Podstawowe cechy WireGuard, które mają znaczenie przy gigabitowym łączu:

• działa wyłącznie w oparciu o UDP, co eliminuje narzut TCP-over-TCP i zmniejsza narzut protokołu,
• używa nowoczesnych, wydajnych algorytmów kryptograficznych (m.in. ChaCha20, Poly1305), które dobrze sprawdzają się na procesorach bez sprzętowego AES,
• może działać w przestrzeni jądra (kernel-space), co znacząco ogranicza przełączanie kontekstu i kopiowanie danych między przestrzeniami,
• ma prostą konfigurację, co ułatwia poprawne ustawienie i ogranicza „dziwne” bugi wydajnościowe.

Efekt w praktyce: na tym samym routerze WireGuard potrafi osiągać 2–4 razy wyższą przepustowość niż OpenVPN przy tym samym poziomie sprzętu i jakości łącza.

OpenVPN – elastyczność, kompatybilność, ale kosztem zasobów

OpenVPN to klasyk w świecie VPN. Ma lata rozwoju, ogromną społeczność i obsługę praktycznie na każdej platformie, od routerów po urządzenia mobilne. Jednocześnie jest cięższy, bardziej rozbudowany i zwykle mniej wydajny na słabszym sprzęcie.

Kluczowe cechy OpenVPN, które wpływają na wydajność:

• działa w przestrzeni użytkownika (user-space), co zwiększa narzut przełączania kontekstu między jądrem a procesem OpenVPN,
• może używać zarówno UDP, jak i TCP – konfiguracje na TCP są wygodniejsze z punktu widzenia firewalli, ale wydajnościowo znacznie gorsze (podwójny narzut TCP),
• domyślnie korzysta z szyfrowania opartego o AES, które na CPU bez akceleracji sprzętowej jest cięższe niż ChaCha20; na nowoczesnych CPU z AES-NI potrafi być za to bardzo szybkie,
• ogromna ilość opcji – różne tryby, kompresja, rozbudowane certyfikaty – daje elastyczność, ale przy okazji ułatwia popełnianie błędów konfiguracyjnych, które zabijają prędkość.

OpenVPN wciąż ma sens tam, gdzie liczy się kompatybilność (np. klienci firmowi, stare systemy) i rozbudowane opcje certyfikatów. W kontekście łącza 1 Gb/s w sieci domowo-biurowej, jego słabością jest głównie koszt CPU i narzut protokołu.

Różnice w architekturze a obciążenie CPU routera

Największa różnica między WireGuard a OpenVPN to miejsce, w którym wykonywana jest logika VPN i szyfrowanie. WireGuard w trybie kernelowym może obrabiać pakiety bezpośrednio w jądrze, z minimalnym kopiowaniem danych. OpenVPN, jako proces użytkownika, wymaga przechodzenia pakietów przez dodatkowe bufory.

W skrócie:

• WireGuard w kernel-space: mniejszy narzut, lepsze wykorzystanie cache procesora, mniej systemowych przełączeń, wyższa przepustowość przy tym samym zegarze CPU.
• OpenVPN w user-space: więcej przełączeń kontekstu, większy narzut związany z socketami, większa ilość kopiowania pamięci i buforowania.

Na routerach z relatywnie słabymi CPU ARM lub MIPS różnice te są dramatycznie widoczne. Jeśli taki router dociąga 150–250 Mb/s w OpenVPN, w WireGuard na tych samych parametrach łącza potrafi osiągnąć kilkaset Mb/s więcej, przy niższym zużyciu CPU.

Bezpieczeństwo w praktyce domowo-biurowej

Z perspektywy teorii kryptografii i audytów kodu oba rozwiązania mogą być bezpieczne pod warunkiem rozsądnej konfiguracji. W praktyce domowo-biurowej zagrożenia rzadko wynikają z „teoretycznej słabości algorytmu”, a częściej z błędów w konfiguracji, słabych haseł, niewłaściwego zarządzania certyfikatami lub nieaktualnego oprogramowania routera.

Różnice, które mają praktyczny wymiar:

• Prostota WireGuard zmniejsza ryzyko błędnej konfiguracji, bo nie ma tam setek przełączników i funkcji, które można źle ustawić.
• Rozbudowane PKI OpenVPN daje precyzyjną kontrolę nad certyfikatami, ale jej wdrożenie i utrzymanie wymaga dyscypliny i czasu.
• WireGuard wprowadza pewne wyzwanie w obszarze logowania i anonimizacji (statyczne klucze, bardziej „stateful” podejście do peerów), ale w kontekście dom–biuro jest to mało istotne w porównaniu z kwestią wydajności.

Przy gigabitowym łączu ważniejsze staje się, czy protokół i router umożliwią stabilny, szybki tunel i czy konfiguracja nie będzie zmorą administracyjną. Z tej perspektywy w większości domowo-biurowych zastosowań przewagę zdobywa WireGuard.

Metodologia testów i środowisko pomiarowe

Łącze 1 Gb/s i drugi koniec tunelu VPN

Aby sensownie porównać wydajność WireGuard i OpenVPN na routerach z obsługą VPN, trzeba zminimalizować zmienne po stronie internetu. Do testów zakłada się symetryczne łącze 1 Gb/s lub bardzo zbliżone (down/up), z możliwie niskimi opóźnieniami do serwera VPN. Drugi koniec tunelu zwykle realizuje się jako:

• dedykowany serwer lub wydajny VPS w dużym centrum danych,
• z dużym zapasem CPU (aby to router, a nie serwer, stał się wąskim gardłem),
• z kartą sieciową 1 Gb/s lub szybszą i stabilnym łączem operatorskim.

Istotne, aby serwer nie limitował prędkości (np. tani VPS z limitem łącza do 200 Mb/s sztucznie zaniży wyniki). Stosunek mocy serwera do routera powinien być wyraźnie na korzyść serwera, aby pomiary odzwierciedlały realne możliwości routerów.

Narzędzia pomiarowe: nie tylko iperf3

Do oceny wydajności routera z VPN nie wystarczy pojedynczy test prędkości. Przydatne jest połączenie kilku metod, z których każda pokazuje trochę inne zjawiska:

• iperf3 – test syntetyczny przepustowości TCP/UDP poprzez tunel VPN. Pozwala zmierzyć maksymalną możliwą prędkość przy kontrolowanej liczbie strumieni i czasie.
• Realne kopiowanie plików – np. transfer dużego pliku z NAS za routerem A do maszyny za routerem B, lub z NAS do laptopa poza domem przez VPN. Pokazuje wpływ buforowania, protokołu SMB/NFS i realne wahania transferu.
• Pomiar opóźnień – ping i jitter (odchylenie standardowe opóźnień) do serwera VPN oraz do hostów za tunelem, w czasie obciążenia i w stanie spoczynku.
• Monitorowanie CPU i pamięci – sprawdzanie obciążenia procesora na routerze podczas obciążenia VPN przy różnych prędkościach.

Parametry testów: liczba strumieni, czas trwania, kierunek ruchu

Same narzędzia to dopiero połowa układanki. Sposób ich użycia potrafi wywrócić wyniki do góry nogami. Żeby uniknąć sztucznego „zabijania” VPN-u lub przeciwnie – upiększania wyników, przy testach na łączu 1 Gb/s sens ma kilka prostych zasad.

Podstawowe założenia dla iperf3:

• kilka równoległych strumieni TCP (np. 4–8), bo pojedyncze połączenie bywa mocno ograniczone przez pojedynczy wątek i parametry TCP,
• czas trwania testu min. 30–60 sekund, żeby ustabilizować transfer i wykluczyć chwilowe piki lub przydławienia,
• testy w obu kierunkach: download i upload przez tunel, bo routery często mają asymetrię wydajności (inna ścieżka przetwarzania, inne offloady),
• brak kompresji w VPN – na współczesnych łączach jest ona zazwyczaj tylko stratą CPU, szczególnie przy przesyle już skompresowanych danych (wideo, archiwa, obrazy ISO).

Do tego dochodzi scenariusz „z życia”: kopiowanie dużego pliku (kilka–kilkadziesiąt GB) z NAS-a lub serwera plików za routerem z VPN-em, z jednoczesnym podglądem obciążenia CPU na routerze. Z takiego testu łatwo wychwycić zachowania typu: chwilowe 800 Mb/s i stopniowe „duszenie się” do 300–400 Mb/s, gdy CPU wchodzi w stałe 100%.

Konfiguracje VPN stosowane w pomiarach

Żeby wyniki były porównywalne, sensownie jest ustalić bazową, „zdroworozsądkową” konfigurację dla obu protokołów. Nie jest to maksymalne możliwe tunningowanie, ale setup, który większość osób faktycznie wdroży w domu lub małym biurze.

Typowe ustawienia dla WireGuard przy łączu 1 Gb/s:

• domyślne algorytmy (ChaCha20-Poly1305),
• brak dodatkowej kompresji ani „magicznych” opcji optymalizacyjnych,
• stałe klucze, klasyczna konfiguracja „site-to-site” lub „road-warrior” z jednym serwerem i kilkoma klientami,
• MTU dostosowane do konkretnej trasy (czasem 1420–1440, aby uniknąć fragmentacji przy PPPoE).

Dla OpenVPN opłaca się od razu pominąć klasyczne „pułapki”:

• tryb UDP zamiast TCP (chyba że firewall po drodze na to nie pozwala),
• szyfrowanie AES-GCM (np. AES-128-GCM) przy włączonej akceleracji AES-NI / sprzętowej,
• kompresja wyłączona (lub pozostawiona tylko tam, gdzie naprawdę daje zysk, co przy gigabitowym łączu zdarza się rzadko),
• kilka równoległych połączeń klienta (jeśli router/OS i setup na to pozwalają) zamiast jednego „tunelu wszystkiego”.

Osoby lubiące wyciskać ostatnie megabity mogą później bawić się w drobne korekty (bufory, MSS, dodatkowe offloady). Na start dużo więcej zmienia właściwy wybór protokołu i samego routera niż dłubanie w egzotycznych flagach.

Przegląd testowanych routerów z obsługą VPN

Segment budżetowy: tanie routery z opcją VPN „na metry”

Na rynku jest sporo tanich routerów, które mają w specyfikacji „VPN server / VPN client”, ale w praktyce ich wydajność bywa bardzo skromna. W tym segmencie dominują:

• konstrukcje oparte o dwurdzeniowe SoC ARM w okolicach 700–1000 MHz,
• często tylko OpenVPN w firmware producenta, bez wsparcia WireGuard,
• 1 Gb/s na portach LAN/WAN, ale praktyczna wydajność VPN rzędu 50–150 Mb/s.

Tego typu sprzęt sprawdzi się przy sporadycznym zdalnym dostępie, podglądzie kamery z działki czy jednorazowych pobraniach plików. Przy regularnych backupach czy pracy na repozytoriach kilkadziesiąt–sto megabitów zaczyna frustrować. Jeżeli cena jest absolutnym priorytetem, ratunkiem bywa:

• instalacja alternatywnego firmware (OpenWrt) i przejście na WireGuard,
• świadome pogodzenie się z tym, że to nie będzie tunel „pod pełny gigabit”, a raczej szybki dostęp awaryjny.

Średnia półka: domowo-biurowe routery z sensownym CPU

Tu zaczyna się segment, który ma największy sens przy łączu 1 Gb/s. Są to routery:

• z cztero- lub dwurdzeniowymi SoC ARM w okolicach 1,2–1,8 GHz,
• często z oficjalnym wsparciem WireGuard (czy to natywnie, czy jako aplikacja / moduł),
• z wydajnością NAT bliską gigabitowi oraz przyzwoitym QoS.

To na nich WireGuard potrafi zbliżyć się do 700–900 Mb/s przy dobrym łączu i rozsądnej konfiguracji, a OpenVPN – wciąż często zatrzymuje się na 200–400 Mb/s. Dla małego biura, w którym 2–3 osoby łączą się zdalnie, to zwykle najlepszy kompromis cena–efekt: jeden, dobrze dobrany router zamiast kombinacji taniego routera i osobnego komputera pod VPN.

Prawie biznesowe: routery z mocniejszym CPU x86 lub ARMv8

Wyżej są urządzenia, które z zewnątrz wyglądają jak „zwykły” router, ale w środku mamy mocniejszy CPU (często 4 rdzenie ARM w okolicach 2 GHz lub energooszczędne x86). Taki sprzęt:

• oferuje pełne gigabitowe NAT z zapasem,
• ma zwykle wbudowany serwer WireGuard i OpenVPN z rozbudowanym interfejsem,
• pozwala uruchomić dodatkowe usługi (IDS/IPS, serwer plików, monitoring) bez natychmiastowego „zamulenia” VPN.

W tym segmencie zaczyna być realne uzyskanie bardzo wysokich prędkości w WireGuardzie, często już na poziomie, na którym ograniczeniem stają się same karty sieciowe, stos TCP/IP w systemie operacyjnym po drugiej stronie tunelu lub parametry łącza operatora. Z drugiej strony – cena takiego routera bywa kilkukrotnie wyższa od sprzętu z półki „średniej”, dlatego sens jego zakupu w domu ma głównie wtedy, gdy:

• VPN ma obsługiwać wiele jednoczesnych klientów (np. kilka zdalnych stanowisk pracy),
• poza VPN-em ten sam router ma realizować dodatkowe, wymagające zadania (np. IDS, filtrację ruchu, VLAN-y, policy routing),
• chcemy uniknąć uruchamiania dodatkowego „serwera pod biurkiem” jako koncentratora VPN.

Alternatywa: mały komputer x86 jako router VPN

Jeżeli priorytetem jest wydajność VPN przy możliwie niskim koszcie, rozsądną alternatywą jest mini-PC x86 z dwiema kartami sieciowymi. Tego typu sprzęt można kupić używany (np. małe terminale, „pudełka” po firewallach) i postawić na nim:

• pfSense, OPNsense lub inną dystrybucję routerową,
• bezpośrednio Linuxa z ręczną konfiguracją WireGuard/OpenVPN.

Takie rozwiązanie często za podobne pieniądze oferuje znacznie większy zapas mocy niż router SOHO, ceną jest jednak:

• większy pobór prądu niż typowy router ARM,
• konieczność ręcznego montażu, konfiguracji i utrzymania systemu,
• brak „gotowego” interfejsu w stylu typowego web GUI producenta routera.

Jeżeli ktoś nie boi się instalacji Linuxa, mini-PC potrafi zapewnić pełne 1 Gb/s w WireGuardzie i bardzo wysokie prędkości w OpenVPN (z AES-NI), jednocześnie dając elastyczność konfiguracji daleko wykraczającą poza to, co zwykle oferuje firmware konsumencki.

Wyniki testów WireGuard na łączu 1 Gb/s

Osiągi w segmencie budżetowym: „działa, ale bez fajerwerków”

Na tańszych routerach z przeciętnym CPU ARM, po włączeniu WireGuard i ustawieniu prostego tunelu site-to-site, zwykle udaje się wycisnąć:

• rzędu 150–300 Mb/s przy kilku równoległych strumieniach,
• czasem nieco więcej, jeśli ruch jest jednostronny (np. głównie download) i router ma przyzwoite offloady.

Przy tej klasie sprzętu głównym ograniczeniem jest czysta moc CPU i to, jak producent zaimplementował WireGuard (kernel-space vs user-space, optymalizacje kompilacji). Przykładowy scenariusz: domowy użytkownik łączy się z biurem, pobiera większe repozytorium lub obraz maszyny wirtualnej. Transfery ok. 200 Mb/s po VPN są już odczuwalnie szybsze niż to, co daje często OpenVPN na tym samym urządzeniu, ale nadal daleko tu do wykorzystania pełnego gigabitu.

Średnia półka: WireGuard zaczyna „lubić” gigabit

Na routerach z mocniejszym CPU różnica jest wyraźna. Przy rozsądnej konfiguracji (brak kompresji, dopasowane MTU, kilka strumieni TCP) wyniki iperf3 przez WireGuard potrafią ustabilizować się na poziomie:

• 500–800 Mb/s w obie strony,
• z obciążeniem CPU na poziomie 60–90% na głównym rdzeniu odpowiedzialnym za VPN.

W praktycznych testach kopiowania plików bywa trochę niżej – sieć LAN, protokół SMB/NFS, opóźnienia i cache systemów plików robią swoje. Realne transfery w okolicach 400–700 Mb/s przy dużych plikach są w tym segmencie jak najbardziej osiągalne. To moment, w którym przestaje się czuć, że „VPN boli” przy normalnym wykorzystaniu łącza: kopie zapasowe, praca na repozytoriach, podgląd kamer, zdalny pulpit – wszystko zachowuje się bardzo podobnie jak w lokalnej sieci, o ile nie próbujemy na raz przepchnąć kilku potężnych backupów.

Routery „prawie biznesowe”: WireGuard blisko limitu 1 Gb/s

Na mocniejszych urządzeniach WireGuard potrafi dojść bardzo blisko fizycznego limitu portu gigabitowego. W testach syntetycznych pojawiają się wartości:

• 800–950 Mb/s przy relatywnie stabilnym transferze,
• CPU pracujący wysoko (często 80–100% na części rdzeni), ale bez dramatycznego spadku przepustowości po kilku minutach.

Przy dłuższych sesjach kopiowania plików typowy obraz to lekkie falowanie prędkości: np. okolice 700–900 Mb/s ze sporadycznymi spadkami, które wynikają bardziej z zachowania systemów plików, cache po stronie serwera/NAS-a oraz buforowania po drodze niż z samego protokołu VPN.

Tu szczególnie widać zaletę WireGuard w kernel-space: małe opóźnienia, stosunkowo niewielki jitter i brak „przytykania się” przy większej liczbie jednoczesnych sesji. Nawet przy kilku podłączonych klientach, jeżeli nie wszyscy „walą” pełnym pasmem, odczuwalna responsywność pozostaje bardzo dobra.

Opóźnienia i responsywność tunelu WireGuard

Przepustowość to jedno, drugi aspekt to opóźnienia. Na łączu 1 Gb/s, przy sensownym serwerze po drugiej stronie, WireGuard zwykle dodaje zaledwie:

• kilka–kilkanaście milisekund do RTT (round-trip time) w stosunku do gołego połączenia bez VPN,
• minimalny jitter w porównaniu z OpenVPN przy podobnym obciążeniu CPU.

Dla zdalnego pulpitu, VoIP, wideokonferencji czy gier jest to odczuwalne. Nawet przy sporych transferach w tle (np. kopiowanie plików) da się jeszcze komfortowo prowadzić rozmowę, o ile nie wyciskamy z łącza absolutnego maksimum. Dobrze skonfigurowany QoS i podział pasma potrafią ten efekt jeszcze poprawić, ale sam wybór WireGuard jako protokołu daje solidny punkt wyjścia.

Wyniki testów OpenVPN na łączu 1 Gb/s

Sprzęt budżetowy: ściana CPU przy łączu kilkuset megabitów

W tanich routerach OpenVPN zazwyczaj jest jedyną oficjalnie wspieraną opcją. Niestety, nawet przy konfiguracji UDP i AES, bez kompresji, osiągane prędkości są skromne:

• 50–150 Mb/s przy obciążeniu CPU w okolicach 100%,
• wahania transferu, szczególnie przy jednoczesnym ruchu kilku klientów lub włączeniu dodatkowych funkcji routera (np. filtrowanie ruchu, QoS).

Dla zdalnego pulpitu, tunelu do plików tekstowych czy okazjonalnego pobrania większego pliku jest to akceptowalne. Problem pojawia się, gdy ktoś próbuje wykorzystać takie rozwiązanie do codziennych backupów czy synchronizacji dużych projektów. Jeśli łącze od operatora ma 1 Gb/s, a przez OpenVPN przechodzi 70 Mb/s, uczucie marnowania potencjału jest nieuniknione.

Średnia półka: OpenVPN wyraźnie poniżej możliwości łącza

Na mocniejszych routerach OpenVPN radzi sobie już trochę lepiej, ale wciąż widać jego koszt. Przy rozsądnym zestawie ustawień (UDP, AES-GCM, brak kompresji) i odpowiednio rozłożonych strumieniach TCP efekty najczęściej mieszczą się w widełkach:

OpenVPN na routerach „prawie biznesowych”: nadal daleko od gigabitu

Na najmocniejszych routerach z tej grupy, często reklamowanych jako „gotowych na gigabit VPN”, sytuacja wygląda lepiej, ale nie cudownie. Przy użyciu AES-GCM z akceleracją sprzętową i rozsądnie dobranych parametrach udało się uzyskać:

• 200–400 Mb/s w testach iperf3,
• obciążenie CPU bardzo blisko 100% na jednym lub dwóch rdzeniach odpowiedzialnych za szyfrowanie.

Przy ruchu rzeczywistym (SMB, HTTP, SFTP) prędkości często spadają o kolejne kilkadziesiąt megabitów, szczególnie jeśli równolegle działa IDS/IPS czy bardziej złożone reguły firewall. W praktyce takie urządzenie daje już w miarę komfortową pracę zdalną, ale pełnego potencjału łącza 1 Gb/s nie da się w ten sposób sensownie wykorzystać.

Dobrym testem „życiowym” jest uruchomienie dużego backupu z biura do domu. Na tych routerach OpenVPN pcha dane wyraźnie szybciej niż w segmencie budżetowym, ale różnica względem tego samego scenariusza po WireGuardzie potrafi być dwu-, trzykrotna. O ile pojedynczy użytkownik przełknie taki kompromis, o tyle kilka równocześnie działających backupów potrafi już wyraźnie „przydusić” router.

Opóźnienia i stabilność OpenVPN przy dużym obciążeniu

Przepustowość to jedno, ale przy OpenVPN widać też różnice w opóźnieniach i wahaniach prędkości. Na łączu 1 Gb/s, przy kilku aktywnych strumieniach, tunel dodaje typowo:

• kilkanaście–kilkadziesiąt milisekund do RTT w porównaniu z połączeniem bez VPN,
• nierównomierny jitter – szczególnie przy mocno obciążonym CPU routera.

Przy samej pracy z plikami czy WWW nie jest to wielki problem, ale przy zdalnym pulpicie i VoIP daje się odczuć „gumowe” reakcje. Gdy ktoś jednocześnie kopiuje duże archiwum przez OpenVPN, a druga osoba próbuje prowadzić spotkanie wideo, router z klasy SOHO potrafi przez chwilę zawiesić się na 100% CPU i serwować kilkusekundowe czkawki w strumieniu.

Da się to łagodzić za pomocą QoS i limitów pasma dla tunelu, ale wtedy znów obniża się efektywnie osiągalną przepustowość. Z punktu widzenia „efekt vs wysiłek” na łączu gigabitowym zaczyna to być mało opłacalna walka, jeśli nie ma technicznego powodu, by trzymać się OpenVPN.

Konfiguracje OpenVPN a wydajność: czego unikać na 1 Gb/s

Sam wybór OpenVPN nie przesądza jeszcze o tym, jak bardzo będzie bolało. Kilka ustawień potrafi zabić wydajność nawet na dobrym CPU. Do najgorszych pomysłów przy łączu 1 Gb/s należą:

• TCP-over-TCP – zestawianie tunelu w trybie TCP i puszczanie przez niego głównie ruchu TCP (SMB, HTTP). Efekt: gigantyczne straty wydajności przy gubionych pakietach i retransmisjach.
• kompresja (lz4, lzo) – na współczesnych łączach WAN rzadko się opłaca, a każda kompresja to dodatkowy koszt CPU; na 1 Gb/s praktycznie zawsze wychodzi gorzej niż bez kompresji.
• zbyt „ciężkie” szyfry bez wsparcia sprzętowego – kombinacje z dużymi kluczami i egzotycznymi algorytmami mogą mieć sens w specyficznych środowiskach, ale w domowo-biurowych realiach tylko zjadają cykle CPU.

Bezpieczna i sensowna konfiguracja pod względem wydajności to zazwyczaj UDP, AES-GCM z AES-NI (jeśli CPU go wspiera), bez kompresji i bez przesadnego kombinowania z parametrami TLS. Nawet wtedy jednak na tanim lub średnim routerze nie ma co liczyć na wykorzystanie całego gigabitu.

Porównanie WireGuard vs OpenVPN: liczby, wrażenia i wąskie gardła

Różnice w przepustowości w trzech klasach sprzętu

Aby uporządkować obraz, łatwo to sprowadzić do prostych przedziałów. Dla tunelu site-to-site na łączu 1 Gb/s, przy kilku równoległych strumieniach i bez kompresji, typowe wyniki wyglądają mniej więcej tak:

• Sprzęt budżetowy:
  • WireGuard: ok. 150–300 Mb/s,
  • OpenVPN: ok. 50–150 Mb/s.
• Średnia półka:
  • WireGuard: ok. 500–800 Mb/s (realnie przy plikach 400–700 Mb/s),
  • OpenVPN: ok. 150–300 Mb/s.
• Routery „prawie biznesowe” / mini-PC x86:
  • WireGuard: ok. 800–950 Mb/s w syntetykach, przy realnych obciążeniach bardzo blisko limitu 1 Gb/s,
  • OpenVPN: ok. 200–400 Mb/s przy wysokim obciążeniu CPU.

Nawet uwzględniając rozrzut wyników pomiędzy konkretnymi modelami i firmware, trend jest czytelny: na tym samym sprzęcie WireGuard daje zwykle od 2 do 4 razy większą przepustowość niż OpenVPN. Im słabszy procesor, tym różnica bardziej boli – w tanich routerach OpenVPN zjada praktycznie cały budżet CPU, podczas gdy WireGuard zostawia jeszcze trochę zapasu na zwykły ruch NAT.

Doświadczenia użytkowe: nie tylko megabity na wykresie

W liczbach WireGuard wygląda lepiej, ale różnica jest też odczuwalna „na oko”. Kilka prostych scenariuszy dobrze to pokazuje:

• zdalny pulpit przy tle backupu – przy OpenVPN kursor potrafi „skakać” co kilka sekund, a obraz odświeża się skokowo; ten sam test po WireGuardzie jest znacznie płynniejszy, nawet jeśli backup w tle korzysta z podobnej przepustowości.
• praca na repozytorium git – przy WireGuardzie operacje typu clone/pull na dużych projektach kończą się zauważalnie szybciej, szczególnie na średnich i mocniejszych routerach; przy OpenVPN-ie ten sam zestaw operacji wydłuża się niekiedy o kilkadziesiąt procent.

Różnice wychodzą też przy większej liczbie jednoczesnych klientów. WireGuard, dzięki prostszej architekturze i implementacji w przestrzeni jądra, trzyma stabilne opóźnienia nawet wtedy, gdy kilka osób jednocześnie korzysta z tunelu. OpenVPN częściej zaczyna „pływać” – przy chwilowym piku ruchu jednego klienta pozostali odczuwają podskakiwanie pingów i chwilowe spadki prędkości.

Główne wąskie gardła: gdzie naprawdę kończy się gigabit

Przy porządnym routerze i WireGuardzie problem coraz rzadziej leży po stronie samego protokołu. W praktyce „sufit” robią inne elementy łańcucha:

• CPU po drugiej stronie tunelu – jeśli serwer VPN to stary NAS czy słaby VPS, szyfrowanie i deszyfrowanie po jego stronie może ograniczać prędkość znacznie poniżej możliwości routera.
• pamięć masowa – talerzowy NAS, który daje 100–150 Mb/s przy sekwencyjnym zapisie, będzie takim samym ograniczeniem przez VPN, jak i lokalnie; to samo dotyczy tanich dysków USB podpiętych do routera.
• stos TCP/IP i ustawienia systemu – zbyt małe bufory, brak window scaling, słabo dobrane parametry kernelowe potrafią przytkać nawet szybkie łącze, szczególnie przy dłuższych trasach między końcami tunelu.
• jakość łącza od operatora – opóźnienia, zmienne trasy, shaping po stronie ISP; te czynniki bywają ważniejsze niż różnica między 700 a 900 Mb/s w idealnych warunkach labowych.

Na domowo-biurowych łączach często okazuje się, że po przesiadce z OpenVPN na WireGuard pierwszy „mur” przepustowości znika, a kolejne ograniczenie wychodzi już po stronie serwera plików, dysku lub infrastruktury operatora.

Overhead protokołu i efektywna wykorzystana przepustowość

Sama „goła” liczba z iperf3 nie mówi wszystkiego. Przy tunelach VPN zawsze występuje narzut nagłówków i pakiety są powiększane o dodatkowe metadane. Różnica między WireGuard a OpenVPN wygląda tak:

• WireGuard ma stosunkowo mały i przewidywalny overhead – w praktyce kilka procent przepustowości „znika” na nagłówki; przy 1 Gb/s różnica w stosunku do połączenia bez VPN jest zauważalna, ale nie dramatyczna.
• OpenVPN, szczególnie w trybie TCP, potrafi mieć znacznie większy narzut, a do tego dochodzą konsekwencje retransmisji, potwierdzeń i „walki” dwóch warstw TCP – realna użyteczna przepustowość potrafi być kilkukrotnie niższa niż teoretyczna.

Efekt jest taki, że nawet jeśli oba protokoły w syntetycznym teście pokażą zbliżone megabity (co i tak jest rzadkie), to przy prawdziwych aplikacjach WireGuard zwykle dowozi więcej „pożytecznych” danych w tym samym czasie.

Bezpieczeństwo i dojrzałość kontra wydajność

Część administratorów trzyma się OpenVPN nie z przyzwyczajenia, lecz z powodu rozbudowanych funkcji: finezyjne mechanizmy autoryzacji, integracje z istniejącą infrastrukturą (np. RADIUS, LDAP), dobrze znane procedury audytu. W wielu firmach dołożenie nowego protokołu to osobny projekt, a nie tylko kliknięcie w panelu.

Z perspektywy wydajności na 1 Gb/s różnica jest jednak wyraźna. Jeżeli:

• tunel ma głównie zapewnić bezpieczny dostęp do kilku usług,
• nie ma twardych wymogów trzymania się konkretnego protokołu,
• a sensowne jest wykorzystanie dostępnej przepustowości łącza,

to inwestowanie w coraz mocniejszy sprzęt pod OpenVPN dobijający najwyżej do kilkuset megabitów zwykle nie ma sensu ekonomicznego. Dużo częściej opłaca się przejść na WireGuard (choćby na skromnym mini-PC) niż kupować droższy router tylko po to, żeby przepchnąć przez OpenVPN 300 zamiast 150 Mb/s.

Próg opłacalności: kiedy przesiadka na WireGuard naprawdę się zwraca

Patrząc na relację „efekt vs wysiłek”, sensowny moment na zmianę protokołu lub sprzętu można ująć w kilku prostych punktach. WireGuard zaczyna wygrywać bezdyskusyjnie, gdy:

• łącze od operatora ma 500 Mb/s lub więcej, a OpenVPN na obecnym routerze dusi się na 100–150 Mb/s,
• codziennie wykonuje się większe backupy lub przesyła duże zbiory danych między lokalizacjami,
• użytkownicy skarżą się na „ociężały” zdalny pulpit, podczas gdy lokalnie w sieci wszystko działa szybko,
• router pracuje już blisko granicy wydajności i każdy dodatkowy ficzer powoduje widoczny spadek przepustowości VPN.

W takich sytuacjach sama zamiana OpenVPN na WireGuard – nawet bez wymiany sprzętu – potrafi przynieść zauważalny zysk. Jeżeli firmware routera tego nie oferuje, najprostszym i często najtańszym krokiem jest wpięcie małego komputera x86 jako koncentratora WireGuard i zostawienie istniejącego routera wyłącznie jako urządzenia brzegowego z NAT-em.

Najczęściej zadawane pytania (FAQ)

Jaki router z VPN potrzebuję do łącza 1 Gb/s?

Do łącza 1 Gb/s szukaj routera z wydajnym CPU (nie najtańsze „plastiki” za kilkadziesiąt zł) i obsługą WireGuard w systemie routera. W praktyce przy gigabicie sens mają dopiero modele z mocniejszym, wielordzeniowym procesorem i minimum kilkuset megaherców na rdzeń.

Jeśli budżet jest ograniczony, priorytetem powinna być obsługa WireGuard i realne testy przepustowości VPN, a nie „1 Gb/s w specyfikacji WAN”. Lepiej wziąć tańszy router z dobrym WireGuardem, który zrobi 400–600 Mb/s w tunelu, niż drogi model, który oferuje tylko wolny OpenVPN.

Czy VPN na routerze jest szybszy niż VPN na komputerze?

Sam z siebie nie jest ani szybszy, ani wolniejszy – wszystko rozbija się o moc CPU. Jeśli masz słaby router i mocny komputer, to klient VPN na PC może osiągnąć lepsze prędkości niż tunel na routerze. Przy wydajnym routerze efekt jest odwrotny: jeden szybki tunel obsłuży całą sieć bez dodatkowego obciążania komputerów.

Pod kątem wygody i czasu konfiguracji VPN w routerze wygrywa przy kilku urządzeniach w domu czy małym biurze. Raz ustawiony tunel obsłuży laptopy, TV, konsole i IoT bez instalowania osobnych aplikacji VPN.

WireGuard czy OpenVPN – co wybrać do łącza 1 Gb/s?

Do gigabitowego łącza zdecydowanie częściej opłaca się WireGuard. Na tym samym sprzęcie potrafi być 2–4 razy szybszy od OpenVPN, ma prostszą konfigurację i mniejszy narzut na CPU. To realnie przekłada się na wyższe prędkości przy niższych kosztach sprzętu.

OpenVPN ma sens głównie tam, gdzie krytyczna jest kompatybilność (np. starsze systemy, gotowe konfiguracje od działu IT) lub bardzo rozbudowana infrastruktura certyfikatów. Do domowo-biurowego tunelu site-to-site i dostępu do NAS-a WireGuard zwykle daje lepszy stosunek „przepustowość za złotówkę”.

Ile realnie wyciągnę w VPN z łącza 1 Gb/s?

W typowych, „budżetowych” warunkach nie ma co liczyć na pełen gigabit w VPN. Na tańszych routerach z OpenVPN kończy się często na 100–200 Mb/s. Przy sensownie dobranym routerze z WireGuardem osiągalne są wartości rzędu 400–700 Mb/s, a w lepiej dobranych konfiguracjach nawet 700–900 Mb/s.

Przy pracy zdalnej i codziennych zadaniach komfort zaczyna się w okolicach 200–300 Mb/s. Pełny gigabit ma znaczenie głównie wtedy, gdy często kopiujesz duże pliki (backupy, materiały wideo, repozytoria) między lokalizacjami.

Kiedy w ogóle opłaca się inwestować w router z VPN?

Router z mocnym VPN ma sens, gdy tunel działa praktycznie non stop: praca zdalna do firmowej sieci, stały dostęp do domowego NAS-a, połączenia site-to-site między biurem a magazynem czy bezpieczny dostęp do automatyki domowej i kamer.

Jeśli VPN włączasz raz w miesiącu na laptopie, wygodniej i taniej będzie zostać przy kliencie na komputerze. Inwestycja w lepszy router „zwraca się” wtedy, gdy kilka osób codziennie korzysta z tunelu i każda sekunda czekania na pliki czy zrywające się połączenia to realny koszt czasu pracy.

Dlaczego mam tylko 100–200 Mb/s w VPN przy łączu 1 Gb/s?

Najczęściej wąskim gardłem jest CPU routera. Przy normalnym ruchu WAN–LAN pakiety obsługuje sprzętowy NAT i przełącznik, więc nawet tani router „robi gigabit”. Po włączeniu VPN każdy pakiet musi zostać zaszyfrowany, opakowany i obsłużony przez dodatkową warstwę oprogramowania, co szybko dobija procesor do 100%.

Typowe objawy to: prędkość tunelu zatrzymuje się na pewnym poziomie mimo zapasu po obu stronach, rosną pingi, transfer „szarpie”, wideokonferencje zaczynają się przycinać. Rozwiązaniem jest albo zmiana protokołu na lżejszy (WireGuard zamiast OpenVPN), albo wymiana routera na model z mocniejszym CPU.

Czy do prostego home office potrzebuję pełnego 1 Gb/s w VPN?

W większości przypadków nie. Do pracy na RDP, systemach księgowych, webowych panelach i okazjonalnych plikach wystarcza stabilne 100–200 Mb/s. Wyższe prędkości są odczuwalne głównie przy dużych backupach, synchronizacji dysków i pracy na dużych projektach (np. wideo, grafika).

Sensownie jest dobrać sprzęt tak, żeby bez bólu osiągał co najmniej 200–300 Mb/s w tunelu. To zazwyczaj tańsze i bardziej opłacalne niż polowanie na konfigurację, która faktycznie dociągnie VPN-em pełne 1 Gb/s.