MTU для маршрута в Linux: три регулятора размера, один маршрут

Три настройки на клиенте Linux звучат одинаково — «сделай пакеты меньше», — но действуют на разных уровнях. MTU интерфейса ограничивает каждый пакет, который отправляет устройство. MTU маршрута ограничивает пакеты, использующие этот маршрут, и для одного назначения VPN часто нужно именно это. Ограничение TCP MSS меняет то, о чём договариваются два конца, и для UDP не делает ничего.

Три регулятора, которые выглядят как одна ручка

Поставьте их рядом, прежде чем выбирать, потому что неверная строка объясняет большую часть советов, которые не работают:

Снижение MTU Ethernet для всей машины — это грубая версия такого исправления. Оно работает, но наказывает и любое другое приложение на хосте, включая те, чьи пути были в порядке. Значение на маршрут выражает то же намерение без побочных затрат.

Сравнение справедливо только для трафика, который создаёт сам хост. Передача пакета для другого клиента включает его собственный путь и внешний бюджет туннеля, а метрика маршрута на этом хосте не выходит за эту границу.

Привяжите бюджет к маршруту, который выигрывает поиск

Примерная запись маршрута 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 тогда выглядит как исправление, которое не сработало через день. Впишите значение в конфигурацию менеджера, а если нужен временный эксперимент, сначала запишите исходный маршрут.

Проверьте новым соединением, которое выполняет застрявшую операцию, и подтвердите, что нужный приватный маршрут по-прежнему выигрывает, а посторонние назначения не изменились. Переподключите туннель и прочитайте маршрут снова: значение, исчезающее при переподключении, — не исправление.

Если доказательства не поддерживают изменение, уберите переопределение через его менеджер и восстановите исходные атрибуты маршрута вместо удаления маршрута. Затем запишите, что и на каком пути вы измеряли, чтобы следующий человек отличил настоящее улучшение от эксперимента, который оставили работать.