MTU чи MSS? Що насправді виправляє зміна VPN

Пінги проходять, великі передачі зависають, а тунель повідомляє, що він здоровий. Хтось знижує MTU інтерфейсу, інший обмежує MSS, і іноді проблема зникає з причин, які ніхто не записує. Ці два числа описують різні об'єкти, тому зміна неправильного дає виправлення, схоже на удачу. Ось процедура: визначте рівень, застосуйте відповідне налаштування, а потім перевірте на новому з'єднанні.

Два числа, два об'єкти

MTU належить каналу або інтерфейсу: це найбільший пакет, який можна передати без поділу. MSS належить TCP: це найбільший обсяг корисного навантаження TCP, який може нести сегмент, і він виключає заголовки і TCP, і IP. На звичайному каналі Ethernet з IPv4 MTU 1500 байтів дає відомий MSS 1460 байтів. Ці числа описують різні рівні й передаються різними механізмами. Переплутати їх легко, бо обидва вимірюються в байтах і обидва близькі до 1500.

Одне приходить як налаштування інтерфейсу. Інше приходить як опція всередині сегмента SYN, узгоджена між кінцевими точками, які ніколи не бачать ваш інтерфейс.

Куди потрапляє зовнішній додатковий обсяг

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

Саме тому збій виглядає вибірковим. Малі запити завершуються, а все, що заповнює сегмент, застрягає, бо відкидаються лише великі пакети. Тунель, що пропускає ping, не є тунелем, який несе дані.

Обмеження MSS і де воно діє

Обмеження MSS переписує значення в сегменті SYN, коли той перетинає обрану точку, через що обидва кінці обирають менше навантаження, не знаючи чому. У Linux це ціль таблиці mangle, яку застосовує явне правило, і воно має влучати в пакети SYN у потрібному вам напрямку. Обмежте його інтерфейсом тунелю й діапазоном адрес, бо широке правило змінює поведінку трафіку, який ніколи не потрапляє в тунель.

Ефект лише для TCP. Застосунок UDP, сеанс QUIC і будь-який протокол, що будує власні дейтаграми, залишаються недоторканими.

Діагностуйте на фіксованому шляху

Тримайте одну змінну за раз. Перевіряйте пакетом, розмір якого обираєте ви самі, і встановіть прапорець 'не фрагментувати', щоб ядро повідомляло результат, а не приховувало його.

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

Чого не виправляє кожна зміна

Зниження MTU інтерфейсу не змінює MSS уже встановленого сеансу. Обмеження MSS не допомагає потоку UDP і не виправляє шлях, де помилки ICMP фільтруються лише в один бік. Кожна зміна виправляє один клас проблем, а решту залишає точно такими, якими вони були.

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