MSS-clamping på en VPN-gateway: hva den retter og hva den ikke retter
Clamping skriver om MSS i TCP-håndtrykkene slik at segmentene passer i tunnelen. Den retter aldri UDP eller en ødelagt path-MTU-sjekk. Tre sjekker, i rekkefølge.
Små forespørsler virker, store nedlastinger henger, og noen foreslår MSS-clamping. Forslaget er riktig ofte nok til å være verdt et forsøk i riktig rekkefølge, og galt ofte nok til å kaste bort en ettermiddag hvis du bruker det i blinde. De tre sjekkene nedenfor skiller et ekte TCP-størrelsesproblem fra et UDP-problem, fra en ødelagt path-MTU-oppdagelse og fra en clamp som aldri ser håndtrykket den skal skrive om.
Start med feilens form
En størrelsesfeil har en signatur: forbindelsen etableres, autentisering og små svar lykkes, og deretter stopper en overføring på ubestemt tid når den trenger et fullstørrelsessegment. Sider som laster tekst men aldri fullfører et bilde er samme feil i mindre skala. Hvis ingenting kobler til i det hele tatt, ligger problemet tidligere i banen og clamping hjelper ikke. En clamp kan ikke reparere et håndtrykk som aldri kom fram.
Signaturen finnes fordi håndtrykket er stedet der segmentstørrelsen avtales. Hver side annonserer en maksimal segmentstørrelse som en TCP-opsjon, og avsendere respekterer motpartens annonse. Hvis banen ikke kan bære et så stort segment, viser feilen seg senere, når avsenderen endelig prøver ett.
Hold transporten i syne mens du leser det symptomet. Clamping er en omskriving av en TCP-opsjon, så en tale- eller videosamtale som stopper under samme tunnel er ikke et MSS-problem og blir ikke bedre av det. Skriv ned transporten før du rører en TCP-opsjon.
Pris banen, og sammenlign den så med tunnelen
To tall betyr noe, og de forveksles ofte. path-MTU er den største pakken banen bærer uten fragmentering, og den annonserte MSS for IPv4 er denne verdien minus de 40 bytene med IP- og TCP-hoder, eller minus 60 for IPv6. Tunnelinnkapsling spiser en del av budsjettet før den indre pakken i det hele tatt begynner.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20Ping med do-not-fragment-biten forteller deg om en pakke av den nyttelaststørrelsen overlever; juster størrelsen til den feiler, og du har funnet banens grense empirisk. tracepath-utdata rapporterer MTU-en som ble oppdaget langs ruten, noe som er raskere når det virker og mindre pålitelig når et mellomhopp filtrerer probene.
Trekk så fra tunnelens overhead. Et ytre IP-hode, et UDP-hode og et tunnelspesifikt hode kommer alle ut av de samme 1500 bytene, så den brukbare indre MTU-en på et typisk Ethernet-underlag er lavere enn den fysiske lenken antyder. Hvis den beregnede indre MTU-en er under det motpartene annonserer, har du funnet en ekte clamp-kandidat og ikke en gjetning. Hvis den beregnede verdien allerede er over motpartenes annonse, stopp her og se et annet sted.
Plasser clampsen der håndtrykket passerer
En clamp virker ved å skrive om MSS-opsjonen i SYN- og SYN-ACK-pakkene når de krysser gatewayen. Hvis regelen sitter på et grensesnitt som ingen av retningene noen gang krysser, fullføres forhandlingen uendret og symptomet består, og derfor avgjør plasseringen resultatet mer enn verdien.
| 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 andre halvdelen. Clamping i én retning retter halvparten av strømmene og lar resten feile på en måte som virker periodisk, så bruk det på begge retninger av trafikken som videresendes. Den klassiske Linux-formen for et tunnelgrensesnitt er en mangle-regel som matcher SYN-pakker:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuLegg merke til hva --clamp-mss-to-pmtu faktisk gjør: den utleder verdien fra rutens MTU, som ikke alltid er tunnelens reelle nyttelastbudsjett. På en rutebasert tunnel der den indre ruten og den ytre banen er forskjellige, er en eksplisitt verdi beregnet i forrige sjekk mer forutsigbar enn en automatisk.
Verifiser med en ny forbindelse, og hold tilbakemeldingen levende
En etablert forbindelse beholder MSS-en den forhandlet, så testing i samme økt beviser ingenting. Åpne en ny forbindelse etter endringen og les den forhandlede verdien direkte i stedet for å utlede den fra en overføring som tilfeldigvis fullføres.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSDen første kommandoen rapporterer socketens MSS sammen med overbelastningstilstanden, noe som er den raskeste bekreftelsen på at clampsen virket. Den andre bekrefter at regelen du tror du la til, er regelen som finnes, i tabellen der den ble plassert.
Beskytt så mekanismen du ikke rettet. path-MTU-oppdagelse avhenger av at ICMP fragmentation-needed-meldinger når avsenderen, så en brannmur som slipper dem vil fortsette å ødelegge store overføringer selv med en korrekt clamp. Tillat disse meldingene for tunnelbanen, eller aksepter at clamping kompenserer for en policy du selv valgte.
Til slutt må du motstå fristelsen til å behandle clampsen som en justeringsknapp. Den begrenser segmentstørrelsen, noe som koster gjennomstrømning på baner som aldri trengte det. Brukt etter de tre sjekkene er den en målrettet reparasjon; brukt først er den en endring som skjuler den opprinnelige feilen og legger til en annen variabel i hver senere test. Den byttehandelen er verdt å gjøre bevisst, ikke som standard.
Skriv ned path-MTU-en du målte, tunnel-overheaden du trakk fra, regelen du la til og MSS-en du så etterpå. Fire tall gjør neste hendelse til et oppslag i stedet for en undersøkelse.