Имате барање што не се свиткува: спротивната страна мора да го прими истиот IP пакет од 1,500 бајти што го испраќа испраќачот, вклучително и заглавијата. Тунелот не може да го спакува тој пакет заедно со своето врамување во втор IP пакет од 1,500 бајти, затоа нешто во дизајнот мора да попушти. Редоследот подолу е оној што го користам во прозорец за промени: запишете го буџетот во бајти, докажете што подлогата навистина може да пренесе, потоа изберете точно еден механизам за пренос и потврдете го внатрешниот пакет на спротивната страна.

Запишете го буџетот во бајти пред да уредувате профил

Инкапсулацијата додава бајти на неколку слоеви, а вкупниот број е својство на вашиот профил, а не константа што може да се најде. Семејството адреси, изборот на шифра, транспортниот протокол и секоја опција за компресија или врамување го менуваат бројот, затоа одземањето копирано од друго распоредување е бескорисно како буџет. Започнете од внатрешното барање, додајте го измерениот товар по пакет на вашата конфигурација и запишете ја добиената надворешна големина на тикетот за промени пред некој да уреди датотека.

Два броја го одлучуваат дизајнот: најголемиот надворешен пакет што патеката го пренесува без фрагментација и дополнителните бајти што му се потребни на вашата инкапсулација. Кога првиот е помал од вториот плус 1,500, еден од нив мора да се смени. Изборот тогаш станува тесен, а не креативен, затоа ги запишувам двата броја пред да разговараме за опциите. Ништо на слојот на тунелот не ги компресира тие бајти, и ниту еден цел број на MTU не го отстранува барањето што ви е дадено.

Испитајте ја подлогата со do-not-fragment ping

Измерете ја патеката наместо да му верувате на MTU на интерфејсот, бидејќи најмалата алка во надворешната патека е онаа што е важна. На Linux, -M do го поставува битот do-not-fragment и -s го зема ICMP товарот, затоа рамка од 1,500 бајти одговара со 1,472 бајти товар кога ќе се одземат IP заглавието од 20 бајти и ICMP заглавието од 8 бајти. Зголемувајте го товарот додека сондата не пропадне, потоа скокнете на 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 конфигурацијата. Исто така одлучува кој од следните два дела се однесува на вас, затоа држете ги двата резултати од сондата до тикетот. Погодувањето овде чини еден прозорец за одржување, бидејќи тунел што се пријавува како up не ви кажува ништо за најголемиот пакет што патеката ќе го прифати.

Зголемете го MTU на патеката само каде што се согласува секој хоп

Jumbo рамките се end-to-end својство, а не поставка што ја вклучувате на двата крајни точки што случајно ги контролирате. Секој прекинувач, рутер и премин кај давателот на надворешната патека мора да се согласи за поголемата големина, а еден хоп од 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 fragment на Community OpenVPN е една реализација на таа идеја и не е исто што и обичната IP фрагментација на надворешниот пакет. Двата peer мора да работат верзија што го поддржува форматот, а патеката на податоците мора да биде онаа што ја мислите: 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'

Ако снимката покажува внатрешен пакет со целосна големина на спротивниот крај, изборот на пренос работи и преостанува да се запише. Ако не покажува ништо додека тунелот се пријавува како up, надворешниот пакет се отфрла некаде меѓу крајните точки, што ве враќа на сондата, а не на поставките за шифра.

Пред да го затворите тикетот, запишете три работи: измерениот надворешен буџет, избраниот механизам и командата што докажала дека внатрешниот пакет преживеал. Следното лице што ќе го допре овој тунел ќе ги побара сите три, а ниту една од нив не може да се реконструира само од конфигурациската датотека.

Поврзани статии