Hoe vind ik de MTU van mijn verbinding?

Linux: ip link show toont de geconfigureerde MTU per interface. macOS: ifconfig en0 | grep mtu . Windows: netsh-interface ipv4 toont interfaces . Om het pad MTU naar een specifieke bestemming te vinden, gebruikt u de hierboven beschreven incrementele ping-test.

Moet ik mijn MTU handmatig wijzigen?

Bijna nooit op een normale verbinding. Moderne besturingssystemen en routers verwerken MTU correct. Als u MTU-symptomen ervaart via een VPN, is de oplossing meestal het MSS-klemmen op de VPN, en niet het wijzigen van de MTU van het apparaat.

Waarom is de MTU 1420 van WireGuard standaard?

1500 (Ethernet) minus 60 bytes WireGuard + IPv4-overhead = 1440, maar 1420 laat ruimte over voor IPv6 in de binnenste pakketten (wat 20 bytes extra header toevoegt). Het is een conservatieve standaard die voor de meeste onderliggende netwerken werkt.

Heeft MTU invloed op de snelheid?

Marginaal. Grotere MTU betekent minder pakketten voor dezelfde data, minder headers, minder CPU-overhead – misschien wel 1-5% verbetering van de doorvoer op een verbinding met hoge bandbreedte. Op een normale internetverbinding is het verschil onzichtbaar.

Wat is de relatie tussen MTU en MSS?

MSS = MTU − IP-header − TCP-header. Voor IPv4 Ethernet: 1500 − 20 − 20 = 1460 MSS. Elk eindpunt kondigt zijn MSS aan in de TCP SYN; de verbinding gebruikt het minimum van de twee. Bij MSS-klemmen wordt door iets in het pad deze aangekondigde waarde naar een kleiner getal herschreven.

MTU en MSS uitgelegd: de pakketgrootte-instellingen die VPN's op mysterieuze manieren kapot maken

De meeste gebruikers zullen een leven lang niet aan MTU denken. De meeste netwerkingenieurs denken er wekelijks over na. Het is de maximale pakketgrootte die een link kan dragen, en als het fout gaat, levert dat een aantal van de meest frustrerende bugs in netwerken op: verbindingen die lijken te werken voor kleine verzoeken en vervolgens op mysterieuze wijze blijven hangen als er grotere datastromen stromen, vooral via VPN's.

De volledige artikeltekst vindt u hieronder in het Engels.

MTU (Maximum Transmission Unit) is het grootste IP-pakket dat een link kan vervoeren. Standaard Ethernet heeft een MTU van 1500 bytes. PPPoE (gebruikt door veel DSL-verbindingen) is 1492. Wi-Fi is 1500. WireGuard-tunnels zijn standaard 1420. MSS (Maximum Segment Size) is het TCP-laag-equivalent: de maximale payload-grootte in een enkel TCP-segment, namelijk de MTU minus IP- en TCP-header-overhead (40 bytes voor IPv4, 60 voor IPv6).

Waarom pakketgrootte belangrijk is

Als u een pakket verzendt dat groter is dan de MTU van een link, zijn er twee dingen mogelijk gebeurt:

Fragmentatie: de router splitst het pakket in kleinere IP-fragmenten. De bestemming komt weer in elkaar. Dit werkt, maar voegt overhead toe en breekt als er een fragment verloren gaat.
Drop met ICMP "Fragmentation Needed": als het IP-pakket de Don't Fragment bitset bevat (TCP doet dat meestal), laat de router het vallen en antwoordt met een ICMP-bericht dat de MTU van de link aangeeft. Van de afzender wordt verwacht dat hij de pakketgrootte verkleint en het opnieuw probeert. Dit is Path MTU Discovery.

Het probleem: veel firewalls blokkeren ICMP Fragmentation Needed-berichten. De afzender leert nooit dat hij pakketten moet verkleinen. Verbindingen lopen vast omdat te grote pakketten stilzwijgend worden verwijderd en nooit opnieuw worden verzonden met een ander formaat. Dit is het klassieke PMTUD zwarte gat.

Waarom VPN's dit nog erger maken

A VPN kapselt uw pakketten in extra headers in. WireGuard voegt 60 bytes (IPv4) of 80 bytes (IPv6) toe. IPsec voegt 50-60 bytes toe, afhankelijk van de modus. OpenVPN voegt 41+ bytes toe plus de overhead van de TCP/UDP-carrier. Dus een pakket van 1500 bytes via Ethernet, wanneer het door een WireGuard-tunnel wordt gevoerd, wordt 1560 bytes – te groot voor de Ethernet-underlay.

Het juiste antwoord: stel de tunnel-MTU lager in dan de underlay-MTU minus de inkapselingsoverhead. WireGuard is standaard ingesteld op 1420, waardoor er 80 bytes aan vrije ruimte overblijft. OpenVPN gebruikt doorgaans 1500 minus de overhead, vaak rond de 1450.

MSS-klemming: de praktische oplossing

De schoonste oplossing voor het PMTUD-zwarte gat is MSS-klemming. Een router of firewall in het pad herschrijft de MSS-optie in TCP SYN-pakketten naar een kleinere waarde voordat deze wordt doorgestuurd. Beide eindpunten onderhandelen vervolgens over een kleinere MSS, passend binnen de kleinste MTU van het pad. Geen ICMP-berichten vereist: de maximale grootte wordt in-band gecommuniceerd.

VPN-servers zijn standaard standaard MSS-clamp. WireGuard-interfaces op Linux kunnen worden geconfigureerd met:

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

Dit klemt dynamisch de MSS van elke TCP-verbinding vast aan wat het pad ook kan dragen.

Symptomen van MTU-problemen

Klassieke tekenen dat MTU de boosdoener is:

LDe voorpagina laden van een bouwplaats; het indienen van een formulier blijft hangen.
SSH-sessie maakt prima verbinding; ls /large/directory loopt vast tijdens de uitvoer.
Sommige sites werken, andere krijgen een time-out.
VPN voelt niet goed voor HTTPS, maar DNS werkt.
Symptomen verschijnen alleen als het verkeer groot wordt (downloads, uploads).

De diagnose: ping -M do -s 1472 example.com verzendt een IPv4-pakket van 1500 bytes (1472 + 20 IP-header + 8 ICMP-header) met de set 'niet-fragmenteren'. Verminder totdat het lukt; de werkgrootte + 28 = het pad MTU.

Jumboframes

Sommige links kunnen pakketten vervoeren die groter zijn dan 1500 bytes - jumboframes, doorgaans 9000 bytes. Ze komen vaak voor in datacenterstructuren waar elke link uniform Ethernet is, en ze verminderen de CPU-overhead per pakket voor werklasten met hoge doorvoer, zoals opslag en HPC. Ze zijn zeldzaam op het openbare internet; de meeste paden gaan naar de MTU.

QUIC van de kleinste link en Path MTU

QUIC (het transport voor HTTP/3) voert zijn eigen pad-MTU-onderzoek uit binnen het protocol. Het begint conservatief (ongeveer 1200 bytes) en groeit door af en toe testpakketten te verzenden om de werkelijke capaciteit van het pad te ontdekken. Dit vermijdt het zwarte gat van PMTUD volledig - QUIC is niet afhankelijk van ICMP-feedback. Naarmate de implementatie van HTTP/3 zich verspreidt, worden MTU-gerelateerde vastlopers steeds zeldzamer op de applicatielaag.

Veelgestelde vragen

Hoe vind ik de MTU van mijn verbinding?: Linux: <code>ip link show</code> toont de geconfigureerde MTU per interface. macOS: <code>ifconfig en0 | grep mtu</code>. Windows: <code>netsh-interface ipv4 toont interfaces</code>. Om het pad MTU naar een specifieke bestemming te vinden, gebruikt u de hierboven beschreven incrementele ping-test.
Moet ik mijn MTU handmatig wijzigen?: Bijna nooit op een normale verbinding. Moderne besturingssystemen en routers verwerken MTU correct. Als u MTU-symptomen ervaart via een VPN, is de oplossing meestal het MSS-klemmen op de VPN, en niet het wijzigen van de MTU van het apparaat.
Waarom is de MTU 1420 van WireGuard standaard?: 1500 (Ethernet) minus 60 bytes WireGuard + IPv4-overhead = 1440, maar 1420 laat ruimte over voor IPv6 in de binnenste pakketten (wat 20 bytes extra header toevoegt). Het is een conservatieve standaard die voor de meeste onderliggende netwerken werkt.
Heeft MTU invloed op de snelheid?: Marginaal. Grotere MTU betekent minder pakketten voor dezelfde data, minder headers, minder CPU-overhead – misschien wel 1-5% verbetering van de doorvoer op een verbinding met hoge bandbreedte. Op een normale internetverbinding is het verschil onzichtbaar.
Wat is de relatie tussen MTU en MSS?: MSS = MTU − IP-header − TCP-header. Voor IPv4 Ethernet: 1500 − 20 − 20 = 1460 MSS. Elk eindpunt kondigt zijn MSS aan in de TCP SYN; de verbinding gebruikt het minimum van de twee. Bij MSS-klemmen wordt door iets in het pad deze aangekondigde waarde naar een kleiner getal herschreven.