Współczesna komunikacja w sieciach komputerowych opiera się na wielowarstwowym modelu enkapsulacji protokołów, w którym każda warstwa dodaje własny narzut nagłówkowy. W sieciach Ethernet standardowa wartość maksymalnej jednostki transmisji (MTU) wynosi 1500 bajtów. Wartość ta stanowi powszechny punkt odniesienia dla stosów sieciowych systemów operacyjnych, algorytmów trasowania oraz protokołów warstwy transportowej.

Wdrożenie wirtualnych sieci prywatnych (VPN) wprowadza mechanizm tunelowania, polegający na pakowaniu oryginalnego pakietu IP użytkownika w dodatkowe nagłówki szyfrujące, uwierzytelniające i transportowe. W zależności od wykorzystywanej technologii - takiej jak IPsec, WireGuard czy OpenVPN - narzut ten wynosi od kilkudziesięciu do ponad stu bajtów. W efekcie całkowity rozmiar enkapsulowanego pakietu przekracza standardowe MTU łącza fizycznego, tworząc krytyczny problem transmisyjny.

Konsekwencją przekroczenia MTU na styku z siecią publiczną jest przymusowa fragmentacja pakietów na routerze brzegowym lub ich ciche odrzucenie, jeśli nadawca ustawił flagę blokady fragmentacji (Don't Fragment). Zjawisko to prowadzi do drastycznego spadku wydajności transmisji, anomalii w negocjacji sesji szyfrowanych oraz zrywania połączeń aplikacyjnych, co wymusza stosowanie dedykowanych mechanizmów inżynierskich.

W dalszej części przedstawiono matematyczne i praktyczne podstawy zarządzania wielkością jednostek transmisyjnych w tunelach VPN. Szczegółowej analizie poddano strukturę narzutów nagłówkowych, mechanizmy automatycznego wykrywania MTU ścieżki (PMTUD), technikę modyfikacji maksymalnego rozmiaru segmentu TCP (MSS Clamping) oraz procedury wdrożeniowe i diagnostyczne na platformach MikroTik RouterOS i Cisco IOS.

Źródła i dokumentacja techniczna: Centrum Edukacji Bezpieczeństwa Rynku Finansowego KNF.

Maksymalna jednostka transmisji (MTU) określa największy dopuszczalny rozmiar protokolarnej jednostki danych (PDU) warstwy sieciowej, jaki może zostać przekazany do medium transmisyjnego w pojedynczej ramce warstwy łącza danych. Dla klasycznej sieci Ethernet (standard IEEE 802.3) wartość MTU wynosi 1500 bajtów. Przy dodaniu 14 bajtów nagłówka Ethernet (adresy MAC i pole typu) oraz 4 bajtów sumy kontrolnej ramki (FCS), całkowity rozmiar ramki na przewodzie wynosi 1518 bajtów (lub 1522 bajty przy tagowaniu VLAN 802.1Q).

W technologiach dostępu szerokopasmowego wartość efektywnego MTU ulega obniżeniu z powodu dodatkowej enkapsulacji. W technologii PPPoE (Point-to-Point Protocol over Ethernet), powszechnie stosowanej w sieciach światłowodowych i DSL, nagłówek sesyjny PPP i PPPoE zabiera dokładnie 8 bajtów, co redukuje standardowe MTU z 1500 do 1492 bajtów. Niezauważenie tej redukcji przez administratora jest jedną z głównych przyczyn problemów z tranzytem tuneli VPN.

W sieciach bezprzewodowych standard IEEE 802.11 formalnie dopuszcza jednostki MSDU o wielkości do 2304 bajtów, jednak punkty dostępowe rutynowo konwertują pakiety do standardu Ethernet, ograniczając MTU do 1500 bajtów. W sieciach komórkowych LTE i 5G transmisja danych opiera się na tunelowaniu GTP-U (GPRS Tunneling Protocol) w sieci rdzeniowej operatora, co w zależności od konfiguracji APN może narzucać MTU na poziomie od 1420 do 1500 bajtów.

W środowiskach centrów danych oraz szkieletowych sieciach korporacyjnych powszechnie wdraża się ramki gigantyczne (Jumbo Frames) o MTU rzędu 9000 bajtów. Rozwiązanie to drastycznie redukuje narzut procesora przy obsłudze ruchu pamięci masowych (iSCSI, NFS), jednak ramki te nie mogą być bezpośrednio przesyłane przez publiczny Internet, gdzie obowiązuje rygorystyczny limit 1500 bajtów.

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Adresacja IP i konfiguracja MTU.

Ścieżka sieciowa pomiędzy dwoma węzłami w sieci Internet składa się z wielu niezależnych łączy telekomunikacyjnych, z których każde może charakteryzować się odmienną wartością MTU. Mechanizm Path MTU Discovery (PMTUD), zdefiniowany w dokumencie RFC 1191 dla protokołu IPv4 oraz zaktualizowany w RFC 8201 dla IPv6, eliminuje konieczność zgadywania rozmiaru pakietów i chroni przed kosztowną fragmentacją w routerach pośredniczących.

Zasada działania klasycznego PMTUD polega na nadawaniu wszystkich wychodzących pakietów z ustawioną w nagłówku IPv4 flagą DF (Don't Fragment = 1). Gdy taki pakiet trafi na router pośredniczący, którego interfejs wyjściowy posiada MTU mniejsze niż rozmiar odbieranego pakietu, węzeł tranzytowy nie ma prawa go pofragmentować. Router odrzuca pakiet i odsyła do nadawcy specjalny komunikat błędu protokołu ICMP.

W protokole IPv4 komunikatem tym jest ICMP Destination Unreachable, Type 3, Code 4 (Fragmentation Needed and DF set). Zgodnie ze standardem RFC 1191, nowoczesny router umieszcza w nagłówku ICMP pole Next-Hop MTU, precyzujące dokładną wartość MTU łącza, które zablokowało transmisję. Na podstawie tej informacji stos sieciowy nadawcy aktualizuje swoją pamięć podręczną trasowania i zmniejsza rozmiar kolejnych generowanych pakietów.

W architekturze IPv6 mechanizm fragmentacji w routerach pośredniczących został całkowicie usunięty ze standardu. Za fragmentację odpowiada wyłącznie węzeł źródłowy, a odpowiednikiem komunikatu IPv4 jest ICMPv6 Type 2 (Packet Too Big). Choć założenia PMTUD są optymalne teoretycznie, w praktyce współczesnego Internetu mechanizm ten ulega częstym awariom z powodu restrykcyjnych polityk bezpieczeństwa.

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Trasowanie IP i obsługa PMTUD.

Kluczowym elementem sprzężenia zwrotnego w mechanizmie PMTUD jest komunikat ICMP Type 3, Code 4. Aby stacja nadawcza mogła zidentyfikować, które połączenie wywołało błąd, pakiet ICMP zawiera w swoim ładunku nie tylko pole Next-Hop MTU, lecz również nienaruszony nagłówek IP odrzuconego pakietu oraz pierwsze 64 bity jego oryginalnego ładunku (co w przypadku TCP obejmuje port źródłowy, docelowy oraz numer sekwencyjny).

Poważnym problemem w strukturze współczesnego Internetu jest zjawisko określane mianem czarnej dziury MTU. Wynika ono z nadgorliwej i błędnej konfiguracji zapór ogniowych przez administratorów, którzy traktują cały ruch ICMP jako potencjalny wektor ataku (np. ICMP Flood czy ataki rozpoznawcze) i wdrażają bezwzględną regułę odrzucania wszystkich pakietów tego protokołu.

Gdy na ścieżce wystąpi czarna dziura MTU, stacja źródłowa wysyła duży pakiet z flagą DF=1, który zostaje odrzucony przez router o mniejszym MTU (np. węzeł tunelu VPN). Router wysyła komunikat ICMP Type 3 Code 4, lecz zapora sieciowa po drodze po cichu go odrzuca. Nadawca nigdy nie dowiaduje się o przyczynie niedoręczenia danych i po upływie limitu czasu ponawia retransmisję dokładnie tego samego, zbyt dużego pakietu.

Efektem zjawiska czarnej dziury MTU jest specyficzne zachowanie aplikacji: małe pakiety (np. uzgadnianie sesji TCP SYN/ACK, zapytania DNS, polecenia tekstowe w SSH) przechodzą bez zakłóceń, natomiast każda próba przesłania większej ilości danych (treść strony WWW, grafika, transfer pliku) powoduje całkowite zawieszenie sesji. Prawidłowa konfiguracja zapory sieciowej musi bezwzględnie dopuszczać komunikaty ICMP powiązane z istniejącymi sesjami (stan RELATED).

Źródła i dokumentacja techniczna: Dokumentacja Netfilter: Packet Filtering HOWTO i obsługa ICMP.

Każdy tunel wirtualnej sieci prywatnej opiera się na zjawisku enkapsulacji: oryginalny pakiet generowany przez aplikację klienta jest opakowywany w dodatkowe struktury danych przed wysłaniem w trasę przez sieć publiczną. Rozmiar tego narzutu jest bezpośrednią funkcją wybranego protokołu VPN, trybu pracy, rodziny adresowej (IPv4 vs IPv6) oraz zastosowanych algorytmów kryptograficznych.

W przypadku protokołu IPsec ESP pracującego w trybie tunelowym, narzut wynosi zazwyczaj od 50 do 70 bajtów. Składa się na niego nowy zewnętrzny nagłówek IP (20 bajtów dla IPv4), nagłówek ESP (8 bajtów), wektor inicjalizujący IV (od 8 do 16 bajtów), dane wyrównujące (padding) z licznikiem i polem kolejnego nagłówka (2 bajty) oraz znacznik weryfikacji integralności ICV (od 12 do 16 bajtów). Włączenie mechanizmu NAT Traversal dodaje kolejne 8 bajtów nagłówka UDP.

Nowoczesne protokoły tunelowania wykazują zróżnicowany profil narzutu. Protokół WireGuard został zaprojektowany z myślą o minimalnym narzucie i wprowadza stały narzut 32 bajtów na poziomie warstwy kryptograficznej, co w połączeniu z zewnętrznym nagłówkiem UDP (8 B) i IP (20 B) daje całkowity narzut 60 bajtów dla IPv4 lub 80 bajtów dla IPv6. OpenVPN, z racji funkcjonowania w przestrzeni użytkownika i bogactwa opcji konfiguracyjnych, generuje zmienny narzut rzędu 50-80 bajtów.

Protokoły starszej generacji, takie jak GRE czy PPTP, charakteryzują się pozornie mniejszym narzutem (GRE to 4 bajty nagłówka bazowego, PPTP około 26-30 bajtów wraz z PPP i GRE), jednak nie zapewniają one natywnego szyfrowania. Dodanie ochrony IPsec do tunelu GRE (GRE over IPsec) sumuje narzuty obu technologii, redukując efektywne MTU łącza do poziomu poniżej 1420 bajtów.

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Architektura i narzut protokołu IPsec.

W trybie tunelowym protokołu IPsec ESP oryginalny pakiet IP zostaje całkowicie ukryty w polu ładunku nowego pakietu tranzytowego. Konstrukcja takiego pakietu rozpoczyna się od zewnętrznego nagłówka IP (20 bajtów dla IPv4 lub 40 bajtów dla IPv6), w którym pole protokołu przyjmuje wartość 50 (ESP). Za nagłówkiem IP umieszczany jest nagłówek ESP, składający się z 4-bajtowego identyfikatora Security Parameters Index (SPI) oraz 4-bajtowego numeru sekwencyjnego, służącego do ochrony przed atakami powtórzeniowymi (Replay Attack).

Bezpośrednio za nagłówkiem ESP znajduje się pole wektora inicjalizującego (IV), którego rozmiar zależy od zastosowanego algorytmu szyfrującego. Dla klasycznego trybu blokowego AES-CBC wektor IV ma długość 16 bajtów. W nowoczesnych szyfrach ze zintegrowanym uwierzytelnianiem AEAD (np. AES-GCM) jawny wektor IV ma zazwyczaj rozmiar 8 bajtów, co pozwala zaoszczędzić 8 bajtów narzutu.

Po zaszyfrowanym ładunku (który obejmuje oryginalny wewnętrzny nagłówek IP oraz dane aplikacji) umieszczane jest dopełnienie wyrównujące (ESP Padding). W algorytmach blokowych takich jak AES-CBC długość szyfrogramu musi być wielokrotnością 16 bajtów, co generuje dopełnienie o wielkości od 0 do 15 bajtów. Na końcu dopełnienia znajdują się dwa obowiązkowe 1-bajtowe pola: Pad Length (określające liczbę dodanych bajtów wyrównania) oraz Next Header (definiujące typ enkapsulowanego protokołu, np. 4 dla IPv4).

Strukturę pakietu zamyka kryptograficzny znacznik autentyczności i integralności (ICV - Integrity Check Value). W starszych implementacjach wykorzystujących HMAC-SHA1 pole to liczyło 12 bajtów (96 bitów), natomiast we współczesnych standardach opartych na HMAC-SHA256 lub tryb AES-GCM znacznik ICV ma długość dokładnie 16 bajtów (128 bitów). Łączny narzut ESP w trybie tunelowym dla IPv4 wynosi zatem od 56 do 76 bajtów.

Źródła i dokumentacja techniczna: Dokumentacja jądra Linux: Architektura podsystemu Crypto i IPsec ESP.

Protokół ESP jest protokołem warstwy sieciowej (IP numer 50) i nie posiada koncepcji portów źródłowych ani docelowych, co uniemożliwia urządzeniom translatorskim (NAPT/PAT) śledzenie wielu równoległych sesji na wspólnym adresie publicznym. Aby rozwiązać ten problem, standard RFC 3948 wprowadził mechanizm NAT Traversal (NAT-T), polegający na umieszczeniu całego pakietu ESP wewnątrz standardowego datagramu UDP na porcie docelowym 4500.

Wprowadzenie dodatkowego nagłówka UDP zwiększa narzut transmisyjny o dokładnie 8 bajtów na każdy pakiet. Ponadto w przypadku komunikatów sterujących protokołu IKE wysyłanych na porcie 4500, standard wymaga wstawienia 4-bajtowego pola Non-ESP Marker (wypełnionego zerami: 0x00000000) pomiędzy nagłówek UDP a ładunek IKE. Pozwala to węzłowi odbierającemu natychmiast rozróżnić pakiety kontrolne od pakietów szyfrowanych danych ESP (w których pierwsze pole to niezerowy identyfikator SPI).

Dodanie enkapsulacji UDP sprawia, że całkowity narzut pakietu IPsec z NAT-T osiąga wartość od 68 do 84 bajtów. Przy standardowym MTU łącza fizycznego wynoszącym 1500 bajtów, przestrzeń dostępna dla wewnętrznego pakietu IP kurczy się do maksymalnie 1416-1432 bajtów. Jest to efektywne MTU tunelu VPN, które musi zostać uwzględnione przy wyliczaniu parametrów stosu TCP.

Standardowy segment TCP na łączu Ethernet posiada pole MSS równe 1460 bajtów (1500 B - 20 B IP - 20 B TCP). W tunelu IPsec z NAT-T taki pakiet po enkapsulacji osiągnąłby rozmiar ponad 1530 bajtów, co doprowadziłoby do jego natychmiastowej utraty w przypadku ustawionej flagi DF. Aby temu zapobiec, konieczne jest obniżenie wartości MSS dla ruchu TCP do bezpiecznego poziomu 1360 bajtów (dla IPv4) lub 1340 bajtów (w przypadku tranzytu IPv6).

Źródła i dokumentacja techniczna: Dokumentacja StrongSwan: Implementacja NAT-T i enkapsulacji UDP.

Protokół WireGuard zyskał ogromną popularność dzięki radykalnemu uproszczeniu architektury kodu oraz zastosowaniu nowoczesnego zestawu kryptograficznego. W odróżnieniu od rozbudowanego stosu IPsec, WireGuard przesyła pakiety danych wyłącznie wewnątrz datagramów UDP. Konstrukcja nagłówka danych transportowych (Transport Data Message) jest stała i zoptymalizowana pod kątem natychmiastowego przetwarzania w strukturach jądra systemu operacyjnego.

Często spotykanym błędem w literaturze sieciowej jest twierdzenie, że całkowity narzut protokołu WireGuard wynosi zaledwie 32 bajty. Wartość 32 bajtów odnosi się wyłącznie do wewnętrznego narzutu samego protokołu WireGuard: 1 bajt typu wiadomości, 3 bajty zarezerwowane, 4 bajty indeksu odbiorcy, 8 bajtów licznika pakietów oraz 16 bajtów kryptograficznego znacznika uwierzytelniającego (Poly1305 Authentication Tag).

Do narzutu kryptograficznego protokołu należy obligatoryjnie doliczyć nagłówki sieciowe pakietu zewnętrznego: 8 bajtów standardowego nagłówka UDP oraz zewnętrzny nagłówek IP. W przypadku transportu przez sieć IPv4 (20 bajtów nagłówka) łączny narzut wynosi dokładnie 60 bajtów (20 B IP + 8 B UDP + 32 B WireGuard). Jeżeli węzły komunikują się w sieci IPv6 (40 bajtów nagłówka), całkowity narzut pakietu wzrasta do 80 bajtów.

W konsekwencji, przy standardowym MTU sieci Ethernet wynoszącym 1500 bajtów, maksymalny dopuszczalny rozmiar wewnętrznego pakietu wynosi 1440 bajtów dla IPv4 oraz 1420 bajtów dla IPv6. Aby zagwarantować pełną stabilność tunelu niezależnie od tego, czy sieć operatora wykorzystuje trasowanie IPv4, IPv6 czy enkapsulację PPPoE (1492 B), twórcy WireGuarda przyjęli uniwersalną, bezpieczną wartość domyślną interfejsu tunelu wynoszącą dokładnie 1420 bajtów.

Źródła i dokumentacja techniczna: Oficjalna specyfikacja protokołu WireGuard.

Protokół OpenVPN charakteryzuje się wyjątkową elastycznością konfiguracyjną, jednak z punktu widzenia inżynierii MTU jest jednym z najbardziej złożonych rozwiązań. Ponieważ OpenVPN realizuje szyfrowanie i zarządzanie sesją w przestrzeni użytkownika z wykorzystaniem biblioteki OpenSSL, narzut pakietu nie jest stały i zależy od wybranego trybu transportu (UDP lub TCP), wersji protokołu IP, wybranego algorytmu szyfrującego, trybu uwierzytelniania HMAC oraz ewentualnego włączenia kompresji.

W najbardziej zalecanej konfiguracji (transport UDP, interfejs warstwy 3 TUN, szyfr AES-256-GCM) narzut nagłówkowy obejmuje: zewnętrzny nagłówek IP (20 B dla IPv4), nagłówek UDP (8 B), nagłówek protokołu OpenVPN (1 B kodu operacji + 4 B identyfikatora sesji w kanale danych), wektor IV (8 B) oraz znacznik uwierzytelniający ICV (16 B). W starszych konfiguracjach wykorzystujących AES-CBC i odrębny HMAC-SHA256 narzut był powiększany o dodatkowe dopełnienie blokowe oraz 32 bajty podpisu HMAC.

Jeżeli OpenVPN zostanie skonfigurowany w trybie warstwy 2 (interfejs TAP), do każdego pakietu dodawany jest pełny 14-bajtowy nagłówek ramki Ethernet. Sprawia to, że łączny narzut OpenVPN waha się od około 50 bajtów w nowoczesnych konfiguracjach do nawet ponad 90 bajtów w trybie mostkowanym TAP z algorytmami CBC.

Do walki z problemami MTU OpenVPN udostępnia dwa kluczowe parametry konfiguracyjne: tun-mtu (domyślnie 1500 bajtów) oraz mssfix. Dyrektywa mssfix (z domyślnym limitem 1450 bajtów lub wskazaną wartością, np. mssfix 1360) przechwytuje pakiety TCP SYN i automatycznie nadpisuje opcję MSS, zabezpieczając ruch TCP przed fragmentacją. Z kolei historyczna opcja fragment pozwalała procesowi OpenVPN na dzielenie pakietów w warstwie aplikacji przed ich wysłaniem do gniazda UDP, co generowało znaczny narzut procesora.

Źródła i dokumentacja techniczna: Oficjalny podręcznik referencyjny OpenVPN 2.6.

Protokół Generic Routing Encapsulation (GRE), opracowany przez firmę Cisco i ustandaryzowany w dokumentach RFC 1701 oraz RFC 2784, jest jednym z najstarszych i najbardziej uniwersalnych protokołów tunelujących. Sam w sobie GRE nie zapewnia żadnych mechanizmów kryptograficznych (ani poufności, ani autentyczności). Jego podstawową zaletą inżynierską jest zdolność do przesyłania ruchu rozgłoszeniowego (broadcast) oraz multiemisji (multicast), co umożliwia uruchamianie protokołów dynamicznego trasowania (OSPF, EIGRP, BGP) pomiędzy odległymi sieciami.

Bazowy nagłówek GRE ma rozmiar zaledwie 4 bajtów. Zawiera on flagi informujące o obecności pól opcjonalnych oraz 2-bajtowe pole EtherType określające typ tunelowanego protokołu (np. 0x0800 dla IPv4). Jeżeli administrator włączy opcjonalną sumę kontrolną (Checksum Present) lub klucz identyfikacyjny tunelu (Key Present), nagłówek rozrasta się odpowiednio do 8 lub 12 bajtów. Wraz z zewnętrznym nagłówkiem IPv4 (20 bajtów), czysty tunel GRE generuje narzut 24 bajtów, co daje maksymalne MTU interfejsu równe 1476 bajtów.

W praktyce korporacyjnej ruch przesyłany tunelem GRE musi być chroniony przed podsłuchem, co realizuje się poprzez zestawienie architektury GRE over IPsec. W tym modelu router najpierw enkapsuluje pakiet w nagłówek GRE, a następnie cały tak powstały pakiet przekazuje do silnika IPsec ESP w trybie transportowym lub tunelowym. W trybie transportowym IPsec ESP dodaje swój narzut (około 56-64 B) bezpośrednio do pakietu GRE, sprawiając, że całkowity narzut przekracza 80 bajtów, a bezpieczne MTU interfejsu GRE spada do około 1400-1420 bajtów.

Protokół PPTP (Point-to-Point Tunneling Protocol) wykorzystuje zmodyfikowaną odmianę enkapsulacji GRE (tzw. Enhanced GRE) do transportu ramek protokołu PPP, uzupełnioną o sesję sterującą TCP na porcie 1723. Narzut enkapsulacji PPTP wynosi łącznie około 26-30 bajtów (20 B zewnętrzny IP + 4-8 B GRE + 2 B nagłówek PPP). Należy jednak podkreślić, że PPTP opiera się na skompromitowanych algorytmach MS-CHAPv2 oraz MPPE/RC4, w związku z czym we współczesnych sieciach został całkowicie wycofany.

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Konfiguracja tuneli GRE i bilans MTU.

Fragmentacja pakietów w protokole IPv4 została zaprojektowana jako mechanizm zapewniający elastyczność w heterogenicznych sieciach o zróżnicowanych parametrach warstwy fizycznej. Gdy router napotka pakiet większy niż MTU łącza wyjściowego z wyzerowaną flagą DF (Don't Fragment = 0), dzieli jego pole ładunku na mniejsze bloki będące wielokrotnością 8 bajtów. Każdy powstały fragment otrzymuje pełny, odrębny nagłówek IP (20 bajtów) z odpowiednio ustawionym przesunięciem (Fragment Offset) oraz flagą More Fragments (MF).

W praktyce inżynierskiej fragmentacja wiąże się z szeregiem poważnych problemów wydajnościowych i bezpieczeństwa. Przede wszystkim podwaja ona liczbę pakietów w sieci, generując dodatkowy narzut nagłówkowy i obciążając procesory węzłów pośredniczących. Co gorsza, ponowne scalenie fragmentów (reassembly) odbywa się dopiero na stacji docelowej. Jeżeli chociażby jeden z fragmentów zostanie utracony w tranzycie, odbiorca musi odrzucić wszystkie odebrane fragmenty, co wymusza retransmisję całego oryginalnego pakietu w warstwie transportowej.

W środowiskach wirtualnych sieci prywatnych kluczowe znaczenie ma rozróżnienie dwóch typów fragmentacji: przed szyfrowaniem (pre-encryption fragmentation) oraz po szyfrowaniu (post-encryption fragmentation). Fragmentacja przed szyfrowaniem zachodzi, gdy router lokalny dzieli duży pakiet danych użytkownika na mniejsze fragmenty, a następnie każdy z nich szyfruje jako niezależny pakiet IPsec/VPN. Proces ten jest wysoce nieoptymalny pod względem kryptograficznym, lecz nie zaburza tranzytu przez zaporę sieciową.

Zdecydowanie najbardziej destrukcyjna jest fragmentacja po szyfrowaniu (post-encryption). Występuje ona, gdy router enkapsuluje nienaruszony pakiet użytkownika w nagłówki VPN, tworząc pakiet przekraczający MTU łącza WAN, który następnie ulega fragmentacji w sieci publicznej. Ponieważ tylko pierwszy fragment zawiera nagłówek UDP/ESP, urządzenia NAT i zapory ogniowe często gubią kolejne fragmenty pozbawione informacji o portach, co prowadzi do masowej utraty danych i całkowitego załamania wydajności tunelu.

Źródła i dokumentacja techniczna: Dokumentacja Wireshark: Filtry analizy protokołu IPv4 i fragmentacji.

Flaga Don't Fragment (DF) to 1-bitowe pole w nagłówku IPv4 (dokładnie drugi bit w 3-bitowym polu Flags). Jej ustawienie (DF=1) stanowi bezwzględny nakaz dla wszystkich węzłów trasujących: pakiet pod żadnym pozorem nie może zostać podzielony na fragmenty. Jeżeli rozmiar takiego pakietu przekracza MTU interfejsu wyjściowego, router ma obowiązek go porzucić i wysłać do nadawcy powiadomienie ICMP.

Wszystkie współczesne implementacje protokołu TCP w systemach Linux, Windows, macOS, Android i iOS domyślnie wysyłają pakiety z ustawioną flagą DF=1. Zachowanie to jest podyktowane chęcią uniknięcia degradacji pasma wywoływanej fragmentacją oraz stanowi fundament funkcjonowania procedury Path MTU Discovery.

W momencie gdy pakiet z flagą DF=1 dociera do routera VPN, brama szyfrująca musi podjąć decyzję o sposobie ukształtowania nowego, zewnętrznego nagłówka IP. Standardowo stosowana jest polityka kopiowania flagi DF (Copy DF): jeśli pakiet wewnętrzny miał DF=1, nagłówek zewnętrzny również otrzymuje DF=1. Chroni to przed niepożądaną fragmentacją zewnętrznych pakietów szyfrowanych w Internecie, lecz w przypadku braku obsługi ICMP prowadzi wprost do problemu czarnej dziury MTU.

Alternatywną strategią inżynierską jest wymuszenie czyszczenia flagi DF w nagłówku zewnętrznym (Clear DF). W tym wariancie brama VPN szyfruje pakiet i zeruje bit DF w zewnętrznym nagłówku IP, dzięki czemu routery w sieci dostawcy usług internetowych mogą pofragmentować pakiet szyfrowany w razie napotkania wąskiego gardła MTU. Choć zapobiega to zrywaniu sesji, drastycznie obciąża procesor routera odbierającego (reassembly) i jest traktowane wyłącznie jako rozwiązanie awaryjne.

Źródła i dokumentacja techniczna: Oficjalny rejestr parametrów i protokołów IP organizacji IANA.

Wprowadzenie tunelu VPN do infrastruktury sieciowej drastycznie komplikuje działanie procedury Path MTU Discovery. W klasycznej komunikacji stacja robocza komunikuje się bezpośrednio z serwerem, a komunikaty ICMP Fragmentation Needed generowane przez routery pośredniczące trafiają bezpośrednio na adres IP nadawcy. W architekturze VPN pakiet użytkownika jest enkapsulowany, co tworzy dwie odrębne domeny MTU: wewnętrzną (tunelową) oraz zewnętrzną (transportową).

Gdy enkapsulowany pakiet szyfrowany przekroczy MTU łącza fizycznego w publicznym Internecie, router tranzytowy odsyła komunikat ICMP do adresu zewnętrznego bramy VPN, a nie do stacji roboczej w sieci LAN. Brama VPN musi wówczas podjąć próbę translacji tego błędu: odczytać oryginalny nagłówek z ładunku ICMP, odszyfrować go (co często jest niemożliwe, jeśli ładunek ICMP został obcięty) i wygenerować sztuczny pakiet ICMP skierowany do hosta lokalnego. W praktyce proces ten niemal zawsze zawodzi.

Drugim krytycznym punktem jest sama brama VPN. Jeżeli host wygeneruje pakiet o rozmiarze 1500 bajtów, brama odbierająca ten pakiet na interfejsie LAN musi go odrzucić jeszcze przed zaszyfrowaniem, ponieważ wie, że po dodaniu nagłówków IPsec pakiet nie zmieści się w łączu WAN. W tym scenariuszu to sam router brzegowy generuje ICMP Type 3 Code 4 z parametrem Next-Hop MTU (np. 1420 bajtów) i odsyła go do stacji lokalnej. Jeśli stacja zignoruje ten komunikat lub zapora lokalna go zablokuje, sesja ulega zamrożeniu.

W odpowiedzi na masową zawodność klasycznego PMTUD opartego na ICMP, IETF opublikowała standard RFC 4821 definiujący procedurę PLPMTUD (Packetization Layer Path MTU Discovery). Zamiast polegać na komunikatach ICMP, stos warstwy transportowej (TCP) aktywnie sonduje ścieżkę, wysyłając segmenty o rosnącym rozmiarze. Jeśli segment o danym rozmiarze zostanie potwierdzony pakietem TCP ACK, stos uznaje dane MTU za bezpieczne; brak potwierdzenia oznacza konieczność zmniejszenia segmentu. Technika ta jest całkowicie odporna na blokady ICMP.

Źródła i dokumentacja techniczna: Opracowanie inżynierskie Tailscale: Anatomia tranzytu pakietów i MTU.

Błędy konfiguracji MTU w tunelach wirtualnych sieci prywatnych należą do najbardziej uciążliwych problemów diagnostycznych w praktyce administratora sieci. Wynika to z faktu, że ich objawy są niespecyficzne i często mylnie interpretowane jako awaria aplikacji, niestabilność łącza internetowego, usterka serwera DNS lub atak sieciowy. Prawidłowa identyfikacja problemu wymaga zrozumienia mechanizmu asymetrii pakietowej.

W protokole HTTP/HTTPS typowym objawem problemu z MTU jest częściowe ładowanie stron internetowych. Przeglądarka internetowa bez problemu pobiera bazowy dokument HTML (ponieważ początkowe segmenty są małe i mieszczą się w buforach), jednak próba załadowania zewnętrznych arkuszy stylów CSS, skryptów JavaScript lub grafiki kończy się nieskończonym oczekiwaniem i błędem przekroczenia limitu czasu. Podobnie w aplikacjach bazodanowych: proste zapytania SQL zwracające kilka wierszy wykonują się błyskawicznie, natomiast zapytania zwracające duże zbiory danych zawieszają aplikację kliencką.

Charakterystycznym przykładem problemu z MTU jest zachowanie protokołu SSH (Secure Shell). Użytkownik zestawia połączenie z serwerem zdalnym, przechodzi pomyślnie uwierzytelnianie hasłem lub kluczem publicznym i uzyskuje interaktywny znak zachęty powłoki. Wpisywanie prostych poleceń (np. pwd, whoami, uptime) działa idealnie, gdyż ich wynik mieści się w małych pakietach. W momencie wydania polecenia generującego duży strumień tekstu (np. dmesg, cat plik.log lub wylistowania obszernego katalogu ls -la) terminal natychmiast przestaje odpowiadać na polecenia.

Analogiczne usterki dotykają połączeń pulpitu zdalnego RDP (zawieszenie sesji natychmiast po wyświetleniu tła ekranu logowania), transferów plików przez SFTP/SCP (natychmiastowe zerwanie transmisji po osiągnięciu pierwszego pełnego bloku danych) oraz poczty elektronicznej (brak możliwości wysłania wiadomości z załącznikiem przy w pełni działającym odbieraniu nagłówków). Wszystkie te zjawiska wskazują jednoznacznie na występowanie problemu czarnej dziury MTU na ścieżce tunelu.

Źródła i dokumentacja techniczna: Baza wiedzy IBM: Podstawy trasowania i transportu pakietów sieciowych.

Podstawowym i najbardziej niezawodnym narzędziem inżynierskim do empirycznego badania MTU ścieżki jest standardowe narzędzie ping, wyposażone w opcje blokowania fragmentacji oraz definiowania rozmiaru bufora danych. Kluczowym elementem poprawnej interpretacji wyników jest uwzględnienie narzutu nagłówków warstwy sieciowej: standardowy pakiet IPv4 zawiera 20 bajtów nagłówka IP oraz 8 bajtów nagłówka ICMP Echo Request. Oznacza to, że całkowity rozmiar pakietu jest zawsze o 28 bajtów większy niż rozmiar ładunku podawany w parametrze narzędzia.

W systemach z rodziny Linux polecenie diagnostyczne przyjmuje składnię: ping -M do -s <rozmiar> <adres_celu>. Parametr -M do bezwzględnie wymusza ustawienie flagi Don't Fragment na poziomie gniazda sieciowego, natomiast opcja -s określa rozmiar ładunku ICMP w bajtach. Dla standardowego MTU 1500 bajtów maksymalna wartość ładunku wynosi dokładnie 1472 bajty (1472 B ładunku + 8 B ICMP + 20 B IP = 1500 B). Jeżeli na ścieżce występuje tunel VPN o MTU 1420 bajtów, test z rozmiarem 1472 zwróci błąd Frag needed and DF set, a maksymalny przechodzący ładunek wyniesie dokładnie 1392 bajty.

W systemie Microsoft Windows tożsame badanie realizuje się za pomocą polecenia: ping -f -l <rozmiar> <adres_celu>, gdzie przełącznik -f odpowiada za włączenie flagi Don't Fragment, a parametr -l definiuje rozmiar bufora (Buffer Size). W systemie macOS oraz platformach BSD stosuje się składnię: ping -D -s <rozmiar> <adres_celu>. Z kolei w systemie MikroTik RouterOS służy do tego polecenie terminalowe: /ping <adres_celu> size=<rozmiar> dont-fragment (należy pamiętać, że w RouterOS parametr size określa całkowity rozmiar pakietu IP wraz z nagłówkiem ICMP, a nie sam ładunek).

Procedura badania polega na wykonaniu tzw. wyszukiwania binarnego (metoda połowienia): rozpoczyna się od wartości 1472 bajtów (dla Ethernetu), a w razie niepowodzenia zmniejsza wartość o połowę, zawężając przedział aż do znalezienia najwyższej wartości, dla której węzeł docelowy odpowiada stabilnie komunikatami ICMP Echo Reply. Do uzyskanej wartości maksymalnego ładunku dodaje się 28 bajtów, uzyskując precyzyjną, rzeczywistą wartość MTU badanej ścieżki sieciowej.

Źródła i dokumentacja techniczna: Dokumentacja podręcznika systemowego Linux: Narzędzie ping.

Analizator pakietów Wireshark jest nieodzownym narzędziem inżynierskim umożliwiającym bezpośrednią obserwację zachowania stosu protokołów oraz precyzyjne potwierdzenie występowania problemów MTU. Analiza śladu sieciowego (pcap) pozwala bezbłędnie zweryfikować, czy błędy w komunikacji wynikają z nieprawidłowego uzgadniania opcji MSS, gubienia fragmentów, czy też braku odpowiedzi na komunikaty ICMP.

Kluczowym filtrem wyświetlania (display filter) w poszukiwaniu problemów z procedurą PMTUD jest wyrażenie: icmp.type == 3 && icmp.code == 4. Odfiltrowuje ono wyłącznie pakiety Destination Unreachable (Fragmentation Needed and DF was set). W szczegółach takiego pakietu inżynier powinien zwrócić uwagę na dwa pola: icmp.nextmtu (wskazujące dokładną wartość MTU łącza, które odrzuciło pakiet) oraz nagłówek wewnętrzny pakietu odrzuconego, co pozwala natychmiast przypisać błąd do konkretnej sesji TCP.

W warstwie transportowej patologię czarnej dziury MTU najszybciej lokalizuje się za pomocą filtra: tcp.analysis.retransmission. Charakterystyczny wzorzec diagnostyczny obejmuje: prawidłowo zrealizowane trójstronne uzgadnianie połączenia (SYN, SYN-ACK, ACK z małymi rozmiarami ramek), następnie przesłanie pierwszego dużego segmentu danych (np. o długości 1460 bajtów lub 1514 bajtów na poziomie ramki), po czym następuje seria powtarzających się retransmisji dokładnie tego samego segmentu (TCP Retransmission) w rosnących odstępach czasu (wykładnicze wydłużanie przerw), bez jakiejkolwiek odpowiedzi ACK od odbiorcy.

Dodatkowo warto stosować filtry: ip.flags.df == 1 do identyfikacji pakietów z zablokowaną fragmentacją, ip.flags.mf == 1 || ip.frag_offset > 0 do tropienia pakietów pofragmentowanych w sieci, a także tcp.flags.syn == 1 z badaniem pola tcp.options.mss_val w celu sprawdzenia, czy routery brzegowe poprawnie modyfikują deklarowany rozmiar segmentu (MSS Clamping).

Źródła i dokumentacja techniczna: Dokumentacja Wireshark: Filtry protokołu ICMP i diagnostyka błędów.

Maximum Segment Size (MSS) jest opcją protokołu TCP (TCP Option Kind 2, długość 4 bajty) negocjowaną wyłącznie podczas nawiązywania połączenia w pakietach z flagą SYN (od klienta do serwera) oraz SYN-ACK (od serwera do klienta). Parametr ten definiuje największą liczbę bajtów czystych danych użytkowych, jaką dany stos sieciowy jest w stanie przyjąć w pojedynczym segmencie TCP. Standardowo stacja robocza Ethernet ogłasza MSS równe 1460 bajtów (1500 B MTU pomniejszone o 20 B nagłówka IPv4 i 20 B nagłówka TCP).

W klasycznej architekturze sieciowej węzły końcowe nie mają świadomości, że na trasie pomiędzy nimi znajduje się tunel VPN narzucający dodatkowe nagłówki. W efekcie oba węzły uzgadniają standardowy MSS 1460 bajtów i generują pakiety o łącznym rozmiarze 1500 bajtów. Po dotarciu do routera VPN pakiety te nie mieszczą się w łączu WAN, co przy zablokowanym ICMP prowadzi do powstania czarnej dziury MTU.

Technika MSS Clamping stanowi proste i skuteczne rozwiązanie tego problemu, zaimplementowane bezpośrednio w zaporze sieciowej routera brzegowego. Router monitoruje cały ruch tranzytowy i przechwytuje pakiety z ustawioną flagą SYN. Gdy w takim pakiecie wykryje pole opcji TCP MSS o wartości przekraczającej bezpieczny limit tunelu (np. 1460 B), podczas transmisji nadpisuje tę wartość mniejszą liczbą (np. 1360 B) oraz przelicza sumę kontrolną nagłówka TCP.

Dzięki tej modyfikacji oba węzły końcowe zostają poinformowane o mniejszym limicie i od początku transmisji generują segmenty o rozmiarze nieprzekraczającym narzuconej wartości. Pakiety z danymi po dodaniu nagłówków IP, TCP oraz pełnego narzutu tunelu VPN (ESP, UDP, WireGuard) mieszczą się idealnie w fizycznym MTU 1500 bajtów łącza WAN. Zapewnia to całkowite wyeliminowanie fragmentacji oraz zjawiska czarnej dziury MTU dla całego ruchu opartego na protokole TCP.

Źródła i dokumentacja techniczna: Dokumentacja Wireshark: Opcje protokołu TCP i badanie wartości MSS.

Prawidłowe wyznaczenie wartości MSS Clamping wymaga przeprowadzenia ścisłego bilansu narzutów nagłówkowych wzdłuż całej ścieżki pakietu. Zbyt wysoka wartość MSS nie rozwiąże problemu fragmentacji i doprowadzi do utraty pakietów, natomiast wartość zbyt niska spowoduje sztuczne zmniejszenie efektywności pasma (spadek wskaźnika Goodput) z powodu niepotrzebnego zwielokrotnienia liczby przesyłanych segmentów.

Punktem wyjścia jest zawsze bazowe MTU interfejsu wyjściowego WAN. W przypadku klasycznego łącza Ethernet wynosi ono 1500 bajtów. Jeżeli jednak dostęp do Internetu realizowany jest przez protokół PPPoE, bazowe MTU łącza fizycznego wynosi zaledwie 1492 bajty. Od tej wartości należy kolejno odejmować narzuty poszczególnych warstw enkapsulacji tunelowej oraz stały narzut wewnętrznych nagłówków IP (20 B dla IPv4 lub 40 B dla IPv6) i TCP (20 B).

Dla protokołu IPsec ESP z mechanizmem NAT-T w sieci IPv4 bilans kształtuje się następująco: MTU bazowe 1500 B pomniejszamy o zewnętrzny nagłówek IPv4 (20 B), nagłówek UDP NAT-T (8 B), nagłówek ESP (8 B), wektor IV (16 B dla AES-CBC), maksymalne dopełnienie wyrównujące (16 B), znaczniki Pad Length i Next Header (2 B) oraz znacznik integralności ICV (16 B), co daje łączny narzut tunelu około 70-86 bajtów. Po odliczeniu wewnętrznego IP (20 B) i TCP (20 B) bezpieczna wartość MSS wynosi dokładnie 1360 bajtów.

W przypadku protokołu WireGuard narzut pakietu w sieci IPv4 wynosi 60 bajtów (20 B IP + 8 B UDP + 32 B WireGuard), co przy MTU 1500 B pozwala na ustawienie MTU tunelu na 1440 B, a wartości MSS na poziomie 1400 bajtów (lub 1380 B dla bezpiecznego MTU 1420 B). Jeżeli transmisja tunelowa lub wewnętrzna korzysta z protokołu IPv6, należy bezwzględnie pamiętać o odliczeniu dodatkowych 20 bajtów wynikających z większego nagłówka IPv6 (40 B zamiast 20 B).

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Reguły zapory sieciowej i bilans pakietów.

W systemie MikroTik RouterOS mechanizm modyfikacji MSS realizowany jest za pośrednictwem tablicy Mangle zapory sieciowej (/ip firewall mangle). Tablica ta służy do zaawansowanego znakowania pakietów oraz manipulacji polami nagłówków przed podjęciem ostatecznych decyzji o trasowaniu lub filtracji. Reguły modyfikacji MSS umieszcza się standardowo w łańcuchu forward, który przetwarza cały ruch tranzytowy przechodzący przez router.

Podstawowa składnia polecenia wiersza poleceń CLI RouterOS przyjmuje postać: /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=1360 comment="Podstawowy MSS Clamping dla VPN". Reguła ta dopasowuje wszystkie pakiety protokołu TCP z ustawioną flagą SYN i bezwarunkowo wymusza wpisanie wartości 1360 do pola opcji MSS.

W praktyce inżynierskiej powyższa reguła wymaga jednak istotnego doprecyzowania. Bezwarunkowe ustawienie new-mss=1360 sprawia, że jeśli stacja kliencka wynegocjowała wcześniej mniejszy MSS (np. urządzenie mobilne w sieci komórkowej ogłaszające MSS 1280 bajtów), router sztucznie zwiększy ten parametr do 1360 bajtów, co doprowadzi do natychmiastowej fragmentacji. Prawidłowa reguła musi obligatoryjnie zawierać warunek progowy: tcp-mss=1361-65535, gwarantujący obniżanie wyłącznie segmentów zbyt dużych.

Dodatkowo zaleca się wykluczenie pakietów z flagą RST poprzez zapis tcp-flags=syn,!rst. Alternatywnym i wysoce zalecanym parametrem w systemie RouterOS jest opcja dynamiczna: action=change-mss passthrough=yes tcp-flags=syn,!rst clamp-to-pmtu=yes. W tym wariancie router samodzielnie odczytuje MTU interfejsu wyjściowego i dynamicznie kalkuluje optymalny MSS, eliminując konieczność ręcznego wpisywania sztywnych wartości liczbowych.

Źródła i dokumentacja techniczna: Dokumentacja jądra Linux: Rozszerzenie TCPMSS w podsystemie iptables.

Wdrożenie globalnej reguły MSS Clamping dla całego ruchu tranzytowego w sieci korporacyjnej rozwiązuje problem tuneli VPN, lecz jest rozwiązaniem suboptymalnym dla komunikacji ogólnej. Pakiety kierowane do serwerów w publicznym Internecie (np. popularnych portali czy usług chmurowych) nie podlegają enkapsulacji VPN i mogłyby bez przeszkód korzystać z pełnego MSS 1460 bajtów. Wymuszanie na nich niższego MSS niepotrzebnie obniża przepustowość łącza WAN.

Właściwą praktyką inżynierską w systemie RouterOS jest wdrożenie selektywnego MSS Clamping, dopasowanego wyłącznie do ruchu tunelowego. Jeżeli router realizuje połączenie site-to-site do zdalnej podsieci korporacyjnej (np. 10.0.0.0/24), regułę Mangle zawęża się poprzez wskazanie adresu docelowego: /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn,!rst dst-address=10.0.0.0/24 tcp-mss=1361-65535 action=change-mss new-mss=1360.

Ponieważ ruch TCP jest dwukierunkowy, pakiety SYN-ACK generowane przez zdalny serwer w podsieci 10.0.0.0/24 również muszą zostać zmodyfikowane. Wymaga to dodania symetrycznej reguły dopasowującej adres źródłowy: src-address=10.0.0.0/24. Alternatywnie administrator może wykorzystać listy adresowe (dst-address-list=Sieci_VPN oraz src-address-list=Sieci_VPN), co pozwala na centralne zarządzanie wieloma podsieciami zdalnymi za pomocą zaledwie dwóch uniwersalnych reguł w tablicy Mangle.

W przypadku tuneli opartych na dedykowanych interfejsach wirtualnych (WireGuard, GRE, IPIP, L2TP) najczystszą metodą selekcji jest odwołanie do nazw interfejsów wyjściowych i wejściowych: out-interface=wg0 lub in-interface=wg0. Zapewnia to 100% pewności, że reguła modyfikacji MSS zadziała dokładnie wtedy, gdy pakiet fizycznie wpływa do tunelu kryptograficznego lub go opuszcza, nie ingerując w żaden inny ruch w sieci.

Źródła i dokumentacja techniczna: Dokumentacja systemowa Linux: Narzędzie iptables i tablica Mangle.

System MikroTik RouterOS w wersji 7 wprowadził pełną, natywną obsługę protokołu WireGuard jako integralnego elementu jądra systemu. Podczas tworzenia nowego interfejsu WireGuard system domyślnie przypisuje mu wartość mtu=1420. Wartość ta została dobrana przez inżynierów w celu zagwarantowania niezawodnej pracy w sieciach o zróżnicowanej infrastrukturze tranzytowej, w tym na łączach z enkapsulacją IPv6 oraz PPPoE.

Weryfikację aktualnego stanu interfejsu w wierszu poleceń CLI wykonuje się za pomocą polecenia: /interface wireguard print. W celu modyfikacji MTU należy posłużyć się precyzyjną składnią odwołującą się do nazwy interfejsu: /interface wireguard set [find name="wg0"] mtu=1420. Powszechnym błędem początkujących administratorów jest próba stosowania parametru numbers=wg0 z podaniem nazwy zamiast indeksu numerycznego, co w skryptach RouterOS skutkuje błędem wykonania polecenia.

Mimo ustawienia MTU interfejsu na 1420 bajtów, stacje robocze w sieci lokalnej generują pakiety TCP o MSS równym 1460 bajtów. Jeżeli stacje te nie obsługują poprawnie komunikatów ICMP generowanych przez router, konieczne jest wdrożenie reguły MSS Clamping dedykowanej dla interfejsu WireGuard. Dla MTU równego 1420 bajtów bezpieczna wartość MSS wynosi dokładnie 1380 bajtów (1420 B - 20 B IP - 20 B TCP).

Właściwa reguła Mangle w systemie RouterOS przyjmuje postać: /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn,!rst out-interface=wg0 tcp-mss=1381-65535 action=change-mss new-mss=1380 comment="MSS Clamping dla ruchu wychodzącego WireGuard". Zaleca się również dodanie reguły dla ruchu przychodzącego z warunkiem in-interface=wg0, co zapewnia symetryczną korektę negocjacji dla połączeń inicjowanych przez zdalnych partnerów (peerów).

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Konfiguracja interfejsu i tuneli WireGuard.

Podczas gdy technika MSS Clamping doskonale rozwiązuje problemy transmisji strumieniowych protokołu TCP, jest ona całkowicie bezradna wobec ruchu bezpołączeniowego UDP (np. zapytania DNS, transmisje głosu VoIP, protokół QUIC). Aby zabezpieczyć ruch UDP przed problemami z MTU, administrator musi skonfigurować prawidłową wartość MTU bezpośrednio na wirtualnym interfejsie tunelowym.

W systemie RouterOS należy bezwzględnie rozróżniać architekturę poszczególnych technologii VPN. Klasyczny IPsec oparty na politykach (/ip ipsec policy) nie tworzy logicznego interfejsu sieciowego w systemie operacyjnym, w związku z czym menu /interface ipsec w RouterOS nie istnieje. Nowoczesne tunele IPsec w trybie VTI (Virtual Tunnel Interface) realizuje się w RouterOS v7 za pomocą dedykowanych interfejsów XFRM: /interface xfrm add name=xfrm-vpn ipsec-policy=polityka1 mtu=1416.

W przypadku popularnych tuneli GRE i EoIP interfejsy logiczne są w pełni konfigurowalne. Czysty tunel GRE na łączu Ethernet otrzymuje domyślnie mtu=1476 (1500 B - 24 B narzutu). Jeżeli jednak włączone zostanie szyfrowanie IPsec (ipsec-secret=Hasło), narzut pakietu wzrasta o ponad 60 bajtów. Administrator musi wówczas ręcznie obniżyć parametr MTU: /interface gre set [find name="gre-tunnel1"] mtu=1416.

Dla tuneli protokołu L2TP konfigurację wykonuje się w menu klienta lub serwera: /interface l2tp-client set [find name="l2tp-out1"] mtu=1400 mru=1400. Ustawienie odpowiednio niskiego MTU bezpośrednio na interfejsie tunelu sprawia, że jądro systemu RouterOS samo generuje lokalne komunikaty ICMP Fragmentation Needed dla zbyt dużych pakietów lub dokonuje ich bezpiecznej fragmentacji przed enkapsulacją, chroniąc przed utratą danych w sieci WAN.

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Konfiguracja interfejsów tunelowych L2TP.

Wdrożenie tuneli VPN w środowisku produkcyjnym wymaga rygorystycznego przestrzegania procedury audytowej. Doświadczenie inżynierskie wskazuje, że większość trudnych do zdiagnozowania awarii sieciowych wynika z pominięcia podstawowych zależności transmisyjnych na styku sieci LAN i WAN. Poniższa lista kontrolna stanowi kompletny przewodnik weryfikacji parametrów MTU w systemie RouterOS.

Krok 1: weryfikacja MTU interfejsów fizycznych i WAN poleceniem /interface print detail ze szczególnym uwzględnieniem łączy dostępowych. Krok 2: w przypadku łączy PPPoE potwierdzenie, że MTU wynosi maksymalnie 1492 bajty (lub mniej, jeśli dostawca narzuca dodatkowe ograniczenia). Krok 3: sprawdzenie konfiguracji interfejsów tunelowych (WireGuard, GRE, XFRM) i upewnienie się, że ich MTU uwzględnia pełny narzut kryptograficzny.

Krok 4: weryfikacja obecności selektywnej reguły MSS Clamping w menu /ip firewall mangle z parametrem new-mss=1360 (dla IPsec) lub 1380 (dla WireGuard) oraz obligatoryjnym warunkiem progowym tcp-mss=1361-65535. Krok 5: sprawdzenie liczników pakietów reguły Mangle (/ip firewall mangle print stats), aby upewnić się, że reguła rzeczywiście przechwytuje pakiety SYN. Krok 6: sprawdzenie kolejności reguł w zaporze sieciowej - reguła Mangle musi znajdować się przed ewentualnymi regułami blokującymi lub akceleracją FastTrack.

Krok 7: wykonanie empirycznego testu poleceniem /ping <zdalny_ip> size=1472 dont-fragment w celu potwierdzenia drożności łącza bazowego. Krok 8: przeprowadzenie testu ping przez tunel z rozmiarem odpowiadającym MTU tunelu (np. size=1420 dont-fragment lub size=1392). Krok 9: weryfikacja reguł filtrujących zapory w menu /ip firewall filter i upewnienie się, że ruch ICMP w stanie connection-state=established,related jest bezwzględnie akceptowany. Krok 10: inspekcja logów systemowych /log print where topics~"ipsec,mangle,firewall" w poszukiwaniu raportów o błędach fragmentacji.

Źródła i dokumentacja techniczna: Dokumentacja MikroTik RouterOS: Podręcznik wiersza poleceń CLI.

W systemie operacyjnym Cisco IOS mechanizm MSS Clamping został zaimplementowany w sposób prosty i wydajny za pomocą dedykowanego polecenia poziomu interfejsu: ip tcp adjust-mss <wartość>. Rozwiązanie to jest zoptymalizowane w strukturach przełączania Cisco Express Forwarding (CEF), dzięki czemu modyfikacja nagłówków TCP nie obciąża procesora głównego routera i nie powoduje degradacji przepustowości łącza.

Kluczową decyzją architektoniczną jest właściwe umiejscowienie polecenia w konfiguracji routera. Najczęściej stosowaną praktyką jest aktywacja mechanizmu na interfejsie wewnętrznym LAN (np. interface GigabitEthernet0/0), skierowanym w stronę stacji roboczych użytkowników. Gdy stacja generuje pakiet TCP SYN z domyślnym MSS 1460 B, router w momencie odbierania pakietu natychmiast modyfikuje nagłówek na wartość wskazaną (np. ip tcp adjust-mss 1360).

Alternatywną metodą, stosowaną w przypadku architektur z wirtualnymi interfejsami tunelowymi (np. GRE over IPsec lub VTI), jest nałożenie polecenia bezpośrednio na interfejs logiczny: interface Tunnel0. Sprawia to, że modyfikacji podlegają wyłącznie segmenty kierowane bezpośrednio do tunelu szyfrowanego, podczas gdy ruch stacji roboczych wychodzący do publicznego Internetu przez interfejs WAN zachowuje standardowy MSS 1460 bajtów.

W nowoczesnych środowiskach z podwójnym stosem (IPv4 i IPv6) należy pamiętać, że polecenie ip tcp adjust-mss obsługuje wyłącznie pakiety protokołu IPv4. Aby zabezpieczyć ruch IPv6 przed problemami z MTU w tunelu, konieczne jest równoległe dodanie dedykowanego polecenia dla nowej generacji protokołu: ipv6 tcp adjust-mss 1340. Weryfikację poprawności konfiguracji przeprowadza się za pomocą polecenia: show ip interface GigabitEthernet0/0 | include adjust.

Źródła i dokumentacja techniczna: Opracowanie inżynierskie NetworkLessons: Konfiguracja MTU i MSS w Cisco IOS.

Zastosowanie bezpośredniego polecenia ip tcp adjust-mss na fizycznym interfejsie LAN w systemie Cisco IOS modyfikuje pakiety SYN dla wszystkich nawiązywanych połączeń, w tym również dla ruchu lokalnego i bezpośredniego tranzytu do Internetu. W rozległych sieciach przedsiębiorstw, gdzie przez jeden interfejs przepływa ruch do wielu odległych oddziałów połączonych tunelami o różnym MTU, konieczne jest zastosowanie rozwiązania bardziej selektywnego.

W systemie Cisco IOS elastyczność taką zapewnia mechanizm trasowania sterowanego polityką (PBR - Policy-Based Routing) w połączeniu z mapami tras (route-map). W pierwszym kroku inżynier definiuje rozszerzoną listę dostępu ACL określającą ruch podlegający modyfikacji: access-list 110 permit tcp 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 eq www lub obejmującą wszystkie porty TCP pomiędzy podsiecią lokalną a siecią zdalną za tunelem VPN.

Następnie tworzona jest mapa trasowania powiązująca zdefiniowaną listę ACL z akcją modyfikacji parametru MSS: route-map ADJUST-MSS permit 10, match ip address 110, set ip tcp adjust-mss 1360. Konstrukcja ta pozwala na zdefiniowanie wielu sekwencji o różnych wartościach MSS dopasowanych do specyfiki poszczególnych tuneli (np. MSS 1360 dla IPsec z NAT-T, a MSS 1400 dla wydajnego tunelu GRE).

Ostatnim etapem jest nałożenie mapy na interfejs wejściowy LAN: interface GigabitEthernet0/0, ip policy route-map ADJUST-MSS. Od tego momentu procesor CEF routera bada pakiety SYN i modyfikuje MSS wyłącznie wtedy, gdy adres docelowy pakietu wskazuje na zdalną sieć korporacyjną. Diagnostykę i weryfikację poprawności dopasowań wykonuje się za pomocą poleceń: show route-map oraz show ip policy.

Źródła i dokumentacja techniczna: Poradnik inżynierski NetworkLessons: Zależności pomiędzy IP MTU, PMTUD i MSS.

W sytuacjach awaryjnych, w których wdrożenie techniki MSS Clamping jest niemożliwe (np. obecność aplikacji generujących duży strumień pakietów UDP) lub gdy na ścieżce występuje nieusuwalna czarna dziura MTU, administrator urządzeń Cisco może zmienić domyślną politykę traktowania flagi Don't Fragment. Standardowo Cisco IOS kopiuje wartość bitu DF z nagłówka wewnętrznego do zewnętrznego nagłówka pakietu IPsec.

W celu wymuszenia czyszczenia flagi DF w konfiguracji map kryptograficznych stosuje się polecenie: set df-bit clear (w starszych wersjach dokumentacji mylnie przytaczaną jako set ip df 0, co nie jest poprawną składnią CLI). Globalnie dla całego routera ustawia się ją w trybie konfiguracji globalnej za pomocą polecenia: crypto ipsec df-bit clear. Na wirtualnych interfejsach tunelowych GRE/VTI stosuje się z kolei polecenie interfejsowe: ip df-bit clear.

Wyzerowanie flagi DF sprawia, że zewnętrzny pakiet IPsec może zostać pofragmentowany przez routery w sieci dostawcy usług internetowych w razie napotkania wąskiego gardła MTU. Choć zapobiega to zrywaniu sesji aplikacyjnych, rozwiązanie to generuje duży narzut na procesor routera odbierającego (reassembly) i powinno być stosowane ze świadomością jego wad wydajnościowych.

Diagnostyka problemów MTU w systemie Cisco IOS opiera się na zestawie poleceń weryfikacyjnych i śledzących: show interfaces GigabitEthernet0/0 | include MTU (sprawdzenie MTU interfejsu), show crypto ipsec sa | include mtu (weryfikacja wynegocjowanego MTU dla tunelu IPsec) oraz debug ip icmp (podgląd przychodzących i odrzucanych komunikatów błędu Fragmentation Needed). W nowszych wersjach IOS polecenie debug ip tcp adjust-mss pozwala na żywo śledzić pakiety podlegające modyfikacji MSS.

Źródła i dokumentacja techniczna: Dokumentacja jądra Linux: Parametry sysctl dla stosu IP i obsługi flagi DF.

Zestawienie stabilnego połączenia IPsec site-to-site pomiędzy dwoma routerami Cisco IOS wymaga harmonijnej integracji kilku niezależnych podsystemów: protokołu zarządzania kluczami ISAKMP/IKE, zestawu transformacji kryptograficznych IPsec (transform-set), mapy kryptograficznej powiązanej z interfejsem WAN, reguł wykluczenia z translacji NAT oraz ochrony parametrów transmisyjnych MSS.

W prezentowanym scenariuszu router R1 (podsieć lokalna 192.168.1.0/24) łączy się przez publiczny Internet z routerem centralnym R2 (podsieć 10.0.0.0/24, publiczny IP 1.2.3.4). Faza 1 IKE wykorzystuje bezpieczne algorytmy: AES-256, SHA-256, uwierzytelnianie kluczem PSK oraz grupę Diffie-Hellmana 14 (2048-bitową). Kluczowym elementem dla środowisk z translacją adresów jest aktywacja mechanizmu podtrzymywania sesji: crypto isakmp nat keepalive 20.

Faza 2 IPsec wykorzystuje nowoczesny zestaw transformacji: crypto ipsec transform-set AES256 esp-aes 256 esp-sha256-hmac, a mapa kryptograficzna wymusza Perfect Forward Secrecy: set pfs group14. Ważnym aspektem jest konfiguracja list kontroli dostępu. Lista ACL 100 sterująca procesem translacji NAT zawiera klauzulę deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255, co chroni pakiety tunelowe przed podmianą adresów źródłowych, natomiast lista ACL 101 definiuje ruch podlegający szyfrowaniu.

Ostatnim elementem wdrożenia jest ochrona przed problemem czarnej dziury MTU. Na wewnętrznym interfejsie LAN (interface GigabitEthernet0/0) wdrożono polecenie: ip tcp adjust-mss 1360. Gwarantuje to, że wszystkie stacje robocze nawiązujące połączenia z serwerami w centrali wynegocjują bezpieczny rozmiar segmentu 1360 bajtów, co całkowicie zapobiega fragmentacji i zapewnia maksymalną wydajność transmisji.

Źródła i dokumentacja techniczna: Dokumentacja StrongSwan: Przewodnik konfiguracji tuneli site-to-site IPsec.

Mechanizm MSS Clamping jest rozwiązaniem dedykowanym wyłącznie dla protokołu TCP, który posiada zdefiniowane pole negocjacji rozmiaru segmentu w nagłówku SYN. Protokół UDP (User Datagram Protocol) jest protokołem całkowicie bezpołączeniowym, pozbawionym mechanizmów negocjacji, potwierdzeń oraz podziału na segmenty w warstwie transportowej. Jeśli aplikacja przekaże do gniazda UDP datagram o rozmiarze 1480 bajtów, router w żaden sposób nie może go 'zmniejszyć' podczas transmisji.

W klasycznych sieciach większość aplikacji UDP generuje małe pakiety: próbki głosu w telefonii VoIP (protokół RTP) liczą zazwyczaj od kilkudziesięciu do około 200 bajtów, a pakiety protokołu NTP zaledwie kilkadziesiąt bajtów, w związku z czym nie napotykają one barier MTU. Poważny problem pojawia się jednak w przypadku protokołu DNS z rozszerzeniem EDNS0 (RFC 6891), które pozwala na odpowiedzi UDP o wielkości do 4096 bajtów (szczególnie przy wdrożeniu podpisów DNSSEC), a także w strumieniowaniu wideo i grach sieciowych.

Istotną zmianę w architekturze ruchu internetowego przyniosło upowszechnienie protokołu QUIC (stanowiącego fundament standardu HTTP/3). QUIC zastępuje klasyczny stos TCP+TLS i przesyła wszystkie dane wewnątrz datagramów UDP. Aby zapobiec powstawaniu czarnych dziur MTU w ruchu UDP, IETF opracowało nowoczesny standard RFC 8899 definiujący procedurę Datagram Packetization Layer Path MTU Discovery (DPLPMTUD).

W ramach DPLPMTUD aplikacja nadawcza aktywnie sonduje ścieżkę specjalnie uformowanymi pakietami UDP (tzw. pakietami próbnymi) o określonym rozmiarze. Jeżeli pakiet testowy zostanie potwierdzony w warstwie protokołu aplikacyjnego, węzeł podnosi efektywne MTU; brak potwierdzenia skutkuje automatycznym obniżeniem rozmiaru datagramów. Dopóki jednak aplikacja nie wspiera RFC 8899, jedyną skuteczną metodą ochrony ruchu UDP w tunelach VPN pozostaje ręczne obniżenie MTU na wirtualnym interfejsie tunelu.

Źródła i dokumentacja techniczna: Dokumentacja Wireshark: Analiza protokołów UDP, QUIC i datagramów.

Wieloletnie doświadczenie audytowe weryfikacji wirtualnych sieci prywatnych pozwala na wyodrębnienie powtarzalnego katalogu błędów popełnianych przez administratorów. Pierwszym i najpoważniejszym błędem jest całkowity brak wdrożenia mechanizmu MSS Clamping. Administrator konfiguruje tunel IPsec lub WireGuard, weryfikuje łączność prostym poleceniem ping i uznaje wdrożenie za zakończone, po czym użytkownicy zgłaszają awarie przy próbie otwierania stron intranetowych czy transferu plików.

Drugim błędem jest dobór niewłaściwej wartości MSS. Ustawienie wartości zbyt wysokiej (np. 1420 bajtów przy IPsec z NAT-T na łączu PPPoE) nie zapobiega fragmentacji i pozostawia problem nierozwiązany. Z kolei ustawienie wartości znacznie za niskiej (np. 1200 bajtów 'na wszelki wypadek') drastycznie obniża wydajność łącza, generując zbędny narzut procesora i zwielokrotniając liczbę przesyłanych ramek.

Trzecim powszechnym błędem jest zastosowanie reguły MSS Clamping na niewłaściwym interfejsie sieciowym (np. na interfejsie WAN zamiast LAN w systemie Cisco IOS), co sprawia, że reguła nie przechwytuje pakietów SYN generowanych przez lokalne stacje robocze. Czwartym błędem jest nieuwzględnienie specyfiki łączy dostępowych PPPoE (MTU 1492 B), co przesuwa cały bilans transmisyjny o 8 bajtów w dół i unieważnia standardowe kalkulacje.

Kolejne krytyczne błędy obejmują: bezwzględne blokowanie całego ruchu ICMP na zaporze sieciowej (tworzenie czarnej dziury MTU), zaniechanie restartu istniejących sesji TCP po rekonfiguracji routera (stare sesje kontynuują transmisję ze starym, wadliwym MSS), ignorowanie ruchu bezpołączeniowego UDP oraz kolizje reguł Mangle z mechanizmami sprzętowej akceleracji FastTrack/FastPath w systemie RouterOS, które potrafią ominąć inspekcję pakietów.

Źródła i dokumentacja techniczna: Oficjalny portal CERT Polska: Zalecenia i standardy cyberbezpieczeństwa.

Zarządzanie parametrem MTU oraz wielkością segmentów MSS stanowi fundamentalny warunek stabilności, przepustowości i niezawodności współczesnych wirtualnych sieci prywatnych. Ignorowanie narzutów enkapsulacji kryptograficznej prowadzi do powstawania trudnych do wykrycia czarnych dziur MTU, objawiających się pozorowaniem prawidłowego działania sieci przy jednoczesnym paraliżu transferu danych użytkowych.

Dla ruchu opartego na protokole TCP najskuteczniejszym rozwiązaniem inżynierskim jest technika MSS Clamping, wdrażana na routerach brzegowych za pomocą tablicy Mangle w systemie MikroTik RouterOS lub polecenia ip tcp adjust-mss w systemie Cisco IOS. W przypadku ruchu UDP konieczne jest prewencyjne obniżenie parametru MTU bezpośrednio na wirtualnych interfejsach tunelowych oraz wspieranie nowoczesnych standardów automatycznej detekcji ścieżki (DPLPMTUD).

W celach wdrożeniowych zaleca się stosowanie następujących sprawdzonych wartości referencyjnych dla łączy o standardowym MTU 1500 bajtów: dla tuneli IPsec ESP z mechanizmem NAT-T referencyjny MSS wynosi 1360 bajtów (IPv4) lub 1340 bajtów (IPv6); dla protokołu WireGuard MTU interfejsu wynosi 1420 bajtów, a bezpieczny MSS to 1380 bajtów; dla protokołu OpenVPN rekomenduje się dyrektywę mssfix 1360; w przypadku łączy dostępowych PPPoE każdą z powyższych wartości MSS należy bezwzględnie obniżyć o dodatkowe 8-10 bajtów (np. 1350 B dla IPsec).

Każde wdrożenie nowego tunelu VPN w infrastrukturze korporacyjnej powinno być obligatoryjnie zakończone weryfikacją empiryczną za pomocą testów ping z wymuszoną flagą DF o rosnącym rozmiarze ładunku oraz inspekcją śladu pakietów w analizatorze Wireshark. Ścisłe przestrzeganie zaprezentowanych zasad eliminuje ryzyko powstawania anomalii transmisyjnych i gwarantuje najwyższą jakość usług w bezpiecznej sieci prywatnej.

Źródła i dokumentacja techniczna: Publikacja NIST SP 800-77 Rev. 1: Przewodnik po bezpiecznych sieciach IPsec VPN.