Wykrywanie MTU ścieżki przez VPN: rozmiar i luka ICMP

Tunel kończy uzgadnianie, małe żądania wracają, a pierwszy duży transfer się zatrzymuje. Ten wzorzec wskazuje na MTU ścieżki znacznie wcześniej niż na przepustowość. Każde łącze na trasie ogranicza rozmiar pakietu, a enkapsulacja zużywa część tego limitu na zewnętrzne nagłówki, więc pakiet wewnętrzny musi być mniejszy, niż sugerowałaby surowa ścieżka. Awaria jest cicha, i właśnie dlatego jest kosztowna w diagnozie.

Co naprawdę mierzy MTU ścieżki

MTU ścieżki to najmniejsze MTU łącza na trasie między dwoma hostami, a nie MTU wydrukowane na lokalnym interfejsie. Wartość lokalna jest punktem wyjścia szacunku, a ścieżka decyduje, gdzie musi się on skończyć. Dlatego identyczny tunel może działać w jednej sieci dostępowej, a zatrzymywać się w innej: zmieniła się trasa, a nie konfiguracja. Zmierzyć raz i zakładać wszędzie to błąd, który utrzymuje ten problem przy życiu.

Dla tunelu liczbą, która ma znaczenie, jest wewnętrzne MTU, czyli limit zewnętrznej ścieżki minus to, co zużywa enkapsulacja. WireGuard dodaje zewnętrzny nagłówek IP i nagłówek UDP; inne transporty dodają własne. Ustaw wewnętrzny rozmiar zbyt wysoko, a każdy pakiet pełnego rozmiaru będzie wymagał fragmentacji, która może nigdy nie nastąpić.

Dlaczego tunel zmniejsza użyteczny pakiet

Jeśli interfejs tunelu zachowuje MTU łącza fizycznego, każdy duży pakiet zależy od tego, czy ktoś dalej na trasie zechce go fragmentować. IPv4 zasadniczo na to pozwala, ale router, któremu kazano nie fragmentować, zwraca zamiast tego błąd. Routery IPv6 nigdy nie fragmentują w tranzycie, więc to samo ustawienie zachowuje się inaczej w zależności od rodziny adresów. Tak czy inaczej nadawca nie dowiaduje się niczego, dopóki coś nie zgłosi tego z powrotem.

Praktyczną konsekwencją jest rozmiar, który mieści się w uzgadnianiu, a nie w ładunku. TLS ClientHello albo zapytanie DNS są dość małe, by nietknięte przejść przez zmniejszoną ścieżkę, podczas gdy masowy transfer nie. Dlatego objawy skupiają się wokół konkretnych operacji, a nie konkretnych hostów.

Wykrywanie działa tylko wtedy, gdy dotrze informacja zwrotna

Wykrywanie IPv4 opiera się na bicie don't-fragment: router, który nie może przekazać pakietu, zwraca ICMP fragmentation-needed z MTU następnego przeskoku, a nadawca obniża swój szacunek. IPv6 używa zamiast tego komunikatów Packet Too Big, ponieważ routery nie fragmentują w tranzycie. Oba mechanizmy zakładają, że komunikat znajdzie drogę z powrotem do nadawcy, przez tunel i obok każdej zapory na ścieżce powrotnej. Gdy to założenie zawodzi, nadawca wciąż ponawia rozmiar, którego ścieżka nie może unieść.

Zapora, która zezwala na echo request i echo reply, niekoniecznie zezwoliła na te typy błędów. ICMP to rodzina, a członkami, które tu mają znaczenie, są błędy, a nie para echa. Sprawdź politykę ruchu sterującego na obu końcach tunelu i na ścieżce między nimi, i stosuj się do wspieranego przez platformę przewodnika, zamiast zezwalać wszędzie na każdy typ ICMP.

To samo filtrowanie może siedzieć wewnątrz tunelu. Jeśli wewnętrzna ścieżka odrzuca błąd, ale zewnętrzna go przenosi, nadawca może dostosować się do limitu, którego enkapsulowany ruch nigdy naprawdę nie widzi.

Testuj ścieżkę zamiast zgadywać liczbę

Utrzymuj cel, sieć dostępową i tunel na stałe, a zmieniaj tylko rozmiar pakietu. Test don't-fragment, który zawodzi ze wskazówką MTU, daje limit następnego przeskoku; powtarzaj, aż jakiś rozmiar przejdzie, i zapisz zarówno rozmiar, jak i rodzinę adresów.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Mieszczący się ping nie dowodzi, że mieszczą się segmenty pełnego rozmiaru prawdziwej aplikacji, więc powtórz test z transferem, który faktycznie zawiódł. Porównaj największy działający test ze skonfigurowanym MTU tunelu i trzymaj te dwie liczby osobno w notatkach. Jeśli różnią się mniej więcej o jeden nagłówek, znalazłeś narzut enkapsulacji, a nie usterkę.

PLPMTUD, opisany w RFC 4821, sonduje w górę i używa potwierdzeń transportu zamiast ufać dostarczonym błędom. Pomaga na ścieżkach filtrujących ICMP, ale wsparcie różni się zależnie od stosu i aplikacji. Strumień TCP może sam się odzyskać, podczas gdy aplikacja UDP o stałym rozmiarze datagramu nadal zawodzi.

Wybierz wartość i zapisz uzasadnienie

Obniżenie MTU tunelu jest zarówno diagnostyką, jak i uzasadnioną naprawą, gdy już znasz ścieżkę. Nie zastępuje wiedzy, która ścieżka i który mechanizm sprzężenia zwrotnego były zaangażowane, ponieważ wartość dostrojona do łącza mobilnego będzie niepotrzebnie mała na łączu światłowodowym. Zapisz wybrany rozmiar, test, który go uzasadnił, i krok wycofania.

Mechanizm IPv4 opisano w RFC 1191, a wskazówki dotyczące pakietowania IPv6 w RFC 8201; wymienienie obu powstrzymuje następnego inżyniera przed ponownym wyprowadzaniem założenia. Jeśli transfer nadal zatrzymuje się przy wybranym rozmiarze, przestań obniżać liczbę i spójrz na następną warstwę. Ścieżka, która zawodzi przy każdym rozmiarze, nie jest problemem MTU.