MSS-clamping på en VPN-gateway: vad den åtgärdar och vad den inte åtgärdar
Clamping skriver om MSS i TCP-handskakningar så att segmenten får plats i tunneln. Den åtgärdar aldrig UDP eller en trasig path-MTU-kontroll. Tre kontroller, i ordning.
Små förfrågningar fungerar, stora nedladdningar hänger sig, och någon föreslår MSS-clamping. Förslaget är tillräckligt ofta rätt för att vara värt ett försök i rätt ordning, och tillräckligt ofta fel för att slösa bort en eftermiddag om du använder det blint. De tre kontrollerna nedan skiljer ett verkligt TCP-storleksproblem från ett UDP-problem, från en trasig path-MTU-upptäckt och från en clamp som aldrig ser handskakningen den ska skriva om.
Börja med felets form
Ett storleksfel har en signatur: anslutningen etableras, autentisering och små svar lyckas, och sedan stannar en överföring på obestämd tid så snart den behöver ett segment i full storlek. Sidor som laddar text men aldrig färdigställer en bild är samma fel i mindre skala. Om ingenting alls ansluter ligger problemet tidigare i vägen och clamping hjälper inte. En clamp kan inte reparera en handskakning som aldrig kom fram.
Signaturen finns eftersom handskakningen är platsen där segmentstorleken avtalas. Varje sida annonserar en maximal segmentstorlek som TCP-alternativ, och avsändare respekterar motpartens annons. Om vägen inte kan bära ett så stort segment visas felet senare, när avsändaren äntligen försöker med ett.
Håll transporten i sikte medan du läser det symptomet. Clamping är en omskrivning av ett TCP-alternativ, så ett tal- eller videosamtal som fastnar under samma tunnel är inte ett MSS-problem och blir inte bättre av det. Skriv ner transporten innan du rör ett TCP-alternativ.
Prissätt vägen och jämför den sedan med tunneln
Två tal spelar roll och de blandas ofta ihop. path-MTU är det största paket som vägen bär utan fragmentering, och den annonserade MSS för IPv4 är det värdet minus de 40 byte IP- och TCP-huvuden, eller minus 60 för IPv6. Tunnelinkapsling äter en del av budgeten innan det inre paketet ens börjar.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20Pinget med do-not-fragment-biten berättar om ett paket av den nyttolaststorleken överlever; justera storleken tills det misslyckas och du har hittat vägens gräns empiriskt. tracepath-utdata rapporterar den MTU som upptäckts längs rutten, vilket är snabbare när det fungerar och mindre tillförlitligt när ett mellanhopp filtrerar sonderna.
Dra sedan av tunnelns overhead. Ett yttre IP-huvud, ett UDP-huvud och ett tunnelspecifikt huvud kommer alla ur samma 1500 byte, så den användbara inre MTU:n på ett typiskt Ethernet-underlag är lägre än den fysiska länken antyder. Om den beräknade inre MTU:n ligger under vad dina motparter annonserar har du hittat en riktig clamp-kandidat och inte en gissning. Om det beräknade värdet redan ligger över motparternas annons, stanna här och titta någon annanstans.
Placera clampsen där handskakningen passerar
En clamp fungerar genom att skriva om MSS-alternativet i SYN- och SYN-ACK-paketen när de passerar gatewayen. Om regeln sitter på ett gränssnitt som ingen av riktningarna någonsin passerar slutförs förhandlingen oförändrad och symptomet kvarstår, därför avgör placeringen resultatet mer än värdet.
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
Riktningen är den andra halvan. Clamping i en riktning åtgärdar hälften av flödena och låter resten misslyckas på ett sätt som verkar intermittent, så tillämpa det på båda riktningarna av trafiken som vidarebefordras. Den klassiska Linux-formen för ett tunnelgränssnitt är en mangle-regel som matchar SYN-paket:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuLägg märke till vad --clamp-mss-to-pmtu faktiskt gör: den härleder värdet från ruttens MTU, vilket inte alltid är tunnelns verkliga nyttolastbudget. På en ruttbaserad tunnel där den inre rutten och den yttre vägen skiljer sig är ett explicit värde beräknat i föregående kontroll mer förutsägbart än ett automatiskt.
Verifiera med en ny anslutning och håll återkopplingen levande
En etablerad anslutning behåller den MSS den förhandlade, så testning i samma session bevisar ingenting. Öppna en ny anslutning efter ändringen och läs det förhandlade värdet direkt i stället för att härleda det från en överföring som råkar bli klar.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSDet första kommandot rapporterar socketens MSS tillsammans med dess överbelastningsstatus, vilket är den snabbaste bekräftelsen på att clampsen verkat. Det andra bekräftar att regeln du tror att du lade till är regeln som finns, i tabellen där den placerades.
Skydda sedan mekanismen du inte åtgärdade. path-MTU-upptäckt beror på att ICMP fragmentation-needed-meddelanden når avsändaren, så en brandvägg som släpper dem kommer att fortsätta bryta stora överföringar även med en korrekt clamp. Tillåt dessa meddelanden för tunnelvägen, eller acceptera att clamping kompenserar för en policy du själv valt.
Till sist, motstå frestelsen att behandla clampsen som en justeringsratt. Den begränsar segmentstorleken, vilket kostar genomströmning på vägar som aldrig behövde det. Använd efter de tre kontrollerna är den en riktad reparation; använd först är den en ändring som döljer det ursprungliga felet och lägger till en andra variabel i varje senare test. Den avvägningen är värd att göra medvetet, inte som standard.
Skriv ner den uppmätta path-MTU:n, tunnel-overheaden du drog av, regeln du lade till och den MSS du såg efteråt. Fyra tal gör nästa incident till ett uppslag i stället för en utredning.