MTU ці MSS? Што насамрэч выправіць змена VPN

Ping-і праходзяць, вялікія перадачы завісаюць, а тунель паведамляе, што ён здаровы. Хтосьці памяньшае MTU інтэрфейса, хтосьці іншы прыціскае MSS, і часам праблема знікае з прычын, якія ніхто не запісвае. Гэтыя два лікі апісваюць розныя аб'екты, таму змена няправільнага дае выпраўленне, якое выглядае як удача. Вось парадак дзеянняў: вызначыце ўзровень, прымяніце адпаведную наладку, затым праверце на новым злучэнні.

Два лікі, два аб'екты

MTU належыць каналу або інтэрфейсу: гэта найбольшы пакет, які можна перадаць без падзелу. MSS належыць TCP: гэта найбольшая колькасць карыснага грузу TCP, якую можа несці сегмент, і яна выключае загалоўкі і TCP, і IP. На звычайным канале Ethernet з IPv4 MTU у 1500 байтаў дае знакаміты MSS у 1460 байтаў. Гэтыя лікі апісваюць розныя ўзроўні і перадаюцца рознымі механізмамі. Зблытаць іх лёгка, бо абодва вымяраюцца ў байтах і абодва блізкія да 1500.

Адзін прыходзіць як наладка інтэрфейсу. Другі прыходзіць як опцыя ўнутры сегмента SYN, узгодненая паміж канцавымі пунктамі, якія ніколі не бачаць вашага інтэрфейсу.

Дзе асядае знешняя дадатковая нагрузка

VPN змяшчае ўнутраны пакет унутры іншага, і знешні пакет павінен змясціцца ў фізічны шлях. Загалоўкі інкапсуляцыі, знешні загаловак IP, транспартны загаловак і любы тэг аўтэнтыфікацыі спажываюць байты, якія ўнутраны пакет не можа выкарыстаць. Пакіньце тунельны інтэрфейс на 1500, і знешні пакет рэгулярна перавышае тое, што можа пранесці шлях. Калі ўсталяваны біт 'не фрагментаваць', маршрутызатар скідвае пакет і павінен адправіць назад памылку ICMP; калі гэтая памылка фільтруецца, адпраўнік пра гэта ніколі не даведаецца.

Менавіта таму збой выглядае выбарачным. Дробныя запыты завяршаюцца, а ўсё, што запаўняе сегмент, спыняецца, бо адкідваюцца толькі вялікія пакеты. Тунель, які прапускае ping, не азначае тунель, які нясе даныя.

Прыціск MSS і дзе ён дзейнічае

Прыціск MSS перапісвае значэнне ў сегменце SYN, калі той перасякае выбраны пункт, і такім чынам абодва канцы выбіраюць меншы карысны груз, не ведаючы чаму. У Linux гэта мэта табліцы mangle, якую прымяняе відавочнае правіла, і яна павінна закранаць пакеты SYN у патрэбным вам кірунку. Абмяжуйце яе тунельным інтэрфейсам і дыяпазонам адрасоў, бо шырокае правіла змяняе паводзіны для трафіку, які ніколі не трапляе ў тунель.

Эфект датычыцца толькі TCP. Праграма на UDP, сесія QUIC і любы пратакол, які будуе ўласныя датаграмы, гэтым не закранаюцца.

Дыягнастуйце на фіксаваным шляху

Трымайце адну зменную за раз. Праверце пакетам, памер якога выбіраеце самі, і ўсталюйце сцяг 'не фрагментаваць', каб ядро паведамляла вынік, а не хавала яго.

Запішыце, дзе пачынаецца збой: унутры тунеля, на тунельным інтэрфейсе або на фізічным шляху пасля інкапсуляцыі. Затым змяніце адзін лік і паўтарыце той самы тэст, а не іншы. Існуючыя злучэнні захоўваюць MSS, пра які яны дамовіліся, таму змена палітыкі бачная толькі на новым злучэнні, і менавіта таму кэшаваная старонка нічога не даказвае ні ў адзін бок. Калі адна вялікая выгрузка пачала працаваць, вы даведаліся пра гэты шлях, а не пра кожны пратакол на ім.

Што не выпраўляе кожная змена

Памяншэнне MTU інтэрфейса не змяняе MSS сесіі, якая ўжо ўсталявана. Прыціск MSS не дапамагае патоку UDP і не рамантуе шлях, дзе памылкі ICMP фільтруюцца толькі ў адзін бок. Кожная змена выпраўляе адзін клас праблем і пакідае астатнія роўна такімі, якімі яны былі.

Запішыце, якую наладку вы прымянілі, дзе і які тэст паказаў розніцу, бо інакш наступны інжынер прымяніць абодва і страціць здольнасць сказаць, якая з іх мела значэнне. Калі абмежаванне рэальнае і пастаяннае, аддайце перавагу MTU тунеля, які яго адлюстроўвае, а не прыціску, які яго хавае. Калі прыціскаць даводзіцца, пакіньце правіла абмежаваным і з каментаром, бо неапісанае правіла mangle па змаўчанні становіцца пастаянным.