Превелик IPv6 пакет: зашто се велики VPN преноси заустављају

Ping ради, прегледач учитава малу страницу, а пренос датотеке се зауставља — све то преко IPv6 кроз исти тунел. Такав образац обично значи да пошиљалац никада није научио стварну величину путање, а не да је тунел спор. IPv6 очекује да рутери пријаве проблем поруком Packet Too Big, а инкапсулација додаје додатни терет пре него што пакет уопште стигне до спољашње мреже. Ако се та порука филтрира, пошиљалац наставља да понавља величину која не може да прође.

Мали захтеви, велика застајања

Тунел увија сваки пакет у још једно заглавље, па је употребљива величина унутра мања од величине споља. Пакет димензионисан за физичку везу пре инкапсулације постаје превелик после ње. IPv4 рутери могу да фрагментирају на путу, док IPv6 рутери то не чине у име пошиљаоца, па пошиљалац мора сам да се прилагоди. И то прилагођавање у потпуности зависи од примања повратне информације.

Једна изгубљена порука довољна је за класичан симптом: руковања и мали одговори успевају, а листа директоријума или отпремање заустављају се сваки пут на истом месту. Корисници то описују као спор VPN, а дневници не показују ништа лоше у аутентификацији. Оба запажања су тачна и ниједно не лоцира квар.

Packet Too Big је повратна информација, а не саобраћај

Порука ICMPv6 Packet Too Big носи величину коју следећи скок може да прихвати, а пошиљалац је користи да смањи своју процену. Филтрирати је исто је као уклонити путоказ и онда кривити возаче. Правило које одбацује сав ICMPv6 изгледа строго, али квари откривање путање на свакој вези којој је потребно. Порука је контролна информација о путањи, а не корисни терет апликације.

Селективно филтрирање је и даље разумно. Захтеви за одјек и откривање суседа имају другачију улогу од порука о грешци, а политика може да их третира другачије. Пратите документоване смернице платформе за филтрирање уместо да прихватите или одбаците цео протокол, јер RFC 8201 одређује како та повратна информација води откривање.

Тестирајте обе фамилије адреса одвојено

Тестирајте IPv6 одвојено, јер успешан пренос преко IPv4 ништа не доказује о путањи IPv6. Затим снимите контролне поруке док се велики пренос зауставља. Два записа заједно или показују да повратна информација излази, или доказују да никада није стигла.

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'

Сонда шаље пакет са постављеним do-not-fragment битом и пријављује величину на којој не успева — то је број који тунел мора да прими. Упит за руту именује интерфејс који би носио одредиште, па знате који MTU везе важи. Снимак филтрира ICMPv6 тип 2, поруку Packet Too Big, и показује да ли она уопште стиже до овог домаћина. Ако се порука појави у снимку, а пренос и даље стаје, пошиљалац је игнорише, што премешта истрагу у стек, а не у мрежу.

Мењајте величину тунела тек после доказа

Смањење MTU тунела може да сакрије филтрирану поруку и уклони симптом, али по цени већег терета на сваки пакет. То је заобилазно решење, а не дијагноза, и треба да следи након снимка, а не да га замени. Произвољно ниска вредност такође ништа видљиво не квари, зато годинама опстаје у конфигурацијама. Мењајте је свесно, запишите вредност и забележите које је мерење оправдало.

Када управљате мрежним пролазом, прегледајте правило које одбацује поруку уместо да искључите заштитни зид. Једно исправљено правило је уже од изузетка у политици и много лакше се брани касније. Иста логика важи и за временска ограничења: није свако застајање проблем величине, а снимак је оно што раздваја два случаја.