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