Міфи про MTU у VPN: чому ваші пакети зменшуються і куди зникає місце

Інкапсуляція та PPPoE з'їдають місце в пакеті, але знижений MTU — не діагноз. Розділіть внутрішні та зовнішні розміри, перш ніж змінювати число.

Хтось каже вам, що VPN "втрачає пакети через MTU", ви ставите тунель на 1400, і передача знову працює. Такий результат здається діагнозом. Зазвичай це арифметичний збіг: ви обрали число, достатньо мале, щоб уміститися під межею, яку так і не визначили, і знову зустрінете ту саму межу в наступній мережі з іншим бюджетом.

Більшість цього створюють два міфи. Перший — що MTU інтерфейсу тунелю це MTU шляху. Другий — що інкапсуляція коштує "одного заголовка", а PPPoE не коштує нічого, що варто було б рахувати. Обидва хибні так, що обране число здається довільним, хоча насправді воно визначене.

Міф перший: MTU тунелю це MTU шляху

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

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

Міф другий: інкапсуляція коштує одного заголовка

Порахуйте зовнішні шари чесно. Зовнішній заголовок IP — 20 байтів у IPv4 або 40 у IPv6. Інкапсуляція UDP для проходу через NAT додає 8. Протокол тунелю додає свій заголовок, вектор ініціалізації або nonce, заповнення до межі блоку чи вирівнювання шифру, кінцевий сегмент і значення перевірки цілісності. Залежно від протоколу й шифру сума спокійно сягає десятків байтів ще до початку внутрішнього пакета.

Потім знову відніміть заголовки самого внутрішнього пакета. Сегмент TCP усередині тунелю несе свій 20-байтовий заголовок IP і 20-байтовий заголовок TCP, а MSS у TCP виводиться з MTU, а не з номінального корисного навантаження тунелю. Тому ping з меншим навантаженням може пройти, поки передача файлу стоїть: інструменти перевіряють різні речі, і лише один із них використовує сегмент TCP повного розміру.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

Міф третій: PPPoE все ще дає вам чисті 1500

Звичайна ланка доступу PPPoE не несе пакет IP розміром 1500 байтів. Заголовок PPPoE разом із полем протоколу PPP займають 8 байтів усередині кадру Ethernet, що залишає 1492 для пакета IP. Це традиційна межа, описана в RFC 2516. Якщо ви ганяєте VPN через таку ланку, накладні витрати тунелю беруться з тих 1492, а не з 1500.

RFC 4638 визначає спосіб узгодити більше корисне навантаження PPP, коли його підтримують і концентратор доступу, і обладнання клієнта, тому сама фраза "це з'єднання використовує PPPoE" не доводить конкретного числа. Локальне налаштування не може змусити проміжний пристрій прийняти пакет, для якого він ніколи не налаштовувався, тож корисне питання — що ланка насправді узгодила, а не що каже етикетка.

Чому збій виглядає вибірковим

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

Друга, пов'язана помилка — плутати три числа: MTU інтерфейсу, MSS у TCP і власне налаштування фрагментації чи заповнення протоколу. Стискання MSS на маршрутизаторі переписує оголошений MSS, щоб відправник будував менші сегменти; воно не змінює MTU тунелю і не допомагає трафіку UDP. Дати всім трьом однакове число, бо вони виглядають пов'язаними, — це спосіб, яким добросовісна зміна ламає робочу конфігурацію.

Що змінювати і в якому порядку

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

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

Схожі статті