VPN MTU-mítoszok: miért zsugorodnak a csomagjaid, és hová megy a hely

Valaki azt mondja neked, hogy a VPN "MTU miatt veszít csomagokat", beállítod az alagutat 1400-ra, és az átvitel újra működik. Ez az eredmény diagnózisnak tűnik. Általában aritmetikai véletlen: olyan számot választottál, amely elég kicsi ahhoz, hogy beférjen egy határ alá, amelyet soha nem azonosítottál, és ugyanezzel a határral fogsz találkozni a következő hálózaton, más költségvetéssel.

Két mítosz okozza ennek a nagy részét. Az első, hogy az alagút interfészének MTU-ja az útvonal MTU-ja. A második, hogy a beágyazás "egy fejléc"-be kerül, a PPPoE pedig semmibe, amit érdemes számolni. Mindkettő olyan módon hamis, hogy a választott szám önkényesnek tűnik, holott valójában meghatározott.

Első mítosz: az alagút MTU-ja az útvonal MTU-ja

Az az érték, amelyet egy alagút-interfészen beállítasz, helyi ígéret a legnagyobb belső csomagról, amelyet a megvalósítás lefelé átad. Az útvonal valódi kapacitása a közted és a távoli vég között lévő minden szakasz tulajdonsága, és változhat, amikor egy útvonal változik, amikor egy mobil kapcsolat átadódik, vagy amikor a forgalom más peeringet vesz. A beállított 1500 azt mondja meg, mit épít a gazdagéped, nem azt, mit szállít a hálózat.

Az útvonal-MTU felderítése azért létezik, hogy összeegyeztesse a kettőt, és visszajelzéstől függ. IPv4-nél egy olyan útválasztónak, amely nem tud továbbítani egy teljes méretű csomagot, ICMP "fragmentation needed" üzenetet kellene küldenie, és a küldő csökkenti a becslését. IPv6-nál annak megfelelője egy Packet Too Big üzenet, és az útválasztók egyáltalán nem darabolják az átvitelt. Ha ezt a visszajelzést szűrik, a küldő továbbra is olyan csomagokat gyárt, amelyeket az útvonal nem tud szállítani, és semmi nem mondja meg neki, miért.

Második mítosz: a beágyazás egy fejlécbe kerül

Számold meg a külső rétegeket őszintén. A külső IP-fejléc 20 bájt IPv4-nél vagy 40 IPv6-nál. A NAT átjárásához szükséges UDP-beágyazás 8-at ad hozzá. Az alagút protokollja hozzáadja a saját fejlécét, egy inicializációs vektort vagy nonce-t, a titkosító blokk- vagy igazítási határáig tartó kitöltést, egy lezáró részt és egy integritás-ellenőrző értéket. A protokolltól és a titkosítástól függően az összeg kényelmesen több tíz bájt, mielőtt a belső csomag egyáltalán elkezdődik.

Utána ismét vond le a belső csomag saját fejléceit. Az alagúton belüli TCP-szegmens a saját 20 bájtos IP-fejlécét és 20 bájtos TCP-fejlécét hordozza, a TCP MSS-e pedig az MTU-ból származik, nem az alagút névleges hasznos terhéből. Ezért sikerülhet a ping kisebb terheléssel, miközben egy fájlátvitel elakad: az eszközök különböző dolgokat tesztelnek, és csak az egyikük gyakorol teljes méretű TCP-szegmenst.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Az első parancs a beállított alagút-MTU-t jelenti. A két próba 1472 bájtos terhelést küld, ami a 28 bájt IPv4 és ICMP fejléccel együtt 1500 bájtos csomag, majd egy kisebbet. Ha a nagy próba teljesen meghiúsul és a kicsi sikerül, méretfüggő hibád van, nem általános útválasztási probléma.

Harmadik mítosz: a PPPoE még mindig tiszta 1500-at ad

Egy hagyományos PPPoE hozzáférési szakasz nem szállít 1500 bájtos IP-csomagot. A PPPoE-fejléc és a PPP protokollmező 8 bájtot foglal az Ethernet-kereten belül, ami 1492-t hagy az IP-csomagnak. Ez az RFC 2516-ban leírt hagyományos határ. Ha VPN-t futtatsz egy ilyen szakaszon, az alagút többlete abból az 1492-ből jön, nem az 1500-ból.

Az RFC 4638 meghatározza, hogyan lehet nagyobb PPP-hasznos terhet tárgyalni, ha a hozzáférési koncentrátor és az ügyfél eszköze is támogatja, ezért az "ez a kapcsolat PPPoE-t használ" önmagában nem bizonyít konkrét számot. Egy helyi beállítás nem kényszeríthet egy köztes eszközt olyan csomag elfogadására, amelyre soha nem konfigurálták, tehát a hasznos kérdés az, mit tárgyalt valójában a szakasz, nem az, mit mond a címke.

Miért tűnik szelektívnek a hiba

A kis kérések sikeressége és a nagy átvitelek elakadása az útvonal-MTU fekete lyukának klasszikus jele. A kézfogás, a DNS-kérés és az API-hívás mind elfér; a tömeges átvitel teljes méretű szegmenseket hoz létre, amelyek egy szakaszon meghalnak, és az ICMP-üzenet, amelynek a problémát jelentenie kellett volna, soha nem érkezik meg. A kapcsolat rendben lévőnek tűnik, a letöltés pedig lóg, ami miatt az emberek az útvonal helyett a szervert nézik.

Egy második, kapcsolódó hiba három szám összekeverése: az interfész MTU-ja, a TCP MSS-e és a protokoll saját darabolási vagy kitöltési beállítása. Az MSS-clamping egy útválasztón átírja a meghirdetett MSS-t, hogy a küldő kisebb szegmenseket építsen; nem változtatja meg az alagút MTU-ját, és nem segít az UDP-forgalmon. Ha mindháromnak ugyanazt a számot adod, mert kapcsolódónak tűnnek, így töri el egy jó szándékú változtatás a működő beállítást.

Mit változtass, és milyen sorrendben

Kezdd bizonyítékkal. Erősítsd meg a fenti próbákkal, hogy a hiba méretfüggő, majd keresd meg a legkisebb méretet, amely átmegy, és a legnagyobbat, amely meghiúsul. Ellenőrizd a hozzáférési szakasz valódi MTU-ját, mielőtt az alagutat hibáztatnád; egy PPPoE-szakasz korlátozza a költségvetést, mielőtt a VPN hozzáér. Jegyezd fel az eredeti értékeket, hogy a változtatás visszafordítható legyen.

Utána alkalmazd a legkisebb módosítást, amelyet az ügyfél dokumentál. Sok ügyfél kínál alagút-MTU-t és MSS-javító opciót, és az MSS-opció gyakran jobb kar a TCP számára, mert minden csomag kicsinyítése nélkül éri el a küldőt. Teszteld újra ugyanazt a célt és ugyanazt az átvitelt, és jegyezd fel a számokat, amelyeknél maradtál. Az egy hálózaton működő alagútérték nem univerzális állandó, és a következő helynek saját költségvetése lesz.