IPv4 fragmentuje při přenosu; IPv6 místo toho posílá zprávu o příliš velkém paketu

Selhání IPv6 se svalují na protokol mnohem častěji než na velikost paketu, která je způsobila. Obě rodiny se s příliš velkým paketem skutečně chovají jinak a právě tunel dělá ten rozdíl důležitým. IPv4 routery smějí paket fragmentovat, když to pravidla dovolí, zatímco IPv6 routery nesmějí fragmentovat v přenosu vůbec. IPv6 to místo toho řekne odesílateli a od odesílatele se očekává reakce. Všechno, co potom selže, plyne z toho, zda ta zpráva dorazí.

Co dělá každá rodina

Tabulka je mechanismus ve čtyřech řádcích a jeden řádek vysvětluje většinu zmatku.

IPv6 nemá fragmentaci v přenosu a nemá žádný příznak DF ke smazání, takže není na co se spolehnout, když je paket příliš velký. Odesílateli to musí být řečeno a odesílatel tomu musí věřit.

Tunel tiše zužuje cestu

VPN přidává vnější hlavičky, a v šifrovaném případě i data integrity, než paket opustí hostitele. Vnitřní paket se může vejít do MTU rozhraní, které vidí, zatímco vnější paket překračuje limit dalšího spoje, a proto se to projeví nejprve v tunelu. Snižte MTU tunelového rozhraní záměrně, nebo na cestě sevřete TCP MSS, a zapište, které číslo jste zvolili a proč.

Režie ESP závisí na režimu a algoritmech, takže správná MTU tunelu je výpočet, a ne konvence. Ať zvolíte cokoli, musí zůstat místo pro plný vnitřní paket IPv6 o velikosti 1280 bajtů, protože každý spoj IPv6 musí tolik unést. Tunel, který neunese 1280 bajtů IPv6, není problém ladění; je to rozbitá cesta pro tuto rodinu. Právě toto omezení zmizí, když se hodnota MTU zkopíruje z nasazení určeného jen pro IPv4.

Proč se symptom projeví jako zamrznutí

Selhání není čistá chyba, a proto se špatně diagnostikuje. TCP handshake proběhne, malé odpovědi dorazí a spojení se zasekne, jakmile začne velká odpověď nebo hromadné nahrávání, protože to jsou první pakety dost velké na to, aby byly zahozeny. SSH se připojí a pak zamrzne na prvním velkém výstupu a hlavička stránky se načte, zatímco tělo nikdy nedoběhne.

Pokud jsou zprávy ICMPv6 o příliš velkém paketu filtrovány, odesílatel se to nikdy nedozví a stále zkouší stejnou velikost. To je černá díra, a ne pomalá cesta, a jejím rysem je opakovatelná velikostní hranice, a ne náhodná ztráta. Povolit příslušný řídicí provoz je součástí funkčního nasazení IPv6, a ne zdvořilostí.

Nevypínejte zprávy, na kterých závisí vaše vlastní cesta, a pak výsledek nepopisujte jako závadu IPv6. Stejný argument platí pro zprávy Fragmentation Needed v IPv4, které jsou u autorů firewallů stejně neoblíbené a stejně nutné.

Změřte hranici a pak opravte vrstvu

Zkoušejte, místo abyste hádali: použijte příznak don't-fragment u IPv4 a pevné velikosti užitečného zatížení u IPv6 a zaznamenejte, kde se odpovědi zastaví. ping -M do -s 1472 a ping -6 -s 1400 stačí k určení tvaru problému a tracepath hlásí zjištěnou MTU cesty po trase.

Pak opravte vrstvu, které to číslo patří: MTU tunelového rozhraní, sevření MSS pro TCP, nebo sama cesta. RFC 8200 je referencí pro pravidlo IPv6 a čte se kratší dobu než incident, kterému brání.

Testujte rodinu, kterou aplikace skutečně používá, protože jméno s dvojím zásobníkem může odpovídat na jedné rodině a na druhé ne a aplikace může po změně sítě přepnout. Zapište adresu, kterou jste testovali, protože výsledek proti záznamu A neříká nic o záznamu AAAA.

Berte velikostní hranici jako důkaz

Opakovatelná velikostní hranice je jedna z mála síťových závad, která se reprodukuje přesně, při stejném počtu bajtů, ze stejného zdroje, pokaždé. To z ní dělá dárek, a ne záhadu, a také to znamená, že opravu lze ověřit, místo aby se v ni doufalo.

Zapište do tiketu zjištěnou MTU, nakonfigurovanou MTU tunelu a test, který rozdíl prokázal. Další člověk potká stejnou aritmetiku na jiném spoji.