Jumbo-rammer gjør ikke at en VPN-rute bærer pakker på 9000 byte

Du aktiverte 9000-byte rammer på LAN-et og forventet at VPN-en skulle bli raskere. Den ble langsommere, eller sluttet helt å slippe gjennom store overføringer. Jumbo-rammer er en lokal lenkeavtale; de utvider ikke veien tunnelen krysser.

Det brukbare budsjettet settes av den minste grensen på ruten, inkludert innkapslingen tunnelen legger til.

Hva jumbo-rammer faktisk endrer

En MTU er en egenskap ved ett grensesnitt. Å heve den på en server og svitsjen dens betyr at de to kan utveksle større rammer uten fragmentering. Det sier ingenting om ruteren bak svitsjen, om leverandøren eller om den andre enden av en tunnel. Disse enhetene har sine egne grenser, og en pakke som overskrider en av dem, blir forkastet eller fragmentert etter regler du ikke har satt.

Lokal avtale, globale konsekvenser. Det er hele forvirringen.

Innkapslingsavgiften

En tunnel pakker pakken din inn i en annen. WireGuard over IPv4 UDP legger til omtrent 60 byte overhead; UDP-modusen til OpenVPN ligger i samme område, og IPsec varierer med modus og algoritmer. Disse bytene kommer fra budsjettet til den ytre veien, ikke fra løse luften.

Så en ytre lenke på 1500 byte kan ikke bære en indre pakke på 1500 byte når en tunnelheader er lagt til.

Regnestykket er verdt å gjøre én gang. På en vei på 1500 byte vil et WireGuard-grensesnitt ha en MTU rundt 1420 slik at den innkapslede pakken får plass. Sett det indre grensesnittet til 9000, og hver stor pakke trenger fragmentering som tunnelen ikke kan gjøre, eller blir forkastet.

Finn den minste lenken på ruten

Gå ruten gjennom og finn den laveste MTU-en. LAN-et er vanligvis 1500 eller 9000, WAN-et vanligvis 1500, og en mobil- eller PPP-lenke kan være enda lavere. Trekk så fra tunnelens overhead. Er resultatet mindre enn MTU-en til det indre grensesnittet, har du svaret. Oppdagelse av banens MTU kan finne dette automatisk, men bare når ICMP-meldingene den er avhengig av, slippes gjennom.

Filtrert ICMP er den klassiske grunnen til at en stor overføring henger mens små forespørsler fungerer fint.

Test størrelsesavhengighet uten å utvide endringen

Bruk en representativ overføring og ta vare på de opprinnelige verdiene så du kan sette dem tilbake. ping -M do -s 1472 tester en pakke på 1500 byte med DF-biten satt; reduser størrelsen til den går gjennom. Hvis bare store pakker feiler, har du et størrelsesproblem og ikke et rutingsproblem.

Vær oppmerksom på offload på vertssiden når du leser opptak. Segmenteringsoffload kan vise rammer langt større enn det som faktisk gikk over ledningen, noe som får en fungerende rute til å se ødelagt ut og en ødelagt rute til å se fin ut.

Når en stor MTU er riktig design

Et kontrollert privat nettverk kan legitimt kjøre større rammer ende til ende, forutsatt at hver enhet på ruten er enig og at tunnelens overhead er regnet med. Det er et koordinert design med en dokumentert verdi per lenke, ikke ett stort tall skrevet inn i en klient.

For en vanlig offentlig utgang, anta 1500 eller mindre og la tunnelen velge en trygg indre MTU. RFC 8201 dekker oppdagelse av banens MTU for IPv6-tilfellet og er en nyttig referanse for hvordan tilbakemeldingen skal fungere.