Откриване на MTU по пътя през VPN: оразмеряване и пропускът на ICMP

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

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

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

За тунела важният брой е вътрешният MTU, тоест лимитът на външния път минус всичко, което инкапсулацията изразходва. WireGuard добавя външна IP заглавка и UDP заглавка; другите транспорти добавят свои. Задайте вътрешния размер твърде висок и всеки пакет с пълен размер ще изисква фрагментация, която може никога да не се случи.

Защо тунелът свива използваемия пакет

Ако интерфейсът на тунела запази MTU на физическата връзка, всеки голям пакет зависи от това някой по-нататък да е готов да го фрагментира. IPv4 по принцип го позволява, но рутер, на който е казано да не фрагментира, връща грешка. Рутерите IPv6 изобщо не фрагментират при транзит, затова една и съща настройка се държи различно според семейството на адресите. И в двата случая подателят не научава нищо, докато нещо не докладва.

Практическата последица е размер, който пасва на ръкостискането, но не и на полезния товар. TLS ClientHello или DNS заявка са достатъчно малки, за да преминат през свит път недокоснати, докато масовият трансфер не е. Затова симптомите се групират около конкретни операции, а не конкретни хостове.

Откриването работи само когато обратната връзка пристигне

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

Защитна стена, която разрешава echo request и echo reply, не е задължително да е разрешила тези типове грешки. ICMP е семейство и членовете, които имат значение тук, са грешките, а не двойката echo. Проверете политиката за контролен трафик в двата края на тунела и по пътя между тях и следвайте поддържаните указания на платформата, вместо да разрешавате всеки тип ICMP навсякъде.

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

Проверете пътя вместо да гадаете число

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

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

PLPMTUD, описан в RFC 4821, сондира нагоре и използва транспортни потвърждения, вместо да се доверява на доставени грешки. Помага по пътища, които филтрират ICMP, но поддръжката варира според стека и приложението. TCP поток може да се възстанови сам, докато UDP приложение с фиксиран размер на дейтаграмата продължава да се проваля.

Изберете стойност и запишете обосновката

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

Механизмът IPv4 е описан в RFC 1191, а указанията за пакетиране при IPv6 — в RFC 8201; назоваването на двете спестява на следващия инженер да извежда предположението наново. Ако трансферът все още засяда при избрания размер, спрете да сваляте числото и погледнете следващия слой. Път, който се проваля при всеки размер, не е проблем с MTU.