Príliš veľký paket IPv6: prečo veľké prenosy cez VPN zamrznú

Ping funguje, prehliadač načíta malú stránku a prenos súboru zamrzne, to všetko cez IPv6 tým istým tunelom. Takýto vzor zvyčajne znamená, že odosielateľ nikdy nezistil skutočnú veľkosť cesty, nie že tunel je pomalý. IPv6 očakáva, že smerovače nahlásia problém správou Packet Too Big, a zapuzdrenie pridáva réžiu ešte predtým, než paket vôbec dorazí do vonkajšej siete. Ak je táto správa filtrovaná, odosielateľ stále opakuje veľkosť, ktorá nemôže prejsť.

Malé požiadavky, veľké zaseknutia

Tunel obaľuje každý paket do ďalšej hlavičky, takže použiteľná veľkosť vnútri je menšia ako veľkosť vonku. Paket dimenzovaný pre fyzické spojenie pred zapuzdrením sa potom stane príliš veľkým. Smerovače IPv4 môžu fragmentovať na ceste, kým smerovače IPv6 to za odosielateľa nerobia, takže odosielateľ sa musí prispôsobiť sám. A toto prispôsobenie úplne závisí od prijatia spätnej väzby.

Jediná stratená správa stačí na klasický príznak: podania rúk a malé odpovede prejdú a výpis adresára alebo nahrávanie sa vždy zasekne v tom istom bode. Používatelia to opisujú ako pomalý VPN a protokoly neukazujú nič zlé na autentifikácii. Obe pozorovania sú presné a ani jedno z nich neurčuje poruchu.

Packet Too Big je spätná väzba, nie prevádzka

Správa ICMPv6 Packet Too Big nesie veľkosť, ktorú môže ďalší skok prijať, a odosielateľ ju použije na zníženie svojho odhadu. Filtrovať ju je to isté ako odstrániť dopravnú značku a potom obviňovať vodičov. Pravidlo, ktoré zahadzuje všetok ICMPv6, vyzerá prísne, ale rozbíja objavovanie cesty na každom spoji, ktorý ho potrebuje. Správa je riadiaca informácia o ceste, nie aplikačná užitočná záťaž.

Selektívne filtrovanie je stále rozumné. Echo požiadavky a objavovanie susedov hrajú inú úlohu ako chybové správy a politika s nimi môže zaobchádzať inak. Riaďte sa dokumentovanými pokynmi platformy na filtrovanie, namiesto toho, aby ste celý protokol prijímali alebo zahadzovali, pretože RFC 8201 určuje, ako táto spätná väzba riadi objavovanie.

Testujte obe rodiny adries oddelene

Testujte IPv6 samostatne, pretože úspešný prenos cez IPv4 nič nedokazuje o ceste IPv6. Potom zachyťte riadiace správy, kým veľký prenos zamrzne. Oba záznamy spolu buď ukazujú, že spätná väzba odchádza, alebo 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 odošle paket s nastaveným bitom do-not-fragment a nahlási veľkosť, pri ktorej zlyhá, čo je číslo, ktoré musí tunel pojať. Dotaz na trasu pomenuje rozhranie, ktoré by nieslo cieľ, takže viete, ktoré MTU spoja platí. Zachytávanie filtruje ICMPv6 typu 2, správu Packet Too Big, a ukazuje, či sa vôbec dostane k tomuto hostiteľovi. Ak sa správa v zázname objaví a prenos stále zamŕza, odosielateľ ju ignoruje, čo presúva vyšetrovanie do zásobníka, nie do siete.

Veľkosť tunela meňte až po dôkazoch

Zníženie MTU tunela môže skryť filtrovanú správu a odstrániť príznak, ale za cenu väčšej réžie pri každom pakete. Je to obchádzka, nie diagnóza, a mala by nasledovať po zachytávaní, nie ho nahrádzať. Svojvoľne nízka hodnota tiež nič viditeľne nerozbíja, a preto v konfiguráciách prežíva roky. Meňte ju vedome, zaznamenajte hodnotu a poznamenajte, ktoré meranie ju ospravedlnilo.

Keď ovládate bránu, preskúmajte pravidlo, ktoré správu zahadzuje, namiesto vypnutia firewallu. Jedno opravené pravidlo je užšie ako výnimka v politike a oveľa ľahšie sa neskôr obhajuje. Rovnaká úvaha platí pre časové limity: nie každé zaseknutie je problém veľkosti a práve zachytávanie obe oddeluje.