VPN-MTU-myter: varför dina paket krymper och vart utrymmet tar vägen

Någon säger att VPN:et "tappar paket på grund av MTU", du ställer in tunneln på 1400 och överföringen fungerar igen. Det resultatet känns som en diagnos. Oftast är det en slump i aritmetiken: du valde ett tal som var litet nog att rymmas under en gräns du aldrig identifierade, och du kommer att möta samma gräns igen i nästa nät med en annan budget.

Två myter orsakar det mesta av detta. Den första är att tunnelgränssnittets MTU är banans MTU. Den andra är att inkapsling kostar "en header" och att PPPoE inte kostar något som är värt att räkna. Båda är fel på sätt som får talet du väljer att verka godtyckligt när det faktiskt är bestämt.

Myte ett: tunnelns MTU är banans MTU

Värdet du ställer in på ett tunnelgränssnitt är ett lokalt löfte om det största inre paketet som implementationen lämnar nedåt. Banans verkliga kapacitet är en egenskap hos varje länk mellan dig och den bortre änden, och den kan ändras när en rutt ändras, när en mobil anslutning lämnas över eller när trafiken tar en annan peering. En inställd 1500 talar om vad din värd bygger, inte vad nätet bär.

Upptäckt av banans MTU finns för att förena de två, och den beror på återkoppling. Med IPv4 ska en router som inte kan vidarebefordra ett paket i full storlek skicka ett ICMP-meddelande "fragmentation needed", och avsändaren sänker sin uppskattning. Med IPv6 är motsvarigheten ett Packet Too Big-meddelande, och routrar fragmenterar inte alls under transport. När den återkopplingen filtreras fortsätter avsändaren att producera paket som banan inte kan bära, och ingenting berättar varför.

Myte två: inkapsling kostar en header

Räkna de yttre lagren ärligt. En yttre IP-header är 20 byte vid IPv4 eller 40 vid IPv6. UDP-inkapsling för NAT-passage lägger till 8. Tunnelprotokollet lägger till sin egen header, en initieringsvektor eller nonce, utfyllnad till chifferns block- eller justeringsgräns, en trailer och ett integritetskontrollvärde. Beroende på protokoll och chiffer ligger summan bekvämt i tiotal byte innan det inre paketet ens börjar.

Dra sedan ifrån igen för det inre paketets egna headers. Ett TCP-segment inne i tunneln bär sin egen 20-byte IP-header och 20-byte TCP-header, och TCP:s MSS härleds från MTU:n, inte från tunnelns nominella nyttolast. Därför kan ping med mindre nyttolast lyckas medan en filöverföring fastnar: verktygen testar olika saker, och bara ett av dem övar ett TCP-segment i full storlek.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Det första kommandot rapporterar den inställda tunnel-MTU:n. De två sonderna skickar en nyttolast på 1472 byte, vilket med 28 byte IPv4- och ICMP-headers är ett paket på 1500 byte, och sedan ett mindre. Om den stora sonden misslyckas helt och den lilla lyckas har du ett storleksberoende fel och inte ett allmänt routingproblem.

Myte tre: PPPoE ger dig fortfarande rena 1500

En vanlig PPPoE-anslutningslänk bär inte ett IP-paket på 1500 byte. PPPoE-headern plus PPP-protokollfältet tar 8 byte inne i Ethernet-ramen, vilket lämnar 1492 till IP-paketet. Det är den traditionella gränsen som beskrivs i RFC 2516. Kör du en VPN över en sådan länk kommer tunnelns overhead från de 1492, inte från 1500.

RFC 4638 definierar ett sätt att förhandla om en större PPP-nyttolast när både åtkomstkoncentratorn och kundens utrustning stöder det, och därför bevisar "den här anslutningen använder PPPoE" ensamt inte ett specifikt tal. En lokal inställning kan inte tvinga en mellanliggande enhet att acceptera ett paket den aldrig konfigurerades för, så den användbara frågan är vad länken faktiskt förhandlade, inte vad etiketten säger.

Varför felet verkar selektivt

Att små förfrågningar lyckas och stora överföringar fastnar är den klassiska signaturen för ett svart hål i banans MTU. Handskakningen, DNS-frågan och API-anropet får alla plats; massöverföringen producerar segment i full storlek som dör på en länk, och ICMP-meddelandet som skulle ha rapporterat problemet kommer aldrig fram. Anslutningen ser bra ut och nedladdningen hänger, vilket får folk att titta på servern i stället för banan.

Ett andra, besläktat misstag är att blanda ihop tre tal: gränssnittets MTU, TCP:s MSS och protokollets egen fragmenterings- eller utfyllnadsinställning. MSS-klämning på en router skriver om den annonserade MSS:en så att avsändaren bygger mindre segment; det ändrar inte tunnel-MTU:n och hjälper inte UDP-trafik. Att ge alla tre samma tal för att de verkar besläktade är hur en välmenande ändring förstör en fungerande konfiguration.

Vad som ska ändras, och i vilken ordning

Börja med bevis. Bekräfta med sonderna ovan att felet är storleksberoende, och hitta sedan den minsta storlek som går igenom och den största som misslyckas. Kontrollera åtkomstlänkens verkliga MTU innan du skyller på tunneln; en PPPoE-länk begränsar budgeten innan din VPN rör den. Anteckna de ursprungliga värdena så att ändringen kan rullas tillbaka.

Använd sedan den minsta justering som klienten dokumenterar. Många klienter erbjuder en tunnel-MTU plus ett MSS-reparationsalternativ, och MSS-alternativet är ofta den bättre hävstången för TCP eftersom det når avsändaren utan att krympa varje paket. Testa samma mål och samma överföring igen, och anteckna talen du landade på. Ett tunnelvärde som fungerar i ett åtkomstnät är inte en universell konstant, och nästa plats har sin egen budget.