Jumbo frames gör inte att en VPN-väg bär paket på 9000 byte

Du aktiverade 9000-byte frames på LAN:et och förväntade dig att VPN:en skulle bli snabbare. Den blev långsammare, eller slutade helt släppa igenom stora överföringar. Jumbo frames är en lokal länköverenskommelse; de förstorar inte vägen som tunneln korsar.

Den användbara budgeten bestäms av den minsta gränsen på vägen, inklusive den inkapsling som tunneln lägger till.

Vad jumbo frames faktiskt förändrar

En MTU är en egenskap hos ett gränssnitt. Att höja den på en server och dess switch innebär att de två kan utbyta större frames utan fragmentering. Det säger ingenting om routern bortom switchen, om leverantören eller om andra änden av en tunnel. De enheterna har sina egna gränser, och ett paket som överskrider en av dem slängs eller fragmenteras enligt regler du inte har satt.

Lokal överenskommelse, globala konsekvenser. Det är hela förvirringen.

Inkapslingsskatten

En tunnel lindar in ditt paket i ett annat. WireGuard över IPv4 UDP lägger till ungefär 60 byte overhead; OpenVPN:s UDP-läge ligger i samma intervall, och IPsec varierar med läge och algoritmer. De byten kommer från den yttre vägens budget, inte från ingenstans.

Så en yttre länk på 1500 byte kan inte bära ett inre paket på 1500 byte när en tunnelhuvud har lagts till.

Räkningen är värd att göra en gång. På en väg på 1500 byte vill ett WireGuard-gränssnitt ha en MTU runt 1420 så att det inkapslade paketet får plats. Sätt det inre gränssnittet till 9000, och varje stort paket behöver fragmentering som tunneln inte kan göra, eller slängs.

Hitta den minsta länken på vägen

Gå igenom vägen och hitta den lägsta MTU:n. LAN:et är oftast 1500 eller 9000, WAN:et oftast 1500, och en mobil- eller PPP-länk kan vara ännu lägre. Dra sedan av tunnelns overhead. Är resultatet mindre än det inre gränssnittets MTU har du svaret. Sökning efter vägens MTU kan hitta detta automatiskt, men bara när ICMP-meddelandena den är beroende av släpps igenom.

Filtrerad ICMP är den klassiska orsaken till att en stor överföring hänger medan små förfrågningar fungerar fint.

Testa storleksberoende utan att bredda ändringen

Använd en representativ överföring och spara de ursprungliga värdena så att du kan sätta tillbaka dem. ping -M do -s 1472 testar ett paket på 1500 byte med DF-biten satt; minska storleken tills det går igenom. Om bara stora paket misslyckas har du ett storleksproblem och inte ett routingproblem.

Se upp för offload på värdsidan när du läser fångster. Segmenteringsoffload kan visa frames långt större än det som faktiskt gick över kabeln, vilket får en fungerande väg att se trasig ut och en trasig att se bra ut.

När en stor MTU är rätt design

Ett kontrollerat privat nät kan legitimt köra större frames från ände till ände, förutsatt att varje enhet på vägen är överens och att tunnelns overhead räknas in. Det är en samordnad design med ett dokumenterat värde per länk, inte ett stort tal som skrivs in i en klient.

För en vanlig offentlig utgång, anta 1500 eller mindre och låt tunneln välja en säker inre MTU. RFC 8201 täcker sökning efter vägens MTU för IPv6-fallet och är en användbar referens för hur återkopplingen ska fungera.