Черна дупка в 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. Запазете оригиналните стойности в тикета, защото поправка, която не може да бъде отменена, е втори проблем, който чака да се случи. Ако тестът за размер минава, а качването все още забива, черната дупка не е била причината и разследването трябва да продължи, вместо да разширява промяната.