Црна рупа 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 сегмента. Сачувајте оригиналне вредности у тикету, јер поправка која не може да се врати је други проблем који чека да се догоди. Ако тест величине прође, а отпремање и даље стаје, црна рупа није била узрок, и истрага треба да иде даље уместо да шири промену.