Małe pakiety mogą działać, a duże znikać: „czarna dziura” MTU
Jedna z najbardziej mylących awarii sieci wygląda tak: ping działa, połączenie TCP się zestawia, małe porcje danych przechodzą, ale próba przesłania większej odpowiedzi zawiesza się. Przyczyną może być PMTUD black hole. Jeśli na trasie znajduje się łącze o mniejszym MTU, zbyt duży pakiet musi zostać zmniejszony lub odrzucony z informacją dla nadawcy. Gdy potrzebny komunikat ICMP zostanie zablokowany, nadawca nie dowiaduje się, że powinien wysyłać mniejsze pakiety. RFC 2923 opisuje właśnie przypadek, w którym małe pakiety przechodzą, a duże znikają bez użytecznej informacji zwrotnej.
Nie każdy odcinek przyjmie ten sam rozmiar
MTU, Maximum Transmission Unit, określa największy pakiet lub ramkę, jaką dany fragment sieci może przenieść bez dodatkowego podziału. Typowa lokalna sieć Ethernet może pozwalać na inny rozmiar niż tunel VPN, połączenie operatorskie czy inna technologia na dalszej trasie. Nadawca nie musi znać wszystkich tych wartości z góry.
Path MTU Discovery szuka najmniejszego ograniczenia
Mechanizm PMTUD próbuje ustalić największy rozmiar pakietu działający na całej ścieżce. W IPv4 router, który nie może przekazać odpowiednio oznaczonego zbyt dużego pakietu, może wysłać ICMP Destination Unreachable z informacją o potrzebie fragmentacji. Host zmniejsza wtedy rozmiar kolejnych pakietów. W IPv6 routery pośrednie w ogóle nie fragmentują pakietów; komunikaty ICMPv6 Packet Too Big są kluczową częścią działania.
Black hole powstaje, gdy znika informacja zwrotna
RFC 2923 opisuje awarie, w których firewall lub inny element filtruje komunikaty ICMP potrzebne PMTUD. Duży pakiet zostaje odrzucony, ale nadawca nie wie dlaczego. Może więc ponawiać transmisję w tym samym zbyt dużym rozmiarze. Z jego punktu widzenia sieć wygląda jak czarna dziura: dane wychodzą, ale ani cel, ani komunikat o błędzie nie wracają.
Dlaczego ping może kłamać w dobrej wierze
Standardowe echo ICMP jest często małe, więc mieści się w ograniczeniu problematycznej trasy. Również handshake TCP składa się z małych segmentów bez dużego payloadu. Połączenie zostaje więc nawiązane poprawnie, a awaria pojawia się dopiero wtedy, gdy aplikacja zaczyna przesyłać większe porcje danych. To prowadzi do symptomów typu „strona zaczyna się otwierać i staje” albo „SSH działa, ale transfer nie”.
To nie musi być strata losowa
Przy zwykłym przeciążeniu część pakietów może ginąć statystycznie. PMTU black hole jest bardziej deterministyczny: pakiety poniżej pewnego rozmiaru przechodzą, a większe konsekwentnie wpadają w problem. Ta zależność od długości danych jest ważną wskazówką diagnostyczną i pokazuje, że pytanie „czy host odpowiada?” jest znacznie prostsze niż „czy cała aplikacja może poprawnie wymieniać dane?”.
Blokowanie całego ICMP bywa błędem
ICMP kojarzy się z pingiem i bywa bezrefleksyjnie blokowany jako „niepotrzebny”. Tymczasem część jego komunikatów pełni funkcję sterującą niezbędną dla poprawnej współpracy warstw sieciowych. RFC 8504 ostrzega przy IPv6, że filtrowanie Packet Too Big może pozwolić zestawić TCP, a następnie doprowadzić do zawieszenia po rozpoczęciu przesyłania danych. Zabezpieczenie sieci musi rozróżniać typy komunikatów zamiast traktować cały ICMP jako zbędny ruch.
Tunel może stworzyć mniejsze MTU pośrodku pozornie zwykłej trasy
Problem z MTU często pojawia się wtedy, gdy pakiet zostaje dodatkowo opakowany, np. przez VPN lub inny tunel. Nowy nagłówek zajmuje część dostępnego rozmiaru, więc użyteczny payload musi być mniejszy niż na zwykłym Ethernetowym odcinku. Komputer na początku ścieżki może o tym nie wiedzieć. Właśnie dlatego poprawne działanie komunikatów o zbyt dużym pakiecie jest tak istotne: pozwala końcówkom dostosować się do ograniczenia, którego nie widać lokalnie. Jeśli firewall blokuje informację zwrotną, awaria zależy od rozmiaru danych, a nie od nazwy domeny czy poprawności połączenia TCP. To jeden z powodów, dla których administrator może godzinami szukać problemu w aplikacji, choć prawdziwa przyczyna leży w kilku dodatkowych bajtach nagłówka na odległym odcinku trasy.