Пренос на фиксиран 1,500-байтов вътрешен пакет през VPN

Имате изискване, което не търпи компромис: отдалечената страна трябва да получи същия 1,500-байтов IP пакет, който изпраща изпращачът, включително заглавките. Тунелът не може да увие този пакет заедно със своето рамкиране във втори 1,500-байтов IP пакет, затова нещо в дизайна трябва да отстъпи. Редът по-долу е този, който използвам в прозорец за промени: запишете бюджета в байтове, докажете какво реално може да пренесе подложната мрежа, след това изберете точно един механизъм за пренос и потвърдете вътрешния пакет от другата страна.

Запишете бюджета в байтове, преди да редактирате профил

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

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

Проверете подложната мрежа с ping с бит забрана на фрагментацията

Измерете пътя, вместо да се доверявате на MTU на интерфейса, защото най-малкото звено във външния път е това, което има значение. В Linux -M do задава бита за забрана на фрагментацията, а -s приема ICMP полезния товар, така че кадър от 1,500 байта отговаря при 1,472 байта полезен товар, след като се извадят 20-байтовата IP заглавка и 8-байтовата ICMP заглавка. Увеличавайте товара, докато проверката се провали, след което скочете до jumbo размер, за да видите дали пътят изобщо го пренася.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Път, който преминава 1,472 и се проваля на 8,972, не може да пренесе 1,500-байтов вътрешен пакет плюс разходи в един външен пакет. Това е отговорът, който ви трябваше, преди да отворите конфигурацията на VPN. Той също решава кой от следващите два раздела се отнася за вас, затова дръжте двата резултата от проверката до заявката. Да гадаете тук струва прозорец за поддръжка, защото тунел, който се обявява за работещ, не ви казва нищо за най-големия пакет, който пътят ще приеме.

Увеличете MTU на пътя само там, където всеки хоп е съгласен

Jumbo кадрите са свойство от край до край, а не настройка, която включвате на двата крайни пункта, които случайно контролирате. Всеки комутатор, рутер и точка на доставчик във външния път трябва да се съгласят за по-големия размер и едно-единствено звено от 1,500 байта ще изхвърли безшумно пакета, който току-що увеличихте. Вдигането само на локалния интерфейс е класическата половинчата промяна, от която тунелът изглежда счупен, докато подложката тихо губи.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Променете интерфейса, след което проверете отново същия път, преди да промените нещо друго. Ако проверката все още се проваля, върнете с ip link set dev eth1 mtu 1500 и преминете към фрагментация, вместо да спорите с доставчик за връзка, която не притежавате.

Използвайте фрагментация на тунела, когато подложката не може да расте

Поддържан механизъм за фрагментация под вътрешния пакет позволява на няколко външни пакета да пренесат един вътрешен пакет и отдалеченият край на тунела ги сглобява отново, преди да предаде оригинала нагоре по стека. Опцията за UDP фрагментация на Community OpenVPN е една реализация на тази идея и не е същото като обикновената IP фрагментация на външния пакет. И двете страни трябва да работят с версия, която поддържа формата, и пътят на данните трябва да е този, който смятате: клиентите на OpenVPN 3 и ускорените в ядрото канали за данни имат различни ограничения, затова профил, който работи на един клиент, може да се провали на друг.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Обикновената външна фрагментация е другият вариант и е по-слабият. Рутерите с IPv6 изобщо не фрагментират препратен пакет, затова прекалено големият външен пакет просто загива и изпращачът научава за това само ако съответното съобщение ICMPv6 оцелее по пътя. Фрагментите също привличат филтриране и усилване на загубите, затова ги третирам като резервен вариант, а не като план.

Външен носител на базата на поток заобикаля въпроса за размера, като сегментира собствения си байтов поток, и реконструираният вътрешен пакет може да остане 1,500 байта. Това е транспортно решение с цена, включително известното поведение на TCP в TCP, затова го вземете съзнателно, а не като страничен ефект от спор за MTU.

Потвърдете, че вътрешният пакет пристига непроменен

Проверката не е успешен ръкостискан. Направете снимка на интерфейса на тунела от двата края и сравнете размера и съдържанието на пакета, който приложението действително е изпратило, с този, който отдалечената страна е получила.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

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

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