MTU eller MSS? Vad en VPN-ändring faktiskt åtgärdar

Ping lyckas, stora överföringar hänger sig och tunneln rapporterar sig som frisk. Någon sänker gränssnittets MTU, någon annan begränsar MSS, och ibland försvinner problemet av skäl som ingen skriver ned. De två talen beskriver olika objekt, så att ändra det felaktiga ger en åtgärd som ser ut som tur. Så här går det till: identifiera lagret, tillämpa motsvarande justering och testa sedan på en ny anslutning.

Två tal, två objekt

MTU hör till en länk eller ett gränssnitt: det är det största paket som kan lämnas över utan att delas. MSS hör till TCP: det är den största mängd TCP-nyttolast ett segment kan bära, och det utesluter både TCP- och IP-huvudet. På en vanlig Ethernet-länk med IPv4 ger en MTU på 1500 byte den välkända MSS:en på 1460 byte. Dessa tal beskriver olika lager och utbyts av olika mekanismer. Det är lätt att förväxla dem eftersom båda mäts i byte och båda ligger nära 1500.

Det ena kommer som en inställning på gränssnittet. Det andra kommer som ett alternativ inne i ett SYN-segment, förhandlat mellan ändpunkter som aldrig ser ditt gränssnitt.

Var den yttre overheaden landar

En VPN lägger det inre paketet inuti ett annat, och det yttre paketet måste rymmas i den fysiska vägen. Inkapslingshuvuden, det yttre IP-huvudet, transporthuvudet och eventuell autentiseringstagg förbrukar byte som det inre paketet inte kan använda. Låt tunnelgränssnittet stå på 1500, och det yttre paketet överskrider rutinmässigt vad vägen kan bära. Med 'fragmentera inte'-biten satt släpper routern det och ska skicka tillbaka ett ICMP-fel; om felet filtreras får avsändaren aldrig veta det.

Det är därför felet ser selektivt ut. Små förfrågningar slutförs och allt som fyller ett segment fastnar, eftersom bara de stora paketen kastas. En tunnel som släpper igenom en ping är inte en tunnel som bär data.

MSS-begränsning, och var den gäller

MSS-begränsning skriver om värdet i SYN-segmentet när det passerar en vald punkt, vilket får båda ändpunkterna att välja en mindre nyttolast utan att någon av dem vet varför. På Linux är det ett mål i mangle-tabellen som tillämpas av en explicit regel, och det måste träffa SYN-paket i den riktning du vill. Begränsa det till tunnelgränssnittet och adressområdet, eftersom en bred regel ändrar beteendet för trafik som aldrig kommer in i tunneln.

Effekten gäller bara TCP. En UDP-applikation, en QUIC-session och alla protokoll som bygger sina egna datagram lämnas orörda.

Diagnostisera med en fast väg

Håll en variabel i taget. Testa med ett paket vars storlek du väljer själv, och sätt flaggan 'fragmentera inte' så att kärnan rapporterar resultatet i stället för att dölja det.

Notera var felet börjar: inne i tunneln, vid tunnelgränssnittet eller på den fysiska vägen efter inkapslingen. Byt sedan ett tal och upprepa samma test i stället för ett annat. Befintliga anslutningar behåller den förhandlade MSS:en, så en policyändring syns bara på en ny anslutning, och därför bevisar en cachad sida ingenting i någon riktning. Om en stor uppladdning börjar fungera har du lärt dig om den vägen och inte om varje protokoll på den.

Vad varje ändring inte åtgärdar

Att sänka gränssnittets MTU ändrar inte MSS:en för en session som redan är upprättad. MSS-begränsning hjälper inte ett UDP-flöde och reparerar inte en väg där ICMP-fel bara filtreras i en riktning. Varje ändring åtgärdar en klass av problem och lämnar resten exakt som de var.

Skriv ned vilken justering du tillämpade, var och vilket test som visade skillnaden, annars tillämpar nästa ingenjör båda och förlorar förmågan att säga vilken som spelade roll. Om begränsningen är verklig och permanent, föredra en tunnel-MTU som speglar den framför en begränsning som döljer den. Om du måste begränsa, låt regeln vara snäv och kommenterad, eftersom en oförklarad mangle-regel blir permanent som standard.