Провалите на IPv6 се преписват на протокола много по-често, отколкото на размера на пакета, който ги е причинил. Двете семейства наистина работят различно с прекалено големия пакет и именно тунелът прави разликата важна. Маршрутизаторите на IPv4 могат да фрагментират пакет, когато правилата го позволяват, докато маршрутизаторите на IPv6 не бива да фрагментират транзитно изобщо. Вместо това IPv6 уведомява подателя и се очаква подателят да реагира. Всичко, което след това се обърка, произтича от това дали това съобщение пристига.

Какво прави всяко семейство

Таблицата е механизмът в четири реда и един ред обяснява по-голямата част от объркването.

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

IPv6 няма транзитна фрагментация и няма флаг DF, който да се изчисти, така че няма на какво да се разчита, когато пакетът е прекалено голям. На подателя трябва да се каже и подателят трябва да го повярва.

Тунелът тихо стеснява пътя

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

Накладните разходи на ESP зависят от режима и алгоритмите, затова правилният MTU на тунела е изчисление, а не навик. Каквото и да изберете, то трябва да остави място за пълен вътрешен пакет IPv6 от 1280 байта, защото всяка връзка IPv6 е длъжна да носи толкова. Тунел, който не може да носи 1280 байта IPv6, не е проблем с настройката; това е счупен път за това семейство. Точно това ограничение изчезва, когато стойност на MTU се копира от внедряване само с IPv4.

Защо симптомът изглежда като забиване

Провалът не е чиста грешка и точно затова се диагностицира погрешно. TCP ръкостискането завършва, малките отговори пристигат и връзката замира веднага щом започне голям отговор или масово качване, защото това са първите пакети, достатъчно големи, за да бъдат изхвърлени. SSH се свързва и после забива на първия голям изход, а заглавката на страницата се зарежда, докато тялото така и не завършва.

Ако съобщенията на ICMPv6 за прекалено голям пакет се филтрират, подателят никога не разбира и продължава да повтаря същия размер. Това е черна дупка, а не бавен път, и подписът ѝ е повтаряща се граница на размера, а не случайна загуба. Разрешаването на съответния контролен трафик е част от работещо внедряване на IPv6, а не любезност.

Не изключвайте съобщенията, от които зависи собственият ви път, и после не описвайте резултата като дефект на IPv6. Същият аргумент важи и за съобщенията Fragmentation Needed на IPv4, които са еднакво непопулярни сред авторите на защитни стени и еднакво необходими.

Измерете границата, после оправете слоя

Проверявайте, вместо да гадаете: използвайте флага don't-fragment при IPv4 и фиксирани размери на полезния товар при IPv6 и записвайте къде отговорите спират. ping -M do -s 1472 и ping -6 -s 1400 са достатъчни, за да установят формата на проблема, а tracepath съобщава открития MTU на пътя по трасето.

После оправете слоя, който притежава числото: MTU на тунелния интерфейс, затягането на MSS за TCP или самия път. RFC 8200 е референцията за правилото на IPv6 и се чете по-бързо, отколкото се разследва инцидентът, който предотвратява.

Тествайте семейството, което приложението наистина използва, защото име с двоен стек може да отговаря по едното семейство и не по другото, а приложението може да превключи след промяна в мрежата. Запишете адреса, който тествахте, защото резултат срещу записа A не казва нищо за записа AAAA.

Третирайте границата на размера като доказателство

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

Запишете в заявката открития MTU, MTU на тунела, който сте конфигурирали, и теста, който доказа разликата. Следващият човек ще срещне същата аритметика на друга връзка.

Подобни статии