MTU fekete lyuk: miért működnek a kis kérések, de a feltöltések elakadnak

Egy oldal betöltődik, egy kis API-hívás visszatér, majd egy fájlfeltöltés lóg, amíg az ügyfél fel nem adja. A kiszolgáló naplójában semmi nem magyarázza, mert a csomagokat az útvonal közepén dobták el anélkül, hogy hasznos válasz ment volna vissza. Ez a minta egy MTU fekete lyuk: a küldő által feltételezettnél keskenyebb kapcsolat, plusz a csendes elzárkózás annak kimondásától. A meghiúsuló méret megismételhető, és ez teszi diagnosztizálhatóvá.

Mitől lesz a lyuk fekete

Minden kapcsolatnak van maximális átviteli egysége, és a következő ugrás korlátjánál nagyobb csomagot vagy fel kell darabolni, vagy el kell utasítani egy ezt kimondó ICMP-üzenettel. Az útvonal MTU-felderítése attól függ, hogy ez az üzenet megérkezik és tiszteletben tartják. Kiszűrése vagy figyelmen kívül hagyása a küldőt arra készteti, hogy egy soha be nem férő csomagot ismételgessen.

A beágyazás ezt gyakorivá teszi a VPN-ek körül, mert az alagút egy külső fejlécet ad ahhoz a csomaghoz, amelyet már a fizikai kapcsolathoz méreteztek. A belső csomag 1500 bájtnál legális, a beágyazott nem, ezért a határon meghal, míg a kis csomagok átcsúsznak. Egy befejezett kézfogás és egy működő bejelentkező oldal csak azt bizonyítja, hogy a kis csomagok működnek. Az alkalmazás által küldeni próbált legnagyobb csomag az, amely számít.

Keresd meg a méretet, ahol eltörik

Keresd meg binárisan a hasznos teher méretét egy darabolásmentes teszttel, az alagút egyik oldalán lévő gazdagéptől a másik oldalin lévőig. A legnagyobb átmenő hasznos teher a használható útvonal-MTU mínusz a fejléc többlete.

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

Egy 1472 bájtos hasznos teher átmegy egy tiszta 1500 bájtos Ethernet-útvonalon, ha hozzáadjuk az IPv4- és ICMP-fejlécek 28 bájtját. Ha ugyanaz a teszt csak kisebb hasznos tehernél sikerül az alagút felállása után, a különbség a beágyazási többlet, és az alagút határa az a hely, ahol az elutasítási üzenetnek keletkeznie kellett volna. Jegyezd fel mindkét számot, csatlakozás előtt és után, mert ez a pár a bizonyíték. Ismételd meg a tesztet IPv6-ra, ha az alkalmazás használja, mivel a fejléc nagyobb, és a hiba küszöbe elmozdul.

Olvasd el a bizonyítékokat, mielőtt az alagutat hibáztatod

A távoli alkalmazások hibái, a torlódás és a szokásos veszteség is elakasztja a feltöltéseket, ezért egyetlen sikertelen átvitel nem azonosít fekete lyukat. Az különbözteti meg őket, hogy milyen a méretviszony: ismételhető siker 1200 bájtnál és ismételhető elakadás 1400 bájtnál, ugyanabban az irányban, ugyanazon a végponton át.

Mindkét végén végzett rögzítés azt mutatja, hogy a nagy csomagok elindulnak és soha nem érkeznek meg, köztük nincs elutasítás. Ez az a pillanat, amikor a kiszolgáló helyett a határeszközt kell nézni, amely minden ténylegesen megkapott kérésre válaszol. A torlódás is elakaszt, de különböző méreteket különböző időpontokban, ami más aláírás.

Ellenőrizd a javítást mindkét átvitelen

A támogatott javítás az, hogy a határ jelentse a valódi korlátot, vagy ott szorítsuk meg a TCP maximális szegmensméretét, hogy semmilyen túlméretes szegmens ne legyen megkísérelve. A hálózat minden MTU-jának csökkentése vagy a tűzfal kikapcsolása elrejti a tünetet, és olyan konfigurációt hagy, amelyről később senki nem tud okoskodni.

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

Ellenőrizd ugyanazzal a méretteszttel, majd azzal az alkalmazással, amelyik meghiúsult, és ellenőrizz egy második protokollt is, mert az UDP-alkalmazások soha nem kapják meg a TCP szegmensméret-korrekcióját. Őrizd meg az eredeti értékeket a jegyben, mert a vissza nem fordítható javítás egy második probléma, amely arra vár, hogy bekövetkezzen. Ha a méretteszt átmegy, és a feltöltés továbbra is elakad, akkor nem a fekete lyuk volt az ok, és a vizsgálatnak tovább kell mennie ahelyett, hogy kiterjesztené a változtatást.