OpenVPN na PPPoE: snížit link-mtu, tun-mtu, nebo mssfix?

Ping odpovídá, DNS se překládá a každá stránka, která potřebuje segment plné velikosti, se zasekne. Na lince, která přidává vlastní zapouzdření, cesta tiše ztrácí několik desítek bajtů rozpočtu a profil napsaný pro čistý Ethernet dál žádá pakety, které linka neunese. Spojení není pomalé; zahazuje právě ty pakety, na kterých záleží.

Tři možnosti to mohou opravit a pracují v různých vrstvách. Výběr špatné buď nic neudělá, nebo udělá tunel křehkým novým způsobem, takže volba začíná tím, co cesta skutečně podporuje.

Tři knoflíky, tři různé vrstvy

link-mtu je vnější rozpočet: zašifrovaný obsah plus hlavička OpenVPN, hlavička UDP a vnější hlavička IP. Popisuje, co opouští stroj, a proto je to číslo, které fyzická cesta omezuje.

tun-mtu je vnitřní rozpočet: rozhraní, které váš provoz vidí. Je větší než to, co cesta unese, přesně o režii tunelu, a OpenVPN ho obvykle odvozuje, místo aby vás nutil ho nastavit.

mssfix je úplně jiný mechanismus. Přepisuje maximální velikost segmentu oznámenou během TCP handshake, aby partneři TCP volili segmenty, které se po zapouzdření vejdou. Nemění MTU rozhraní a na UDP nemá žádný vliv.

Pokud link-mtu nastavíte explicitně, OpenVPN odečte vlastní režii, aby odvodil vnitřní MTU. Tato režie není pevná konstanta; závisí na šifře a autentizaci, a proto hodnota zkopírovaná z přís pěvku na fóru může být na jiném profilu špatná. Nastavení link-mtu i tun-mtu zároveň dává klientovi dva protichůdné pokyny.

Změřte cestu, než zvolíte jakékoli číslo

Měřte z fyzického rozhraní, ne zevnitř tunelu, a pamatujte, že ping hlásí obsah, ne velikost paketu. Před porovnáním obsahu s rámcem o 1500 bajtech přičtěte 28 bajtů za hlavičky IPv4 a ICMP a mějte tuto korekci na paměti, když partner ohlásí jiné číslo.

Na linuxovém klientu ping -M do -s 1472 zakazuje fragmentaci a selže, pokud je paket příliš velký. Snižujte obsah, dokud neprojde, pak přičtěte 28, abyste dostali MTU cesty. PPPoE stojí 8 bajtů, takže 1492 je na DSL běžné. DS-Lite a některé mobilní cesty stojí 40 nebo více a odpověď bývá nižší, než naznačuje nominální rychlost linky.

Pokud každá velikost pingu uspěje, ale velké přenosy stále zamrzají, podezírejte černou díru, ne prostý limit velikosti. Zpráva ICMP o potřebě fragmentace se někde na cestě filtruje, takže odesílatel se nikdy nedozví, že se má zmenšit, a všimnou si toho jen toky, které potřebují velký segment.

Nejdřív sevřete TCP, potom zmenšete tunel

TCP handshake je jediné, čeho se mssfix dotýká, což z něj obvykle dělá nejméně rušivý ovládací prvek, který je vhodné zkusit první. Nastavte ho trochu pod skutečný rozpočet cesty, pošlete stejnou hodnotu ze serveru, aby se oba konce shodly, a znovu otestujte velké stahování. Pokud zaseknutí zmizí, problém byl ve velikosti TCP segmentu a nic jiného měnit netřeba.

Snižte vnitřní MTU, když postižený provoz není TCP. Služba UDP, tunel v tunelu nebo aplikace, která posílá datagramy plné velikosti, budou po sevření MSS dál selhávat, protože nic nepřepisuje velikost jejich paketu. Pro takový případ snižte tun-mtu, nebo nastavte link-mtu a nechte klienta odvodit vnitřní hodnotu, ale nikdy obojí.

Nesahajte po staré možnosti fragmentace. Dělila pakety uvnitř tunelu, přidávala režii a byla opuštěna z dobrých důvodů; moderní OpenVPN očekává, že cesta bude místo toho popsána přesně.

Proč malé sondy stále fungují

DNS dotazy, ICMP ozvěny a TCP handshaky jsou hluboko pod velikostí, při které to selhává. Tunel proto v každém rychlém testu vypadá zdravě, zatímco TLS handshaky a odpovědi HTTP tiše selhávají. Tahle kombinace, fungující traceroute a prohlížeč, který se zasekne na první velké odpovědi, je signatura, kterou je třeba hledat. Než sáhnete po novém profilu, sáhněte po sondě plné velikosti.

Ověřte to provozem, který selhal. Načtěte velkou stránku, pošlete datagram UDP plné velikosti, pokud je to postižená služba, a zopakujte to z druhého klienta na jiné lince. Zapište naměřené MTU cesty a zvolenou hodnotu, protože další člověk, který se profilu dotkne, bude číslo jinak považovat za libovolné.

Nikdy nesnižujte vnitřní MTU pod 1280, když tunelem prochází IPv6, protože to je minimum, které musí každé IPv6 spojení unést. Menší MTU je fakt o cestě, ne nastavení výkonu, které se ladí pocitem.