MTU за маршрут в Linux: три контрола на размера, един маршрут
MTU на интерфейса, MTU на маршрута и ограничението на MSS действат на различни слоеве. Прикачете бюджет към маршрута, който печели търсенето, и запазете промяната обратима.
Три настройки на Linux клиент звучат като „направи пакетите по-малки“ и работят на различни слоеве. MTU на интерфейса ограничава всеки пакет, който устройството изпраща. MTU на маршрута ограничава пакетите, които използват този маршрут, а това често е точно това, което искате за една VPN дестинация. Ограничението TCP MSS променя това, за което се договарят двете страни, и не прави нищо за UDP.
Три контрола, които изглеждат като едно и също копче
Поставете ги едно до друго, преди да избирате, защото грешният ред обяснява повечето съвети, които не работят:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Намаляването на Ethernet MTU за цялата машина е грубата версия на това решение. Работи, но също така наказва всяко друго приложение на хоста, включително тези, чиито пътища са били наред. Стойност за маршрут изразява същото намерение без страничната цена.
Сравнението е валидно само за трафик, който хостът генерира. Препредаването на пакет за друг клиент включва собствения път на този клиент и външния бюджет на тунела, а метрика на маршрута на този хост не стига отвъд тази граница.
Прикачете бюджета към маршрута, който печели търсенето
Примерен запис на маршрут IPv4 изглежда така:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Четете записа като описание на намерение, а не като стойност за поставяне. Префиксът, устройството и предпочитаният източник трябва да съвпадат с реалната конфигурация и числото трябва да идва от доказателства за инкапсулирания път, а не от публикация в блог. MTU на маршрута ограничава вътрешния IP пакет, което не е същото като TCP полезен товар от 1380 байта или криптиран външен пакет от 1380 байта.
Вижте къде реално се разрешава търсенето, преди да добавяте каквото и да е. Хост с правила за политика може да насочи дадена дестинация през таблица, различна от main, а метрика, която съществува само в main е невидима за тази заявка. Сравнете ip -4 route show table all с отговора от ip route get, включително контекста на маркировката или пространството от имена, когато правилата ги използват. Ако двете не съвпадат, таблицата, която е отговорила, е тази, която се нуждае от метриката, а не онази, която изглежда по-подредена.
mtu не е mtu lock
По подразбиране ядрото все още може да обновява MTU на пътя от обратната връзка по ICMP, за което служи откриването на MTU на пътя. Добавянето на lock спира това. Това е различно решение, не по-силен начин да запазите същото число, и за IPv4 променя документираната обработка на бита „не фрагментирай“.
Заключването е разумно, когато сте измерили пътя и искате стойността да остане фиксирана независимо от това какво пристига. Тя е лоша настройка по подразбиране, когато мрежата изпраща легитимна обратна връзка за размера, защото ядрото вече не може да се адаптира и отказът се премества в друг симптом.
Ако ICMP се филтрира някъде по пътя, никоя настройка на маршрута не го поправя. Поправката принадлежи на филтъра, а по-малък MTU е заобиколно решение, което скрива истинската повреда до следващата промяна на пътя.
Софтуерът за тунели добавя свои собствени копчета за размер
OpenVPN- mssfix регулира размера на TCP сегментите за документирания си случай на UDP тунел. Работи върху TCP разговора, така че не е друг правопис на MTU на маршрута на операционната система и не може да помогне на UDP услуга, която игнорира договарянето.
Не струпвайте MTU на маршрут, промяна на MTU на интерфейса и ограничение на MSS в един прозорец за промени. Ако проблемът изчезне, няма да знаете кое е имало значение, а това, което запазите, ще ограничава трафика с години без причина, която някой помни.
Направете го обратимо, после го докажете
Истинският собственик на маршрута решава дали промяната оцелява след повторно свързване. VPN клиент, който инсталира маршрута динамично, обикновено ще го изгради отново без вашата метрика и ръчната ip route add тогава изглежда като поправка, която се е провалила ден по-късно. Поставете стойността в конфигурацията на мениджъра и ако ви трябва временен експеримент, първо запишете оригиналния маршрут.
Тествайте с нова връзка, която изпълнява операцията, която е заседнала, после потвърдете, че предвиденият частен маршрут все още печели и несвързаните дестинации са непроменени. Свържете тунела отново и прочетете маршрута пак, защото стойност, която изчезва при повторно свързване, не е поправка.
Ако доказателствата не подкрепят промяната, премахнете замяната през нейния мениджър и възстановете оригиналните атрибути на маршрута, вместо да изтривате маршрута. След това отбележете какво сте измерили и по кой път, за да може следващият човек да различи истинско подобрение от експеримент, оставен да работи.