Чорна діра MTU: чому малі запити працюють, а завантаження застрягають

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

Що робить діру чорною

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

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

Знайдіть розмір, на якому все ламається

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

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Корисне навантаження в 1472 байти проходить чистим шляхом Ethernet у 1500 байтів, щойно додаються 28 байтів заголовків IPv4 і ICMP. Коли той самий тест проходить лише з меншим навантаженням після підняття тунелю, різниця — це накладні витрати інкапсуляції, а межа тунелю — те місце, де мало з'явитися повідомлення про відмову. Запишіть обидва числа, до і після підключення, бо ця пара і є доказом. Повторіть тест для IPv6, коли застосунок його використовує, оскільки заголовок більший і поріг збою зсувається.

Прочитайте докази, перш ніж звинувачувати тунель

Помилки віддалених застосунків, перевантаження і звичайні втрати теж зупиняють завантаження, тому одна невдала передача не визначає чорну діру. Їх розділяє співвідношення розмірів: відтворюваний успіх за 1200 байтів і відтворювана зупинка за 1400 байтів, в одному напрямку, через ту саму кінцеву точку.

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

Перевірте виправлення на обох транспортах

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

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

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