Чорная дзірка 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. Захавайце зыходныя значэнні ў заяўцы, бо выпраўленне, якое немагчыма адмяніць, — гэта другая праблема, якая чакае свайго часу. Калі тэст памеру праходзіць, а загрузка ўсё яшчэ затынаецца, чорная дзірка не была прычынай, і расследаванне павінна рухацца далей, а не пашыраць змену.