Upptäckt av banans MTU genom en VPN: dimensionering och ICMP-gapet

En tunnel slutför sin handskakning, små förfrågningar kommer tillbaka, och den första stora överföringen stannar. Det mönstret pekar på banans MTU långt innan det pekar på genomströmning. Varje länk längs vägen begränsar paketstorleken, och inkapslingen spenderar en del av den kvoten på yttre rubriker, så det inre paketet måste vara mindre än den råa vägen skulle antyda. Felet är tyst, och det är just därför det är dyrt att diagnostisera.

Vad banans MTU faktiskt mäter

Banans MTU är den minsta länk-MTU:n på vägen mellan två värdar, inte den MTU som är tryckt på ditt lokala gränssnitt. Det lokala värdet är där uppskattningen börjar, och vägen avgör var den måste sluta. Det är därför en identisk tunnel kan fungera i ett åtkomstnät och stanna i ett annat: vägen ändrades, inte konfigurationen. Att mäta en gång och anta överallt är felet som håller det här problemet vid liv.

För en tunnel är talet som spelar roll den inre MTU:n, det vill säga den yttre vägens kvot minus det inkapslingen förbrukar. WireGuard lägger till en yttre IP-rubrik och en UDP-rubrik; andra transportlager lägger till sina egna. Ställ den inre storleken för högt och varje paket i full storlek behöver fragmentering som kanske aldrig sker.

Varför en tunnel krymper det användbara paketet

Om tunnelgränssnittet behåller den fysiska länkens MTU beror varje stort paket på att någon längre ned är villig att fragmentera det. IPv4 tillåter det i princip, men en router som fått order om att inte fragmentera returnerar ett fel i stället. IPv6-routrar fragmenterar aldrig under transport, så samma inställning beter sig olika beroende på adressfamilj. Hur som helst lär sig avsändaren ingenting förrän något rapporterar tillbaka.

Den praktiska konsekvensen är en storlek som passar i handskakningen men inte i nyttolasten. En TLS ClientHello eller en DNS-fråga är liten nog att passera en krympt väg orörd, medan en massöverföring inte är det. Symtomen samlas därför kring specifika operationer och inte specifika värdar.

Upptäckten fungerar bara när återkopplingen kommer fram

IPv4-upptäckt bygger på don't-fragment-biten: en router som inte kan vidarebefordra paketet returnerar ICMP fragmentation-needed med nästa hopps MTU, och avsändaren sänker sin uppskattning. IPv6 använder i stället Packet Too Big-meddelanden, eftersom routrar inte fragmenterar under transport. Båda mekanismerna förutsätter att meddelandet hittar vägen tillbaka till avsändaren, genom tunneln och förbi alla brandväggar på returvägen. När den förutsättningen brister fortsätter avsändaren att prova en storlek som vägen inte kan bära.

En brandvägg som tillåter echo request och echo reply har inte nödvändigtvis tillåtit de feltyperna. ICMP är en familj, och medlemmarna som spelar roll här är felen, inte ekoparet. Kontrollera policyn för kontrolltrafik i båda ändar av tunneln och på vägen mellan dem, och följ plattformens rekommenderade vägledning i stället för att tillåta alla ICMP-typer överallt.

Samma filtrering kan sitta inne i tunneln. Om den inre vägen släpper felet men den yttre vägen bär det, kan avsändaren anpassa sig till en gräns som den inkapslade trafiken aldrig egentligen ser.

Testa vägen i stället för att gissa ett tal

Håll destinationen, åtkomstnätet och tunneln fasta och variera bara paketstorleken. Ett don't-fragment-test som misslyckas med en MTU-ledtråd ger dig gränsen för nästa hopp; upprepa tills en storlek passerar, och notera både storleken och adressfamiljen.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

En ping som passar bevisar inte att fullstorlekssegment från en verklig applikation passar, så upprepa testet med överföringen som faktiskt misslyckades. Jämför det största fungerande testet med den tunnel-MTU du konfigurerade, och håll de två talen åtskilda i dina anteckningar. Om de skiljer sig med ungefär en rubrik har du hittat inkapslingsöverheaden och inte ett fel.

PLPMTUD, som beskrivs i RFC 4821, testar uppåt och använder transportbekräftelser i stället för att lita på levererade fel. Det hjälper på vägar som filtrerar ICMP, men stödet varierar beroende på stack och applikation. Ett TCP-flöde kan återhämta sig självt medan en UDP-applikation med fast datagramstorlek fortsätter att misslyckas.

Välj ett värde och dokumentera resonemanget

Att sänka tunnel-MTU:n är både en diagnos och en legitim åtgärd när du väl känner vägen. Det ersätter inte kunskapen om vilken väg och vilken återkopplingsmekanism som var inblandad, eftersom ett värde anpassat för en mobillänk blir onödigt litet på en fiberanslutning. Notera den valda storleken, testet som motiverade den och återställningssteget.

IPv4-mekanismen beskrivs i RFC 1191 och IPv6-paketeringsvägledningen i RFC 8201; att nämna båda hindrar nästa ingenjör från att härleda antagandet igen. Om överföringen fortfarande stannar vid den storlek du valde, sluta sänka talet och titta på nästa lager. En väg som misslyckas vid varje storlek är inte ett MTU-problem.