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