OpenVPN PPPoE-n: csökkentsük a link-mtu, tun-mtu vagy mssfix értékét?

A pingek válaszolnak, a DNS felold, és minden oldal, amely teljes méretű szegmenst igényel, lefagy. Olyan kapcsolaton, amely saját beágyazást ad hozzá, az útvonal csendesen elveszít néhány tucat bájtot a keretből, és a tiszta Ethernetre írt profil továbbra is olyan csomagokat kér, amelyeket a vonal nem tud elvinni. A kapcsolat nem lassú; pontosan azokat a csomagokat dobja el, amelyek számítanak.

Három lehetőség orvosolhatja ezt, és különböző rétegeken hatnak. A rossz választás vagy semmit nem tesz, vagy új módon teszi törékennyé az alagutat, ezért a döntés azzal kezdődik, amit az útvonal valóban támogat.

Három gomb, három különböző réteg

link-mtu a külső keret: a titkosított hasznos teher plusz az OpenVPN fejléc, az UDP fejléc és a külső IP fejléc. Azt írja le, mi hagyja el a gépet, és ezért ez az a szám, amelyet a fizikai útvonal korlátoz.

tun-mtu a belső keret: az az interfész, amelyet a forgalom lát. Pontosan az alagút többletével nagyobb annál, mint amit az útvonal el tud vinni, és az OpenVPN rendszerint származtatja, ahelyett hogy beállításra kényszerítené.

mssfix teljesen más mechanizmus. Átírja a TCP-kézfogások során bejelentett maximális szegmensméretet, hogy a TCP-partnerek olyan szegmenseket válasszanak, amelyek a beágyazás után elférnek. Nem változtatja meg az interfész MTU-ját, és nincs hatása az UDP-re.

Ha kifejezetten beállítja a link-mtu értéket, az OpenVPN levonja a saját többletét a belső MTU származtatásához. Ez a többlet nem rögzített állandó; a titkosítástól és a hitelesítéstől függ, ezért egy fórumból másolt érték hibás lehet egy másik profilban. Ha mind a link-mtu, mind a tun-mtu értéket beállítja, két ellentmondó utasítást ad az ügyfélnek.

Mérje meg az útvonalat, mielőtt bármilyen számot választ

A fizikai interfésztől mérjen, ne az alagút belsejéből, és ne feledje, hogy a ping a hasznos terhet jelenti, nem a csomagméretet. Adjon hozzá 28 bájtot az IPv4- és ICMP-fejlécekhez, mielőtt a hasznos terhet egy 1500 bájtos kerethez hasonlítja, és tartsa szem előtt ezt a korrekciót, amikor egy partner más számot jelent.

Linux-ügyfélen a ping -M do -s 1472 megtiltja a töredezést, és meghiúsul, ha a csomag túl nagy. Csökkentse a hasznos terhet, amíg át nem megy, majd adjon hozzá 28-at az útvonal MTU-jának megkapásához. A PPPoE 8 bájtba kerül, ezért a DSL-en az 1492 normális. A DS-Lite és egyes mobil útvonalak 40 vagy több bájtba kerülnek, és a válasz általában alacsonyabb, mint amit a névleges kapcsolati sebesség sugall.

Ha minden pingméret sikerül, de a nagy átvitelek továbbra is elakadnak, fekete lyukat gyanítson egyszerű méretkorlát helyett. A szükséges töredezésről szóló ICMP-üzenetet valahol az útvonalon szűrik, így a küldő soha nem tanul meg csökkenteni, és csak azok az adatfolyamok veszik észre, amelyeknek nagy szegmensre van szükségük.

Először a TCP-t korlátozza, utána zsugorítsa az alagutat

A TCP-kézfogások az egyetlen dolog, amelyhez mssfix hozzányúl, ezért ez általában a legkevésbé zavaró vezérlő, amelyet először érdemes kipróbálni. Állítsa valamivel az útvonal valódi kerete alá, tolja ugyanazt az értéket a szerverről, hogy mindkét vég egyetértsen, és tesztelje újra a nagy letöltést. Ha az elakadás megszűnik, a probléma a TCP szegmensméret volt, és semmi mást nem kell megváltoztatni.

Csökkentse a belső MTU-t, ha az érintett forgalom nem TCP. Egy UDP-szolgáltatás, az alagúton belüli alagút vagy egy teljes méretű adatgramokat küldő alkalmazás az MSS-korlátozás után is meghiúsul, mert semmi nem írja át a csomagméretét. Ebben az esetben csökkentse a tun-mtu értéket, vagy állítsa be a link-mtu értéket, és hagyja, hogy az ügyfél származtassa a belső értéket, de soha ne mindkettőt.

Ne nyúljon a régi töredezési opcióhoz. Az alagúton belül osztotta fel a csomagokat, többletet adott hozzá, és jó okokból elavult; a modern OpenVPN az útvonal pontos leírását várja.

Miért működnek továbbra is a kis próbák

A DNS-lekérdezések, az ICMP-visszhangok és a TCP-kézfogások mind messze a meghiúsuló méret alatt vannak. Az alagút ezért minden gyors tesztben egészségesnek látszik, miközben a TLS-kézfogások és a HTTP-válaszok csendesen meghiúsulnak. Pontosan ez a kombináció, egy működő traceroute és egy böngésző, amely az első nagy válasznál elakad, az a jel, amelyet keresni kell. Nyúljon teljes méretű próbához, mielőtt új profilhoz nyúl.

Ellenőrizze azzal a forgalommal, amely meghiúsult. Töltsön be egy nagy oldalt, küldjön teljes méretű UDP-adatgramot, ha az az érintett szolgáltatás, és ismételje meg egy második ügyféltől egy másik kapcsolaton. Jegyezze fel a mért útvonal-MTU-t és a választott értéket, mert különben a következő ember, aki a profilhoz nyúl, önkényesnek tekinti a számot.

Soha ne vigye a belső MTU-t 1280 alá, amikor az IPv6 az alagúton fut, mert ez az a minimum, amelyet minden IPv6-kapcsolatnak el kell vinnie. A kisebb MTU tény az útvonalról, nem teljesítménybeállítás, amelyet érzésre kell hangolni.