Itim na butas ng MTU: bakit gumagana ang maliliit na kahilingan pero nauutal ang pag-upload

Naglo-load ang isang pahina, bumabalik ang isang maliit na tawag sa API, at pagkatapos ay nakasabit ang pag-upload ng file hanggang sumuko ang kliyente. Walang anuman sa log ng server ang nagpapaliwanag nito, dahil itinapon ang mga packet sa gitna ng landas nang walang kapaki-pakinabang na sagot na naipadala pabalik. Ang pattern na iyon ay itim na butas ng MTU: isang link na masikip kaysa sa inaakala ng nagpapadala, kasama ang tahimik na pagtanggi na sabihin iyon. Ang laki na nabibigo ay nauulit, at iyon ang dahilan kung bakit ito masusuri.

Ano ang nagpapaitim sa butas

Bawat link ay may pinakamataas na yunit ng pagpapadala, at ang packet na mas malaki kaysa sa limitasyon ng susunod na hop ay dapat hatiin o tanggihan ng mensaheng ICMP na nagsasabi nito. Nakasalalay ang pagtuklas ng MTU ng landas sa pagdating ng mensaheng iyon at pagsunod dito. Ang pagsala o pagbalewala dito ay nag-iiwan sa nagpapadala na paulit-ulit na ipadala ang packet na hindi kailanman kasya.

Ginagawang karaniwan ito ng encapsulation sa paligid ng VPN, dahil nagdadagdag ang tunnel ng panlabas na header sa packet na nasukat na para sa pisikal na link. Legal ang panloob na packet sa 1500 byte at hindi ang naka-encapsulate, kaya namamatay ito sa hangganan habang dumadaan ang maliliit na packet. Ang natapos na handshake at gumaganang pahina ng pag-login ay nagpapatunay lamang na gumagana ang maliliit na packet. Ang pinakamalaking packet na sinusubukang ipadala ng application ang mahalaga.

Hanapin ang laki kung saan ito nasisira

Hanapin nang binary ang laki ng payload gamit ang pagsubok na walang fragmentation, mula sa host sa isang gilid ng tunnel patungo sa host sa kabilang gilid. Ang pinakamalaking payload na dumadaan ay ang magagamit mong MTU ng landas na binawasan ng overhead ng header.

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

Ang payload na 1472 byte ay dumadaan sa malinis na landas na Ethernet na 1500 byte kapag idinagdag ang 28 byte ng mga header na IPv4 at ICMP. Kapag ang parehong pagsubok ay pumasa lamang sa mas maliit na payload pagkatapos umangat ang tunnel, ang pagkakaiba ay ang overhead ng encapsulation, at ang hangganan ng tunnel ang lugar kung saan dapat nalikha ang mensahe ng pagtanggi. Itala ang dalawang numero, bago at pagkatapos kumonekta, dahil ang pares na iyon ang patunay. Ulitin ang pagsubok para sa IPv6 kapag ginagamit ito ng application, dahil mas malaki ang header at gumagalaw ang hangganan ng pagkabigo.

Basahin ang ebidensya bago sisihin ang tunnel

Ang mga error ng remote application, siksikan at ordinaryong pagkawala ay nagpapahinto rin ng pag-upload, kaya ang isang nabigong paglilipat ay hindi tumutukoy ng itim na butas. Ang naghihiwalay sa kanila ay ang ugnayan ng laki: nauulit na tagumpay sa 1200 byte at nauulit na paghinto sa 1400 byte, sa parehong direksyon, sa parehong dulong punto.

Ang pagkuha sa magkabilang dulo ay nagpapakita ng malalaking packet na lumalabas at hindi kailanman dumarating, na walang pagtanggi sa pagitan. Iyon ang sandali upang tingnan ang aparato sa hangganan sa halip na ang server, na sumasagot sa bawat kahilingang aktwal na natatanggap nito. Humihinto rin ang siksikan, ngunit nagpapahinto ito ng iba't ibang laki sa iba't ibang oras, at iba iyon na pirma.

Suriin ang pag-aayos sa parehong transport

Ang sinusuportahang pag-aayos ay hayaang iulat ng hangganan ang tunay na limitasyon, o higpitan doon ang pinakamataas na laki ng segment ng TCP upang walang sobrang laking segment na subukan. Ang pagbaba ng bawat MTU sa network, o pagpatay sa firewall, ay nagtatago ng sintomas at nag-iiwan ng configuration na walang makakapag-isip nang makatwiran mamaya.

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

I-verify gamit ang parehong pagsubok sa laki, pagkatapos gamit ang application na nabigo, at suriin ang pangalawang protocol, dahil hindi kailanman natatanggap ng mga application na UDP ang pagwawasto sa laki ng segment ng TCP. Itago ang orihinal na mga halaga sa ticket, dahil ang pag-aayos na hindi maibabalik ay pangalawang problema na naghihintay mangyari. Kung pumasa ang pagsubok sa laki at nauutal pa rin ang upload, hindi ang itim na butas ang dahilan, at dapat magpatuloy ang imbestigasyon sa halip na palawakin ang pagbabago.