Митове за MTU при VPN: защо пакетите ви се свиват и къде отива мястото

Някой ви казва, че VPN „губи пакети заради MTU“, вие задавате тунела на 1400 и преносът отново тръгва. Такъв резултат изглежда като диагноза. Обикновено това е аритметично съвпадение: избрали сте число, достатъчно малко, за да се побере под граница, която така и не сте установили, и ще срещнете същата граница отново в следващата мрежа с друг бюджет.

Два мита причиняват по-голямата част от това. Първият е, че MTU на интерфейса на тунела е MTU на пътя. Вторият е, че инкапсулацията струва „един заглавен блок“, а PPPoE не струва нищо, което си заслужава броене. И двата са грешни по начин, който прави избраното от вас число да изглежда произволно, докато то всъщност е определено.

Мит първи: MTU на тунела е MTU на пътя

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

Откриването на MTU на пътя съществува, за да помири двете, и зависи от обратна връзка. При IPv4 рутер, който не може да препрати пакет с пълен размер, трябва да изпрати ICMP съобщение „fragmentation needed“, и изпращачът понижава оценката си. При IPv6 еквивалентът е съобщение Packet Too Big, а рутерите изобщо не фрагментират по пътя. Когато тази обратна връзка се филтрира, изпращачът продължава да произвежда пакети, които пътят не може да носи, и нищо не му казва защо.

Мит втори: инкапсулацията струва един заглавен блок

Пребройте външните слоеве честно. Външният IP заглавен блок е 20 байта при IPv4 или 40 при IPv6. UDP инкапсулацията за преминаване през NAT добавя 8. Протоколът на тунела добавя свой заглавен блок, вектор за инициализация или nonce, допълване до границата на блока или подравняването на шифъра, завършващ сегмент и стойност за проверка на целостта. В зависимост от протокола и шифъра сумата спокойно стига десетки байта, преди вътрешният пакет дори да започне.

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

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Първата команда показва зададения MTU на тунела. Двете проби изпращат полезен товар от 1472 байта, което с 28 байта IPv4 и ICMP заглавни блокове е пакет от 1500 байта, а после по-малък. Ако голямата проба се провали напълно, а малката успее, имате дефект, зависещ от размера, а не общ проблем с маршрутизацията.

Мит трети: PPPoE все още ви дава чисти 1500

Обикновената PPPoE връзка за достъп не носи IP пакет от 1500 байта. PPPoE заглавният блок плюс полето за PPP протокол заемат 8 байта в Ethernet кадъра, което оставя 1492 за IP пакета. Това е традиционната граница, описана в RFC 2516. Ако пускате VPN през такава връзка, разходите на тунела идват от тези 1492, а не от 1500.

RFC 4638 определя начин за договаряне на по-голям PPP полезен товар, когато и концентраторът за достъп, и оборудването на клиента го поддържат, поради което самото „тази връзка използва PPPoE“ не доказва конкретно число. Местна настройка не може да накара междинно устройство да приеме пакет, за който никога не е конфигурирано, така че полезният въпрос е какво връзката действително е договорила, а не какво казва етикетът.

Защо повредата изглежда избирателна

Малките заявки, които минават, и големите преноси, които зациклят, са класическият отпечатък на черна дупка в MTU на пътя. Ръкостискането, DNS заявката и API извикването се побират; масовият пренос произвежда сегменти с пълен размер, които умират на една връзка, а ICMP съобщението, което е трябвало да докладва проблема, така и не пристига. Връзката изглежда наред, а изтеглянето виси, което кара хората да гледат сървъра вместо пътя.

Втора, свързана грешка е да се бъркат три числа: MTU на интерфейса, TCP MSS и собствената настройка за фрагментиране или допълване на протокола. Прищипването на MSS на рутер преписва обявения MSS, така че изпращачът да изгражда по-малки сегменти; то не променя MTU на тунела и не помага на UDP трафика. Задаването на едно и също число на трите, защото изглеждат свързани, е начинът работна конфигурация да се счупи от добронамерена промяна.

Какво да промените и в какъв ред

Започнете с доказателства. Потвърдете с пробите по-горе, че дефектът зависи от размера, после намерете най-малкия размер, който минава, и най-големия, който се проваля. Проверете истинския MTU на връзката за достъп, преди да обвинявате тунела; PPPoE връзката ограничава бюджета, преди VPN да я докосне. Запишете оригиналните стойности, за да може промяната да се върне.

След това приложете най-малката корекция, която клиентът документира. Много клиенти предлагат MTU на тунела плюс опция за поправка на MSS, а MSS опцията често е по-добрият лост за TCP, защото стига до изпращача, без да смалява всеки пакет. Тествайте отново същата дестинация и същия пренос и запишете числата, на които сте се спрели. Стойност на тунела, която работи в една мрежа за достъп, не е универсална константа, и следващият обект ще има свой бюджет.