Zbyt duży pakiet IPv6: dlaczego duże transfery VPN się zatrzymują

Ping działa, przeglądarka wczytuje małą stronę, a transfer pliku się zatrzymuje — wszystko przez IPv6 w tym samym tunelu. Taki wzorzec zwykle oznacza, że nadawca nigdy nie poznał rzeczywistego rozmiaru ścieżki, a nie że tunel jest wolny. IPv6 oczekuje, że routery zgłoszą problem komunikatem Packet Too Big, a enkapsulacja dodaje narzut, zanim pakiet w ogóle dotrze do sieci zewnętrznej. Jeśli ten komunikat jest filtrowany, nadawca powtarza rozmiar, który nie może przejść.

Małe żądania, duże zatrzymania

Tunel owija każdy pakiet w kolejny nagłówek, więc użyteczny rozmiar wewnątrz jest mniejszy niż rozmiar na zewnątrz. Pakiet dopasowany do łącza fizycznego przed enkapsulacją staje się potem zbyt duży. Routery IPv4 mogą fragmentować po drodze, natomiast routery IPv6 nie robią tego w imieniu nadawcy, więc nadawca musi sam się dostosować. A to dostosowanie zależy całkowicie od otrzymania informacji zwrotnej.

Jedna utracona wiadomość wystarczy, by powstał klasyczny objaw: uściski dłoni i małe odpowiedzi się udają, a lista katalogu lub wysyłanie pliku zatrzymuje się za każdym razem w tym samym miejscu. Użytkownicy opisują to jako wolny VPN, a logi nie pokazują niczego złego w uwierzytelnianiu. Obie obserwacje są trafne i żadna nie wskazuje miejsca usterki.

Packet Too Big to informacja zwrotna, nie ruch

Komunikat ICMPv6 Packet Too Big niesie rozmiar, który może przyjąć następny skok, a nadawca używa go do obniżenia swojego szacunku. Filtrowanie go to jak zdjęcie znaku drogowego i obwinianie potem kierowców. Reguła, która odrzuca cały ICMPv6, wygląda surowo, ale psuje wykrywanie ścieżki na każdym łączu, które go potrzebuje. Komunikat jest informacją sterującą o ścieżce, a nie ładunkiem aplikacji.

Filtrowanie selektywne nadal jest rozsądne. Żądania echa i wykrywanie sąsiadów odgrywają inną rolę niż komunikaty błędów, a polityka może traktować je inaczej. Postępuj zgodnie z udokumentowanymi wytycznymi platformy dotyczącymi filtrowania, zamiast przyjmować lub odrzucać cały protokół, bo RFC 8201 określa, jak ta informacja zwrotna napędza wykrywanie.

Testuj obie rodziny adresów osobno

Testuj IPv6 osobno, bo udany transfer IPv4 niczego nie dowodzi o ścieżce IPv6. Potem przechwyć komunikaty sterujące, gdy duży transfer się zatrzymuje. Oba zapisy razem albo pokazują, że informacja zwrotna wychodzi, albo dowodzą, że nigdy nie dotarła.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Sonda wysyła pakiet z ustawionym bitem do-not-fragment i zgłasza rozmiar, przy którym zawodzi, czyli liczbę, którą tunel musi pomieścić. Zapytanie o trasę wskazuje interfejs, który niósłby cel, więc wiesz, które MTU łącza obowiązuje. Przechwytywanie filtruje ICMPv6 typu 2, komunikat Packet Too Big, i pokazuje, czy dociera on do tego hosta. Jeśli komunikat pojawia się w przechwytywaniu, a transfer nadal się zatrzymuje, nadawca go ignoruje, co przenosi dochodzenie do stosu, a nie do sieci.

Zmieniaj rozmiar tunelu dopiero po dowodach

Obniżenie MTU tunelu może ukryć filtrowany komunikat i usunąć objaw, ale kosztem większego narzutu na każdy pakiet. To obejście, a nie diagnoza, i powinno następować po przechwytywaniu, a nie je zastępować. Dowolnie niska wartość też niczego widocznie nie psuje, dlatego przetrwa w konfiguracjach latami. Zmieniaj ją świadomie, zapisuj wartość i odnotuj, który pomiar ją uzasadnił.

Gdy kontrolujesz bramę, sprawdź regułę, która odrzuca komunikat, zamiast wyłączać zaporę. Jedna poprawiona reguła jest węższa niż wyjątek w polityce i znacznie łatwiejsza do obrony później. To samo rozumowanie dotyczy limitów czasu: nie każde zatrzymanie to problem rozmiaru, i to przechwytywanie rozdziela oba przypadki.