15001420fits!underlay MTUVPN tunnel MTU+80 bytes encap overhead

MTU och MSS

10 min lästNätverk

De flesta användare kommer att gå en livstid utan att tänka på MTU. De flesta nätverksingenjörer tänker på det varje vecka. Det är den maximala paketstorleken som en länk kan bära, och att få det fel producerar några av de mest frustrerande buggarna i nätverk – anslutningar som verkar fungera för små förfrågningar och sedan på mystiskt sätt hänger sig när större data flödar, särskilt genom VPN.

Hela artikeltexten finns på engelska nedan.

MTU (Maximum Transmission Unit) är det största IP-paket en länk kan bära. Standard Ethernet har en MTU på 1500 byte. PPPoE (används av många DSL-anslutningar) är 1492. Wi-Fi är 1500. WireGuard-tunnlar är 1420 som standard. MSS (Maximum Segment Size) är motsvarigheten till TCP-skiktet — den maximala nyttolaststorleken i ett TCP-segment, vilket är MTU minus IP- och TCP-header-overhead (40 byte för IPv4, 60 för IPv6). MTU, en av två saker händer:

  • Fragmentation: routern delar upp paketet i mindre IP-fragment. Destinationen sätts ihop igen. Detta fungerar men lägger till overhead och går sönder om något fragment försvinner.
  • Drop med ICMP "Fragmentation Needed": om IP-paketet har Don't Fragment-biten (TCP brukar göra det), routern släpper ett ICMP-länkmeddelande och reparerar det. Avsändaren förväntas minska paketstorleken och försöka igen. Detta är Path MTU Discovery.

Problemet: många brandväggar blockerar ICMP Fragmentation Needed-meddelanden. Avsändaren lär sig aldrig att den ska krympa paket. Anslutningarna hänger sig eftersom överdimensionerade paket släpps tyst och aldrig återsänds i en annan storlek. Detta är det klassiska PMTUD-svarta hålet.

Varför VPN: er gör detta värre

A VPN kapslar in dina paket i ytterligare rubriker. WireGuard lägger till 60 byte (IPv4) eller 80 (IPv6). IPsec lägger till 50–60 byte beroende på läge. OpenVPN lägger till 41+ byte plus TCP/UDP-bäraroverhead. Så ett paket på 1500 byte via Ethernet, när det bärs genom en WireGuard-tunnel, blir 1560 byte — för stort för Ethernet-underlägget.

Rätt svar: ställ in tunnelns MTU lägre än MTU-underlaget minus inkapslingsoverheaden. WireGuard har som standard 1420, vilket ger 80 byte utrymme. OpenVPN använder vanligtvis 1500 minus dess overhead, ofta runt 1450.

MSS klämning: den praktiska fixen

Den renaste fixeringen för PMTUD svarta hålet är MSS clamping. En router eller brandvägg i sökvägen skriver om MSS-alternativet i TCP SYN-paket till ett mindre värde innan vidarebefordran. Båda ändpunkterna förhandlar sedan fram en mindre MSS, som passar inom banans minsta MTU. Inga ICMP-meddelanden krävs — storleksgränsen kommuniceras inom band.

VPN-servrar vanligtvis MSS-clamp som standard. WireGuard-gränssnitt på Linux kan konfigureras med:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Detta klämmer dynamiskt varje TCP-anslutnings MSS till vad än sökvägen kan bära.

Symtom på MTU-problem

Classic tecken på att MTU är skyldige:

  • Ladda framsidan av en webbplats fungerar; skicka ett formulär fastnar.
  • SSH-sessionen ansluter bra; ls /large/directory fryser mitt i produktionen.
  • Vissa webbplatser fungerar, andra timeout.
  • VPN känns trasig för HTTPS men DNS fungerar.
  • Symtom visas bara när trafiken blir stor (nedladdningar) uppladdningar).

Diagnostiken: ping -M do -s 1472 example.com skickar ett 1500-byte IPv4-paket (1472 + 20 IP-rubrik + 8 ICMP-rubrik) med inte-fragment-uppsättning. Minska tills det lyckas; arbetsstorleken + 28 = sökvägen MTU.

Jumbo-ramar

Vissa länkar kan bära paket som är större än 1500 byte — jumbo-ramar, vanligtvis 9000 byte. De är vanliga i datacenterstrukturer där varje länk är enhetlig Ethernet, och de minskar CPU-overhead per paket för arbetsbelastningar med hög genomströmning som lagring och HPC. De är sällsynta på det offentliga Internet; de flesta sökvägarna faller till den minsta länkens MTU.

QUIC och Path MTU

QUIC (transporten för HTTP/3) gör sin egen sökväg-MTU-sondering inuti protokollet. Den startar konservativt (cirka 1200 byte) och växer genom att skicka enstaka sondpaket för att upptäcka banans faktiska kapacitet. Detta undviker det svarta hålet PMTUD helt – QUIC är inte beroende av ICMP-feedback. När HTTP/3-distributionen sprider sig blir MTU-relaterade hängningar sällsynta i applikationslagret.

Vanliga frågor

Hur hittar jag min anslutnings MTU?
Linux: <code>ip-länk show</code> visar den konfigurerade MTU per gränssnitt. macOS: <code>ifconfig en0 | grep mtu</code>. Windows: <code>netsh-gränssnitt ipv4 visar gränssnitt</code>. För att hitta sökvägen till MTU till en specifik destination, använd det inkrementella pingtestet som beskrivs ovan.
Ska jag ändra min MTU manuellt?
Nästan aldrig på en typisk anslutning. Moderna operativsystem och routrar hanterar MTU korrekt. Om du upplever MTU-symtom över ett VPN, är korrigeringen vanligtvis att MSS klämmer fast på VPN, inte att ändra enhetens MTU.
Varför är WireGuards MTU 1420 som standard?
1500 (Ethernet) minus 60 byte av WireGuard + IPv4 overhead = 1440, men 1420 lämnar utrymme för IPv6 i de inre paketen (vilket lägger till 20 fler byte av header). Det är en konservativ standard som fungerar för de flesta underliggande nätverk.
Påverkar MTU hastigheten?
Marginalt. Större MTU innebär färre paket för samma data, färre rubriker, mindre CPU-overhead – kanske 1–5 % förbättring av genomströmningen på en länk med hög bandbredd. På en vanlig internetanslutning är skillnaden osynlig.
Vad är förhållandet mellan MTU och MSS?
MSS = MTU − IP-huvud − TCP-huvud. För IPv4 Ethernet: 1500 − 20 − 20 = 1460 MSS. Varje slutpunkt tillkännager sin MSS i TCP SYN; anslutningen använder det minsta av de två. MSS-klämning är när något i sökvägen skriver om detta aviserade värde till ett mindre antal.
MTU och MSS förklaras: paketstorleksinställningarna som bryter VPN på mystiska sätt