Jumbo-rammer gjer ikkje at ei VPN-rute ber pakkar på 9000 byte

Du slo på 9000-byte-rammer på LAN-et og venta at VPN-en skulle bli raskare. Han vart seinare, eller slutta heilt å sleppe gjennom store overføringar. Jumbo-rammer er ein lokal lenkeavtale; dei utvidar ikkje vegen tunnelen kryssar.

Det brukbare budsjettet blir sett av den minste grensa på ruta, inkludert innkapslinga tunnelen legg til.

Kva jumbo-rammer faktisk endrar

Ein MTU er ein eigenskap ved eitt grensesnitt. Å heve han på ein tenar og svitsjen hans tyder at dei to kan utveksle større rammer utan fragmentering. Det seier ingenting om rutaren bak svitsjen, om leverandøren eller om den andre enden av ein tunnel. Desse einingane har sine eigne grenser, og ein pakke som går over ei av dei, blir kasta eller fragmentert etter reglar du ikkje har sett.

Lokal avtale, globale følgjer. Det er heile forvirringa.

Innkapslingsavgifta

Ein tunnel pakkar pakken din inn i ein annan. WireGuard over IPv4 UDP legg til om lag 60 byte overhead; UDP-modusen til OpenVPN ligg i same område, og IPsec varierer med modus og algoritmar. Desse byta kjem frå budsjettet til den ytre vegen, ikkje frå lause lufta.

Så ei ytre lenke på 1500 byte kan ikkje bera ein indre pakke på 1500 byte når ein tunnelheader er lagd til.

Reknestykket er verd å gjere éin gong. På ein veg på 1500 byte vil eit WireGuard-grensesnitt ha ein MTU kring 1420 slik at den innkapsla pakken får plass. Set det indre grensesnittet til 9000, og kvar stor pakke treng fragmentering som tunnelen ikkje kan gjere, eller blir kasta.

Finn den minste lenka på ruta

Gå ruta gjennom og finn den lågaste MTU-en. LAN-et er vanlegvis 1500 eller 9000, WAN-et vanlegvis 1500, og ei mobil- eller PPP-lenke kan vere endå lågare. Trekk så frå tunneloverheaden. Er resultatet mindre enn MTU-en til det indre grensesnittet, har du svaret. Oppdaging av banens MTU kan finne dette automatisk, men berre når ICMP-meldingane han er avhengig av, blir sleppte gjennom.

Filtrert ICMP er den klassiske grunnen til at ein stor overføring heng medan små førespurnader fungerer fint.

Test storleiksavhengnad utan å utvide endringa

Bruk ein representativ overføring og ta vare på dei opphavlege verdiane så du kan setje dei tilbake. ping -M do -s 1472 testar ein pakke på 1500 byte med DF-biten sett; reduser storleiken til han går gjennom. Viss berre store pakkar feilar, har du eit storleiksproblem og ikkje eit rutingsproblem.

Ver merksam på offload på vertssida når du les opptak. Segmenteringsoffload kan vise rammer langt større enn det som faktisk gjekk over leidninga, noko som får ein fungerande veg til å sjå øydelagd ut og ein øydelagd veg til å sjå fin ut.

Når ein stor MTU er rett design

Eit kontrollert privat nettverk kan legitimt køyre større rammer ende til ende, føresett at kvar eining på ruta er samd og at tunneloverheaden er rekna med. Det er eit koordinert design med ein dokumentert verdi per lenke, ikkje eitt stort tal skrive inn i ein klient.

For ein vanleg offentleg utgang, rekn med 1500 eller mindre og la tunnelen velje ein trygg indre MTU. RFC 8201 dekkjer oppdaging av banens MTU for IPv6-tilfellet og er ei nyttig tilvising for korleis tilbakemeldinga skal fungere.