Пренос фиксног унутрашњег пакета од 1,500 бајтова кроз VPN

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

Напишите буџет у бајтовима пре измене профила

Енкапсулација додаје бајтове на више слојева, а укупан број је особина вашег профила, а не константа коју можете да пронађете. Фамилија адреса, избор шифре, транспортни протокол и свака опција компресије или фрејмирања померају број, зато је одузимање копирано из другог постављања безвредно као буџет. Пођите од унутрашњег захтева, додајте измерени трошак по пакету сопствене конфигурације и напишите добијену спољну величину на тикет за измене пре него што неко измени датотеку.

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

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

Мерите путању уместо да верујете 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 клијенти и kernel-ом убрзани data канали имају различита ограничења, па профил који ради на једном клијенту може да падне на другом.

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

Обична спољна фрагментација је друга опција и слабија је. IPv6 рутери уопште не фрагментишу прослеђени пакет, па превелики спољни пакет једноставно умре, а пошиљалац то сазна само ако релевантна ICMPv6 порука преживи путању. Фрагменти такође позивају на филтрирање и појачање губитака, зато ово третирам као резервну опцију, а не као план.

Спољни носач заснован на току заобилази питање величине сегментисањем сопственог тока бајтова, а реконструисани унутрашњи пакет и даље може да буде 1,500 бајтова. То је транспортна одлука са сопственом ценом, укључујући познато понашање TCP-а унутар TCP-а, зато је донесите намерно, а не као споредни ефекат расправе о MTU-у.

Потврдите да унутрашњи пакет стиже непромењен

Верификација није успешан handshake. Снимите на интерфејсу тунела на оба краја и упоредите величину и садржај пакета који је апликација заиста послала са оним што је друга страна примила.

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, спољни пакет се одбацује негде између крајњих тачака, што вас враћа на тест, а не на подешавања шифре.

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