Problem maksymalnej jednostki transmisji (MTU) w kontekście sieci VPN jest jednym z najczęściej pomijanych, a zarazem krytycznych zagadnień w praktyce inżynierskiej. MTU określa maksymalny rozmiar pojedynczego pakietu, który może być przesłany przez interfejs sieciowy bez konieczności fragmentacji. W sieciach Ethernet standardowa wartość MTU wynosi 1500 bajtów, co jest wartością przyjętą jako domyślna dla większości systemów operacyjnych i urządzeń sieciowych.
Protokoły VPN dodają własne nagłówki do przesyłanych pakietów, co zmniejsza przestrzeń dostępną dla danych użytkownika. Przykładowo IPSec w trybie tunelowym z NAT-T dodaje około 60-80 bajtów narzutu, co oznacza, że pakiet TCP z danymi o rozmiarze 1460 bajtów (standardowy MSS) po enkapsulacji może przekroczyć MTU łącza. Konsekwencją jest fragmentacja pakietów po stronie nadawcy lub ich odrzucenie, gdy ustawiona jest flagą Don't Fragment (DF).
W trakcie wykładu przeanalizujemy mechanizmy powstawania problemów MTU w tunelach VPN, omówimy techniki diagnostyczne oraz praktyczne metody konfiguracji MSS Clamping na platformach MikroTik RouterOS i Cisco IOS. przedstawione zostaną również gotowe przykłady konfiguracji, które można zastosować w rzeczywistych wdrożeniach.
MTU jest parametrem charakterystycznym dla każdego interfejsu sieciowego i zależy od zastosowanej technologii warstwy fizycznej i łącza danych. Standard IEEE 802.3 dla Ethernetu definiuje maksymalny rozmiar ramki na 1518 bajtów, z czego 18 bajtów stanowią nagłówki warstwy łącza (adres MAC źródła i celu, EtherType, FCS). Po odjęciu tych 18 bajtów otrzymujemy 1500 bajtów dla pakietu IP, co jest standardowym MTU dla Ethernetu.
W sieciach operatorskich opartych na PPPoE (Point-to-Point Protocol over Ethernet), które są powszechnie stosowane w technologiach ADSL i VDSL, nagłówek PPPoE dodaje 8 bajtów, redukując MTU do 1492 bajtów. Jest to częsta przyczyna problemów z VPN u klientów korzystających z łączy DSL, ponieważ standardowe aplikacje zakładają MTU 1500, a rzeczywiste MTU łącza jest o 8 bajtów mniejsze.
Jumbo frames (ramki o rozmiarze do 9000 bajtów) są stosowane w sieciach szkieletowych i centrach danych, gdzie pozwalają na redukcję narzutu związanego z przetwarzaniem dużej liczby małych pakietów. W kontekście VPN jumbo frames mogą być problematyczne, ponieważ tunel VPN dodaje własne nagłówki, które mogą spowodować przekroczenie MTU fizycznego interfejsu, nawet jeśli wewnętrzny pakiet mieści się w standardowym MTU.
Path MTU Discovery jest kluczowym mechanizmem umożliwiającym hostom wykrycie maksymalnego rozmiaru pakietu, który może być przesłany bez fragmentacji na całej trasię między źródłem a celem. Proces rozpoczyna się od wysłania pakietu o rozmiarze równym MTU interfejsu źródłowego z flagą DF ustawioną na 1. Jeśli któryś z routerów pośrednich ma niższe MTU, odrzuca pakiet i odsyła komunikat ICMP Fragmentation Needed, podając w polu Next-Hop MTU wartość swojego MTU.
Host źródłowy po otrzymaniu komunikatu ICMP zmniejsza rozmiar pakietu do wartości wskazanej w komunikacie i ponawia próbę. Proces ten jest powtarzany aż do momentu, gdy pakiet dotrze do celu bez fragmentacji. Ostateczna wartość MTU jest zapisywana w tablicy routingu i wykorzystywana do kolejnych połączeń z danym celem. W systemach Linux i Windows zarządzanie tym procesem odbywa się automatycznie w stosię TCP/IP.
W przypadku protokołu TCP, odkryte MTU jest wykorzystywane do ustawienia MSS (Maximum Segment Size) podczas negocjacji połączenia. Dzięki temu hosty od razu używają odpowiedniego rozmiaru segmentów, unikając fragmentacji. Niestety w środowiskach VPN mechanizm ten często zawodzi, ponieważ router VPN enkapsuluje pakiety, a hosty wewnątrz tunelu nie są świadome narzutów dodawanych przez tunel.
Blokowanie komunikatów ICMP przez zapory sieciowe jest jedną z najczęstszych przyczyn problemów z łącznością w sieciach VPN, a jednocześnie jednym z najtrudniejszych do zdiagnozowania objawów. Administratorzy sieciowi często blokują cały ruch ICMP, kierując się błędnym przekonaniem, że zwiększa to bezpieczeństwo sieci. W rzeczywistości ICMP jest niezbędny do poprawnego działania protokołu IP, a jego blokowanie prowadzi do poważnych problemów z wydajnością i stabilnością.
Zjawisko MTU black hole polega na tym, że host źródłowy wysyła pakiet z flagą DF=1, router pośredni odrzuca go z powodu przekroczenia MTU i wysyła komunikat ICMP Fragmentation Needed, ale komunikat ten jest blokowany przez zaporę sieciową zanim dotrze do hosta źródłowego. Host, nie otrzymawszy informacji zwrotnej, kontynuuje wysyłanie pakietów o tym samym rozmiarze, które są konsekwentnie odrzucane. W przypadku TCP prowadzi to do wielokrotnych retransmisji i ostatecznego timeoutu połączenia.
Objawy MTU black hole są niespecyficzne i często mylnie interpretowane jako problemy z DNS, przeciążenie sieci lub błędy aplikacji. Typowe symptomy to: strona WWW ładuje się częściowo (HTML się pobiera, ale CSS/obrazy nie), maile z załącznikami nie chcą zostać wysłane, transfery plików przez SMB/CIFS zawieszają się przy większych plikach, połączenia SSH nawiązują się, ale po wpisaniu hasła terminal zawiesza się. Wszystkie te objawy znikają po zastosowaniu MSS Clamping.
Zrozumienie narzutów poszczególnych protokołów VPN jest kluczowe dla poprawnego skonfigurowania MTU w sieci. Każdy protokół dodaje własne nagłówki na różnych warstwach modelu OSI, co zwiększa całkowity rozmiar pakietu przesyłanego przez sieć fizyczną. Jeśli suma nagłówków VPN i oryginalnego pakietu IP przekracza MTU interfejsu fizycznego, dochodzi do fragmentacji lub odrzucenia pakietu w zależności od stanu flagi DF.
Należy pamiętać, że podane wartości są orientacyjne i mogą się różnić w zależności od konkretnej konfiguracji protokołu. Na przykład OpenVPN może mieć większy narzut przy użyciu starszych algorytmów szyfrowania (np. AES-256-CBC z HMAC) niż przy nowoczesnych (AES-256-GCM). Podobnie IPSec może mieć różny narzut w zależności od wybranego algorytmu szyfrowania, długości ICV oraz obecności NAT-T.
WireGuard wyróżnia się na tle innych protokołów minimalnym narzutem wynoszącym około 32 bajty. Osiąga to dzięki prostocie konstrukcji - pojedynczy typ pakietu, brak negocjacji w oddzielnym kanale, zintegrowane szyfrowanie i uwierzytelnianie. Dla porównania IPSec z NAT-T może dodawać nawet 80 bajtów narzutu, co przy standardowym MSS 1460 daje efektywny rozmiar danych na poziomie 1380-1400 bajtów.
Szczegółowa analiza struktury pakietu IPSec ESP w trybie tunelowym pozwala zrozumieć, skąd bierze się narzut protokołu i jak go optymalizować. Zewnętrzny nagłówek IP zawiera adresy publiczne punktów końcowych tunelu, czyli routerów VPN. Jest on niezbędny do routowania pakietu przez Internet i podlega translacji NAT, jeśli taka występuje na drodze pakietu. W przypadku IPv4 nagłówek ten ma 20 bajtów, a w IPv6 - 40 bajtów.
Nagłówek ESP składa się z Security Parameters Index (4 bajty) i Sequence Number (4 bajty). SPI identyfikuje security association (SA) używane do deszyfrowania pakietu, a Sequence Number chroni przed atakami replay. Wektor inicjujący IV jest wymagany przez algorytmy szyfru blokowego w trybie CBC i ma długość 16 bajtów dla AES. Niektóre algorytmy, takie jak AES-GCM, używają IV o długości 8 lub 12 bajtów, ale wymagają dodatkowego pola.
Padding (wypełnienie) jest dodawany w celu dopasowania długości szyfrowanego tekstu do rozmiaru bloku algorytmu szyfrującego. Dla AES blok ma 16 bajtów, więc padding może wynosić od 0 do 255 bajtów. W praktyce dla typowych rozmiarów pakietów padding wynosi 0-15 bajtów po zaokrągleniu. ICV (Integrity Check Value) to suma kontrolna zapewniająca integralność pakietu - dla SHA-256 ma długość 16 bajtów.
NAT-T (NAT Traversal) dodaje 8-bajtowy nagłówek UDP do pakietów ESP, co zwiększa całkowity narzut protokołu IPSec. Nagłówek UDP jest niezbędny do tego, aby router NAT mógł poprawnie translować pakiety ESP, które w oryginalnej postaci nie mają numerów portów. Dzięki enkapsulacji w UDP router NAT traktuje ruch VPN jak zwykły ruch UDP i może go translować bez naruszania integralności wewnętrznych struktur danych.
Non-ESP Marker to 4-bajtowe pole o wartości 0x00000000, które jest dodawane przed pakietami IKE po przełączeniu na port 4500. Służy do odróżnienia pakietów IKE od pakietów ESP - jeśli pierwsze 4 bajty po nagłówku UDP mają wartość 0, oznacza to pakiet IKE; w przeciwnym razie jest to pakiet ESP. Dla pakietów ESP pole to nie występuje, co oszczędza 4 bajty narzutu.
Przy MTU 1500 i narzucie IPSec z NAT-T wynoszącym około 68-80 bajtów, efektywne MTU dla danych wewnątrz tunelu wynosi około 1420-1432 bajty. Przekładając to na MSS TCP, po odjęciu nagłówków TCP i IP (łącznie 40 bajtów) otrzymujemy zalecaną wartość MSS na poziomie 1360-1392 bajtów. Jest to wartość, którą należy ustawić w konfiguracji MSS Clamping po obu stronach tunelu.
WireGuard został zaprojektowany z myślą o minimalnym narzucie protokołowym, co czyni go jednym z najbardziej wydajnych protokołów VPN pod względem wykorzystania MTU. Cała komunikacja w WireGuard odbywa się za pomocą pojedynczego typu pakietów transportowych, które łączą w sobie funkcje szyfrowania, uwierzytelniania i tunelowania. Dzięki temu narzut protokołu jest znacznie mniejszy niż w przypadku tradycyjnego IPSec.
Standardowa wartość MTU dla interfejsów WireGuard w systemie RouterOS wynosi 1420 bajtów. Jest to wartość bezpieczna, która uwzględnia narzut protokołu WireGuard (~52-60 bajtów) oraz ewentualne dodatkowe nagłówki (VLAN, QoS). W systemach Linux domyślne MTU dla WireGuard wynosi 1420 bajtów, choć w wielu dystrybucjach można je skonfigurować w zakresię od 1280 do 1500 bajtów.
Obliczenie MSS dla WireGuard jest proste: od MTU interfejsu WireGuard (1420) odejmujemy nagłówek IP (20) i TCP (20), otrzymując 1380 bajtów. W praktyce oznacza to, że dla routerów z włączonym WireGuard nie jest konieczne stosowanie MSS Clamping, o ile MTU interfejsu WireGuard jest ustawione prawidłowo. W przypadku gdy WireGuard jest używany razem z IPSec (tzw. double VPN), narzut sumuje się i konieczne jest dodatkowe zmniejszenie MTU.
OpenVPN oferuje największą elastyczność w konfiguracji parametrów MTU spośród wszystkich popularnych protokołów VPN. W pliku konfiguracyjnym można ustawić zarówno MTU interfejsu tunelu (tun-mtu), jak i włączyć wbudowany mechanizm MSS clamping (mssfix). Domyślna wartość MTU dla interfejsu tunelu OpenVPN wynosi 1500 bajtów, ale zaleca się jej zmniejszenie do 1400-1420 bajtów w środowiskach z NAT.
Parametr mssfix w OpenVPN działa podobnie jak MSS Clamping na routerze - modyfikuje pole MSS w pakietach TCP SYN przechodzących przez tunel. Wartość domyślna mssfix wynosi 1450 bajtów, ale dla połączeń przez IPSec z NAT-T zaleca się ustawienie mssfix 1350. Opcja mssfix 0 wyłącza mechanizm, co może być przydatne, gdy MSS Clamping jest realizowany na poziomie routera.
W trybie TCP (proto tcp) OpenVPN ma dodatkowy problem - podwójna enkapsulacja TCP w TCP prowadzi do zjawiska TCP meltdown, gdzie retransmisje na obu warstwach TCP nakładają się na siebie, powodując gwałtowny spadek wydajności. Z tego powodu zaleca się stosowanie OpenVPN w trybie UDP, a TCP używać tylko w ostateczności, gdy UDP jest blokowany przez zaporę sieciową.
Protokół GRE jest często używany w sieciach operatorskich do enkapsulacji różnych protokołów warstwy 3 (IPv4, IPv6, IPX) przez sieci IPv4. Jego narzut jest stosunkowo niski - standardowy nagłówek GRE ma tylko 4 bajty (2 bajty flag + 2 bajty EtherType). Jednak GRE jest protokołem IP o numerze 47, co oznacza, że ma te same problemy z NAT co ESP - brak numerów portów uniemożliwia PAT.
W praktyce inżynierskiej GRE rzadko występuje samodzielnie - najczęściej jest chroniony przez IPSec (GRE over IPSec). W takiej konfiguracji narzut sumuje się: GRE dodaje 4 bajty, IPSec w trybie tunelowym dodaje około 50-60 bajtów, a zewnętrzny nagłówek IP dodaje 20 bajtów. Łączny narzut wynosi około 74-84 bajty, co przy MTU 1500 daje efektywne MTU dla danych na poziomie 1416-1426 bajtów.
PPTP, mimo że ma niski narzut (około 26-30 bajtów), jest protokołem przestarzałym i niebezpiecznym. Zawiera liczne luki bezpieczeństwa, z których najpoważniejsza dotyczy łatwego łamania klucza MS-CHAPv2. Microsoft, główny promotor PPTP, zaleca stosowanie L2TP/IPSec lub SSTP. Z punktu widzenia MTU, PPTP przez GRE ma podobne problemy z NAT jak inne protokoły IP, ale ze względu na brak bezpieczeństwa nie powinien być w ogóle rozważany w nowych wdrożeniach.
Fragmentacja IP jest mechanizmem pozwalającym na przesyłanie pakietów większych niż MTU łącza poprzez podzielenie ich na mniejsze jednostki. Każdy fragment jest samodzielnym pakietem IP z własnym nagłówkiem, zawierającym informacje o offsetcie i flagąch umożliwiające złożenie oryginalnego pakietu po stronie odbiorcy. W kontekście VPN fragmentacja jest szczególnie problematyczna, ponieważ odbywa się na dwóch poziomach: przed enkapsulacją i po niej.
W IPSec fragmentacja przed szyfrowaniem oznacza, że oryginalny pakiet IP jest dzielony na fragmenty, a każdy fragment jest osobno szyfrowany i enkapsulowany. To mnoży narzut protokołowy - zamiast jednego nagłówka ESP, dla każdego fragmentu dodawany jest osobny nagłówek ESP, IV i ICV. W praktyce oznacza to, że pakiet podzielony na 3 fragmenty generuje trzykrotnie większy narzut niż pakiet nie fragmentowany.
dodatkowym problemem jest fakt, że wiele zapór sieciowych i systemów IDS/IPS traktuje fragmenty jako potencjalne zagrożenie i odrzuca je. Ataki typu IP fragmentation attack (np. Teardrop, overlapping fragments) sprawiły, że administratorzy często blokują fragmenty lub stosują agresywne polityki ich składania. W przypadku VPN oznacza to, że nawet jeśli fragmentacja jest dozwolona, pakiety mogą być odrzucane przez zapory sieciowe na trasie.
Sposób obsługi flagi DF w kontekście IPSec ma kluczowe znaczenie dla zrozumienia problemów MTU w sieciach VPN. Większość implementacji IPSec domyślnie kopiuje flagę DF z wewnętrznego pakietu (oryginalnego) do zewnętrznego (po enkapsulacji). Oznacza to, że jeśli wewnętrzny pakiet miał DF=1, to zewnętrzny również będzie miał DF=1. W konsekwencji, jeśli po dodaniu nagłówków IPSec rozmiar pakietu przekracza MTU fizycznego interfejsu, router odrzuci go zamiast fragmentować.
RouterOS domyślnie kopiuje flagę DF z wewnętrznego pakietu do zewnętrznego. W większości przypadków jest to pożądane zachowanie, ponieważ aplikacje ustawiające DF=1 oczekują, że pakiet nie będzie fragmentowany. Jednak w sytuacji, gdy MTU tunelu jest zbyt małe, prowadzi to do odrzucania pakietów. W RouterOS nie ma bezpośredniej możliwości wyczyszczenia flagi DF w konfiguracji IPSec, dlatego zaleca się stosowanie MSS Clamping.
Cisco IOS oferuje opcję clear-df w konfiguracji crypto map, która pozwala na wyczyszczenie flagi DF w zewnętrznym nagłówku IP. Dzięki temu router może fragmentować pakiet po enkapsulacji, nawet jeśli wewnętrzny pakiet miał DF=1. Jest to przydatne w sytuacjach, gdy nie można zastosować MSS Clamping (np. dla ruchu UDP), ale należy pamiętać, że fragmentacja zwiększa narzut i obciążenie procesora.
PMTUD w środowisku VPN napotyka na fundamentalny problem - enkapsulacja pakietów przez router VPN oznacza, że router VPN staje się nowym źródłem pakietów z punktu widzenia sieci zewnętrznej. Kiedy pakiet po enkapsulacji przekracza MTU któregoś z interfejsów na ścieżce, router pośredni odsyła ICMP Fragmentation Needed na adres źródłowy zewnętrznego nagłówka IP, czyli na adres WAN routera VPN, a nie na adres wewnętrznego hosta.
Router VPN otrzymuje komunikat ICMP, ale nie ma mechanizmu, który pozwoliłby mu na przekazanie tej informacji do wewnątrz tunelu. Komunikat ICMP zawiera bowiem adres źródłowy i docelowy oryginalnego (zewnętrznego) pakietu, a nie wewnętrznego. Router VPN nie wie, który host wewnątrz tunelu wygenerował pakiet, który spowodował problem, ponieważ adresy wewnętrzne są ukryte za enkapsulacją.
Konsekwencją jest całkowite załamanie mechanizmu PMTUD dla ruchu przechodzącego przez tunel VPN. Hosty wewnątrz tunelu nie otrzymują informacji o konieczności zmniejszenia MTU, ponieważ komunikaty ICMP są przechwytywane przez router VPN. Jedynym skutecznym rozwiązaniem jest ręczne ustawienie odpowiedniej wartości MSS (MSS Clamping) na routerze VPN, które wymusi na hostach używanie mniejszych segmentów TCP bez potrzeby wykrywania MTU.
Objawy problemów MTU w sieciach VPN są niezwykle podstępne, ponieważ często imitują inne problemy sieciowe. Najczęstszym objawem jest częściowe ładowanie stron WWW - dokument HTML pobiera się poprawnie, ale obrazy, arkusze CSS i skrypty JavaScript nie ładują się lub ładują się tylko częściowo. Dzieje się tak, ponieważ małe pakiety HTML przechodzą przez tunel, ale większe pakiety z obrazami przekraczają MTU i są odrzucane.
charakterystycznym objawem problemów MTU jest utrata łączności po dłuższym okresię bezczynności. Dzieje się tak, ponieważ małe pakiety keepalive i początkowa negocjacja mieszczą się w MTU, ale gdy aplikacja zaczyna przesyłać większe porcje danych, pakiety przekraczają MTU i są odrzucane. To tłumaczy, dlaczego połączenie SSH nawiązuje się poprawnie, ale zawiesza się po wpisaniu hasła - wymiana kluczy i uwierzytelnianie używają małych pakietów, ale dalsza komunikacja już większych.
Objawy mogą być niesystematyczne i występować tylko dla określonych kierunków ruchu lub typów połączeń. Na przykład problem może dotyczyć tylko ruchu wychodzącego do sieci zdalnej, podczas gdy ruch przychodzący działa poprawnie. Może też zależeć od konkretnego typu implementacji TCP po stronie klienta. To sprawia, że diagnoza problemów MTU wymaga systematycznego podejścia i znajomości odpowiednich narzędzi diagnostycznych.
Test ping z flagą Don't Fragment i zmiennym rozmiarem pakietu jest podstawowym narzędziem diagnostycznym do wykrywania problemów MTU. Polega on na wysyłaniu pakietów ICMP Echo Request z ustawioną flagą DF i stopniowym zwiększaniu rozmiaru pakietu, aż do momentu, gdy pakiet przestanie docierać do celu. Rozmiar, przy którym następuje pierwsze niepowodzenie, wskazuje na MTU ścieżki sieciowej.
Dla testów przez tunel VPN kluczowe jest pingowanie hosta znajdującego się za tunelem, a nie samego routera VPN. Ping do routera VPN testuje tylko MTU ścieżki do routera, ale nie uwzględnia narzutu tunelu. Dopiero ping do hosta za tunelem wymusza enkapsulację pakietów ICMP w tunel VPN, co pozwala na wykrycie efektywnego MTU tunelu wraz z narzutem protokołu.
W systemie RouterOS do testów MTU służy komenda /ping z opcjami size i dont-fragment. Przykładowo: /ping 10.0.0.1 size=1472 dont-fragment. Jeśli ping zwraca 100% strat, należy zmniejszyć rozmiar o 8-16 bajtów i powtórzyć. Maksymalny rozmiar, który przechodzi bez strat, powiększony o 28 bajtów (IP 20 B + ICMP 8 B) daje MTU ścieżki między routerami przez tunel.
Wireshark jest niezastąpionym narzędziem do szczegółowej analizy problemów MTU w sieciach VPN. Pozwala na przechwytywanie i analizę pakietów na każdym etapie transmisji, co umożliwia zlokalizowanie dokładnego miejsca, w którym dochodzi do problemu. Kluczowe jest zastosowanie odpowiednich filtrów wyświetlania, które wyodrębnią z przechwyconego ruchu pakiety związane z wykrywaniem MTU i fragmentacją.
Filtr icmp.type == 3 && icmp.code == 4 wyświetla wszystkie komunikaty ICMP Fragmentation Needed, które pojawiają się w sieci. Jeśli takie komunikaty są obecne, oznacza to, że PMTUD działa, ale pakiety są zbyt duże. Jeśli ich brak, a jednocześnie występują retransmisje TCP (filtr tcp.analysis.retransmission), może to wskazywać na MTU black hole - hosty próbują wysyłać duże pakiety, ale nie otrzymują informacji o konieczności zmniejszenia MTU.
Analiza fragmentów IP (filtr ip.flags.mf == 1 || ip.frag_offset > 0) pozwala zidentyfikować, które routery dokonują fragmentacji i jakie pakiety są fragmentowane. W kontekście VPN fragmentacja powinna być zjawiskiem rzadkim - jeśli występuje często, oznacza to, że MSS Clamping nie działa poprawnie lub że są aplikacje używające UDP z dużymi pakietami. W takiej sytuacji należy rozważyć zmniejszenie MTU na interfejsię tunelu.
MSS Clamping jest jednym z najskuteczniejszych mechanizmów zapobiegających problemom MTU w tunelach VPN. Działa on na zasadzie modyfikacji opcji MSS w nagłówku TCP podczas trójstronnego uzgadniania połączenia. Gdy klient wysyła pakiet SYN, deklaruje w nim maksymalny rozmiar segmentu TCP, jaki może odebrać. Router z włączonym MSS Clamping przechwytuje ten pakiet i, jeśli zadeklarowany MSS przekracza skonfigurowany próg, zmniejsza go do żądanej wartości.
Zmodyfikowana wartość MSS jest następnie przekazywana do serwera, który w odpowiedźi SYN-ACK używa tej samej (zmniejszonej) wartości. W rezultacie obie strony od samego początku używają mniejszych segmentów TCP, które po dodaniu nagłówków VPN mieszczą się w MTU fizycznego interfejsu. Dzięki temu eliminowana jest potrzeba fragmentacji oraz problemy z flagą DF i blokowaniem ICMP.
Należy podkreślić, że MSS Clamping działa wyłącznie dla ruchu TCP, ponieważ tylko TCP posiada opcję MSS w nagłówku. Dla protokołów UDP, takich jak DNS (z dużymi odpowiedźiami), DHCP, VoIP (RTP) czy strumieniowanie wideo, konieczne jest zastosowanie innych mechanizmów, takich jak ręczne ustawienie MTU na interfejsię tunelu lub zastosowanie aplikacji obsługujących wykrywanie MTU na poziomie warstwy aplikacji.
Prawidłowe wyliczenie wartości MSS dla tunelu VPN wymaga uwzględnienia wszystkich narzutów protokołowych na trasię pakietu. Podstawowy wzór to: MSS = MTU interfejsu fizycznego - nagłówek IP (20 B) - nagłówek TCP (20 B) - narzut protokołu VPN. Wartość tę należy zaokrąglić w dół do pełnych dziesiątek lub setek, aby mieć margines bezpieczeństwa na ewentualne dodatkowe nagłówki (VLAN, QoS, MPLS).
Dla IPSec w trybie tunelowym z NAT-T bezpieczna wartość MSS to 1360 bajtów. Przy MTU 1500 daje to 140 bajtów zapasu na nagłówki VPN, co powinno wystarczyć dla typowej konfiguracji AES-256 z SHA-256. W przypadku gdy tunel przechodzi przez PPPoE (MTU 1492), wartość tę należy zmniejszyć do 1340-1350 bajtów, aby uwzględnić dodatkowy narzut PPPoE.
Dla WireGuard zalecana wartość MSS zależy od ustawionego MTU interfejsu. Jeśli MTU WireGuard wynosi 1420 (domyślne w RouterOS), to MSS = 1420 - 40 = 1380. Jeśli MTU zostało zwiększone do 1500 (co jest możliwe, ale ryzykowne), MSS = 1500 - 40 - 32 (narzut WG) = 1428. W praktyce zaleca się pozostawienie domyślnego MTU 1420 dla WireGuard i ustawienie MSS Clamping na 1380.
# Podstawowy MSS Clamping dla calego ruchu TCP /ip firewall mangle add chain=forward \ protocol=tcp tcp-flags=syn \ action=change-mss \ new-mss=1360 # Sprawdzenie reguły: /ip firewall mangle print # Statystyki dopasowan: /ip firewall mangle stats
Podstawowa konfiguracja MSS Clamping w RouterOS jest niezwykle prosta i sprowadza się do dodania pojedynczej reguły w łańcuchu forward firewalla mangle. Reguła przechwytuje wszystkie pakiety TCP z ustawioną flagą SYN (pierwszy pakiet w trójstronnym uzgadnianiu) i modyfikuje pole MSS do wartości 1360 bajtów. Jest to wartość bezpieczna dla większości tuneli IPSec z NAT-T.
Reguła w łańcuchu forward dotyczy ruchu przechodzącego przez router, czyli pakietów, których źródło i cel znajdują się w różnych sieciach. Nie obejmuje ona ruchu generowanego przez samego routera (chain=input) ani ruchu kierowanego do routera (chain=output). Dla ruchu generowanego przez router (np. aktualizacje, backup, monitoring) MSS można ustawić globalnie w ustawieniach IP.
Po dodaniu reguły warto sprawdzić jej działanie za pomocą komendy /ip firewall mangle print, która wyświetli listę reguł z licznikami dopasowań. Jeśli liczniki rosną podczas generowania ruchu testowego, oznacza to, że reguła działa poprawnie. Komenda /ip firewall mangle stats pokazuje bardziej szczegółowe statystyki dla każdej reguły.
# MSS Clamping tylko dla ruchu do sieci 10.0.0.0/24 (zdalna przez tunel) /ip firewall mangle add chain=forward \ protocol=tcp tcp-flags=syn \ dst-address=10.0.0.0/24 \ action=change-mss \ new-mss=1360 # Albo: tylko dla ruchu z określonej podsieci lokalnej /ip firewall mangle add chain=forward \ protocol=tcp tcp-flags=syn \ src-address=192.168.1.0/24 \ action=change-mss \ new-mss=1360 # Można też łączyć: src-address + dst-address /ip firewall mangle add chain=forward \ src-address=192.168.1.0/24 \ dst-address=10.0.0.0/24 \ protocol=tcp tcp-flags=syn \ action=change-mss \ new-mss=1360
Selektywny MSS Clamping pozwala na modyfikację MSS tylko dla ruchu kierowanego do konkretnych sieci zdalnych dostępnych przez tunel VPN. Jest to szczególnie przydatne, gdy router ma jednocześnie dostęp do Internetu (gdzie MSS 1460 jest optymalne) i do sieci VPN (gdzie konieczne jest mniejsze MSS). Dzięki selektywnemu clampingowi ruch do Internetu korzysta z pełnego MSS, a ruch do sieci VPN z obniżonego.
W pierwszym przykładzie reguła modyfikuje MSS tylko dla pakietów kierowanych do sieci zdalnej 10.0.0.0/24. Ruch do innych sieci (np. do Internetu) nie jest modyfikowany, co zapewnia optymalną wydajność. W drugim przykładzie reguła dotyczy tylko pakietów pochodzących z konkretnej sieci lokalnej, co jest przydatne, gdy różne sieci lokalne mają dostęp do różnych tuneli VPN o różnych narzutach.
Najbardziej precyzyjna jest reguła łącząca src-address i dst-address, która modyfikuje MSS tylko dla ruchu między konkretną siecią lokalną a konkretną siecią zdalną. Jest to zalecane w topologiach hub-and-spoke, gdzie centrala łączy wiele oddziałów, każdy z własnym tunelem i potencjalnie innym narzutem. Należy jednak pamiętać, że zbyt wiele reguł mangle może obciążyć procesor routera.
# Sprawdzenie aktualnego MTU interfejsu WireGuard /interface wireguard print # Ustawienie MTU na interfejsię WireGuard /interface wireguard set numbers=wg0 mtu=1420 # MSS Clamping dla WireGuard (MSS = MTU 1420 - 40 = 1380) /ip firewall mangle add chain=forward \ protocol=tcp tcp-flags=syn \ out-interface=wg0 \ action=change-mss \ new-mss=1380 # LUB: globalny clamping dla calego forward /ip firewall mangle add chain=forward \ protocol=tcp tcp-flags=syn \ action=change-mss \ new-mss=1380
WireGuard w RouterOS v7 oferuje możliwość ustawienia MTU bezpośrednio na interfejsię tunelu, co jest najprostszym sposobem na kontrolę rozmiaru pakietów. Domyślna wartość MTU dla interfejsu WireGuard w RouterOS wynosi 1420 bajtów, co jest wartością bezpieczną uwzględniającą narzut protokołu (~52 bajty) oraz ewentualne dodatkowe nagłówki sieciowe.
W pierwszym przykładzie reguła MSS Clamping używa parametru out-interface=wg0, co oznacza, że MSS jest modyfikowany tylko dla pakietów wychodzących przez interfejs WireGuard. Jest to najbardziej precyzyjna metoda - reguła dotyczy wyłącznie ruchu kierowanego do sieci zdalnej przez tunel WireGuard, nie wpływając na ruch do Internetu.
Warto zauważyć, że dla WireGuard nie zawsze jest konieczne stosowanie MSS Clamping na routerze, jeśli MTU interfejsu jest ustawione prawidłowo. Systemy operacyjne hostów końcowych automatycznie dostosują MSS na podstawie MTU interfejsu tunelu (którym dla hosta jest interfejs WireGuard). MSS Clamping na routerze jest potrzebne głównie wtedy, gdy hosty nie używają bezpośrednio interfejsu WireGuard, ale łączą się przez router, który jest punktem końcowym tunelu.
# MTU dla interfejsu IPSec (VTI - Virtual Tunnel Interface) /interface ipsec set numbers=0 mtu=1430 # MTU dla interfejsu WireGuard /interface wireguard set numbers=wg0 mtu=1420 # MTU dla interfejsu L2TP (klient) /interface l2tp-client set numbers=0 mtu=1400 # MTU dla interfejsu EoIP (over IPSec) /interface eoip set numbers=0 mtu=1400 # MTU dla interfejsu GRE /interface gre set numbers=0 mtu=1476 # GRE 4 B = 1500 - 20 - 4 = 1476 # Sprawdzenie MTU interfejsów /interface print detail
Ręczne ustawienie MTU na interfejsię tunelu VPN jest metodą uzupełniającą wobec MSS Clamping, która działa dla wszystkich protokołów warstwy transportowej, w tym UDP. Podczas gdy MSS Clamping modyfikuje wyłącznie ruch TCP, ustawienie MTU na interfejsię tunelu wpływa na wszystkie pakiety IP przechodzące przez ten interfejs, niezależnie od protokołu warstwy transportowej.
W RouterOS MTU na interfejsię tunelu można ustawić za pomocą komendy /interface
Ustawienie MTU na interfejsię tunelu powoduje, że router będzie fragmentował wszystkie pakiety większe niż MTU tego interfejsu, ale robi to przed enkapsulacją. Dzięki temu pakiety po enkapsulacji mieszczą się w MTU interfejsu fizycznego. Należy jednak pamiętać, że fragmentacja zwiększa obciążenie procesora routera, dlatego w przypadku ruchu TCP zawsze lepszym rozwiązaniem jest MSS Clamping, które eliminuje potrzebę fragmentacji.
Lista kontrolna MTU dla RouterOS stanowi praktyczne narzędzie do weryfikacji poprawności konfiguracji pod kątem problemów z maksymalną jednostką transmisji. Proces rozpoczyna się od sprawdzenia MTU interfejsów fizycznych, które określa górny limit rozmiaru pakietów. W przypadku łączy PPPoE (częste w technologiach DSL) MTU wynosi 1492, a nie standardowe 1500, co wymaga uwzględnienia w obliczeniach.
Test ping z flagą dont-fragment jest najprostszym i najbardziej wiarygodnym sposobem weryfikacji, czy konfiguracja MTU jest poprawna. Ping z rozmiarem 1472 bajtów (MTU 1500 minus 28 bajtów na nagłówki ICMP i IP) powinien przechodzić przez tunel VPN bez problemu. Jeśli nie przechodzi, należy stopniowo zmniejszać rozmiar, aż do znalezienia maksymalnej wartości, która przechodzi. Ta wartość powiększona o 28 daje rzeczywiste MTU ścieżki przez tunel.
Monitorowanie statystyk reguł mangle za pomocą komendy /ip firewall mangle stats pozwala zweryfikować, czy reguła MSS Clamping faktycznie przetwarza pakiety. Jeśli liczniki nie rosną podczas ruchu testowego, oznacza to, że reguła jest nieprawidłowo skonfigurowana (np. zła kolejność w łańcuchu, błędne kryteria dopasowania). W takiej sytuacji należy sprawdzić logi systemowe i debugowanie firewalla.
! Topologia: R1(LAN 192.168.1.0/24) --- IPSec --- R2(LAN 10.0.0.0/24) ! R1 za NAT, R2 z publicznym IP ! ! MSS Clamping na interfejsię wewnętrznym R1 (LAN) Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip tcp adjust-mss 1360 ! ! Alternatywnie: na interfejsię tunelu Router(config)# interface Tunnel0 Router(config-if)# ip tcp adjust-mss 1360 ! ! Weryfikacja działania Router# show ip interface GigabitEthernet0/0 | include adjust Router# show tcp tcb
Komenda ip tcp adjust-mss w systemie Cisco IOS jest najprostszym sposobem na wdrożenie MSS Clamping. Działa ona na poziomie interfejsu i modyfikuje pole MSS we wszystkich pakietach TCP SYN przechodzących przez ten interfejs. Komendę można zastosować na interfejsię wewnętrznym (LAN), gdzie podłączone są hosty, lub na interfejsię tunelu VPN.
Zastosowanie komendy na interfejsię wewnętrznym (LAN) powoduje, że MSS jest modyfikowany dla wszystkich połączeń TCP wychodzących z sieci lokalnej, niezależnie od tego, czy trafiają one do tunelu VPN, czy do Internetu. Jest to rozwiązanie proste, ale nieoptymalne - ruch do Internetu również otrzymuje obniżony MSS, co zmniejsza wydajność. Z tego powodu zaleca się stosowanie komendy na interfejsię tunelu, jeśli to możliwe.
Weryfikacja działania MSS Clamping w Cisco IOS odbywa się za pomocą komendy show ip interface, która wyświetla skonfigurowane parametry interfejsu, w tym wartość adjust-mss. dodatkowo można użyć komendy show tcp tcb, która pokazuje szczegółowe informacje o aktywnych połączeniach TCP, w tym negocjowaną wartość MSS. W przypadku problemów warto sprawdzić logi systemowe i debugowanie.
! ACL definiujacy ruch do sieci zdalnej przez VPN Router(config)# access-list 110 permit tcp \ 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 ! ! Route-map wywolujaca adjust-mss dla dopasowanego ruchu Router(config)# route-map ADJUST-MSS permit 10 Router(config-route-map)# match ip address 110 Router(config-route-map)# set ip tcp adjust-mss 1360 ! ! Aplikacja route-map na interfejsię wewnętrznym (policy routing) Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip policy route-map ADJUST-MSS ! ! Weryfikacja Router# show route-map Router# show ip policy
Route-map w połączeniu z policy routing pozwala na selektywne stosowanie MSS Clamping tylko dla wybranego ruchu w Cisco IOS. Jest to szczególnie przydatne w topologiach, gdzie router obsługuje jednocześnie wiele tuneli VPN o różnych narzutach oraz zwykły ruch internetowy. Dzięki route-map można skonfigurować inną wartość MSS dla każdego tunelu, zapewniając optymalną wydajność dla każdego rodzaju ruchu.
W przykładzie ACL 110 definiuje ruch z sieci lokalnej 192.168.1.0/24 do sieci zdalnej 10.0.0.0/24 dostępnej przez tunel VPN. Route-map ADJUST-MSS dopasowuje ten ruch i ustawia dla niego MSS na 1360. Następnie route-map jest aplikowana na interfejsię wewnętrznym za pomocą komendy ip policy route-map, co wymusza na routerze przetwarzanie wszystkich pakietów wchodzących przez ten interfejs przez zdefiniowaną route-map.
Weryfikacja działania route-map odbywa się za pomocą komend show route-map i show ip policy. Pierwsza wyświetla zdefiniowane route-mapy wraz z licznikami dopasowań, druga pokazuje, na których interfejsach są one aplikowane. W przypadku problemów z wydajnością należy pamiętać, że policy routing zwiększa obciążenie procesora routera, ponieważ każdy pakiet jest dodatkowo analizowany pod kątem reguł route-map.
! Wlaczenie clear-df w crypto map dla danego peera Router(config)# crypto map CMAP 10 ipsec-isakmp Router(config-crypto-map)# set ip df 0 ! Alternatywnie: globalnie dla wszystkich tuneli Router(config)# crypto ipsec df-bit clear ! ! Debugowanie problemów MTU Router# debug ip icmp ! ICMP Fragmentation Needed Router# debug crypto ipsec ! IPSec SA Router# debug ip tcp adjust-mss ! MSS clamping (IOS 15+) ! ! Sprawdzenie MTU interfejsów Router# show interfaces GigabitEthernet0/0 | include MTU Router# show crypto ipsec sa | include mtu
Opcja clear-df w Cisco IOS pozwala na wyczyszczenie flagi Don't Fragment w zewnętrznym nagłówku IP pakietów IPSec. Dzięki temu router może fragmentować pakiety po enkapsulacji, nawet jeśli wewnętrzny pakiet miał DF=1. Jest to przydatne w sytuacjach, gdy nie można zastosować MSS Clamping, na przykład dla ruchu UDP, lub gdy chcemy mieć pewność, że pakiety nie będą odrzucane z powodu flagi DF.
W konfiguracji crypto map opcja set ip df 0 czyści flagę DF dla wszystkich pakietów wychodzących przez daną crypto map. Globalna komenda crypto ipsec df-bit clear działa na wszystkie tunele IPSec na routerze. Istnieje również opcja crypto ipsec df-bit copy (domyślna), która kopiuje stan DF z wewnętrznego pakietu, oraz crypto ipsec df-bit set, która zawsze ustawia DF=1.
Debugowanie problemów MTU w Cisco IOS wymaga użycia kilku komend debug. Komenda debug ip icmp pokazuje wszystkie pakiety ICMP, w tym Fragmentation Needed, co pozwala na śledzenie, czy router otrzymuje komunikaty o zbyt dużych pakietach. Komenda debug ip tcp adjust-mss (dostępna w IOS 15+) pokazuje informacje o modyfikacji MSS przez MSS Clamping. Należy pamiętać, że debugowanie w czasię rzeczywistym może obciążyć procesor routera.
! ===== R1 - za NAT (203.0.113.1) ===== crypto isakmp policy 10 encryption aes 256 hash sha256 authentication pre-share group 14 crypto isakmp key VPNHaslo address 1.2.3.4 crypto isakmp nat keepalive 20 crypto ipsec transform-set AES256 esp-aes 256 esp-sha256-hmac crypto map VPN 10 ipsec-isakmp set peer 1.2.3.4 set transform-set AES256 set pfs group14 match address 101 interface GigabitEthernet0/1 ip address 203.0.113.1 255.255.255.252 ip nat outside crypto map VPN interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 ip tcp adjust-mss 1360 ! MSS Clamping access-list 100 deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 access-list 100 permit ip 192.168.1.0 0.0.0.255 any access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 ip nat inside source list 100 interface G0/1 overload
Pełna konfiguracja site-to-site z IPSec, NAT-T i MSS Clamping pokazuje, jak wszystkie elementy współpracują ze sobą w praktycznym scenariuszu. Router R1 znajduje się za NAT (adres WAN 203.0.113.1) i łączy się z centralą R2 (adres publiczny 1.2.3.4). Konfiguracja obejmuje politykę ISAKMP z AES-256 i SHA-256, NAT keepalive co 20 sekund, transform-set dla fazy 2 oraz crypto map z PFS group14.
MSS Clamping jest skonfigurowany na interfejsię wewnętrznym GigabitEthernet0/0 za pomocą komendy ip tcp adjust-mss 1360. Wszystkie pakiety TCP SYN wychodzące z sieci lokalnej 192.168.1.0/24 będą miały zmodyfikowane pole MSS do 1360, co zapewni, że po dodaniu nagłówków IPSec z NAT-T pakiety nie przekroczą MTU łącza.
Router R2 (centrala) ma znacznie prostszą konfigurację - nie wymaga NAT keepalive ani reguł NAT bypass. W jego konfiguracji również zaleca się dodanie MSS Clamping na interfejsię wewnętrznym (po stronie sieci 10.0.0.0/24) z tą samą wartością 1360. Dzięki temu ruch w obu kierunkach będzie miał jednakowy MSS, co zapewni symetryczną wydajność tunelu.
Ruch UDP w tunelach VPN stanowi szczególne wyzwanie, ponieważ protokół UDP nie posiada mechanizmu MSS, który pozwalałby na negocjację rozmiaru segmentów. Oznacza to, że aplikacje UDP mogą wysyłać datagramy o dowolnym rozmiarze (mieszczącym się w MTU interfejsu), a jedynym mechanizmem zapobiegającym przekroczeniu MTU jest fragmentacja IP lub ręczne ustawienie MTU na interfejsię tunelu.
Najczęstszym źródłem dużych pakietów UDP w sieciach korporacyjnych są odpowiedźi DNS. Standardowy limit dla DNS over UDP wynosi 512 bajtów, ale mechanizm EDNS0 (RFC 6891) pozwala na negocjację większych rozmiarów pakietów, nawet do 4096 bajtów. Gdy serwer DNS wysyła odpowiedź większą niż MTU tunelu, a pakiet ma DF=1, zostanie odrzucony, co objawia się błędami rozwiązywania nazw.
Protokół QUIC (używany przez HTTP/3) implementuje własny mechanizm PMTUD dla UDP, wysyłając pakiety probingowe z różnymi rozmiarami. Jednak w środowisku VPN mechanizm ten może zawodzić z tych samych powodów co tradycyjny PMTUD - komunikaty ICMP są blokowane lub przechwytywane przez router VPN. Z tego powodu w sieciach z VPN zaleca się jawne ustawienie MTU na interfejsię tunelu na wartość uwzględniającą narzut protokołu VPN.
Najczęstszym błędem konfiguracji MTU w sieciach VPN jest całkowity brak MSS Clamping. Administratorzy często konfigurują tunel VPN, sprawdzają, że "działa" za pomocą pingu, i uznają zadanie za zakończone. Problem pojawia się dopiero przy próbie przesyłania większych plików lub ładowania stron WWW z dużą liczbą zasobów. Objawy są niespecyficzne i często mylnie przypisywane innym przyczynom, co prowadzi do długotrwałej i frustrującej diagnostyki.
Drugim najczęstszym błędem jest ustawienie zbyt wysokiej wartości MSS. Administratorzy często obliczają narzut teoretyczny, ale nie uwzględniają dodatkowych nagłówków, które mogą pojawić się na trasie: VLAN (4 B), QoS (różne), MPLS (4+ B), PPPoE (8 B). Z tego powodu zaleca się stosowanie wartości bezpiecznych, które mają kilkadziesiąt bajtów zapasu: 1360 dla IPSec, 1380 dla WireGuard, 1350 dla OpenVPN.
Błędem jest również ignorowanie faktu, że MSS Clamping działa tylko dla nowych połączeń TCP. Istniejące połączenia, które zostały nawiązane przed włączeniem clamping, nadal używają starego (większego) MSS. Dlatego po zmianie konfiguracji MSS należy odczekać, aż stare połączenia wygasną, lub zrestartować usługi. W przypadku krytycznych aplikacji zaleca się zaplanowanie okna serwisowego na wprowadzenie zmian konfiguracji MSS.
Podsumowując, problem MTU w sieciach VPN jest zjawiskiem powszechnym, ale stosunkowo łatwym do rozwiązania przy użyciu odpowiednich narzędzi. Kluczem do zrozumienia problemu jest świadomość, że każdy protokół VPN dodaje własne nagłówki, które zmniejszają przestrzeń dostępną dla danych użytkownika. Ignorowanie tego faktu prowadzi do fragmentacji pakietów, odrzucania połączeń przez flagę DF oraz niewyjaśnionych problemów z wydajnością aplikacji sieciowych.
MSS Clamping pozostaje najskuteczniejszym i najprostszym w konfiguracji rozwiązaniem problemów MTU dla ruchu TCP. Zarówno RouterOS (firewall mangle z action=change-mss), jak i Cisco IOS (ip tcp adjust-mss) oferują wbudowane mechanizmy do modyfikacji MSS, które działają transparentnie dla użytkowników końcowych. Dla ruchu UDP konieczne jest ręczne ustawienie MTU na interfejsię tunelu.
Diagnostyka problemów MTU powinna zaczynać się od prostego testu ping z flagą DF i stopniowym zwiększaniem rozmiaru pakietu. Narzędzia takie jak Wireshark pozwalają na zaawansowaną analizę komunikatów ICMP i identyfikację dokładnego miejsca, gdzie MTU ulega zmniejszeniu. Zachęcam do samodzielnych eksperymentów w laboratorium z wykorzystaniem Cisco Packet Tracer oraz RouterOS. Znajomość mechanizmów MTU jest niezbędna dla każdego inżyniera sieciowego projektującego i utrzymującego tunele VPN.