Internet działa, strony otwierają się normalnie, a test prędkości pokazuje kilkaset megabitów na sekundę. Mimo to firmowy VPN przestaje przesyłać dane, panel logowania zawiesza się po wpisaniu hasła, a niektóre witryny ładują się tylko częściowo. Ponowne uruchomienie routera zwykle niczego nie zmienia. Przyczyną może być nieprawidłowy rozmiar pakietów IP, a dokładniej problem z parametrami MTU i MSS.
Charakterystyczne jest to, że niewielkie porcje danych docierają do celu, natomiast większe pakiety są odrzucane po drodze. Jeśli urządzenie wysyłające nie otrzymuje informacji o ograniczeniu rozmiaru, ponawia transmisję i połączenie pozornie zastyga. Taki problem występuje między innymi przy PPPoE, tunelach VPN i błędnej obsłudze komunikatów ICMP. Można go zdiagnozować bez wymieniania routera czy reinstalowania systemu, ale samo zmniejszenie MTU nie zawsze oznacza usunięcie rzeczywistej awarii.
Czym są MTU, MSS i fragmentacja pakietów
MTU (Maximum Transmission Unit) określa maksymalny rozmiar pakietu warstwy sieciowej, jaki dany interfejs może przesłać bez fragmentacji. W typowej sieci Ethernet wynosi 1500 bajtów. Limit dotyczy całego pakietu IP, czyli nagłówka IP i jego zawartości, lecz nie obejmuje nagłówka ramki Ethernet.
MSS (Maximum Segment Size) to maksymalna ilość danych aplikacji przesyłanych w pojedynczym segmencie TCP, bez nagłówków TCP i IP. Wartość MSS jest ogłaszana podczas ustanawiania połączenia TCP za pomocą opcji w segmencie SYN. Poszczególne strony połączenia mogą deklarować różne wartości.
Przy standardowych nagłówkach zależność jest prosta: IPv4 wymaga 20 bajtów nagłówka, IPv6 standardowo 40 bajtów, natomiast podstawowy nagłówek TCP zajmuje 20 bajtów. Dlatego przy MTU 1500 maksymalny MSS wynosi zwykle 1460 bajtów dla TCP/IPv4 i 1440 bajtów dla TCP/IPv6. Przy MTU 1492 wartości spadają odpowiednio do 1452 i 1432 bajtów, a przy MTU 1400 do 1360 i 1340 bajtów. Dodatkowe opcje TCP oraz rozszerzenia nagłówków IP mogą zmniejszać ilość danych mieszczących się w konkretnym pakiecie.
Problem pojawia się, gdy urządzenie wysyła pakiet o rozmiarze 1500 bajtów, ale jeden z odcinków trasy obsługuje maksymalnie 1492 bajty. Taka sytuacja jest typowa dla połączeń PPPoE, spotykanych również u polskich operatorów internetowych. Standardowy narzut PPPoE i PPP zajmuje łącznie 8 bajtów, co przy tradycyjnym limicie Ethernet ogranicza MTU pakietu IP do 1492. Istnieją rozszerzenia pozwalające na większe pakiety, ale muszą je obsługiwać urządzenia oraz infrastruktura operatora.
W IPv4 router może podzielić zbyt duży pakiet na mniejsze fragmenty, o ile nie zabrania tego flaga DF (Don’t Fragment). Fragmentacja ma jednak swoją cenę: zwiększa narzut przetwarzania, a utrata jednego fragmentu może uniemożliwić odtworzenie całego pakietu. Przy ustawionej fladze DF router powinien odrzucić zbyt duży pakiet i odesłać komunikat ICMP Fragmentation Needed.
Ten komunikat umożliwia działanie mechanizmu Path MTU Discovery (PMTUD), dzięki któremu nadawca ustala ograniczenie rozmiaru pakietów na trasie do odbiorcy.
W IPv6 zasady są inne. Routery pośredniczące nie fragmentują pakietów. Jeśli pakiet nie mieści się na kolejnym łączu, router odrzuca go i wysyła komunikat ICMPv6 Packet Too Big. Ewentualną fragmentację wykonuje urządzenie źródłowe. Blokowanie tych komunikatów przez zaporę może więc skutecznie uniemożliwić prawidłową transmisję.
Praktyczny przykład? Pracownik łączy się z firmową siecią przez VPN. Uwierzytelnienie przechodzi poprawnie, ponieważ początkowa wymiana wykorzystuje niewielkie pakiety. Problemy zaczynają się dopiero przy pobieraniu dokumentu z serwera lub otwieraniu rozbudowanego panelu administracyjnego. Duże pakiety przekraczają rzeczywiste MTU tunelu, a informacja o ich odrzuceniu nie wraca do nadawcy. Powstaje PMTU black hole — połączenie istnieje, lecz część transmisji nie dociera do celu.
Nie oznacza to, że każdy niedziałający VPN cierpi na problem z MTU. Jeśli klient nie rozpoznaje nazwy serwera, należy najpierw sprawdzić DNS. Jeżeli brakuje trasy do sieci firmowej, właściwym obszarem diagnostyki jest routing. Dopiero sytuacja, w której małe porcje danych przechodzą, a większe regularnie zawodzą, uzasadnia testowanie ograniczeń rozmiaru pakietów.
Jak wykryć nieprawidłowy rozmiar pakietu
Pierwszy krok to ustalenie, czy problem dotyczy konkretnej trasy. Warto porównać działanie tej samej usługi po wyłączeniu VPN, przy połączeniu przez router domowy oraz przez hotspot LTE/5G. Jeśli firmowy system działa przez hotspot, a zawiesza się na łączu stacjonarnym, podejrzenie pada na konfigurację routera, tunelu albo sieci operatora. Nie jest to jeszcze dowód, ale pozwala ograniczyć liczbę możliwych przyczyn.
Najbardziej użytecznym prostym testem jest wysłanie pakietów IPv4 z ustawioną flagą DF, która uniemożliwia ich fragmentację na trasie.
W systemie Windows należy uruchomić Wiersz polecenia i wpisać:
ping -4 -f -l 1472 CEL
W Linuksie, przy użyciu narzędzia ping z pakietu iputils, odpowiednikiem jest:
ping -4 -M do -s 1472 CEL
Zamiast CEL należy podać adres IPv4 hosta odpowiadającego na ICMP. Najlepiej wykorzystać kontrolowany serwer znajdujący się na badanej trasie, np. po drugiej stronie firmowego VPN. Wyniki testowania przypadkowego publicznego hosta nie muszą odpowiadać warunkom występującym podczas korzystania z problematycznej usługi.
Skąd wartość 1472? Polecenie określa wielkość danych ICMP. Po dodaniu 20 bajtów standardowego nagłówka IPv4 oraz 8 bajtów nagłówka ICMP powstaje pakiet o rozmiarze 1500 bajtów. Zakładamy przy tym brak dodatkowych opcji IPv4.
Do diagnostyki przydają się trzy rozmiary:
- 1472 bajty danych ICMP + 28 bajtów nagłówków = 1500 bajtów MTU.
- 1464 bajty danych ICMP + 28 bajtów nagłówków = 1492 bajty MTU.
- 1372 bajty danych ICMP + 28 bajtów nagłówków = 1400 bajtów MTU.
Jeśli pakiet 1500-bajtowy powoduje komunikat o konieczności fragmentacji, należy sprawdzić 1492 bajty. W Windows służy do tego polecenie ping -4 -f -l 1464 CEL, a w Linuksie ping -4 -M do -s 1464 CEL.
Gdy pakiet 1492-bajtowy przechodzi, można zwiększać rozmiar danych małymi krokami, aby ustalić najwyższą wartość obsługiwaną przez trasę. Jeśli natomiast nie przechodzi, należy sprawdzić niższe rozmiary, np. 1400 bajtów całego pakietu.
Interpretacja wyniku jest ważniejsza niż samo wykonanie polecenia. Komunikat Fragmentation needed albo jego lokalny odpowiednik stanowi konkretną wskazówkę dotyczącą ograniczenia rozmiaru. Natomiast zwykły timeout nie dowodzi problemu z MTU. Host docelowy może blokować ping, urządzenia pośrednie mogą ograniczać ICMP, a pakiety mogą ginąć z innych przyczyn.
Trzeba także rozróżnić MTU lokalnego interfejsu od Path MTU, czyli faktycznego ograniczenia na całej trasie do wskazanego celu. Komputer może mieć ustawione 1500 bajtów, choć połączenie przez VPN umożliwia przesyłanie mniejszych pakietów.
W Windows lokalne parametry interfejsów IPv4 można sprawdzić poleceniem:
netsh interface ipv4 show subinterfaces
W Linuksie:
ip link show
Oba polecenia pokazują konfigurację interfejsów, ale nie wyznaczają automatycznie MTU do konkretnego serwera.
Przy bardziej skomplikowanej awarii pomocny będzie Wireshark. Dla IPv4 należy szukać komunikatów ICMP typu 3, kodu 4, oznaczających konieczność fragmentacji. W IPv6 odpowiednikiem jest ICMPv6 typu 2, czyli Packet Too Big. Brak tych komunikatów w przechwyconym ruchu nie wyklucza problemu — mogą zostać odrzucone wcześniej, zanim dotrą do urządzenia.
W praktyce rozsądna kolejność wygląda tak: najpierw porównanie połączenia na dwóch trasach, następnie testy pakietów różnej wielkości, a dopiero potem analiza pakietów w Wiresharku. Nie ma sensu zaczynać od rozbudowanego przechwytywania ruchu, jeśli już prosty test pokazuje, że połączenie PPPoE ogranicza MTU do 1492 bajtów.
Trzeba również uwzględnić protokół. Test DF opisany powyżej dotyczy IPv4. Jeśli problem występuje wyłącznie w IPv6, należy oddzielnie sprawdzić ścieżkę IPv6 oraz poprawność obsługi ICMPv6 Packet Too Big. Pozytywny wynik testu IPv4 nie potwierdza prawidłowego działania IPv6.
Kiedy zmiana MTU ma sens, a kiedy jedynie maskuje awarię
Zmniejszenie MTU ma sens, gdy rzeczywista trasa wymaga mniejszych pakietów niż te wysyłane przez urządzenie. Dotyczy to przede wszystkim PPPoE, połączeń VPN, tuneli między oddziałami i sieci z dodatkowymi warstwami enkapsulacji. Zmiana powinna jednak wynikać z rozpoznanego ograniczenia, a nie z przypadkowego poradnika zalecającego wszystkim ustawienie 1400 bajtów.
Dobrym przykładem jest WireGuard pracujący przez PPPoE. Sam WireGuard przesyła zaszyfrowane dane w UDP, co generuje dodatkowy narzut. W przypadku zewnętrznego IPv4 podstawowy narzut pakietu danych WireGuard wynosi 60 bajtów: 20 bajtów nagłówka IPv4, 8 bajtów UDP oraz 32 bajty nagłówka i znacznika uwierzytelniającego WireGuard. Przy zewnętrznym IPv6 narzut rośnie do 80 bajtów. Dochodzi jeszcze dopełnienie szyfrowanych danych do wielokrotności 16 bajtów.
Jeśli łącze PPPoE obsługuje MTU 1492, testowe ustawienie MTU 1400 na interfejsie WireGuard jest uzasadnionym punktem wyjścia. Przy takim rozmiarze pozostaje miejsce na wskazany narzut i dopełnienie. Nie jest to jednak wartość uniwersalna. Trzeba uwzględnić inne warstwy tunelowania, zewnętrzny protokół IP oraz ograniczenia na dalszych odcinkach trasy.
W Linuksie najpierw można sprawdzić MTU interfejsu:
ip link show dev wg0
Następnie, jeśli badany tunel rzeczywiście używa nazwy wg0, przeprowadzić tymczasową próbę:
sudo ip link set dev wg0 mtu 1400
W Windows przykładowa tymczasowa zmiana MTU interfejsu IPv4 może wyglądać tak:
netsh interface ipv4 set subinterface "NAZWA" mtu=1400 store=active
Zamiast NAZWA trzeba podać dokładną nazwę właściwego interfejsu sieciowego, a terminal uruchomić z uprawnieniami administratora. To polecenie dotyczy IPv4. Parametr store=active nie zapisuje zmiany na stałe. W Linuksie ustawienie wprowadzone przez ip link również jest nietrwałe i może zostać nadpisane przez usługę zarządzającą siecią.
Przed testem należy zapisać poprzednie MTU i zapewnić możliwość przywrócenia konfiguracji. Zmiana parametrów aktywnego tunelu na serwerze, którym administrator zarządza wyłącznie zdalnie, może spowodować utratę sesji. Bez dostępu awaryjnego taki eksperyment jest niepotrzebnym ryzykiem.
Po zmianie nie wystarczy sprawdzić, czy otwiera się strona główna. Należy ponowić operację, która wcześniej zawodziła: pobrać większy plik, otworzyć problematyczny panel, sprawdzić transmisję przez VPN i obserwować połączenie po ponownym zestawieniu tunelu. Jeśli wszystko działa, można stopniowo zwiększać MTU, aby ustalić najwyższą stabilną wartość.
Zbyt niskie MTU ma swoje konsekwencje. Więcej pakietów jest potrzebnych do przesłania tej samej ilości danych, rośnie udział nagłówków w transmisji oraz obciążenie związane z ich przetwarzaniem. W niektórych sieciach spadek wydajności będzie niewielki, w innych stanie się zauważalny. Dlatego ustawienie 1280 bajtów na wszystkich urządzeniach „dla bezpieczeństwa” jest złym pomysłem. W IPv6 1280 bajtów stanowi minimalne MTU wymagane od łącza na poziomie protokołu; nie jest to zalecana wartość dla każdej sieci.
Inaczej należy postępować, gdy nieprawidłowy rozmiar pakietów jest tylko objawem większej awarii. Jeśli wszystkie komputery za jednym routerem mają podobny problem, obniżanie MTU na każdym laptopie maskuje źródło usterki. Należy sprawdzić MTU na interfejsie WAN, prawidłowość konfiguracji PPPoE, zasady tunelowania i działanie Path MTU Discovery.
Jedną z częstszych przyczyn jest nieprawidłowe filtrowanie ICMP. Blokowanie komunikatów Fragmentation Needed w IPv4 albo Packet Too Big w IPv6 uniemożliwia nadawcom prawidłowe dostosowanie rozmiaru pakietów. W takiej sytuacji lepiej naprawić reguły zapory, dopuszczając wymagane komunikaty błędów, niż stale zmniejszać MTU. Nie oznacza to wyłączania całej zapory ani zezwalania na dowolny ruch ICMP bez kontroli.
Innym rozwiązaniem jest MSS clamping, stosowany między innymi na routerach MikroTik i urządzeniach z Linuksem. Mechanizm modyfikuje wartość MSS w pakietach TCP SYN przechodzących przez router, dzięki czemu urządzenia końcowe uzgadniają mniejsze segmenty danych TCP.
Przy łączu PPPoE z MTU 1492 typową maksymalną wartością MSS dla TCP/IPv4 jest 1452 bajty, jeśli nie występuje dodatkowe ograniczenie trasy. Gdy transmisja przechodzi jeszcze przez VPN, wartość może wymagać dalszego obniżenia. Nie wolno jednak mechanicznie przypisywać MSS 1452 do każdego tunelu — należy uwzględnić rzeczywistą ścieżkę i dodatkowe nagłówki.
MSS clamping sprawdza się wtedy, gdy problem rzeczywiście dotyczy segmentów TCP, a router zna odpowiednie ograniczenie. Ma jednak ważne słabości. Nie naprawia transmisji UDP, a więc nie rozwiązuje bezpośrednio problemów z datagramami WireGuard czy ruchem QUIC wykorzystywanym przez HTTP/3. Ponadto przy trasach asymetrycznych automatyczne ograniczanie MSS na podstawie PMTU może dawać nieodpowiedni wynik. Zbyt agresywne ograniczenie zwiększy liczbę segmentów i może pogorszyć wydajność.
Jeśli po zmianie MSS działa pobieranie plików przez TCP, ale aplikacje korzystające z UDP nadal się zawieszają, dalsze obniżanie MSS nie ma sensu. Trzeba sprawdzić MTU tunelu, narzut enkapsulacji, trasy pakietów i komunikaty ICMP. Podobnie, gdy zmiana MTU nie daje żadnej poprawy, należy przywrócić poprzednie ustawienie i wrócić do diagnostyki DNS, routingu, zapory lub samej usługi.
FAQ – najczęstsze pytania o MTU i MSS
Czy MTU 1500 oznacza MSS 1500?
Nie. Przy standardowych nagłówkach MSS wynosi zwykle 1460 bajtów w TCP/IPv4 lub 1440 bajtów w TCP/IPv6. Resztę miejsca zajmują nagłówki protokołów.
Czy przy światłowodzie należy ustawić MTU 1492?
Nie zawsze. MTU 1492 jest typowe dla standardowego PPPoE, niezależnie od tego, czy operator korzysta ze światłowodu. Połączenia IPoE często obsługują MTU 1500. Niektóre sieci PPPoE także mogą obsługiwać większe pakiety dzięki odpowiednim rozszerzeniom.
Czy brak odpowiedzi na ping oznacza błędne MTU?
Nie. Timeout może oznaczać filtrowanie ICMP, stratę pakietów albo niedostępność urządzenia. Bardziej miarodajny jest komunikat o koniecznej fragmentacji i powtarzalna różnica w zachowaniu pakietów o konkretnych rozmiarach.
Czy MTU 1400 jest najlepsze dla każdego VPN?
Nie. Jest użyteczną wartością testową dla części konfiguracji tunelowych, ale docelowe MTU zależy od protokołu VPN, zewnętrznego IPv4 lub IPv6, narzutu enkapsulacji i rzeczywistych ograniczeń trasy.
Czy MSS clamping rozwiąże problemy z HTTP/3?
Nie bezpośrednio. HTTP/3 wykorzystuje QUIC działający na UDP, natomiast MSS jest parametrem TCP. Trzeba sprawdzić rzeczywiste MTU ścieżki i działanie mechanizmów dostosowania rozmiaru datagramów.
Czy niższe MTU poprawia stabilność internetu?
Tylko wtedy, gdy wcześniej pakiety przekraczały możliwości trasy. Bez takiego ograniczenia zmniejszenie MTU przeważnie zwiększa narzut transmisji i nie rozwiązuje przyczyny problemu.
Co sprawdzić jako pierwsze, gdy internet działa tylko częściowo?
Najpierw porównaj działanie usługi na dwóch trasach, a następnie wykonaj testy IPv4 z flagą DF dla pakietów 1500 i 1492 bajtów, wykorzystując odpowiednio 1472 i 1464 bajty danych ICMP. Jeśli większy pakiet wymaga fragmentacji, a mniejszy przechodzi, sprawdź MTU interfejsu WAN lub VPN oraz komunikaty potrzebne do PMTUD. Pierwszą zmianę wykonaj tylko na interfejsie, którego ograniczenie potwierdzono. Jeśli test nie przyniesie poprawy, przywróć wcześniejszą wartość zamiast obniżać MTU na ślepo.
