MTU útvonalanként Linuxon: három méretszabályzó, egy útvonal

Három beállítás egy Linux-kliensen mindegyike úgy hangzik, hogy „csináld kisebbre a csomagokat”, és különböző rétegeken hatnak. Az interfész MTU korlátozza az eszköz által küldött minden csomagot. Egy útvonal MTU-ja korlátozza azokat a csomagokat, amelyek ezt az útvonalat használják, és ez gyakran pont az, amit egy VPN-célhoz valóban szeretnél. A TCP MSS korlát megváltoztatja, miről állapodik meg a két végpont, és az UDP-vel semmit nem tesz.

Három szabályzó, amely ugyanannak a gombnak látszik

Tedd őket egymás mellé, mielőtt választasz, mert a rossz sor kiválasztása magyarázza a legtöbb nem működő tanácsot:

Az Ethernet MTU csökkentése az egész gépre ennek a javításnak a nyers változata. Működik, és minden más alkalmazást is büntet a gazdagépen, azokat is, amelyeknek az útvonalai rendben voltak. Az útvonalankénti érték ugyanazt a szándékot fejezi ki a mellékköltség nélkül.

Az összehasonlítás csak a gazdagép által generált forgalomra érvényes. Egy csomag továbbítása másik kliensnek annak saját útvonalát és az alagút külső keretét érinti, és egy útvonal-metrika ezen a gazdagépen nem ér át ezen a határon.

Csatold a keretet ahhoz az útvonalhoz, amely megnyeri a keresést

Egy szemléltető IPv4 útvonalrekord így néz ki:

ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380

A rekordot szándékleírásként olvasd, ne beillesztendő értékként. Az előtag, az eszköz és az előnyben részesített forrás feleljen meg a valódi konfigurációnak, és a számnak a beágyazott útvonalra vonatkozó bizonyítékból kell jönnie, nem blogbejegyzésből. Az útvonal MTU-ja a belső IP-csomagot korlátozza, ami nem ugyanaz, mint egy 1380 bájtos TCP-terhelés vagy egy 1380 bájtos titkosított külső csomag.

Nézd meg, hol oldódik meg valójában a keresés, mielőtt bármit hozzáadnál. Egy házirend-szabályokkal rendelkező gazdagép egy adott célt más táblán keresztül is irányíthat, mint a main, és az a metrika, amely csak a main táblában létezik, láthatatlan annak a kérésnek. Hasonlítsd össze ip -4 route show table all a válaszával ip route get, beleértve a jelölés vagy névtér kontextusát, amikor a szabályok használják őket. Ha a kettő nem egyezik, a válaszoló tábla az, amelyiknek a metrikára szüksége van, nem az, amelyik rendezettebbnek látszik.

az mtu nem mtu lock

Alapértelmezésben a kernel továbbra is frissítheti az útvonal MTU-ját ICMP-visszajelzésből, erre való az útvonal-MTU felderítés. A lock hozzáadása ezt leállítja. Ez más döntés, nem ugyanannak a számnak az erősebb megőrzése, és IPv4 esetén megváltoztatja a „ne darabold” bit dokumentált kezelését.

A zárolás akkor ésszerű, ha megmérted az útvonalat, és azt szeretnéd, hogy az érték attól függetlenül maradjon, hogy mi érkezik. Rossz alapértelmezés, ha a hálózat jogos méret-visszajelzést küld, mert a kernel már nem tud alkalmazkodni, és a hiba más tünetbe kerül.

Ha az ICMP valahol az útvonalon szűrve van, egyetlen útvonal-beállítás sem javítja meg. A javítás a szűrőhöz tartozik, a kisebb MTU pedig kerülőút, amely elrejti a valódi hibát a következő útvonalváltozásig.

Az alagút-szoftver saját méretszabályzókat ad hozzá

OpenVPN- mssfix a dokumentált UDP-alagút-esetéhez igazítja a TCP-szegmens méretét. A TCP-beszélgetésen hat, tehát nem az operációs rendszer útvonal-MTU-jának másik írásmódja, és nem tud segíteni egy UDP-szolgáltatáson, amely figyelmen kívül hagyja az egyeztetést.

Ne halmozz egy útvonal-MTU-t, egy interfész-MTU-változtatást és egy MSS-korlátot ugyanabba a változtatási ablakba. Ha a probléma eltűnik, nem tudod, melyik számított, és a megtartottak évekig korlátozzák a forgalmat anélkül, hogy bárki emlékezne az okra.

Tedd visszafordíthatóvá, aztán bizonyítsd

Az útvonal igazi tulajdonosa dönti el, hogy a változtatás túléli-e az újracsatlakozást. Egy VPN-kliens, amely dinamikusan telepíti az útvonalat, általában a metrikád nélkül építi újra, és egy kézi ip route add utána úgy néz ki, mint egy javítás, amely egy nappal később elbukott. Tedd az értéket a kezelő konfigurációjába, és ha ideiglenes kísérletre van szükséged, először jegyezd fel az eredeti útvonalat.

Tesztelj egy új kapcsolattal, amely végrehajtja az elakadt műveletet, majd erősítsd meg, hogy a szándékolt privát útvonal továbbra is nyer, és a nem kapcsolódó célok változatlanok. Csatlakoztasd újra az alagutat, és olvasd ki újra az útvonalat, mert az újracsatlakozáskor eltűnő érték nem javítás.

Ha a bizonyítékok nem támasztják alá a változtatást, távolítsd el a felülírást a kezelőjén keresztül, és állítsd vissza az eredeti útvonal-attribútumokat az útvonal törlése helyett. Ezután jegyezd fel, mit mértél és melyik útvonalon, hogy a következő ember meg tudja különböztetni a valódi javulást a futni hagyott kísérlettől.