Виявлення MTU шляху через VPN: розмір і розрив ICMP

Тунель завершує рукостискання, невеликі запити повертаються, а перше велике передавання зависає. Ця картина вказує на MTU шляху значно раніше, ніж на пропускну здатність. Кожна ланка на маршруті обмежує розмір пакета, а інкапсуляція витрачає частину цього ліміту на зовнішні заголовки, тому внутрішній пакет має бути меншим, ніж припускав би сирий шлях. Відмова безмовна, і саме тому її дорого діагностувати.

Що насправді вимірює MTU шляху

MTU шляху — це найменший MTU ланки на маршруті між двома хостами, а не MTU, надрукований на локальному інтерфейсі. Локальне значення — точка, з якої починається оцінка, а шлях вирішує, де вона має закінчитися. Тому однаковий тунель може працювати в одній мережі доступу й застрягати в іншій: змінився маршрут, а не конфігурація. Виміряти один раз і припускати всюди — помилка, яка підтримує цю проблему живою.

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

Чому тунель зменшує корисний пакет

Якщо інтерфейс тунелю зберігає MTU фізичної ланки, кожен великий пакет залежить від того, чи хтось нижче на шляху погодиться його фрагментувати. IPv4 у принципі це дозволяє, але маршрутизатор, якому наказано не фрагментувати, повертає помилку. Маршрутизатори IPv6 ніколи не фрагментують у транзиті, тому те саме налаштування поводиться інакше залежно від сімейства адрес. У будь-якому разі відправник нічого не дізнається, доки щось не повідомить назад.

Практичний наслідок — розмір, який уміщається в рукостискання, але не в корисне навантаження. TLS ClientHello або запит DNS достатньо малі, щоб пройти зменшений шлях недоторканими, тоді як масове передавання — ні. Тому симптоми групуються навколо конкретних операцій, а не конкретних хостів.

Виявлення працює лише тоді, коли надходить зворотний зв'язок

Виявлення IPv4 спирається на біт don't-fragment: маршрутизатор, який не може переслати пакет, повертає ICMP fragmentation-needed з MTU наступного стрибка, і відправник знижує свою оцінку. IPv6 натомість використовує повідомлення Packet Too Big, бо маршрутизатори не фрагментують у транзиті. Обидва механізми припускають, що повідомлення знайде дорогу назад до відправника, крізь тунель і повз будь-який міжмережевий екран на зворотному шляху. Коли це припущення руйнується, відправник продовжує повторювати розмір, який шлях не може перенести.

Міжмережевий екран, який дозволяє echo request і echo reply, не обов'язково дозволив ці типи помилок. ICMP — це родина, і тут важливі помилки, а не пара відлуння. Перевірте політику керуючого трафіку на обох кінцях тунелю й на шляху між ними, і дотримуйтеся підтримуваних рекомендацій платформи замість того, щоб дозволяти будь-який тип ICMP всюди.

Та сама фільтрація може бути всередині тунелю. Якщо внутрішній шлях відкидає помилку, але зовнішній її переносить, відправник може підлаштуватися під межу, якої інкапсульований трафік насправді ніколи не бачить.

Перевіряйте шлях, а не вгадуйте число

Тримайте пункт призначення, мережу доступу й тунель фіксованими, а змінюйте лише розмір пакета. Перевірка don't-fragment, яка зазнає невдачі з підказкою 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

Ping, що вміщається, не доводить, що вміщаються сегменти повного розміру реального застосунку, тож повторіть тест із передаванням, яке справді зазнало невдачі. Порівняйте найбільшу робочу перевірку з MTU тунелю, який ви налаштували, і тримайте ці два числа окремо у своїх нотатках. Якщо вони різняться приблизно на один заголовок, ви знайшли накладні витрати інкапсуляції, а не несправність.

PLPMTUD, описаний у RFC 4821, перевіряє вгору й використовує підтвердження транспорту замість довіри доставленим помилкам. Це допомагає на шляхах, що фільтрують ICMP, але підтримка залежить від стека й застосунку. Потік TCP може відновитися сам, тоді як UDP-застосунок із фіксованим розміром дейтаграми продовжує зазнавати невдач.

Виберіть значення й запишіть обґрунтування

Зниження MTU тунелю — це і діагностика, і законне виправлення, коли ви вже знаєте шлях. Воно не замінює знання того, який шлях і який механізм зворотного зв'язку були задіяні, бо значення, налаштоване для мобільної ланки, буде зайво малим на оптоволоконному з'єднанні. Запишіть вибраний розмір, перевірку, що його виправдала, і крок відкату.

Механізм IPv4 описано в RFC 1191, а рекомендації щодо пакетизації IPv6 — у RFC 8201; згадка обох позбавляє наступного інженера від повторного виведення цього припущення. Якщо передавання все ще застрягає на вибраному розмірі, припиніть знижувати число й подивіться на наступний рівень. Шлях, який зазнає невдачі за будь-якого розміру, — це не проблема MTU.