Útvonal-MTU felderítés VPN-en át: méretezés és az ICMP-rés

Egy alagút befejezi a kézfogást, a kis kérések visszatérnek, és az első nagy átvitel elakad. Ez a minta jóval korábban mutat az útvonal-MTU-ra, mint az áteresztőképességre. Az útvonal minden láncszeme korlátozza a csomagméretet, és a beágyazás ennek a keretnek egy részét külső fejlécekre költi, ezért a belső csomagnak kisebbnek kell lennie, mint amit a nyers útvonal sugallna. A hiba csendes, és éppen ezért drága diagnosztizálni.

Mit mér valójában az útvonal-MTU

Az útvonal-MTU a két gazdagép közötti útvonal legkisebb láncszem-MTU-ja, nem a helyi interfészre nyomtatott MTU. A helyi érték az a pont, ahol a becslés elkezdődik, és az útvonal dönti el, hol kell végződnie. Ezért működhet ugyanaz az alagút az egyik hozzáférési hálózaton, és akadhat el egy másikon: az útvonal változott meg, nem a konfiguráció. Egyszer mérni és mindenhol feltételezni az a hiba, amely életben tartja ezt a problémát.

Egy alagútnál a számító szám a belső MTU, amely a külső útvonal kerete mínusz az, amit a beágyazás felemészt. A WireGuard külső IP-fejléket és UDP-fejléket ad hozzá; más átvitelek a sajátjukat. Állítsa túl magasra a belső méretet, és minden teljes méretű csomaghoz töredezés kell, amely talán soha nem történik meg.

Miért csökkenti az alagút a hasznos csomagot

Ha az alagút interfésze megtartja a fizikai lánc MTU-ját, minden nagy csomag attól függ, hogy valaki lejjebb hajlandó-e töredezni. Az IPv4 ezt elvben engedi, de az a router, amelynek azt mondták, hogy ne töredezzen, inkább hibát ad vissza. Az IPv6-routerek átvitel közben egyáltalán nem töredeznek, ezért ugyanaz a beállítás címcsaládonként másképp viselkedik. Akárhogy is, a küldő semmit sem tanul, amíg valami vissza nem jelent.

A gyakorlati következmény egy olyan méret, amely belefér a kézfogásba, de a hasznos terhelésbe nem. Egy TLS ClientHello vagy egy DNS-lekérdezés elég kicsi ahhoz, hogy érintetlenül átkeljen egy összezsugorodott útvonalon, egy tömeges átvitel viszont nem. Ezért a tünetek konkrét műveletek köré csoportosulnak, nem konkrét gazdagépek köré.

A felderítés csak akkor működik, ha a visszajelzés megérkezik

Az IPv4-felderítés a don't-fragment bitre támaszkodik: az a router, amely nem tudja továbbítani a csomagot, ICMP fragmentation-needed üzenetet ad vissza a következő ugrás MTU-jával, és a küldő csökkenti a becslését. Az IPv6 ehelyett Packet Too Big üzeneteket használ, mert a routerek átvitel közben nem töredeznek. Mindkét mechanizmus feltételezi, hogy az üzenet megtalálja az utat vissza a küldőhöz, az alagúton keresztül és a visszaúton lévő bármely tűzfalon túl. Amikor ez a feltevés megbukik, a küldő tovább próbálkozik egy olyan mérettel, amelyet az útvonal nem tud hordozni.

Egy olyan tűzfal, amely engedi az echo request és echo reply üzeneteket, nem feltétlenül engedte meg ezeket a hibatípusokat. Az ICMP egy család, és itt a hibák a fontos tagok, nem az echo pár. Ellenőrizze a vezérlőforgalom szabályzatát az alagút mindkét végén és a köztük lévő útvonalon, és kövesse a platform támogatott útmutatását ahelyett, hogy mindenhol minden ICMP-típust engedélyezne.

Ugyanez a szűrés az alagúton belül is lehet. Ha a belső útvonal eldobja a hibát, de a külső útvonal továbbítja, a küldő olyan korláthoz alkalmazkodhat, amelyet a beágyazott forgalom valójában soha nem lát.

Vizsgálja az útvonalat a szám tippelése helyett

Tartsa rögzítve a célt, a hozzáférési hálózatot és az alagutat, majd csak a csomagméretet változtassa. Egy don't-fragment vizsgálat, amely MTU-jelzéssel bukik meg, megadja a következő ugrás korlátját; ismételje, amíg egy méret átmegy, és jegyezze fel a méretet és a címcsaládot is.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Egy beleférő ping nem bizonyítja, hogy egy valódi alkalmazás teljes méretű szegmensei is beleférnek, ezért ismételje meg a tesztet a ténylegesen meghibásodott átvitellel. Hasonlítsa össze a legnagyobb működő vizsgálatot a beállított alagút-MTU-val, és tartsa a két számot külön a jegyzeteiben. Ha nagyjából egy fejlécnyi különbség van, akkor a beágyazási többletet találta meg, nem hibát.

A PLPMTUD, amelyet a RFC 4821 ír le, felfelé vizsgál, és átviteli nyugtákat használ a kézbesített hibákra való hagyatkozás helyett. Segít az ICMP-t szűrő útvonalakon, de a támogatás stackenként és alkalmazásonként változik. Egy TCP-folyam magától helyreállhat, míg egy rögzített adatgramméretű UDP-alkalmazás folyamatosan meghibásodik.

Válasszon értéket, és jegyezze fel az indoklást

Az alagút-MTU csökkentése egyszerre diagnózis és legitim javítás, ha már ismeri az útvonalat. Nem helyettesíti annak ismeretét, hogy melyik útvonal és melyik visszajelzési mechanizmus volt érintett, mert a mobil láncszemhez hangolt érték szükségtelenül kicsi lesz egy száloptikai kapcsolaton. Jegyezze fel a választott méretet, az azt igazoló vizsgálatot és a visszaállítás lépését.

Az IPv4-mechanizmust a RFC 1191 írja le, az IPv6 csomagolási útmutatást pedig a RFC 8201; mindkettő megnevezése megkíméli a következő mérnököt attól, hogy újra levezesse a feltevést. Ha az átvitel a választott méreten még mindig elakad, hagyja abba a szám csökkentését, és nézze a következő réteget. Az az útvonal, amely minden méreten meghibásodik, nem MTU-probléma.