Příliš velký paket IPv6: proč velké přenosy přes VPN zamrznou

Ping funguje, prohlížeč načte malou stránku a přenos souboru zamrzne — to vše přes IPv6 stejným tunelem. Takový vzorec obvykle znamená, že odesílatel nikdy nezjistil skutečnou velikost cesty, nikoli že je tunel pomalý. IPv6 očekává, že směrovače problém ohlásí zprávou Packet Too Big, a zapouzdření přidává režii ještě předtím, než paket vůbec dorazí do vnější sítě. Pokud je tato zpráva filtrována, odesílatel stále opakuje velikost, která nemůže projít.

Malé požadavky, velká zaseknutí

Tunel obaluje každý paket do další hlavičky, takže použitelná velikost uvnitř je menší než velikost venku. Paket dimenzovaný pro fyzické spojení před zapouzdřením se potom stane příliš velkým. Směrovače IPv4 mohou fragmentovat na cestě, zatímco směrovače IPv6 to za odesílatele nedělají, takže se odesílatel musí přizpůsobit sám. A toto přizpůsobení zcela závisí na přijetí zpětné vazby.

Jediná ztracená zpráva stačí k vytvoření klasického příznaku: handshaky a malé odpovědi projdou a výpis adresáře nebo nahrávání se vždy zasekne ve stejném bodě. Uživatelé to popisují jako pomalý VPN a protokoly neukazují nic špatného na autentizaci. Obě pozorování jsou přesná a ani jedno z nich neurčuje poruchu.

Packet Too Big je zpětná vazba, ne provoz

Zpráva ICMPv6 Packet Too Big nese velikost, kterou může další skok přijmout, a odesílatel ji použije ke snížení svého odhadu. Filtrovat ji je totéž jako odstranit dopravní značku a pak obviňovat řidiče. Pravidlo, které zahazuje veškerý ICMPv6, vypadá přísně, ale rozbíjí objevování cesty na každém spoji, který ho potřebuje. Zpráva je řídicí informace o cestě, ne aplikační užitečné zatížení.

Selektivní filtrování je stále rozumné. Požadavky na echo a objevování sousedů hrají jinou roli než chybové zprávy a zásada s nimi může zacházet jinak. Řiďte se dokumentovaným pokynem platformy pro filtrování, místo abyste celý protokol přijímali nebo zahazovali, protože RFC 8201 určuje, jak tato zpětná vazba řídí objevování.

Testujte obě rodiny adres odděleně

Testujte IPv6 samostatně, protože úspěšný přenos přes IPv4 nic nedokazuje o cestě IPv6. Potom zachyťte řídicí zprávy, zatímco velký přenos zamrzne. Oba záznamy dohromady buď ukazují, že zpětná vazba odchází, nebo dokazují, že nikdy nedorazila.

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 odešle paket s nastaveným bitem zákazu fragmentace a hlásí velikost, při níž selže, což je číslo, které musí tunel pojmout. Dotaz na trasu pojmenuje rozhraní, které by neslo cíl, takže víte, které MTU spoje platí. Zachytávání filtruje ICMPv6 typu 2, zprávu Packet Too Big, a ukazuje, zda vůbec dorazí k tomuto hostiteli. Pokud se zpráva v záznamu objeví a přenos stále zamrzá, odesílatel ji ignoruje, což přesouvá vyšetřování do zásobníku, nikoli do sítě.

Měňte velikost tunelu až po důkazech

Snížení MTU tunelu může skrýt filtrovanou zprávu a odstranit příznak, ovšem za cenu větší režie u každého paketu. To je obcházení, nikoli diagnóza, a mělo by následovat zachytávání, ne ho nahrazovat. Libovolně nízká hodnota také nic viditelně nerozbíjí, a proto v konfiguracích přežívá roky. Měňte ji vědomě, zaznamenejte hodnotu a poznamenejte, které měření ji ospravedlnilo.

Když ovládáte bránu, prohlédněte pravidlo, které zprávu zahazuje, místo abyste vypínali firewall. Jedno opravené pravidlo je užší než výjimka v zásadě a mnohem snáze se později obhajuje. Stejná úvaha platí pro časové limity: ne každé zaseknutí je problém velikosti a právě zachytávání obojí odděluje.