Engedélyezte a 9000 bájtos kereteket a LAN-on, és azt várta, hogy a VPN gyorsabb lesz. Lassabb lett, vagy teljesen abbahagyta a nagy átvitelek átengedését. A jumbo keretek helyi kapcsolati megállapodás; nem tágítják azt az útvonalat, amelyet az alagút átszel.

A használható keretet az útvonal legkisebb határa határozza meg, beleértve az alagút által hozzáadott beágyazást is.

Mit változtatnak valójában a jumbo keretek

Az MTU egyetlen interfész tulajdonsága. Ha egy kiszolgálón és annak kapcsolóján megemeli, az azt jelenti, hogy ez a kettő nagyobb kereteket is cserélhet töredezés nélkül. Ez semmit sem mond a kapcsoló utáni routerről, a szolgáltatóról vagy az alagút túlsó végéről. Ezeknek az eszközöknek megvannak a saját korlátaik, és az a csomag, amely túllépi valamelyiket, az Ön által nem beállított szabályok szerint eldobódik vagy töredezik.

Helyi megállapodás, globális következmények. Ez a teljes zavar.

A beágyazási adó

Az alagút becsomagolja a csomagot egy másikba. A WireGuard IPv4 UDP felett körülbelül 60 bájt többletet ad; az OpenVPN UDP módja ugyanebben a tartományban van, az IPsec pedig módtól és algoritmusoktól függően változik. Ezek a bájtok a külső útvonal keretéből jönnek, nem a semmiből.

Így egy 1500 bájtos külső kapcsolat nem tud 1500 bájtos belső csomagot szállítani, ha hozzáadják az alagút fejlécét.

Érdemes egyszer kiszámolni. Egy 1500 bájtos útvonalon a WireGuard interfész MTU-ja körülbelül 1420 legyen, hogy a beágyazott csomag beférjen. Állítsa a belső interfészt 9000-re, és minden nagy csomaghoz olyan töredezés kell, amelyet az alagút nem tud elvégezni, vagy pedig eldobják.

Keresse meg az útvonal legkisebb kapcsolatát

Járja végig az útvonalat, és keresse meg a legalacsonyabb MTU-t. A LAN általában 1500 vagy 9000, a WAN általában 1500, és egy mobil- vagy PPP-kapcsolat még ennél is alacsonyabb lehet. Ezután vonja le az alagút többletét. Ha az eredmény kisebb, mint a belső interfész MTU-ja, megvan a válasz. Az útvonal-MTU felderítés ezt automatikusan megtalálhatja, de csak ha az ehhez szükséges ICMP-üzeneteket átengedik.

A szűrt ICMP a klasszikus oka annak, hogy egy nagy átvitel elakad, miközben a kis kérések szépen működnek.

Tesztelje a méretfüggést a változtatás kiszélesítése nélkül

Használjon reprezentatív átvitelt, és őrizze meg az eredeti értékeket, hogy vissza tudja állítani őket. ping -M do -s 1472 egy 1500 bájtos csomagot próbál beállított DF-bittel; csökkentse a méretet, amíg át nem megy. Ha csak a nagy csomagok hibáznak, méret- és nem útvonalválasztási problémája van.

Óvakodjon a hosztoldali offloadtól a felvételek olvasásakor. A szegmentálási offload sokkal nagyobb kereteket mutathat annál, mint ami valóban átment a vezetéken, amitől egy működő útvonal töröttnek, egy törött pedig rendben lévőnek látszik.

Mikor megfelelő tervezés a nagy MTU

Egy ellenőrzött magánhálózat jogszerűen futtathat nagyobb kereteket végponttól végpontig, feltéve, hogy az útvonal minden eszköze egyetért, és az alagút többletét beszámítják. Ez koordinált tervezés, kapcsolatonként dokumentált értékkel, nem egyetlen nagy szám, amelyet egy kliensbe begépeltek.

Egy közönséges nyilvános kijáratnál tételezzen fel 1500-at vagy kevesebbet, és hagyja, hogy az alagút biztonságos belső MTU-t válasszon. RFC 8201 az IPv6 eset útvonal-MTU felderítését tárgyalja, és hasznos hivatkozás arra nézve, hogyan kellene a visszajelzésnek működnie.

Kapcsolódó cikkek