OpenVPN mssfix: защо един клиент спира при големи трансфери
mssfix пренаписва размера на TCP сегмента, обявен вътре в тунела. Той не променя UDP и стойността означава само това, което вашата версия казва.
Един лаптоп спира при качване през тунела, докато всяко друго устройство на същия сървър продължава да работи. Този модел сочи към един път, а не към конфигурацията на сървъра, и това е обичайният вход към въпроса за mssfix. Опцията може да помогне, но само за TCP връзките, които тя действително пренаписва. Познаването на обхвата ѝ ви пази от промяна на работещ сървър, за да спасите един клиент.
Какво пренаписва опцията
mssfix редактира максималния размер на сегмента, обявен в TCP ръкостисканията, които преминават през тунела, така че изпращащата страна да избира сегменти, които се побират в инкапсулирания бюджет. Той действа върху ръкостискането, което означава, че връзка, отворена преди промяната, запазва договорената стойност.
Той не свива UDP дейтаграмите и не задава MTU на тунела. Два различни проблема дават един и същ симптом: TCP изпращач, който пренебрегва ограничението на пътя, и път, който тихо изхвърля големи пакети при всякакъв размер. mssfix се справя с първия и не прави нищо за втория.
Това разграничение обяснява разочароващите експерименти. Задаването на по-малка стойност на път с черна дупка променя размера на сегмента, но не и изхвърлянето, което следва, затова трансферът се проваля на друго място.
Обхватът е TCP вътре в тунела
Пренаписва се само TCP трафикът. QUIC сесия, игра или приложение, което изпраща големи UDP дейтаграми, ще запази своите размери на пакетите и ако точно тези трансфери зациклят, поправката принадлежи по-скоро на MTU на тунела или пътя. Прочетете кой протокол използва проблемният трансфер, преди да посегнете към TCP опция, защото грешният слой има своя поправка.
Посоката също има значение. Настройката на клиента влияе на трафика, който този клиент изпраща в тунела, докато сървърът покрива потоците, които препраща към клиентите. Ако зациклят само входящите изтегляния, стойността от страна на клиента не е цялата история.
Числото и ключовата дума не са преносими
Общностната версия на OpenVPN 2.6 приема незадължителна ключова дума след стойността. С mtu числото описва размера на външния пакет, включително IP и UDP заглавките; без нея аргументът следва друга отчетна конвенция. Затова ред, копиран между версии, не описва същия бюджет на пакета. Проверете страницата от ръководството, която идва със сборката, която всъщност изпълнявате, вместо урок за друго издание.
Синтаксисът изглежда така:
mssfix 1400 mtu
Приемайте 1400 като заместител, а не като препоръка за вашия път. Изведете стойността от измерения път и реално използваната инкапсулация и помнете, че клиенти на по-стари версии или други реализации може да отхвърлят или преосмислят ключовата дума.
Първо потвърдете на единствения клиент
Измерете пътя от проблемната машина, преди да промените нещо. Полезният товар, който пътят може да пренесе без фрагментация, е числото, което търсите:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1
Първата проба побира пакет от 1500 байта, след като се добавят 28 байта заглавки. Ако тя се провали с грешка за фрагментация, а по-малката успее, използваемият размер е някъде между тях, а разходите на тунела се приспадат отгоре.
След това повторете зациклилия трансфер на нова връзка и сравнете. Ако единственият клиент се подобри, докато останалите са незасегнати, намерили сте обхвата на проблема. Ако зациклят всички клиенти, стойността от страна на сървъра е тази, която трябва да прегледате. Нито един от двата резултата не оправдава промяна на хардуер, който никога не е бил на проблемния път.