Jumbo-frames zorgen er niet voor dat een VPN-pad pakketten van 9000 byte vervoert

Je hebt frames van 9000 byte op de LAN aangezet en verwachtte dat de VPN sneller zou worden. Hij werd langzamer, of stopte helemaal met het doorlaten van grote overdrachten. Jumbo-frames zijn een lokale linkafspraak; ze vergroten niet het pad dat de tunnel oversteekt.

Het bruikbare budget wordt bepaald door de kleinste grens op de route, inclusief de encapsulation die de tunnel toevoegt.

Wat jumbo-frames echt veranderen

Een MTU is een eigenschap van één interface. Hem verhogen op een server en zijn switch betekent dat die twee grotere frames kunnen uitwisselen zonder fragmentatie. Het zegt niets over de router voorbij de switch, over de provider of over de andere kant van een tunnel. Die apparaten hebben hun eigen limieten, en een pakket dat er een overschrijdt wordt weggegooid of gefragmenteerd volgens regels die jij niet hebt ingesteld.

Lokale afspraak, wereldwijde gevolgen. Dat is de hele verwarring.

De encapsulatietaks

Een tunnel wikkelt je pakket in een ander pakket. WireGuard over IPv4 UDP voegt ongeveer 60 byte overhead toe; de UDP-modus van OpenVPN zit in dezelfde orde, en IPsec varieert met modus en algoritmen. Die bytes komen uit het budget van het buitenste pad, niet uit het niets.

Een buitenste schakel van 1500 byte kan dus geen binnenste pakket van 1500 byte vervoeren zodra er een tunnelheader bij komt.

De rekensom is het één keer waard. Op een pad van 1500 byte wil een WireGuard-interface een MTU rond 1420 zodat het ingekapselde pakket past. Zet de binnenste interface op 9000 en elk groot pakket heeft fragmentatie nodig die de tunnel niet kan uitvoeren, of wordt weggegooid.

Vind de kleinste schakel op het pad

Loop de route na en vind de laagste MTU. De LAN is meestal 1500 of 9000, de WAN meestal 1500, en een mobiele of PPP-verbinding kan nog lager zijn. Trek dan de tunnel-overhead eraf. Is het resultaat kleiner dan de MTU van de binnenste interface, dan heb je je antwoord. Path-MTU-discovery kan dit automatisch vinden, maar alleen als de ICMP-berichten waarvan het afhangt worden doorgelaten.

Gefilterde ICMP is de klassieke reden dat een grote overdracht blijft hangen terwijl kleine verzoeken prima werken.

Test grootteafhankelijkheid zonder de wijziging te verbreden

Gebruik een representatieve overdracht en bewaar de oorspronkelijke waarden zodat je ze terug kunt zetten. ping -M do -s 1472 test een pakket van 1500 byte met de DF-bit gezet; verklein de grootte tot het doorkomt. Als alleen grote pakketten mislukken, heb je een grootteprobleem en geen routingprobleem.

Let op offload aan de hostkant bij het lezen van captures. Segmentatie-offload kan frames tonen die veel groter zijn dan wat er werkelijk over de kabel ging, waardoor een werkend pad kapot lijkt en een kapot pad in orde.

Wanneer een grote MTU het juiste ontwerp is

Een gecontroleerd particulier netwerk kan grotere frames van begin tot eind draaien, mits elk apparaat op het pad het eens is en de tunnel-overhead wordt meegerekend. Dat is een gecoördineerd ontwerp met een gedocumenteerde waarde per schakel, niet één groot getal dat in een client is getypt.

Voor een gewone openbare uitgang, ga uit van 1500 of minder en laat de tunnel een veilige binnenste MTU kiezen. RFC 8201 behandelt path-MTU-discovery voor het IPv6-geval en is een nuttige referentie voor hoe de terugkoppeling hoort te werken.