MTU-musta aukko: miksi pienet pyynnöt toimivat mutta lataukset juuttuvat

Sivu latautuu, pieni API-kutsu palaa, ja sitten tiedoston lataus roikkuu, kunnes asiakas luovuttaa. Mikään palvelimen lokissa ei selitä sitä, koska paketit pudotettiin kesken polun lähettämättä hyödyllistä vastausta takaisin. Tämä kuvio on MTU-musta aukko: lähettäjän olettamaa kapeampi linkki sekä äänetön kieltäytyminen sanomasta sitä. Epäonnistuva koko on toistettavissa, ja juuri se tekee siitä diagnosoitavan.

Mikä tekee aukosta mustan

Jokaisella linkillä on suurin siirtoyksikkö, ja seuraavan hypyn rajaa suurempi paketti on joko pilkottava tai hylättävä ICMP-viestillä, joka kertoo sen. Polun MTU:n löytäminen riippuu siitä, että viesti saapuu perille ja sitä noudatetaan. Sen suodattaminen tai huomiotta jättäminen jättää lähettäjän toistamaan pakettia, joka ei koskaan mahdu.

Kapselointi tekee tästä yleistä VPN:ien ympärillä, koska tunneli lisää ulomman otsikon paketille, joka oli jo mitoitettu fyysiselle linkille. Sisempi paketti on laillinen 1500 tavulla ja kapseloitu ei ole, joten se kuolee rajalla, kun pienet paketit lipuvat läpi. Valmis kättely ja toimiva kirjautumissivu todistavat vain, että pienet paketit toimivat. Suurin paketti, jota sovellus yrittää lähettää, on se, jolla on merkitystä.

Etsi koko, jossa se katkeaa

Etsi hyötykuorman koko binäärisesti ei-pilkontatestillä, tunnelin toisella puolella olevasta isännästä toisella puolella olevaan isäntään. Suurin läpi menevä hyötykuorma on käytettävissä oleva polun MTU miinus otsikon ylimäärä.

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 tavun hyötykuorma menee läpi puhtaalla 1500 tavun Ethernet-polulla, kun IPv4- ja ICMP-otsikoiden 28 tavua lisätään. Kun sama testi onnistuu vain pienemmällä hyötykuormalla tunnelin noustua, ero on kapseloinnin ylimäärä, ja tunnelin raja on paikka, jossa hylkäysviesti olisi pitänyt tuottaa. Kirjaa molemmat luvut, ennen yhteyttä ja sen jälkeen, koska tuo pari on todiste. Toista testi IPv6:lle, kun sovellus käyttää sitä, koska otsikko on suurempi ja epäonnistumiskynnys siirtyy.

Lue todisteet ennen kuin syytät tunnelia

Etäsovellusten virheet, ruuhka ja tavallinen häviö pysäyttävät myös latauksia, joten yksi epäonnistunut siirto ei tunnista mustaa aukkoa. Ne erottaa kokosuhde: toistettava onnistuminen 1200 tavulla ja toistettava juuttuminen 1400 tavulla, samaan suuntaan, saman päätepisteen kautta.

Kaappaus molemmissa päissä näyttää suurten pakettien lähtevän eivätkä koskaan saapuvan, ilman hylkäystä niiden välissä. Silloin on hetki katsoa rajalaitetta palvelimen sijaan, joka vastaa jokaiseen pyyntöön, jonka se todella vastaanottaa. Ruuhka juuttuu myös, mutta se juuttuu eri kokoihin eri aikoina, ja se on erilainen allekirjoitus.

Tarkista korjaus molemmilla kuljetuksilla

Tuettu korjaus on antaa rajan raportoida todellinen raja tai kiristää siellä TCP:n suurin segmenttikoko, jotta liian suurta segmenttiä ei yritetä. Jokaisen MTU:n laskeminen verkossa tai palomuurin poistaminen käytöstä kätkee oireen ja jättää kokoonpanon, josta kukaan ei voi myöhemmin järkeillä.

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

Vahvista samalla kokotestillä, sitten sovelluksella, joka epäonnistui, ja tarkista toinen protokolla, koska UDP-sovellukset eivät koskaan saa TCP:n segmenttikoon korjausta. Pidä alkuperäiset arvot tiketissä, koska korjaus, jota ei voi peruuttaa, on toinen ongelma, joka odottaa tapahtumista. Jos kokotesti menee läpi ja lataus juuttuu yhä, musta aukko ei ollut syy, ja tutkinnan pitäisi jatkaa sen sijaan, että muutosta laajennetaan.