Waarom veroorzaakt een MTU-mismatch gedeeltelijke connectiviteit van de thuisserver?

Een MTU-mismatch veroorzaakt gedeeltelijke connectiviteit van de thuisserver wanneer kleine pakketten het pad kunnen passeren maar grotere pakketten niet. DNS-antwoorden, TCP-handshakes, pings en korte API-aanroepen kunnen slagen, wat de indruk wekt dat de route gezond is. De verbinding stokt vervolgens wanneer TLS, een webrespons, een upload of een bestandsoverdracht een IP-pakket produceert dat groter is dan één link kan dragen.

Een correct pad rapporteert die groottebeperking zodat de zender zijn pakketten kan verkleinen. Gedeeltelijke storing doet zich voor wanneer een tunnel, virtuele brug, router of ISP-link een kleinere MTU heeft en de feedback nooit de zender bereikt — of wanneer verschillende lagen groottes adverteren die niet overeenkomen met hun werkelijke ingekapselde pad. Het resultaat is bereikbaarheid zonder betrouwbare gegevensoverdracht.

Het korte antwoord: pakketgrootte is onderdeel van connectiviteit

MTU is het grootste IP-pakket dat een interface in één link-laagtransmissie kan verzenden. Eindpunten zijn geïnteresseerd in de kleinste bruikbare waarde over het volledige pad, niet alleen de 1500-byte instelling die wordt weergegeven op de Ethernet-poort van een thuisserver. VPN- en overlay-headers nemen ruimte in beslag, dus een pakket dat op het LAN past, kan na encapsulatie te groot zijn.

De storing is gedeeltelijk omdat protocollen beginnen met kleine controlepakketten. Een TCP three-way handshake kan worden voltooid en een browser kan verbinding maken voordat een van beide zijden een volledig datasegment verzendt. Als te grote pakketten verdwijnen terwijl bevestigingen en kleinere hertransmissies nog steeds passeren, lijkt de sessie actief maar maakt weinig of geen voortgang.

MTU, MSS en Path MTU Discovery zijn gerelateerd maar verschillend

Interface MTU beperkt het IP-pakket op één interface. TCP Maximum Segment Size, of MSS, geeft aan hoeveel TCP-gegevens een eindpunt in elk segment wil; er wordt ruimte gelaten voor IP- en TCP-headers. MSS-clamping kan die geadverteerde payload bij een router verlagen, maar het beïnvloedt TCP-onderhandelingen en niet elk UDP- of ICMP-pakket.

Path MTU Discovery, of PMTUD, stelt een zender in staat om de kleinste MTU langs een route te achterhalen. Voor IPv4 definieert RFC 1191 een proces waarbij een router die een pakket met de Don't Fragment-bit ingesteld niet kan doorsturen, ICMP feedback geeft dat fragmentatie nodig is. De zender kan dan de padwaarde verlagen en het pakket opnieuw verzenden.

IPv6-routers fragmenteren geen transitpakketten. RFC 8201 specificeert dat een IPv6-knooppunt ICMPv6 Packet Too Big-berichten gebruikt om een kleinere pad-MTU te leren. Het blokkeren van dat controleverkeer verstevigt het datapad niet; het voorkomt dat het eindpunt zich aanpast aan een echte limiet.

Waar een Home Server-pad begint met het weggooien van grotere pakketten

Een tunnel verkleint de bruikbare payload

WireGuard, IPsec, PPPoE, VLAN's en andere encapsulaties voegen headers toe rond het oorspronkelijke pakket. Een binnenpakket van 1500 bytes kan niet ongewijzigd in een buitenlink van 1500 bytes passen zodra die headers aanwezig zijn. Een tunnelinterface adverteert normaal gesproken een lagere MTU, maar een handmatige override of een tussenliggend apparaat kan de eindpunten een optimistische waarde laten behouden.

De mismatch kan de externe toegang beïnvloeden terwijl de lokale service perfect blijft. Een telefoon op Wi-Fi bereikt de server via gewone Ethernet, terwijl dezelfde telefoon op een VPN het kleinere tunnelpad gebruikt. Omdat routering, authenticatie en kleine verzoeken nog steeds werken, kan het symptoom lijken op een applicatie- of certificaatprobleem.

Geneste paden verergeren het probleem. Een containerpakket kan een virtuele Ethernet-paar en brug passeren, een VM-adapter binnenkomen en vervolgens een VPN betreden. De beperkende MTU hoort bij de volledige route, terwijl elke zichtbare interface een plausibele waarde voor zijn eigen laag kan rapporteren.

ICMP-feedback wordt gefilterd of gaat verloren

Als de limiterende router een te groot pakket weggooit en de foutmelding de bron bereikt, kan PMTUD herstellen. Als een firewall alle ICMP- of ICMPv6-berichten willekeurig weggooit, blijft de afzender een grootte gebruiken die het pad niet aankan. Cloudflare beschrijft deze moderne fout als een Path MTU black hole: grote pakketten gaan stilzwijgend verloren terwijl de applicatie wacht.

Asymmetrische routering kan hetzelfde resultaat opleveren, zelfs wanneer geen enkele firewall het bericht opzettelijk blokkeert. Het datapakket kan via één pad gaan en de ICMP-fout via een ander; beleidsroutering, NAT of een providerfilter kan voorkomen dat het retourbericht wordt gekoppeld aan de oorspronkelijke afzender. Pakketcaptatie moet daarom zowel de data- als de feedbackrichting inspecteren.

Herhaalde TCP-hertransmissies zijn een aanwijzing, geen bewijs. Congestie en draadloos verlies veroorzaken ook hertransmissies. MTU-problemen worden waarschijnlijker wanneer fouten beginnen bij een herhaalbare payloadgrootte, kleine probes slagen, en het verlagen van de interface-MTU of geadverteerde MSS direct vooruitgang herstelt.

Virtuele netwerken adverteren de verkeerde grootte

Container-bridges en VM-switches kunnen een MTU erven of standaard instellen die groter is dan de onderliggende laag. De container bouwt dan een pakket dat geldig is voor zijn virtuele interface maar te groot is nadat de host het via een VPN, cloud-overlay of PPPoE-uplink verzendt. Offload-functies kunnen captures groter doen lijken dan kabelpakketten, dus de locatie van de capture is belangrijk.

Een gedocumenteerd Docker-geval volgde precies dit onderliggende probleem: een kleine LDAP-aanvraag slaagde, maar de respons verdween omdat de VPN-MTU 1400 was terwijl Docker 1500 gebruikte. Host-netwerken leken de app te repareren omdat het de niet-overeenkomende virtuele laag verwijderde, niet omdat de applicatie veranderde.

Trek geen conclusies over het gedrag op de kabel uit één capture met enorme TCP-segmenten. Generieke segmentatie-offload kan grote buffers aan het besturingssysteem presenteren en deze later splitsen. Maak een capture aan de ontvangende kant, schakel offloads tijdelijk uit voor diagnose, of koppel interface-tellers aan gecontroleerde pakketgroottetests voordat je concludeert dat een apparaat een onmogelijk frame heeft verzonden.

Upstream- en tunnelinstellingen bepalen de werkelijke limiet

De thuisserver is niet altijd de plek waar de mismatch is ontstaan. PPPoE, een ISP-overgangsmechanisme, een remote-access tunnel of een upstream-router kan de smalste schakel introduceren. Volg de exacte client-naar-service route en noteer elke encapsulatiegrens in plaats van alleen de fysieke NIC te wijzigen.

Sta de controleberichten toe die PMTUD nodig heeft. Voor IPv4 omvat dat het relevante destination-unreachable fragmentation-needed bericht; voor IPv6 omvat dat Packet Too Big. Pas een strikte firewallregel toe op berichttype en status in plaats van alle ICMP te blokkeren. Een server kan geen padbeperking leren die het netwerk weigert te melden.

Vermijd afhankelijkheid van fragmentatie als normale oplossing. RFC 8900 legt uit dat IP-fragmentatie operationele kwetsbaarheid introduceert. Het afstemmen van MTU, het behouden van PMTUD of het veilig laten uitvoeren van de transportprobe is robuuster dan aannemen dat elke middlebox fragmenten zal doorsturen en opnieuw zal assembleren.

Als één router niet kan worden aangepast, kan MSS-clamping een praktische TCP-omzeiling zijn op de tunnel- of doorstuurgrens. Stel dit in vanaf het echte pad in plaats van een universeel getal te kopiëren. Het repareert geen te grote UDP-datagrammen en een onnodig lage waarde voegt pakket- en headeroverhead toe, dus bevestig de verbetering met captures en applicatietests.

Server-, VM- en containerinstellingen moeten overeenkomen

Inventariseer de MTU op de fysieke NIC, bond, VLAN, bridge, VM-adapter, container netwerk en tunnel. De waarden hoeven niet numeriek identiek te zijn als een laag correct rekening houdt met encapsulatie, maar geen enkele binnenste laag mag pakketten produceren die de volgende laag niet kan vervoeren of als te groot rapporteert.

Voor Docker stelt u een geschikte MTU in bij het aanmaken van het netwerk of via de daemonconfiguratie, en maakt u vervolgens de getroffen netwerken en containers opnieuw aan indien nodig. Het probleemoplossingsvoorbeeld van Civo laat zien hoe een Docker MTU die de onderliggende laag negeert onverwachte verbindingsproblemen kan veroorzaken. Controleer daarna de actieve interface; alleen de configuratie bewerken bewijst niet dat het actieve netwerk is gewijzigd.

Houd prestatie-afstemming gescheiden van reparatie. De uitleg van ZimaSpace over TCP-windowgrootte op langeafstandslijnen gaat over hoeveel data in de lucht kan blijven, terwijl MTU de pakketgrootte regelt. Het vergroten van buffers kan een te groot pakket niet door een kleinere verbinding laten passen.

Controles die de defecte fase vinden

Vind het grootste pakket dat consequent passeert

Gebruik platformgeschikte ping-opties om de payloadgrootte in te stellen en fragmentatie te verbieden waar ondersteund, en vergeet niet IP- en ICMP-headerbytes toe te voegen bij het vergelijken van het resultaat met een interface-MTU. Test verschillende groottes vanaf hetzelfde clientpad dat de fout toont. Een herhaalbare drempel is informatiever dan één succesvolle standaardping.

Herhaal de test op het LAN, via de VPN en vanuit de container of VM. Als de drempel verandert bij een bepaalde grens, wordt die laag de hoofdverdachte. Sommige netwerken beperken of blokkeren echo-verkeer, dus bevestig het resultaat met TCP-applicatieverzoeken of een speciaal ontworpen path-MTU-tool.

Controleer interfaces, routes en encapsulatie

Noteer de geselecteerde route en uitgaande interface voor de getroffen bestemming. Controleer MTU-waarden op elke virtuele en fysieke interface die het pakket passeert, plus tunnel- en container-netwerkconfiguratie. Ga er niet van uit dat de standaardroute wordt gebruikt wanneer beleidsroutering of split tunneling actief is.

Bereken de header-overhead voor de daadwerkelijke tunnelstack, inclusief de buitenste IP-versie en transport. De veilige binnenste MTU moet ruimte laten voor die headers op het buitenste pad. Als de tunnel een veranderende route gebruikt, kies dan een waarde die werkt over de ondersteunde onderliggende netwerken of behoud een werkend detectiemechanisme.

Maak een capture van data en ICMP-feedback aan beide zijden

Maak een capture dicht bij de zender en na de vermoedelijke smalle verbinding. Zoek naar een groot pakket dat herhaald wordt zonder bevestiging, een ICMP-fragmentatie-nodig bericht, of een ICMPv6 Packet Too Big-bericht. Als de fout stroomafwaarts verschijnt maar nooit de zender bereikt, richt je dan op retourroutering en firewallbeleid.

Voor TCP, controleer de MSS-opties in SYN- en SYN-ACK-pakketten en vergelijk deze met de waargenomen datasegmenten. Een lagere MSS kan voorkomen dat de zender te grote TCP-pakketten maakt, maar het onthult niet of UDP nog steeds defect is. Gebruik de capture om de reparatie te valideren in plaats van een geladen firewallregel als succes te beschouwen.

Stel MTU af of klem MSS, test vervolgens opnieuw

Geef de voorkeur aan het corrigeren van de MTU op de interface die op de hoogte is van de kleinere onderliggende laag. Maak virtuele netwerken opnieuw aan wanneer hun MTU bij creatie is vastgezet. Als dat onmogelijk is, clamp dan TCP MSS op de doorgeef- of tunnelgrens en sta de vereiste ICMP-feedback toe. Breng één wijziging tegelijk aan zodat het resultaat toewijsbaar blijft.

Test de oorspronkelijke workflow opnieuw, niet alleen ping. Voltooi TLS-onderhandeling, laad een antwoord groter dan één pakket, upload en download een bestand, en houd de verbinding lang genoeg actief om retransmissies te observeren. Gedeeltelijke connectiviteit is pas opgelost wanneer de applicaties die het blootlegden data betrouwbaar in beide richtingen overdragen.

Wanneer gedeeltelijke connectiviteit een serieus probleem wordt

Behandel het probleem als urgent wanneer het back-ups, herstel, externe administratie, synchronisatie of authenticatie beïnvloedt. Deze workflows kunnen voorlopige controles doorstaan en pas falen nadat betekenisvolle data begint te bewegen, wat leidt tot onvolledige kopieën of time-outs die operators verkeerd interpreteren als opslag- of inlogfouten.

Geef er ook prioriteit aan wanneer IPv6 zich anders gedraagt dan IPv4, een alleen-VPN-pad faalt, of containerverkeer verschilt van hostverkeer. Die contrasten tonen welke route of encapsulatie de bruikbare pakketgrootte verandert. Hoe deterministischer de grens, hoe minder zinvol het is om de applicatie steeds opnieuw te laten proberen zonder het netwerkpad te repareren.

FAQ

Waarom kan ik de thuisserver pingen terwijl de website niet laadt?

Standaard ping-pakketten zijn klein, net als DNS-uitwisselingen en TCP-handshakes. De website kan alleen vastlopen wanneer TLS of HTTP een pakket boven de padlimiet verzendt. Test grotere niet-fragmenterende probes en leg de mislukte webverbinding vast in plaats van één ping-antwoord als bewijs te zien dat elke pakketgrootte werkt.

Moet elke interface een MTU van 1500 gebruiken?

Nee. Ethernet gebruikt vaak 1500, maar tunnels en andere encapsulaties hebben ruimte nodig voor buitenste headers. Wat telt is dat elke laag ofwel een grootte adverteert die de volgende laag kan dragen, of werkende feedback ontvangt die het laat aanpassen aan de kleinste MTU langs de route.

Is MSS-clamping hetzelfde als het fixeren van MTU?

Nee. MSS-clamping verandert de TCP-payloadgrootte die tijdens de verbinding tot stand wordt gebracht wordt geadverteerd, wat TCP-pakketten onder een bekende limiet kan houden. Het verandert de interface-MTU niet en beperkt UDP of ander IP-verkeer niet direct.

MTU-afstemming en functionerende PMTUD richten zich op het pad zelf. Clamping is waardevol wanneer een doorgeefapparaat of tunnel anders de beperking niet kan communiceren, maar het moet zorgvuldig worden gemeten, op de juiste grens worden geplaatst en gevolgd worden door tests van elk getroffen protocol.