IPv4 fragmentuje v tranzite; IPv6 namiesto toho posiela správu o príliš veľkom pakete

Zlyhania IPv6 sa zvaľujú na protokol oveľa častejšie než na veľkosť paketu, ktorá ich spôsobila. Obe rodiny sa s príliš veľkým paketom skutočne zaobchádzajú inak a práve tunel robí ten rozdiel dôležitým. IPv4 routery smú paket fragmentovať, keď to pravidlá dovolia, zatiaľ čo IPv6 routery nesmú fragmentovať v tranzite vôbec. IPv6 to namiesto toho povie odosielateľovi a od odosielateľa sa očakáva reakcia. Všetko, čo potom zlyhá, vyplýva z toho, či tá správa dorazí.

Čo robí každá rodina

Tabuľka je mechanizmus v štyroch riadkoch a jeden riadok vysvetľuje väčšinu zmätku.

IPv6 nemá fragmentáciu v tranzite ani príznak DF na vymazanie, takže niet na čo sa spoľahnúť, keď je paket príliš veľký. Odosielateľovi to treba povedať a odosielateľ tomu musí veriť.

Tunel potichu zužuje cestu

VPN pridáva vonkajšie hlavičky, a v šifrovanom prípade aj údaje o integrite, skôr než paket opustí hostiteľa. Vnútorný paket sa môže zmestiť do MTU rozhrania, ktoré vidí, kým vonkajší paket prekračuje limit ďalšieho spoja, a preto sa to prejaví najprv v tuneli. Zámerne znížte MTU tunelového rozhrania alebo na ceste zovrite TCP MSS a zapíšte, ktoré číslo ste zvolili a prečo.

Réžia ESP závisí od režimu a algoritmov, takže správna MTU tunela je výpočet, a nie konvencia. Nech zvolíte čokoľvek, musí zostať miesto pre plný vnútorný paket IPv6 s veľkosťou 1280 bajtov, pretože každý spoj IPv6 musí toľko uniesť. Tunel, ktorý neunesie 1280 bajtov IPv6, nie je problém ladenia; je to rozbitá cesta pre túto rodinu. Práve toto obmedzenie zmizne, keď sa hodnota MTU skopíruje z nasadenia určeného iba pre IPv4.

Prečo sa príznak prejaví ako zamrznutie

Zlyhanie nie je čistá chyba, a preto sa nesprávne diagnostikuje. TCP handshake prebehne, malé odpovede dorazia a spojenie sa zasekne hneď, ako sa začne veľká odpoveď alebo hromadné nahrávanie, pretože to sú prvé pakety dostatočne veľké na to, aby boli zahodené. SSH sa pripojí a potom zamrzne na prvom veľkom výstupe a hlavička stránky sa načíta, kým telo sa nikdy nedokončí.

Ak sú správy ICMPv6 o príliš veľkom pakete filtrované, odosielateľ sa to nikdy nedozvie a stále skúša rovnakú veľkosť. To je čierna diera a nie pomalá cesta, a jej znakom je opakovateľná veľkostná hranica a nie náhodná strata. Povoliť príslušnú riadiacu prevádzku je súčasťou funkčného nasadenia IPv6, a nie zdvorilosťou.

Nevypínajte správy, na ktorých závisí vaša vlastná cesta, a potom výsledok neopisujte ako poruchu IPv6. Ten istý argument platí pre správy Fragmentation Needed v IPv4, ktoré sú u autorov firewallov rovnako neobľúbené a rovnako potrebné.

Zmerajte hranicu a potom opravte vrstvu

Skúšajte, namiesto aby ste hádali: použite príznak don't-fragment pri IPv4 a pevné veľkosti užitočného zaťaženia pri IPv6 a zaznamenajte, kde sa odpovede zastavia. ping -M do -s 1472 a ping -6 -s 1400 stačia na určenie tvaru problému a tracepath hlási zistenú MTU cesty po trase.

Potom opravte vrstvu, ktorej to číslo patrí: MTU tunelového rozhrania, zovretie MSS pre TCP, alebo samotnú cestu. RFC 8200 je referenciou pre pravidlo IPv6 a číta sa kratšie než incident, ktorému zabraňuje.

Testujte rodinu, ktorú aplikácia skutočne používa, pretože názov s dvojitým zásobníkom môže odpovedať na jednej rodine a na druhej nie a aplikácia sa po zmene siete môže prepnúť. Zapíšte adresu, ktorú ste testovali, pretože výsledok voči záznamu A nehovorí nič o zázname AAAA.

Berte veľkostnú hranicu ako dôkaz

Opakovateľná veľkostná hranica je jedna z mála sieťových porúch, ktorá sa reprodukuje presne, pri rovnakom počte bajtov, z rovnakého zdroja, zakaždým. To z nej robí darček a nie záhadu, a tiež to znamená, že opravu možno overiť namiesto dúfania.

Zapíšte do tiketu zistenú MTU, nakonfigurovanú MTU tunela a test, ktorý rozdiel dokázal. Ďalší človek stretne tú istú aritmetiku na inom spoji.