MSS-clamping på en VPN-gateway: hvad den retter, og hvad den ikke retter
Clamping omskriver MSS i TCP-handshakes, så segmenterne passer i tunnelen. Den retter aldrig UDP eller et ødelagt path-MTU-tjek. Tre tjek, i rækkefølge.
Små anmodninger virker, store downloads hænger, og nogen foreslår MSS-clamping. Det forslag er rigtigt ofte nok til at være værd at prøve i den rigtige rækkefølge og forkert ofte nok til at spilde en eftermiddag, hvis du anvender det i blinde. De tre tjek nedenfor adskiller et ægte TCP-størrelsesproblem fra et UDP-problem, fra en ødelagt path-MTU-opdagelse og fra en clamp, der aldrig ser det handshake, den skal omskrive.
Start med fejlens form
En størrelsesfejl har en signatur: forbindelsen oprettes, godkendelse og små svar lykkes, og derefter går en overførsel i stå på ubestemt tid, når den har brug for et segment i fuld størrelse. Sider, der indlæser tekst, men aldrig færdiggør et billede, er samme fejl i mindre målestok. Hvis intet overhovedet forbinder, ligger problemet tidligere på vejen, og clamping hjælper ikke. En clamp kan ikke reparere et handshake, der aldrig nåede frem.
Signaturen findes, fordi handshaket er stedet, hvor segmentstørrelsen aftales. Hver side annoncerer en maksimal segmentstørrelse som en TCP-option, og afsendere respekterer modpartens annoncering. Hvis vejen ikke kan bære et så stort segment, viser fejlen sig senere, når afsenderen endelig prøver et.
Hold transporten i syne, mens du læser det symptom. Clamping er en omskrivning af en TCP-option, så et tale- eller videoopkald, der går i stå under den samme tunnel, er ikke et MSS-problem og bliver ikke bedre af det. Skriv transporten ned, før du rører en TCP-option.
Pris vejen, og sammenlign den så med tunnelen
To tal betyder noget, og de forveksles ofte. path-MTU er den største pakke, vejen bærer uden fragmentering, og den annoncerede MSS for IPv4 er denne værdi minus de 40 byte IP- og TCP-headere, eller minus 60 for IPv6. Tunnelindkapsling spiser en del af budgettet, før den indre pakke overhovedet begynder.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20Pinget med do-not-fragment-bitten fortæller dig, om en pakke af den nyttelaststørrelse overlever; justér størrelsen, indtil det fejler, og du har fundet vejens grænse empirisk. tracepath-outputtet rapporterer den MTU, der blev opdaget undervejs, hvilket er hurtigere, når det virker, og mindre pålideligt, når et mellemhop filtrerer proberne.
Træk nu tunnelens overhead fra. En ydre IP-header, en UDP-header og en tunnelspecifik header kommer alle ud af de samme 1500 byte, så den brugbare indre MTU på et typisk Ethernet-underlag er lavere, end det fysiske link antyder. Hvis den beregnede indre MTU er under det, dine modparter annoncerer, har du fundet en rigtig clamp-kandidat frem for et gæt. Hvis den beregnede værdi allerede er over annonceringen, så stop her og kig andre steder.
Placér clampsen, hvor handshaket passerer
En clamp virker ved at omskrive MSS-optionen i SYN- og SYN-ACK-pakkerne, når de krydser gatewayen. Hvis reglen sidder på et interface, som ingen af retningerne nogensinde krydser, fuldføres forhandlingen uændret, og symptomet består, og derfor afgør placeringen resultatet mere end værdien.
| 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 |
Retningen er den anden halvdel. Clamping i én retning retter halvdelen af flows og lader resten fejle på en måde, der ser periodisk ud, så anvend det på begge retninger af den videresendte trafik. Den klassiske Linux-form for et tunnelinterface er en mangle-regel, der matcher SYN-pakker:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuBemærk, hvad --clamp-mss-to-pmtu faktisk gør: den udleder værdien fra rutenes MTU, som ikke altid er tunnelens reelle nyttelastbudget. På en rutebaseret tunnel, hvor den indre rute og den ydre vej er forskellige, er en eksplicit værdi beregnet i det forrige tjek mere forudsigelig end en automatisk.
Bekræft med en ny forbindelse, og hold feedbacken i live
En etableret forbindelse beholder den MSS, den forhandlede, så test på samme session beviser intet. Åbn en frisk forbindelse efter ændringen, og læs den forhandlede værdi direkte i stedet for at udlede den af en overførsel, der tilfældigvis bliver færdig.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSDen første kommando rapporterer socketens MSS sammen med dens overbelastningstilstand, hvilket er den hurtigste bekræftelse på, at clampen virkede. Den anden bekræfter, at den regel, du tror, du tilføjede, er den regel, der findes, i den tabel, hvor den blev placeret.
Beskyt derefter den mekanisme, du ikke rettede. path-MTU-opdagelse afhænger af, at ICMP fragmentation-needed-beskeder når afsenderen, så en firewall, der dropper dem, vil fortsat ødelægge store overførsler, selv med en korrekt clamp på plads. Tillad disse beskeder for tunnelens vej, eller accepter, at clamping kompenserer for en politik, du selv har valgt.
Modstå til sidst fristelsen til at behandle clampen som en tuningknap. Den begrænser segmentstørrelsen, hvilket koster gennemstrømning på veje, der aldrig havde brug for det. Anvendt efter de tre tjek er den en målrettet reparation; anvendt først er den en ændring, der skjuler den oprindelige fejl og tilføjer en anden variabel til hver senere test. Den handel er værd at gøre bevidst, ikke som standard.
Skriv den path-MTU ned, du målte, det tunnel-overhead du trak fra, den regel du tilføjede, og den MSS, du så bagefter. Fire tal gør den næste hændelse til et opslag i stedet for en undersøgelse.