Jumbo-frames gør ikke en VPN-rute i stand til at bære pakker på 9000 byte
En stor MTU er en lokal linkaftale. Træk tunnelens overhead fra det mindste led på ruten, før du hæver det indre interface.
Du aktiverede 9000-byte frames på LAN'et og forventede, at VPN'en blev hurtigere. Den blev langsommere eller holdt helt op med at sende store overførsler igennem. Jumbo-frames er en lokal linkaftale; de forstørrer ikke den vej, tunnelen krydser.
Det brugbare budget fastsættes af den mindste grænse på ruten, inklusive den indkapsling, tunnelen tilføjer.
Hvad jumbo-frames faktisk ændrer
En MTU er en egenskab ved ét interface. At hæve den på en server og dens switch betyder, at de to kan udveksle større frames uden fragmentering. Det siger intet om routeren bag switchen, om udbyderen eller om den anden ende af en tunnel. De enheder har deres egne grænser, og en pakke, der overskrider en af dem, kasseres eller fragmenteres efter regler, du ikke har sat.
Lokal aftale, globale konsekvenser. Det er hele forvirringen.
Indkapslingsafgiften
En tunnel pakker din pakke ind i en anden. WireGuard over IPv4 UDP tilføjer cirka 60 byte overhead; OpenVPNs UDP-tilstand ligger i samme område, og IPsec varierer med tilstand og algoritmer. De byte kommer fra den ydre vejs budget, ikke ud af ingenting.
Så et ydre led på 1500 byte kan ikke bære en indre pakke på 1500 byte, når der er tilføjet et tunnelhoved.
Regnestykket er værd at lave én gang. På en vej på 1500 byte vil et WireGuard-interface have en MTU omkring 1420, så den indkapslede pakke passer. Sæt det indre interface til 9000, og hver stor pakke kræver fragmentering, som tunnelen ikke kan udføre, eller bliver kasseret.
Find det mindste led på ruten
Gå ruten igennem, og find den laveste MTU. LAN'et er som regel 1500 eller 9000, WAN'et er som regel 1500, og et mobil- eller PPP-led kan være lavere endnu. Træk derefter tunnelens overhead fra. Er resultatet mindre end det indre interfaces MTU, har du svaret. Path MTU discovery kan finde det automatisk, men kun når de ICMP-beskeder, den er afhængig af, slippes igennem.
Filtreret ICMP er den klassiske grund til, at en stor overførsel hænger, mens små forespørgsler fungerer fint.
Test størrelsesafhængighed uden at udvide ændringen
Brug en repræsentativ overførsel, og gem de oprindelige værdier, så du kan sætte dem tilbage. ping -M do -s 1472 tester en pakke på 1500 byte med DF-bittet sat; sænk størrelsen, indtil den går igennem. Hvis kun store pakker fejler, har du et størrelsesproblem og ikke et routingproblem.
Vær opmærksom på offload på værtssiden, når du læser captures. Segmenteringsoffload kan vise frames langt større end det, der faktisk gik over ledningen, hvilket får en fungerende rute til at se brudt ud og en brudt rute til at se fin ud.
Hvornår en stor MTU er det rigtige design
Et kontrolleret privat netværk kan legitimt køre større frames ende til ende, forudsat at hver enhed på ruten er enig, og at tunnelens overhead er regnet med. Det er et koordineret design med en dokumenteret værdi pr. led, ikke ét stort tal, der er tastet ind i en klient.
For en almindelig offentlig udgang, antag 1500 eller mindre, og lad tunnelen vælge en sikker indre MTU. RFC 8201 dækker path MTU discovery for IPv6-tilfældet og er en nyttig reference til, hvordan feedbacken er meningen at fungere.