IPv4 фрагментуе ў транзіце; IPv6 замест гэтага шле паведамленне пра занадта вялікі пакет

Збоі IPv6 часцей за ўсё спісваюць на пратакол, а не на памер пакета, які іх выклікаў. Два сямействы сапраўды па-рознаму абыходзяцца з завялікім пакетам, і менавіта тунель робіць гэтую розніцу важнай. Маршрутызатары IPv4 могуць фрагментаваць пакет, калі правілы гэта дазваляюць, а маршрутызатары IPv6 не павінны фрагментаваць у транзіце зусім. IPv6 замест гэтага паведамляе адпраўніку, і ад адпраўніка чакаюць рэакцыі. Усё, што потым ідзе не так, вынікае з таго, ці даходзіць гэта паведамленне.

Што робіць кожнае сямейства

Табліца — гэта механізм у чатырох радках, і адзін радок тлумачыць большую частку блытаніны.

У 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 тунеля, які вы наладзілі, і тэст, які даказаў розніцу. Наступны чалавек сутыкнецца з той самай арыфметыкай на іншым звяне.