Dlaczego szyfrowanie zwalnia sieć – ale musi?
Równowaga między bezpieczeństwem a wydajnością
Każde szyfrowanie w sieci firmowej ma swoją cenę. Tą ceną jest głównie czas procesora, dodatkowe bajty w pakietach i kilka nowych punktów, które mogą stać się „wąskim gardłem”. Z drugiej strony, brak szyfrowania to dziś praktycznie otwarte zaproszenie do kradzieży danych, podsłuchu i ataków typu man-in-the-middle. Dlatego celem nie jest pytanie „czy szyfrować?”, tylko jak szyfrować tak, żeby sieć nadal była szybka i przewidywalna.
Porównaj to do wysyłania paczek. Możesz wkładać towar luzem do koperty – tanio i szybko – ale pierwsza ulewa albo ciekawszy listonosz zrobią swoje. Możesz też każdą przesyłkę pakować w kilka warstw folii bąbelkowej, karton i taśmę. Jest bezpiecznie, ale wysyłka jest wolniejsza, droższa, a do busa wchodzi mniej paczek. Rozsądna firma logistyczna szuka złotego środka, dopasowując poziom zabezpieczenia do wartości i wrażliwości towaru. Z siecią jest dokładnie tak samo.
Szyfrowanie w sieci firmowej nie musi drastycznie spowalniać pracy użytkowników. Najczęściej problem nie leży w samym szyfrowaniu, lecz w nieoptymalnym projekcie sieci, złej konfiguracji VPN lub źle dobranym sprzęcie. Dobrze zaprojektowana infrastruktura jest w stanie obsłużyć szyfrowany ruch przy akceptowalnym wzroście opóźnień, który dla użytkownika jest praktycznie niewidoczny.
„Wolno, bo szyfrujemy” vs „wolno, bo źle zaprojektowane”
W wielu firmach szyfrowanie jest pierwszym podejrzanym, gdy tylko pojawi się narzekanie na wolny dostęp do zasobów. W praktyce często okazuje się, że:
- VPN terminowany jest na małym firewallu, który dawno przekroczył swoje możliwości sprzętowe,
- tunel IPSec dodaje spory narzut do rozmiaru pakietu i wszystko zaczyna się fragmentować,
- cały ruch internetowy użytkowników zdalnych jest bezrefleksyjnie przepychany przez centralę (full-tunnel), dławąc łącze,
- algorytmy szyfrowania dobrano kiedyś „na zapas” (np. 3DES, nieoptymalne zestawy cipher suites) i nikt tego od lat nie dotknął.
W takiej sytuacji próba „przyspieszenia” sieci przez wyłączenie szyfrowania jest jak próba naprawienia zakorkowanego skrzyżowania poprzez zdjęcie świateł i znaków drogowych. Może na chwilę coś ruszy, ale problem leży gdzie indziej. Dużo lepszym podejściem jest zidentyfikowanie realnego wąskiego gardła: czy to CPU, czy łącze, czy może parametry tunelu.
Gdzie spadek wydajności jest odczuwalny najbardziej
Szyfrowanie nie obciąża wszystkich typów ruchu w tej samej skali. Są obszary, gdzie każdy dodatkowy milisekund ma znaczenie i takie, gdzie narzut jest praktycznie niezauważalny. W praktyce administratorzy najczęściej słyszą skargi w trzech scenariuszach:
Zdalna praca użytkowników. Tu kumuluje się kilka efektów: domowe łącza, dodatkowe opóźnienie przez VPN, czasem słaby router po stronie użytkownika i przeciążony koncentrator VPN w centrali. Użytkownik widzi to jako „zamulenie” aplikacji, wolne otwieranie plików, lagi w RDP.
Dostęp do aplikacji w chmurze przez firmowy VPN. Jeżeli ruch do SaaS (np. Microsoft 365, CRM w chmurze) jest najpierw tunelowany do centrali, a dopiero potem wychodzi do internetu, robi się „U-turn” ruchu. To wydłuża drogę pakietu i obciąża łącza centralne. U wielu firm przejście na split-tunnel lub lokalny breakout do internetu dało większy efekt niż jakiekolwiek „tuningi” algorytmów szyfrowania.
Połączenia między oddziałami (site-to-site). Jeżeli tunel IPSec jest źle zestawiony (złe MTU, przestarzałe algorytmy, brak sprzętowego wsparcia), to wraz z rosnącym ruchem zaczyna się „duszony” transfer, a aplikacje biznesowe (ERP, systemy magazynowe) zaczynają się zachowywać dziwnie: logowanie trwa długo, transakcje „mielą”, a czasem coś się rozłącza.
Poziomy szyfrowania – dlaczego nie wszystko wrzucać do jednego worka
W sieci firmowej szyfrowanie może działać na kilku różnych warstwach:
- Poziom aplikacji – najczęściej TLS/HTTPS dla stron WWW, API, poczty (IMAPS/SMTPS), protokołów takich jak LDAP over SSL, itp.
- Poziom transportu / sieci – VPN (IPSec, SSL VPN, WireGuard, OpenVPN), który „pakuje” całe połączenia w dodatkowy tunel.
- Poziom dysku / systemu – szyfrowanie dysków (BitLocker, LUKS), szyfrowanie baz danych, backupów itp.
Każdy z tych poziomów ma inne konsekwencje dla wydajności. TLS na poziomie aplikacji głównie obciąża serwer (CPU podczas handshaku i odszyfrowywania), ale sam ruch przez sieć zwykle rośnie tylko o niewielki procent. Z kolei VPN na poziomie transportu dodaje dodatkowe nagłówki, zmiany MTU, a czasem dodatkowe przejścia przez urządzenia pośredniczące – tu wpływ na łączność i parametry sieci jest znacznie bardziej odczuwalny.
Szyfrowanie dysków wpływa natomiast głównie na wydajność I/O i jest niemal niezależne od wydajności sieci. Dlatego mieszanie wszystkich „szyfrowań” w jedną kategorię często tylko zaciemnia obraz. Żeby coś zoptymalizować, trzeba precyzyjnie wskazać które szyfrowanie i na jakim poziomie powoduje problem.
Podstawy szyfrowania w sieciach firmowych – co faktycznie obciąża łącze i serwery
Symetryczne i asymetryczne szyfrowanie – o co tutaj chodzi dla wydajności
Silnikiem większości współczesnych rozwiązań są dwa rodzaje kryptografii: symetryczna i asymetryczna. Z punktu widzenia wydajności trzeba jasno oddzielić ich role.
Szyfrowanie symetryczne (np. AES, ChaCha20) korzysta z jednego klucza do szyfrowania i odszyfrowywania. Jest szybkie, dobrze nadaje się do „ciągłego” szyfrowania dużych ilości danych w ruchu. To główny „koniu pociągowy” w TLS, IPSec, WireGuardzie i większości VPN-ów.
Szyfrowanie asymetryczne (np. RSA, ECDSA, ECDH/ECDHE) używa pary kluczy: prywatnego i publicznego. Jest znacznie cięższe obliczeniowo. W praktyce wykorzystuje się je głównie do:
- uwierzytelnienia (podpisy cyfrowe, certyfikaty),
- wymiany kluczy dla algorytmów symetrycznych (np. w handshaku TLS).
Większość „ciężkiej” pracy kryptograficznej dzieje się na etapie nawiązywania połączenia (handshake). Potem, gdy już ustalone zostaną klucze sesyjne, ruch aplikacyjny szyfrowany jest szybkim algorytmem symetrycznym.
Handshake, sesja i ich koszt w TLS/VPN
Przy każdym nowym połączeniu TLS (np. użytkownik otwiera stronę HTTPS) serwer i klient wykonują handshake. Ustalają wersję protokołu, pakiet szyfrów (cipher suite), negocjują klucze sesyjne i weryfikują certyfikaty. To jest moment, w którym:
- wykonywane są operacje asymetryczne (np. ECDHE, ECDSA),
- przetwarzane są certyfikaty X.509,
- powstaje nowy klucz sesyjny do szyfrowania symetrycznego.
Ten etap jest „drogi” dla CPU, szczególnie przy dużej liczbie krótkich połączeń. Dlatego serwery, które obsługują tysiące nowych połączeń HTTPS na sekundę, stosują:
- utrzymywanie połączeń (keep-alive),
- re-use sesji TLS lub sesji resumption,
- TLS offloading na dedykowanych urządzeniach (load balancerach, reverse proxy).
W VPN-ach sytuacja jest podobna, ale handshake wykonywany jest dużo rzadziej: tunel zestawia się na dłużej. Dlatego w ich przypadku bardziej od liczby sesji boli ciągły transfer danych i jego narzut.
Kluczowe technologie szyfrowania w sieciach firmowych
W typowej infrastrukturze spotkasz kilka głównych technologii, z których każda ma inny profil wydajnościowy:
- TLS/HTTPS – podstawa bezpiecznego ruchu do serwisów WWW, API, poczty. Obciąża głównie serwery aplikacyjne / reverse proxy. Zwykle nie powoduje odczuwalnego spadku przepustowości łącza.
- IPSec – najpowszechniejsza technologia VPN site-to-site (oddziały ↔ centrala, centrala ↔ chmura). Dodaje nagłówki AH/ESP, często współpracuje z GRE. Narzut na pakiety jest wyraźny, ale przewidywalny.
- SSL VPN (np. AnyConnect, GlobalProtect, OpenVPN w trybie TLS) – popularne rozwiązanie dla zdalnych użytkowników. Działa na poziomie aplikacji (TCP/443), łatwo przechodzi przez firewalle, ale może mieć dodatkowy narzut wynikający z tunelowania na TCP.
- WireGuard – nowoczesny, lekki protokół VPN działający w jądrze systemu (Linux, BSD, itp.), z bardzo prostym zestawem kryptografii (ChaCha20, Poly1305, Curve25519). Zaprojektowany z myślą o prostocie i wydajności.
- OpenVPN – elastyczny, ale cięższy, potrafi pracować na UDP lub TCP, często używany tam, gdzie trzeba „przebić się” przez restrykcyjne firewalle. Wymaga starannego tuningu, by osiągnąć dobrą wydajność.
Znając te technologie, łatwiej określić, który element infrastruktury jest odpowiedzialny za spadek wydajności. VPN site-to-site będzie obciążał routery/firewalle i łącza między lokalizacjami. Z kolei TLS spowolni głównie serwery aplikacji, zwłaszcza przy dużej liczbie krótkich połączeń.
Narzut w pakiecie – skąd biorą się dodatkowe bajty
Każdy tunel czy warstwa szyfrowania oznacza dodatkowe nagłówki. Można to zobaczyć patrząc na pojedynczy pakiet IP:
- zwykły pakiet IP niesie dane aplikacji (np. HTTP),
- pakiet TLS/HTTPS ma dodatkowy nagłówek TLS, ale pozostaje w „tym samym” IP,
- pakiet w tunelu IPSec może być opakowany w dodatkowy nagłówek IP + nagłówki ESP/AH,
- OpenVPN może dołożyć kolejną warstwę (np. UDP), a jeszcze GRE – kolejną.
Każdy taki nagłówek „zjada” część maksymalnego rozmiaru pakietu (MTU). Jeżeli nie zostanie to uwzględnione, pakiety mogą ulec fragmentacji – czyli zostaną podzielone na kilka mniejszych, co:
- zwiększa liczbę pakietów do przetworzenia przez routery,
- zwiększa podatność na straty pakietów (zagubienie jednego fragmentu unieważnia całość),
- powoduje dziwne i trudne do zdiagnozowania problemy w aplikacjach.
To właśnie ten „ukryty” narzut często jest odpowiedzialny za słabą wydajność VPN, a nie sam algorytm szyfrowania.
Gdzie naprawdę ginie wydajność – CPU, MTU, RTT i inne ciche zabójcy
Obciążenie CPU i pamięci przy szyfrowaniu
Szyfrowanie to przede wszystkim intensywna praca procesora. Każdy pakiet, który wchodzi i wychodzi z tunelu VPN, musi zostać zaszyfrowany/odszyfrowany. Im więcej ruchu, tym więcej cykli CPU. Jeżeli router, firewall lub serwer aplikacyjny pracuje blisko 100% obciążenia procesora, zaczynają się typowe objawy:
- skoki opóźnień (jitter),
- losowe rozłączenia sesji VPN,
- wyraźny spadek przepustowości przy godzinach szczytu.
Ważne jest rozróżnienie dwóch typów obciążenia:
- krótki, intensywny pik CPU podczas handshake (TLS, IPSec),
- ciągłe obciążenie przy dużym, stałym transferze szyfrowanych danych.
Serwery WWW i API cierpią głównie z powodu pierwszego (tysiące handshaków na sekundę), natomiast koncentratory VPN i routery między oddziałami – z powodu drugiego. W praktyce oznacza to inne podejście do optymalizacji: dla serwerów kluczowe są mechanizmy typu TLS offloading, keep-alive, session resumption; dla VPN – dobór sprzętu, wsparcie AES-NI, akceleratory kryptograficzne.
Handshake vs ruch stały – dlaczego wiele krótkich połączeń boli
Jeśli aplikacja tworzy wiele krótkich połączeń HTTPS (np. mikroserwisy, agresywne API, aplikacje mobilne), overhead z handshaków może stać się dominującym czynnikiem. Każdy handshake to:
- kilka wymian pakietów (round-tripów),
- kilka kosztownych operacji kryptograficznych,
RTT, okno TCP i szyfrowanie – dlaczego „daleka” centrala zawsze wydaje się wolna
Gdy użytkownicy narzekają, że „w domu VPN działa wolniej niż w biurze”, często winowajcą nie jest sam tunel ani algorytm szyfrowania, tylko RTT (round-trip time), czyli czas podróży pakietu tam i z powrotem. Szyfrowanie dorzuca do tego swoją cegiełkę – każda dodatkowa warstwa i urządzenie po drodze dokłada kilka milisekund opóźnienia na przetworzenie pakietu.
Przepustowość TCP w dużej mierze zależy od relacji między wielkością okna TCP a RTT. Im większe opóźnienie między końcami połączenia, tym wolniej rośnie okno i tym dłużej trwa „rozpędzanie się” połączenia. Dodaj do tego tunel VPN, który przechodzi przez kilka dodatkowych routerów i firewalli, a uzyskasz zestaw czynników, które tną realną przepustowość o połowę lub więcej – mimo że łącze „na papierze” jest szybkie.
Typowy scenariusz: aplikacja kliencka łączy się z serwerem w centrali przez IPSec site-to-site. Po drodze pakiet jest:
- zabezpieczany na routerze w oddziale (szyfrowanie + enkapsulacja),
- przesyłany przez kilku operatorów,
- odszyfrowywany w centrali, przechodząc dodatkowo przez firewall aplikacyjny.
Każdy z tych elementów dodaje swoją porcję milisekund. Jeżeli dołożysz do tego wysoki packet loss (nawet 1–2%), TCP zaczyna mocno ograniczać tempo wysyłania, bo „widzi” to jako przeciążenie sieci. W praktyce oznacza to, że latencja + strata + szyfrowanie tworzą mieszankę, która potrafi bardziej zepsuć wydajność niż jakikolwiek narzut na bajty w pakiecie.
MTU, MSS i PMTUD – gdy „niewidzialne” limity łamią VPN
Temat MTU wielu administratorów odkłada na później – do momentu, aż połowa aplikacji zaczyna dziwnie działać przez VPN. Z szyfrowaniem sprawa jest o tyle podstępna, że dokłada ono dodatkowe nagłówki, a więc faktycznie zmniejsza ilość danych, jaką można zmieścić w pojedynczym pakiecie. Jeśli po drodze trafisz na łącze z niższym MTU (np. 1492, 1476, 1400), konieczna jest fragmentacja lub zmniejszenie rozmiaru segmentu TCP (MSS).
Jeśli wszystko zadziała wzorcowo, mechanizm Path MTU Discovery (PMTUD) poinformuje nadawcę, że musi wysyłać mniejsze pakiety. Problem w tym, że w praktyce:
- routery i firewalle często blokują pakiety ICMP „Fragmentation needed”,
- niektóre urządzenia VPN nieprawidłowo tworzą lub przekazują te komunikaty,
- administrator ustawia MTU „na oko”, nie testując faktycznej ścieżki.
Efekt? Zamrożone sesje HTTPS, przycinające się pliki przez SMB, losowe rozłączenia RDP – zwykle tylko przy większych transferach, bo małe pakiety mieszczą się bez problemu. W logach czysto, łącze „jest”, a ludzie i tak narzekają.
W praktyce często pomaga proste podejście: obniżenie MTU na interfejsie tunelu (np. do 1400–1420 bajtów), ustawienie clamp MSS to PMTU na routerach granicznych i upewnienie się, że kluczowe segmenty sieci poprawnie przepuszczają niezbędne komunikaty ICMP. To nie jest „magia”, tylko wyrównanie parametrów do realnych możliwości ścieżki.
Kolejki, QoS i buforbloat – jak szyfrowanie utrudnia „porządkowanie” ruchu
Szyfrowanie ma też nieoczywisty skutek uboczny: ogranicza możliwości klasyfikacji i kształtowania ruchu. Jeżeli cały ruch z oddziału trafia do centrali w jednym wielkim tunelu IPSec, router pośredni widzi tylko „jeden strumień” zaszyfrowanych pakietów. Nie jest w stanie łatwo odróżnić VoIP od kopii zapasowej czy RDP od streamingu wideo.
Bez sensownego QoS i zarządzania kolejkami zaczyna się zjawisko buforbloatu – duże bufory w routerach i urządzeniach dostępnych „gładko” przyjmują ruch, ale gdy przychodzi moment przeciążenia, opóźnienie eksploduje. Użytkownik ma „pełny pasek” przepustowości, a jednak wideokonferencja się zacina, bo pakiety VoIP stoją w kolejce za ogromną paczką danych z backupu przechodzącego przez ten sam tunel.
Szyfrowanie nie powoduje buforbloatu samo z siebie, ale znacznie utrudnia sensowną politykę kolejkowania. Rozwiązaniem jest często:
- stosowanie oddzielnych tuneli dla różnych klas ruchu (np. osobny tunel tylko dla VoIP),
- kształtowanie ruchu przed zaszyfrowaniem – na routerze brzegowym w oddziale, według adresów źródłowych/docelowych i portów,
- dobór urządzeń, które potrafią robić QoS na zaszyfrowanym ruchu z użyciem DSCP lub innych znaczników przenoszonych przez tunel.
Gdy użytkownicy odczuwają dramatyczne opóźnienia tylko wtedy, gdy „ktoś coś wielkiego ściąga”, często nie chodzi o wydajność algorytmu szyfrowania, tylko o brak sensownej polityki kolejkowania i priorytetyzacji.
Implementacja w jądrze vs w przestrzeni użytkownika – dlaczego WireGuard „lata”, a OpenVPN nie zawsze
Spory kawałek wydajności „gubi się” nie w samej kryptografii, lecz w tym, gdzie i jak jest zaimplementowana. Protokół działający w jądrze systemu (kernel space) ma zdecydowanie mniej przełączeń kontekstu, mniej kopiowania danych między buforami i może korzystać z bardziej bezpośredniego dostępu do stosu sieciowego.
WireGuard jest dobrym przykładem: prosta kryptografia, niewielka liczba linii kodu, integracja z jądrem – i nagle okazuje się, że ten sam serwer jest w stanie obsłużyć zauważalnie więcej ruchu niż przy OpenVPN, który często działa w przestrzeni użytkownika, z dodatkową warstwą logiki i abstrakcji. Gdy do tego dochodzi TLS po stronie OpenVPN (tryb TCP/443), obciążenie CPU i koszty kontekstu rosną jeszcze mocniej.
Wysokie opóźnienia, niskie throughputy i dziwne „przytykanie się” przy dużych transferach często znikają po migracji z ciężkiej implementacji użytkownikowej na lżejsze rozwiązanie jądrowe. Nie oznacza to, że zawsze trzeba „przepisywać” infrastrukturę, ale że w pewnym momencie sama wymiana algorytmu szyfrowania z AES na ChaCha20 nie wystarczy – ograniczeniem staje się architektura implementacji.
Algorytmy i protokoły – które szyfrują „ciężej”, a które lżej
AES vs ChaCha20 – teoria, praktyka i różne platformy
W sieciach firmowych najczęściej spotka się dziś dwa główne konie pociągowe: AES i ChaCha20. Na papierze obydwa potrafią być bardzo szybkie, ale w różnych środowiskach pokazują swoje mocne strony w odmienny sposób.
AES (szczególnie w trybie GCM) jest świetnie wspierany przez współczesne procesory x86 dzięki instrukcjom AES-NI. Jeżeli router, firewall czy serwer ma sprzętowe wsparcie AES, różnica między „bez szyfrowania” a „AES-GCM” w praktyce bywa zaskakująco mała – szczególnie przy ruchu, którego nie da się w pełni wysycić łącza. Problem pojawia się na starszym sprzęcie lub platformach bez AES-NI, gdzie AES staje się zauważalnie cięższy.
ChaCha20-Poly1305 projektowano z myślą o wysokiej wydajności na procesorach bez akceleracji AES – np. na ARM-ach, routerach SOHO, urządzeniach mobilnych. Tam często wygrywa z AES-em, bo jest prostszy i bardziej „przyjazny” dla ogólnej architektury CPU. Dlatego wiele nowoczesnych protokołów (np. WireGuard, TLS 1.3 w przeglądarkach mobilnych) chętnie używa ChaCha20, gdy wykryje brak AES-NI.
Dobór algorytmu nie powinien być więc decyzją „z tabelki”, tylko rezultatem odpowiedzi na kilka pytań:
- Na jakiej platformie to będzie działać (x86 z AES-NI czy słabszy ARM)?
- Czy bardziej ogranicza nas CPU, czy łącze (gigabit vs łącze radiowe)?
- Czy są wymagania compliance (np. FIPS dopuszcza konkretny zbiór algorytmów)?
W praktyce w środowisku serwerowym, z nowym sprzętem, AES-GCM bywa nadal najlepszym wyborem. Na małych routerach lub urządzeniach mobilnych często lepiej sprawdza się ChaCha20, nawet jeśli nominalnie „benchmarki” na desktopach pokazują odwrotne wyniki.
Tryby pracy AES – CBC, GCM i ich wpływ na wydajność
Oprócz samego algorytmu szyfrującego liczy się tryb pracy. Dwa najczęściej spotykane w starych i nowszych wdrożeniach to:
- CBC (Cipher Block Chaining) – popularny w starszych wersjach TLS i IPSec, wymaga sekwencyjnego przetwarzania bloków.
- GCM (Galois/Counter Mode) – nowszy, łączy szyfrowanie z uwierzytelnieniem (AEAD), dobrze nadaje się do równoległego przetwarzania bloków.
AES-CBC jest podatny na pewne klasy ataków, a do tego dużo trudniej go sensownie przyspieszyć. Każdy blok zależy od poprzedniego, co ogranicza możliwości równoległego przetwarzania. AES-GCM z kolei pozwala na większą równoległość obliczeń, a przy wsparciu sprzętowym potrafi być naprawdę szybki. Dlatego w większości nowych wdrożeń TLS, IPSec i VPN dochodzi do migracji z AES-CBC na AES-GCM lub inne tryby AEAD.
Aktualizacja konfiguracji szyfrów w TLS/SSH/VPN z „historycznych” ustawień (AES-CBC + HMAC) na nowoczesne (AES-GCM, ChaCha20-Poly1305) często przynosi podwójną korzyść: lepsze bezpieczeństwo i odczuwalnie niższe obciążenie CPU. Oczywiście pod warunkiem, że urządzenia końcowe to wspierają.
RSA, ECDSA, ECDHE – ciężar handshaku w szczegółach
Na etapie zestawiania połączenia kluczową rolę grają algorytmy asymetryczne. Historycznie dominował RSA (zarówno do podpisu, jak i wymiany kluczy), ale w nowoczesnych środowiskach przechodzi się na krzywe eliptyczne (ECDSA, ECDHE). Powodów jest kilka:
- mniejsze klucze przy podobnym poziomie bezpieczeństwa,
- znacznie niższy koszt obliczeniowy,
- lepsza skalowalność przy dużej liczbie handshaków.
Przykład z praktyki: serwer WWW obsługujący tysiące krótkich połączeń HTTPS na sekundę. Przy certyfikacie RSA na 2048 bitów i wymianie kluczy opartej na RSA, CPU szybko dochodzi do granic wydajności. Po zmianie na ECDSA + ECDHE i wymuszeniu TLS 1.2/1.3 obciążenie procesora spada, mimo że aplikacja i całkowity ruch pozostają bez zmian.
Podobnie w VPN-ach: krótsze, lżejsze wymiany kluczy (np. ECDH/ECDHE na krzywych o wysokiej wydajności) zmniejszają koszt renegocjacji i odświeżania kluczy. Nie wpływa to na stały transfer (tam i tak rządzi szyfr symetryczny), ale ma duże znaczenie, gdy w infrastrukturze występują częste rozłączenia i ponowne zestawianie tuneli – choćby w środowiskach mobilnych czy przy słabym łączu.
TLS 1.2 vs TLS 1.3 – co zmienia nowa wersja dla wydajności
Różnica między TLS 1.2 a TLS 1.3 to nie tylko „numer wersji”. Z perspektywy wydajności na pierwszy plan wysuwają się dwa elementy:
- mniej rund wymiany w handshaku – krótszy czas zestawiania połączenia, mniejsze zapotrzebowanie na RTT,
- session resumption 0-RTT – możliwość szybkiego ponownego nawiązania sesji z minimalnym opóźnieniem.
W rozproszonych systemach i aplikacjach mobilnych, gdzie połączenia są często zrywające się i wznawiane, przejście na TLS 1.3 potrafi znacząco zmniejszyć latencję postrzeganą przez użytkownika. Wpływ na CPU jest tu mniej spektakularny niż zmiana algorytmu asymetrycznego, ale sumarycznie – krótszy handshake + lepsze mechanizmy wznawiania – dają wymierne efekty.
Do tego dochodzi „oczyszczenie” listy szyfrów – TLS 1.3 porzuca wiele legacy cipher suites, które były zarówno słabsze bezpieczeństwowo, jak i cięższe obliczeniowo. Mniej opcji to również prostsza konfiguracja po stronie administratora i mniejsza szansa na pozostawienie starych, nieoptymalnych ustawień „bo kiedyś coś nie działało”.
Sprzęt i architektura – kiedy problemem nie jest „szyfrowanie”, tylko pudełko
Tablica IPSec, NAT-T i limity „magicznego” UTM
State table, sesje i „tajemnicze” limity po stronie firewalla
Urządzenia z kategorii UTM/NGFW często są sprzedawane hasłem „gigabitowy firewall”, ale już drobnym drukiem dopisuje się, że bez IPSec, bez IPS, bez URL filteringu. Po włączeniu pełnego pakietu zabezpieczeń ten sam sprzęt zaczyna „zamykać się” przy setkach megabitów. Szyfrowanie staje się wtedy wygodnym kozłem ofiarnym, choć tak naprawdę często mamy do czynienia z limitem liczby sesji i rozmiarem tablicy stanów.
Każdy tunel IPSec, każde połączenie TLS przez ten tunel, każda przepinana sesja TCP – wszystko to ląduje w tablicy stanów firewalla. Gdy ilość sesji zbliża się do górnej granicy, rosną opóźnienia wyszukiwania, rosną koszty garbage collection, a przy słabej implementacji zaczyna dochodzić do losowego wywalania sesji. Użytkownik widzi to jako „VPN muli” lub „strony się nie ładują za pierwszym razem”.
Przy planowaniu wydajności trzeba więc patrzeć nie tylko na „VPN throughput”, lecz także na:
- maksymalną liczbę jednoczesnych sesji deklarowaną dla urządzenia,
- wydajność przy włączonych wszystkich wymaganych funkcjach (IPS, AV, URL filtering),
- politykę timeoutów dla sesji (zbyt długie – zapchana tablica, zbyt krótkie – ciągłe nowe handshaki).
Dość typowy scenariusz: mały UTM w oddziale, jeden tunel IPSec do centrali, a w nim całe życie biura – Teams, VoIP, drukowanie, backup, aktualizacje. Sprzęt na papierze ma „VPN 500 Mb/s”, ale state table pozwala na kilka tysięcy sesji. Gdy przychodzi okres aktualizacji systemów, nagle wszystko wydaje się dwa razy wolniejsze, bo firewall ledwo nadąża z zarządzaniem sesjami i inspekcją. Z punktu widzenia użytkownika: „od kiedy mamy szyfrowanie, net nie działa”.
Offload kryptograficzny, kartki z ASIC-iem i realne korzyści
Część „magicznych pudełek” szczyci się akceleracją kryptografii na dedykowanych układach (ASIC, NPU, karty HSM). W praktyce takie offloady potrafią odciążyć CPU główny, ale tylko przy określonym wzorcu ruchu i konfiguracji. Jeśli cała ścieżka pakietu i tak przechodzi przez szereg filtrów aplikacyjnych w CPU, zysk z samego przyspieszenia szyfrowania bywa mniejszy niż obiecuje folder marketingowy.
Największy sens ma offload wtedy, gdy:
- tunel jest stosunkowo prosty (IPSec z minimalnym zestawem opcji, bez pełnej inspekcji aplikacyjnej w środku),
- duża część ruchu to ciągłe strumienie danych (backup, replikacje, storage over IP),
- sprzęt faktycznie robi pełny offload, a nie tylko część operacji (np. sam HMAC).
Dobrym kompromisem bywa architektura „dual-box”: jedno urządzenie pełni rolę szybkiego terminatora VPN (z porządnym offloadem), a drugie – głównego firewalla z inspekcją aplikacyjną. Wtedy ciężki ruch zaszyfrowany można zakończyć i zregenerować w pierwszym pudełku, a do firewalla aplikacyjnego przekazać już tylko to, co naprawdę trzeba analizować dogłębnie.
Wirtualizacja, NUMA i „niewidzialne” granice hypervisora
Kiedy VPN-y lądują w maszynach wirtualnych, pojawia się kolejna warstwa ograniczeń. Szyfrowanie jest wtedy tylko jednym z gości na imprezie, obok wirtualnych kart sieciowych, współdzielonego CPU i pamięci. Jeśli hypervisor nie jest dobrze „podkarmiony” zasobami, a interfejsy nie są sensownie przypięte do vCPU i NUMA node, nawet najlepszy algorytm szyfrowania nie pomoże.
Przy projektowaniu wirtualnych bram VPN warto sprawdzić kilka rzeczy:
- czy interfejsy WAN/LAN są na różnych kolejkach (multi-queue) i czy system gościnny je wykorzystuje,
- czy vCPU przydzielone maszynie nie są rozrzucone po wielu NUMA node’ach, co powoduje kosztowne dostępy do pamięci,
- czy nie ma przesadnego oversubscription CPU – router VPN nie lubi dzielić rdzenia z głośną bazą danych.
Czasem samo przeniesienie wirtualnego routera VPN na inny host lub przypisanie mu pełnych, niepodzielonych rdzeni CPU (pinned vCPU) potrafi przynieść więcej niż kombinacje z listą szyfrów. Zwłaszcza gdy ruch ma charakter burstowy, a szyfrowanie dokłada tylko niewielki narzut do już przeciążonego środowiska.
Monitoring „na żywo” – jak odróżnić ograniczenie kryptograficzne od sieciowego
Zanim zacznie się zmieniać algorytmy i kupować nowe sprzęty, trzeba sprawdzić, czy to faktycznie szyfrowanie jest wąskim gardłem. Bez sensownego monitoringu łatwo szukać problemu nie tam, gdzie trzeba.
Przy diagnozie dobrze mieć pod ręką kilka podstawowych obserwacji:
- CPU na bramach VPN – czy jest stale wysoko (np. 80–100%), czy tylko rośnie skokowo?
- Opóźnienia i jitter – jak zmieniają się RTT między filiami przy wyłączonych/odłączonych tunelach?
- Wskaźniki kolejki interfejsu – czy widać drops i retransmisje na fizycznych portach, czy tylko w logach IPSec/TLS?
Jeżeli CPU na urządzeniu VPN „dobija do sufitu” przy każdym większym transferze, a na łączu fizycznym nie widać wysokiego wykorzystania, prawdopodobnie to kryptografia stała się głównym obciążeniem. Jeśli za to łącze jest stale na 90–100%, a CPU się nudzi, winny jest bardziej brak przepustowości lub słaba polityka QoS niż szyfrowanie jako takie.
Projektowanie topologii VPN i segmentacja ruchu – nie wszystko musi być w jednym tunelu
Hub-and-spoke, full mesh i „gwiazda śmierci” w centrali
Klasyczna topologia hub-and-spoke (wszystkie oddziały łączą się z centralą) jest wygodna organizacyjnie, ale potrafi zabić wydajność. Każdy pakiet między dwoma filiami musi przejść przez centralny hub, być tam rozpakowany, przekierowany, znów zaszyfrowany i wysłany dalej. To oznacza dodatkowe obciążenie dla CPU centralnego urządzenia i dwa razy większy ruch na jego interfejsach.
Przy większej liczbie lokalizacji łatwo tworzy się „gwiazda śmierci”: jedno pudło w centrali obsługuje setki tuneli, a każdy nowy oddział to kolejne obciążenie CPU, tablic routingu i tablic IPSec. Nawet jeśli łącza są szybkie, pojedynczy hub staje się punktem krytycznym.
Dobrym sposobem na rozładowanie takiego zatoru jest:
- wprowadzenie regionalnych hubów (np. po jednym na kraj/region),
- uruchomienie ograniczonego full-mesh między lokalizacjami, które faktycznie ze sobą intensywnie rozmawiają,
- podział roli „terminatora VPN” i „głównego firewalla” na osobne urządzenia.
Nie każda mała filia musi mieć tunel do każdej innej, ale jeśli dwie fabryki wymieniają codziennie duże ilości danych, sensowne jest zestawienie bezpośredniego tunelu między nimi, zamiast ciągnięcia wszystkiego przez centralę. To odciąża zarówno łącza, jak i procesory kryptograficzne w core.
Split-tunneling vs full-tunnel – ile ruchu naprawdę trzeba szyfrować
W środowiskach z użytkownikami zdalnymi często pojawia się dychotomia: full-tunnel (cały ruch przez VPN) kontra split-tunneling (tylko ruch do firmowych zasobów przez VPN). Wariant „wszystko przez tunel” bywa prostszy z punktu widzenia bezpieczeństwa i polityki, ale dla wydajności to ciężki kamień u szyi.
Jeżeli każdy film szkoleniowy na YouTube czy każda aktualizacja pakietu biurowego przechodzi przez centralny VPN, tunel staje się niepotrzebnym gardłem. Szyfrowanie takiego ruchu przez centralę nie dodaje mu sensownej ochrony – atakujący i tak nie dostanie się z publicznego internetu do prywatnych zasobów firmy, jeśli zostały dobrze odseparowane.
Rozsądnie zaprojektowany split-tunneling może wyglądać tak:
- do VPN wpada tylko ruch do prywatnych podsieci oraz do kilku zaufanych usług w chmurze (np. określonych adresacją),
- reszta ruchu (internet, usługi publiczne) idzie bezpośrednio z lokalnego łącza użytkownika,
- na urządzeniu końcowym nadal działa lokalny firewall i EDR, więc bezpieczeństwo nie opiera się wyłącznie na centrali.
W praktyce taka zmiana potrafi w jednej chwili uwolnić przepustowość po stronie bram VPN i poprawić opóźnienia w krytycznych aplikacjach, bo nie konkurują one już z całym „internetowym hałasem” użytkownika.
Segmentacja ruchu w tunelach – osobno VoIP, osobno backup, osobno „reszta świata”
Wiele wdrożeń VPN kończy się jednym wielkim tunelem „do wszystkiego”. Brzmi prosto, ale z punktu widzenia wydajności i zarządzania QoS to bardzo utrudnia życie. Mieszają się ze sobą pakiety VoIP, RDP, systemów ERP i ogromne strumienie backupowe, a administrator automatycznie traci precyzję sterowania ruchem.
Lepsze podejście to logiczna segmentacja ruchu w tunelach. Nie zawsze oznacza to fizycznie więcej tuneli, choć w wielu przypadkach właśnie to daje najwięcej elastyczności. Konkretny przykład:
- tunel A: ruch interaktywny – VoIP, wideokonferencje, RDP, aplikacje czasu rzeczywistego,
- tunel B: ruch aplikacyjny – systemy biznesowe, bazy danych, API,
- tunel C: ruch masowy – backup, replikacje plików, synchronizacja dużych repozytoriów.
Na każdym z takich tuneli można osobno ustawić QoS, limity przepustowości, priorytety kolejkowania. Jeśli backup nagle ruszy pełną parą, dusi własny tunel, ale nie zabiera powietrza rozmowom telefonicznym. Do tego da się dobrać różne parametry kryptograficzne: np. dla ruchu real-time priorytetem będzie minimalne opóźnienie, a dla backupów – większe bezpieczeństwo kosztem nieco większego narzutu obliczeniowego.
Topologie hybrydowe – VPN + MPLS/SD-WAN jako zespół, nie konkurencja
Nie trzeba wszystkich jajek wkładać do koszyka „VPN po internecie”. W wielu firmach i tak istnieje jakaś forma prywatnego szkieletu (MPLS, dark fiber, dedykowane L2), którą można połączyć z tunelami IPSec/SSL w jedną, sensowną całość. Szyfrowanie nie musi obsługiwać wszystkiego; niektóre ścieżki mogą polegać bardziej na izolacji fizycznej/logicznej.
Coraz częściej robi się to przy pomocy SD-WAN. Zamiast jednego statycznego tunelu między lokalizacjami mamy kilka ścieżek: VPN po internecie, łącze MPLS, może jeszcze trzeci kanał zapasowy LTE. Kontroler SD-WAN dynamicznie decyduje, który ruch gdzie wysłać, uwzględniając opóźnienie, jitter, dostępne pasmo i priorytet aplikacji.
Jeżeli ruch VoIP/VDI ląduje na najstabilniejszym i najszybszym łączu, a backupy i aktualizacje lecą przez tańszy kanał z większym opóźnieniem, wtedy szyfrowanie przestaje być uniwersalnym winowajcą. Jest po prostu jedną z warstw ochrony, a nie jedynym pomostem między wszystkimi punktami sieci.
Ruch do chmury – kiedy nie warto „ciągnąć” wszystkiego przez centralę
Jak tylko główne aplikacje firmowe przenoszą się do chmury, klasyczny model „wszystko przez centralę, potem do internetu” przestaje się bronić. Każde żądanie do SaaS (CRM, systemy księgowe, współdzielone dokumenty) robi niepotrzebne kółko: laptop – VPN – centrala – internet – chmura i z powrotem.
Rozsądniejszą strategią bywa:
- wprowadzenie lokalnego wyjścia do internetu w oddziałach lub u użytkownika,
- wykorzystanie bezpiecznych konektorów chmurowych (np. IPSec/SSL bezpośrednio z oddziału do regionu chmurowego),
- stosowanie identity-based access (SSO, Conditional Access), które ogranicza poleganie wyłącznie na lokalizacji sieciowej.
W takim modelu szyfrowanie nie musi „obracać” całego ruchu chmurowego przez centralę. Tunel z oddziału do chmury robi swoje, a centrala może służyć raczej jako dodatkowy punkt kontroli niż pojedyncza szyja butelki. Użytkownicy zdalni zyskują krótszą ścieżkę do aplikacji, a procesory w centrali – więcej oddechu.
Scenariusze mieszanego zaufania – kiedy różne poziomy szyfrowania współistnieją
Nie w każdej części sieci ten sam poziom szyfrowania jest konieczny. Połączenie dwóch data center przez prywatne łącze światłowodowe ma inną ekspozycję na ryzyko niż dostęp pracownika z domowego Wi-Fi do systemów finansowych. Jeżeli wszystko wrzuci się do jednego worka, zarządzanie staje się trudne i drogie.
Najczęściej zadawane pytania (FAQ)
Czy szyfrowanie naprawdę spowalnia sieć firmową?
Szyfrowanie zawsze generuje pewien narzut – zużywa CPU, dodaje bajty do pakietów i może zmieniać parametry transmisji (np. MTU). Samo w sobie nie musi jednak oznaczać „mulącej” sieci; w dobrze zaprojektowanej infrastrukturze różnica dla użytkownika jest zwykle ledwie zauważalna.
Najczęściej źródłem problemów jest nie tyle szyfrowanie, co słaby sprzęt, zły punkt terminowania VPN, przestarzałe algorytmy lub tunelowanie całego ruchu przez jedno miejsce w sieci. Gdy te elementy są sensownie dobrane, szyfrowanie staje się po prostu standardowym elementem ruchu, a nie kozłem ofiarnym.
Jak sprawdzić, czy za wolne działanie VPN odpowiada szyfrowanie czy projekt sieci?
Najprościej zacząć od podstawowych pomiarów: obciążenia CPU na firewallu / koncentratorze VPN, wykorzystania łącza (up/down) oraz opóźnień i utraty pakietów między lokalizacjami. Jeżeli CPU jest permanentnie „na 90%+”, a po jego odciążeniu (np. wyłączeniu części tuneli testowo) sytuacja się poprawia, szyfrowanie faktycznie może być wąskim gardłem.
Jeżeli natomiast urządzenia kryptograficzne się nudzą, a dusi się łącze lub widać fragmentację pakietów, problem leży raczej w MTU, trasowaniu, sposobie tunelowania (full-tunnel vs split-tunnel) albo w konkretnej aplikacji. Dobrą wskazówką jest też porównanie: jak działa aplikacja bez VPN (np. z sieci lokalnej lub z innej lokalizacji), a jak przez tunel.
Jak zoptymalizować VPN, żeby był bezpieczny i szybki jednocześnie?
Na początek warto zweryfikować algorytmy: nowoczesne szyfry symetryczne (np. AES-GCM, ChaCha20) są szybkie i dobrze wspierane sprzętowo. Stare konfiguracje oparte na 3DES czy egzotycznych zestawach cipher suites potrafią niepotrzebnie obciążać urządzenia, nie dając realnie lepszego bezpieczeństwa.
Kolejny krok to architektura: tam, gdzie to rozsądne, stosować split-tunnel lub lokalny breakout do internetu, żeby nie robić „U-turnu” ruchu do chmury przez centralę. Do tego dochodzi poprawne MTU/MSS (żeby uniknąć nadmiernej fragmentacji) i odpowiednio wydajny sprzęt z akceleracją kryptograficzną, jeśli ruchu jest dużo.
Dlaczego praca zdalna przez VPN jest wolniejsza niż w biurze?
U zdalnego pracownika nakłada się kilka czynników: domowy internet (często asymetryczny), dodatkowe opóźnienie wprowadzane przez tunel VPN, jakość routera domowego oraz wydajność koncentratora w firmie. Użytkownik widzi to jako „lagi” w RDP, wolne otwieranie plików z udziałów sieciowych czy ślamazarną pracę systemu ERP.
W praktyce często pomaga rozdzielenie ruchu: kluczowe usługi firmowe przez VPN, a ruch do internetu (np. YouTube, prywatne strony) poza tunelem. Druga rzecz to zadbanie o sensowny router po stronie użytkownika i stabilne łącze – nawet najlepszy VPN nie naprawi fragmentującego się, niestabilnego domowego internetu.
Czy HTTPS (TLS) wpływa na prędkość internetu w firmie tak samo jak VPN?
Nie. TLS/HTTPS obciąża głównie serwery aplikacyjne i urządzenia po drodze (np. reverse proxy), głównie przy nawiązywaniu nowych połączeń. Sam narzut na wielkość pakietu i przepustowość łącza jest stosunkowo niewielki i rzadko jest głównym winowajcą spadku wydajności.
VPN (IPSec, SSL VPN, WireGuard) działa na niższej warstwie i „pakuje” całe połączenia w dodatkowy tunel, dodając widoczne nagłówki i czasem wymuszając inną ścieżkę ruchu. Z tego powodu jego wpływ na opóźnienia i przepustowość jest zwykle bardziej odczuwalny, szczególnie przy tunelach między oddziałami.
Jakie algorytmy szyfrowania wybrać, żeby nie zabić wydajności?
W typowych wdrożeniach sieci firmowych rozsądny zestaw to: AES-GCM (128 lub 256 bitów) albo ChaCha20-Poly1305 jako szyfry symetryczne oraz ECDHE/ECDSA dla wymiany kluczy i uwierzytelniania. To algorytmy zaprojektowane pod wysoką wydajność, często wspierane sprzętowo przez procesory i urządzenia sieciowe.
Unikaj przestarzałych szyfrów jak 3DES, RC4 czy bardzo długich kluczy RSA tam, gdzie nie są potrzebne. Dobrze dobrany, nowoczesny zestaw cipher suites zazwyczaj zwiększa bezpieczeństwo i jednocześnie odciąża procesory w porównaniu ze starymi, „historycznymi” konfiguracjami.
Czy szyfrowanie dysku (np. BitLocker) może wpływać na szybkość sieci?
Szyfrowanie dysku obciąża przede wszystkim operacje I/O na serwerze lub stacji roboczej, a nie samą transmisję sieciową. Jeżeli jednak dysk serwera jest bardzo wolny, to użytkownik może odczuwać opóźnienia przy otwieraniu plików czy pracy z bazą danych i mylnie wiązać to z siecią lub VPN.
W praktyce na przepustowość łącza i opóźnienia między lokalizacjami wpływa głównie szyfrowanie „w ruchu” (TLS, IPSec, VPN), a nie szyfrowanie „w spoczynku” (dyski, backupy, bazy danych). Rozdzielenie tych dwóch światów ułatwia diagnozowanie, co tak naprawdę zwalnia pracę użytkowników.
Co warto zapamiętać
- Sama obecność szyfrowania rzadko jest głównym winowajcą „mulącej” sieci; problemy zwykle biorą się z przestarzałego sprzętu, złej konfiguracji VPN i tuneli oraz braku przemyślanej architektury.
- Kluczowe jest szukanie równowagi: szyfrowanie jest niezbędne z punktu widzenia bezpieczeństwa, więc celem nie jest jego wyłączanie, tylko takie zaprojektowanie infrastruktury, by narzut wydajnościowy był dla użytkownika praktycznie niewidoczny.
- Wąskie gardła najczęściej pojawiają się w punktach terminowania VPN (słaby firewall, przeciążony koncentrator), przy źle dobranym MTU i przy full-tunnelu, który niepotrzebnie przepycha cały ruch internetowy przez centralę.
- Najbardziej odczuwalne spadki wydajności występują przy pracy zdalnej, dostępie do aplikacji SaaS przez centralny VPN oraz w tunelach site-to-site – tam nawet niewielkie opóźnienia czy fragmentacja pakietów potrafią „zabić” komfort pracy w ERP czy RDP.
- Ogromny efekt daje świadome rozdzielenie ruchu: split-tunnel lub lokalny breakout do internetu często przynoszą większą poprawę niż zmiana algorytmów szyfrowania, bo skracają drogę pakietów i odciążają łącza w centrali.
- Szyfrowanie działa na różnych poziomach (aplikacja, transport/VPN, dysk) i każdy z nich inaczej obciąża system; wrzucanie wszystkiego do jednego worka utrudnia diagnozę, więc trzeba precyzyjnie wskazać, który poziom generuje problem.
