Гигантските кадри не карат VPN път да носи пакети от 9000 байта

Включихте кадри от 9000 байта в LAN и очаквахте VPN да стане по-бърз. Той стана по-бавен или напълно спря да пропуска големи трансфери. Гигантските кадри са местно споразумение за връзката; те не разширяват пътя, който тунелът пресича.

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

Какво всъщност променят гигантските кадри

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

Местно споразумение, глобални последствия. Това е цялото объркване.

Данъкът върху инкапсулацията

Тунелът увива вашия пакет в друг. WireGuard върху IPv4 UDP добавя около 60 байта допълнителни разходи; UDP режимът на OpenVPN е в същия диапазон, а IPsec варира според режима и алгоритмите. Тези байтове излизат от бюджета на външния път, а не от нищото.

Така външна връзка от 1500 байта не може да носи вътрешен пакет от 1500 байта, след като се добави заглавка на тунела.

Аритметиката си струва да се направи веднъж. На път от 1500 байта интерфейсът WireGuard иска MTU около 1420, за да се побере инкапсулираният пакет. Задайте вътрешния интерфейс на 9000 и всеки голям пакет ще се нуждае от фрагментация, която тунелът не може да извърши, или ще бъде отхвърлен.

Намерете най-малката връзка по пътя

Минете по маршрута и намерете най-ниския MTU. LAN обикновено е 1500 или 9000, WAN обикновено е 1500, а мобилна или PPP връзка може да е още по-ниска. След това извадете разходите на тунела. Ако резултатът е по-малък от MTU на вътрешния интерфейс, имате отговора. Откриването на MTU по пътя може да намери това автоматично, но само когато ICMP съобщенията, от които зависи, се пропускат.

Филтрираният ICMP е класическата причина голям трансфер да виси, докато малките заявки работят добре.

Тествайте зависимостта от размера, без да разширявате промяната

Използвайте представителен трансфер и запазете оригиналните стойности, за да можете да ги върнете. ping -M do -s 1472 тества пакет от 1500 байта с установен DF бит; намалявайте размера, докато не премине. Ако се провалят само големите пакети, имате проблем с размера, а не с маршрутизацията.

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

Кога големият MTU е правилният дизайн

Контролирана частна мрежа може законно да пуска по-големи кадри от край до край, при условие че всяко устройство по пътя е съгласно и разходите на тунела са отчетени. Това е координиран дизайн с документирана стойност за всяка връзка, а не едно голямо число, написано в клиент.

За обикновен публичен изход приемете 1500 или по-малко и оставете тунела да избере безопасен вътрешен MTU. RFC 8201 покрива откриването на MTU по пътя за случая с IPv6 и е полезна справка за това как трябва да работи обратната връзка.