Твърде голям пакет 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'

Пробата изпраща пакет с установен бит за забрана на фрагментация и докладва размера, при който се проваля — числото, което тунелът трябва да побере. Заявката за маршрут посочва интерфейса, който би понесъл дестинацията, така че да знаете кой MTU на връзката важи. Прихващането филтрира ICMPv6 тип 2, съобщението Packet Too Big, и показва дали то изобщо стига до този хост. Ако съобщението се появи в прихващането, а преносът все още виси, изпращачът го игнорира, което премества разследването в стека, а не в мрежата.

Променяйте размера на тунела само след доказателства

Намаляването на MTU на тунела може да скрие филтрирано съобщение и да премахне симптома, но на цената на повече разходи за всеки пакет. Това е заобикалящо решение, а не диагноза, и трябва да следва прихващането, вместо да го заменя. Произволно ниската стойност също не чупи нищо видимо и точно затова оцелява в конфигурациите с години. Променяйте я съзнателно, записвайте стойността и отбелязвайте кое измерване я е оправдало.

Когато контролирате шлюза, прегледайте правилото, което изхвърля съобщението, вместо да изключвате защитната стена. Едно поправено правило е по-тясно от изключение в политиката и много по-лесно за защита по-късно. Същата логика важи и за таймаутите: не всяко спиране е проблем с размера и именно прихващането разделя двете.