Varför orsakar MTU-mismatch delvis anslutning till hemservern?

En MTU-mismatch orsakar delvis hemmserversanslutning när små paket kan passera vägen men större paket inte kan. DNS-svar, TCP-handskakningar, pingar och korta API-anrop kan lyckas, vilket ger intrycket att rutten är frisk. Anslutningen stannar sedan när TLS, ett webbsvar, en uppladdning eller en filöverföring producerar ett IP-paket som är större än vad en länk kan bära.

En korrekt väg rapporterar den storleksgränsen så att sändaren kan minska sina paket. Delvis fel uppstår när en tunnel, virtuell brygga, router eller ISP-länk har en mindre MTU och feedbacken aldrig når sändaren – eller när olika lager annonserar storlekar som inte speglar deras verkliga inkapslade väg. Resultatet är nåbarhet utan pålitlig dataöverföring.

Det korta svaret: Paketstorlek är en del av anslutningen

MTU är det största IP-paket som ett gränssnitt kan skicka i en enda länk-lageröverföring. Ändpunkter bryr sig om det minsta användbara värdet över hela vägen, inte bara den 1500-byte inställningen som visas på en hemmservers Ethernet-port. VPN- och överliggande huvuden tar plats, så ett paket som passar i LAN kan vara för stort efter inkapsling.

Felet är delvis eftersom protokoll börjar med små kontrollpaket. En TCP-trehandskakning kan slutföras och en webbläsare kan ansluta innan någon av parterna skickar ett fullstort datasegment. Om för stora paket försvinner medan bekräftelser och mindre omförsändelser fortfarande passerar, ser sessionen levande ut men gör liten eller ingen framsteg.

MTU, MSS och Path MTU Discovery är relaterade men olika

Interface MTU begränsar IP-paketet på en enskild gränssnitt. TCP Maximum Segment Size, eller MSS, annonserar hur mycket TCP-data en ändpunkt vill ha i varje segment; det lämnar plats för IP- och TCP-huvuden. MSS-klämning kan sänka den annonserade nyttolasten vid en router, men det påverkar TCP-förhandlingar snarare än varje UDP- eller ICMP-paket.

Path MTU Discovery, eller PMTUD, låter en sändare ta reda på den minsta MTU längs en rutt. För IPv4 definierar RFC 1191 en process där en router som inte kan vidarebefordra ett paket med Don’t Fragment-biten satt returnerar ICMP-fragmenteringsbehovsfeedback. Sändaren kan då sänka värdet för vägen och skicka om paketet.

IPv6-routrar fragmenterar inte transitpaket. RFC 8201 specificerar att en IPv6-nod använder ICMPv6 Packet Too Big-meddelanden för att lära sig en mindre path MTU. Att blockera den kontrolltrafiken stärker inte datapathen; det förhindrar att ändpunkten anpassar sig till en verklig begränsning.

Var en hemserverväg börjar släppa större paket

En tunnel krymper den användbara nyttolasten

WireGuard, IPsec, PPPoE, VLAN och andra inkapslingar lägger till headers runt det ursprungliga paketet. Ett 1500-byte inre paket kan inte passa oförändrat in i en 1500-byte yttre länk när dessa headers finns. Ett tunnelgränssnitt annonserar normalt en lägre MTU, men en manuell överskrivning eller en mellanliggande enhet kan lämna ändpunkterna med ett optimistiskt värde.

Mismatchen kan påverka fjärråtkomst medan den lokala tjänsten förblir perfekt. En telefon på Wi-Fi når servern via vanlig Ethernet, medan samma telefon på ett VPN använder den mindre tunnelvägen. Eftersom routing, autentisering och små förfrågningar fortfarande fungerar kan symtomet likna ett applikations- eller certifikatproblem.

Inbäddade vägar förvärrar problemet. Ett containerpaket kan korsa ett virtuellt Ethernet-par och brygga, gå in i en VM-adapter och sedan in i ett VPN. Den restriktiva MTU:n tillhör hela rutten, medan varje synligt gränssnitt kan rapportera ett rimligt värde för sitt eget lager.

ICMP-återkoppling filtreras eller förloras

Om den begränsande routern släpper ett för stort paket och dess fel når källan, kan PMTUD återhämta sig. Om en brandvägg slänger all ICMP eller ICMPv6 utan urskillning, fortsätter avsändaren använda en storlek som vägen inte kan bära. Cloudflare beskriver detta moderna fel som ett Path MTU black hole: stora paket förloras tyst medan applikationen väntar.

Asymmetrisk routing kan ge samma resultat även när ingen brandvägg medvetet blockerar meddelandet. Datapaketet kan ta en väg och ICMP-felet en annan; policyrouting, NAT eller en leverantörsfilter kan förhindra att returmeddelandet kopplas till den ursprungliga avsändaren. Paketfångst måste därför inspektera både data- och återkopplingsriktningarna.

Upprepade TCP-omöverföringar är en ledtråd, inte bevis. Trängsel och trådlösa förluster utlöser också omöverföring. MTU-problem blir mer sannolikt när fel börjar nära en upprepad nyttolaststorlek, små tester lyckas och att minska gränssnittets MTU eller annonserad MSS omedelbart återställer framsteg.

Virtuella nätverk annonserar fel storlek

Containerbryggor och VM-switchar kan ärva eller ha standard-MTU som är större än underliggande lager. Containern bygger då ett paket som är giltigt för dess virtuella gränssnitt men för stort efter att värden skickar det genom en VPN, molnöverlagring eller PPPoE-upplänk. Avlastningsfunktioner kan få inspelningar att se större ut än kabelframtida paket, så inspelningsplats är viktig.

Ett dokumenterat Docker-fall följde exakt detta underproblem: en liten LDAP-förfrågan lyckades, men svaret försvann eftersom VPN-MTU var 1400 medan Docker använde 1500. Värdnätverk verkade lösa appen eftersom det tog bort det felmatchade virtuella lagret, inte för att applikationen ändrades.

Dra inte slutsatser om kabelbeteende från en enda inspelning som visar jättestora TCP-segment. Generisk segmenteringsavlastning kan presentera stora buffertar för operativsystemet och dela upp dem senare. Fånga på mottagarsidan, inaktivera avlastningar tillfälligt för diagnos eller korrelera gränssnitts-räknare med kontrollerade paketstorlekstester innan du drar slutsatsen att en enhet skickade en omöjlig ram.

Inställningar för upstream och tunnel formar den verkliga gränsen

Hemmaservern är inte alltid platsen där mismatchen skapades. PPPoE, en ISP-övergångsmekanism, en fjärråtkomsttunnel eller en upstream-router kan introducera den smalaste länken. Spåra den exakta klient-till-tjänst-vägen och notera varje kapslingsgräns istället för att bara ändra den fysiska NIC:n.

Tillåt de kontrollmeddelanden som PMTUD behöver. För IPv4 inkluderar det det relevanta destination-unreachable fragmentation-needed-meddelandet; för IPv6 inkluderar det Packet Too Big. Använd en snäv brandväggspolicy efter meddelandetyp och tillstånd istället för att blockera all ICMP. En server kan inte lära sig en vägbegränsning som nätverket vägrar att rapportera.

Undvik att förlita dig på fragmentering som en normal lösning. RFC 8900 förklarar att IP-fragmentering medför operativ skörhet. Att anpassa MTU, bevara PMTUD eller göra transportproben säkert är mer robust än att anta att varje mellanbox vidarebefordrar och sätter ihop fragment.

Om en router inte kan ändras kan MSS-klämning vara en praktisk TCP-lösning vid tunneln eller vidarebefordringsgränsen. Ställ in den från den verkliga vägen istället för att kopiera ett universellt nummer. Det reparerar inte överstora UDP-datagram, och ett onödigt lågt värde ökar paket- och headeröverhuvud, så bekräfta förbättringen med fångster och applikationstester.

Server-, VM- och containerinställningar måste överensstämma

Inventera MTU på den fysiska NIC, bond, VLAN, brygga, VM-adapter, containernätverk och tunnel. Värdena behöver inte vara numeriskt identiska när ett lager korrekt tar hänsyn till kapsling, men inget inre lager ska producera paket som nästa lager inte kan bära eller rapportera som för stora.

För Docker, ställ in en lämplig MTU när du skapar nätverket eller via daemon-konfigurationen, och återskapa sedan berörda nätverk och containrar vid behov. Civos felsökningsexempel visar hur en Docker MTU som ignorerar underliggande lager kan orsaka oväntade anslutningsproblem. Verifiera den aktiva gränssnittet efteråt; att bara redigera konfigurationen bevisar inte att det körande nätverket ändrats.

Håll prestandaoptimering separat från reparation. ZimaSpaces förklaring av TCP-fönsterstorlek på långdistanslänkar handlar om hur mycket data som kan vara i flykt, medan MTU styr paketstorlek. Att öka buffertar kan inte få ett för stort paket att passa genom en mindre länk.

Kontroller som hittar det trasiga steget

Hitta det största paketet som konsekvent passerar

Använd plattformsanpassade ping-alternativ för att ställa in nyttolaststorlek och förhindra fragmentering där det stöds, och kom ihåg att lägga till IP- och ICMP-headerbitar när du jämför resultatet med ett gränssnitts MTU. Testa flera storlekar från samma klientväg som visar felet. En upprepbar tröskel är mer informativ än en lyckad standardping.

Upprepa testet på LAN, genom VPN och från insidan av containern eller VM. Om tröskeln ändras vid en gräns blir det lagret huvudmisstänkt. Vissa nätverk begränsar eller blockerar eko-trafik, så bekräfta resultatet med TCP-applikationsförfrågningar eller ett specialbyggt path-MTU-verktyg.

Inspektera gränssnitt, rutter och inkapsling

Registrera den valda rutten och utgångsgränssnittet för den berörda destinationen. Inspektera MTU-värden på varje virtuellt och fysiskt gränssnitt som paketet passerar, plus tunnel- och container-nätverkskonfiguration. Anta inte att standardrutten används när policyrouting eller split tunneling är aktivt.

Beräkna headeröverhuvud för den faktiska tunnelstacken, inklusive yttre IP-version och transport. Den säkra inre MTU:n måste lämna plats för dessa headers på den yttre vägen. Om tunneln använder en föränderlig rutt, välj ett värde som fungerar över dess stödda underliggande nätverk eller behåll en fungerande upptäcktsmekanism.

Fånga data och ICMP-feedback på båda sidor

Fånga nära sändaren och efter den misstänkta smala länken. Leta efter ett stort paket som upprepas utan bekräftelse, ett ICMP-meddelande om fragmentering krävs eller ett ICMPv6 Packet Too Big-meddelande. Om felet uppträder nedströms men aldrig når sändaren, fokusera på returväg och brandväggspolicy.

För TCP, inspektera MSS-alternativen i SYN- och SYN-ACK-paketen och jämför dem med de observerade datasegmenten. En lägre MSS kan förhindra att sändaren skapar för stora TCP-paket, men det avslöjar inte om UDP fortfarande är trasigt. Använd fångsten för att validera reparationen istället för att betrakta en laddad brandväggsregel som en framgång.

Justera MTU eller begränsa MSS, sedan testa igen

Föredra att korrigera MTU vid det gränssnitt som känner till den mindre underliggande. Återskapa virtuella nätverk när deras MTU är fastställd vid skapandet. Om det är omöjligt, kläm TCP MSS vid vidarebefordrings- eller tunnelgränsen och tillåt nödvändig ICMP-återkoppling. Gör en ändring i taget så att resultatet förblir spårbart.

Testa om det ursprungliga arbetsflödet, inte bara ping. Slutför TLS-förhandling, ladda en respons större än ett paket, ladda upp och ladda ner en fil och håll anslutningen aktiv tillräckligt länge för att observera omförsändelser. Partiell anslutning löses bara när de applikationer som exponerade den överför data pålitligt i båda riktningarna.

När partiell anslutning blir ett allvarligt problem

Behandla problemet som brådskande när det påverkar säkerhetskopior, återställningar, fjärradministration, synkronisering eller autentisering. Dessa arbetsflöden kan klara preliminära kontroller och bara misslyckas efter att meningsfull data börjar flyttas, vilket lämnar ofullständiga kopior eller timeout som operatörer misstolkar som lagrings- eller autentiseringsfel.

Prioritera det också när IPv6 beter sig annorlunda än IPv4, en VPN-endast-väg misslyckas eller containertrafik skiljer sig från värdtrafik. Dessa kontraster avslöjar vilken rutt eller inkapsling som ändrar den användbara paketstorleken. Ju mer deterministisk gränsen är, desto mindre användbart är det att fortsätta försöka med applikationen utan att reparera nätvägen.

Vanliga frågor

Varför kan jag pinga hemservern när dess webbplats inte laddas?

Standard ping-paket är små, liksom DNS-utbyten och TCP-handshakes. Webbplatsen kan bara stanna upp när TLS eller HTTP skickar ett paket över vägens gräns. Testa större icke-fragmenterande sonder och fånga den misslyckade webbanslutningen istället för att behandla ett ping-svar som bevis för att varje paketstorlek fungerar.

Bör varje gränssnitt använda en MTU på 1500?

Nej. Ethernet använder ofta 1500, men tunnlar och andra inkapslingar behöver utrymme för yttre headers. Det viktiga är att varje lager antingen annonserar en storlek som nästa lager kan hantera eller får fungerande återkoppling som låter det anpassa sig till den minsta MTU längs vägen.

Är MSS-klämning samma sak som att fixa MTU?

Nej. MSS-klämning ändrar den TCP-payloadstorlek som annonseras under anslutningsuppsättningen, vilket kan hålla TCP-paket under en känd gräns. Det ändrar inte gränssnittets MTU och begränsar inte direkt UDP eller annan IP-trafik.

MTU-justering och fungerande PMTUD hanterar själva vägen. Klämning är värdefull när en vidarebefordrande enhet eller tunnel annars inte kan kommunicera begränsningen, men det bör mätas, placeras vid rätt gräns och följas av tester av varje påverkad protokoll.