MSS-clamping på ein VPN-gateway: kva han rettar og kva han ikkje rettar

Små førespurnader verkar, store nedlastingar heng, og nokon føreslår MSS-clamping. Forslaget er riktig ofte nok til å vere verdt eit forsøk i riktig rekkjefølgje, og gale ofte nok til å kaste bort ein ettermiddag om du brukar det i blinde. Dei tre sjekkane nedanfor skil eit ekte TCP-storleiksproblem frå eit UDP-problem, frå ei øydelagd path-MTU-oppdaging og frå ein clamp som aldri ser handtrykket han skal skrive om.

Start med forma på feilen

Ein storleiksfeil har ein signatur: sambandet vert oppretta, autentisering og små svar lukkast, og deretter stoppar ein overføring på ubestemt tid når han treng eit segment i full storleik. Sider som lastar tekst men aldri fullfører eit bilete er same feilen i mindre skala. Viss ingenting koplar til i det heile, ligg problemet tidlegare i banen og clamping hjelper ikkje. Ein clamp kan ikkje reparere eit handtrykk som aldri kom fram.

Signaturen finst fordi handtrykket er staden der segmentstorleiken vert avtalt. Kvar side annonserer ein maksimal segmentstorleik som ein TCP-opsjon, og avsendarar respekterer annonsen til motparten. Viss banen ikkje kan bere eit så stort segment, viser feilen seg seinare, når avsendaren endeleg prøver eitt.

Hald transporten i syne medan du les det symptomet. Clamping er ei omskriving av ein TCP-opsjon, så ein tale- eller videosamtale som stoppar under same tunnel er ikkje eit MSS-problem og vert ikkje betre av det. Skriv ned transporten før du rører ein TCP-opsjon.

Pris banen, og samanlikn han så med tunnelen

To tal betyr noko, og dei vert ofte forveksla. path-MTU er den største pakken banen ber utan fragmentering, og den annonserte MSS for IPv4 er denne verdien minus dei 40 byta med IP- og TCP-hovud, eller minus 60 for IPv6. Tunnelinnkapsling et ein del av budsjettet før den indre pakken i det heile byrjar.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Ping med do-not-fragment-biten fortel deg om ein pakke av den nyttelaststorleiken overlever; juster storleiken til han feilar, og du har funne grensa til banen empirisk. tracepath-utdata rapporterer MTU-en som vart oppdaga langs ruta, noko som er raskare når det verkar og mindre påliteleg når eit mellomhopp filtrerer probane.

Trekk så frå overheaden til tunnelen. Eit ytre IP-hovud, eit UDP-hovud og eit tunnelspesifikt hovud kjem alle ut av dei same 1500 byta, så den brukbare indre MTU-en på eit typisk Ethernet-underlag er lågare enn den fysiske lenka antydar. Viss den berekna indre MTU-en er under det motpartane annonserer, har du funne ein ekte clamp-kandidat og ikkje ei gissing. Viss den berekna verdien allereie er over annonsen til motpartane, stopp her og sjå ein annan stad.

Plasser clampsen der handtrykket passerer

Ein clamp verkar ved å skrive om MSS-opsjonen i SYN- og SYN-ACK-pakkane når dei kryssar gatewayen. Viss regelen sit på eit grensesnitt som ingen av retningane nokon gong kryssar, vert forhandlinga fullført uendra og symptomet står ved lag, og difor avgjer plasseringa resultatet meir enn verdien.

Retninga er den andre halvdelen. Clamping i éi retning rettar halvparten av straumane og lèt resten feile på ein måte som verkar periodisk, så bruk det på begge retningane av trafikken som vert vidaresend. Den klassiske Linux-forma for eit tunnelgrensesnitt er ein mangle-regel som matchar SYN-pakkar:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Legg merke til kva --clamp-mss-to-pmtu faktisk gjer: han leier verdien ut frå MTU-en til ruta, som ikkje alltid er det reelle nyttelastbudsjettet til tunnelen. På ein rutebasert tunnel der den indre ruta og den ytre banen er ulike, er ein eksplisitt verdi rekna ut i førre sjekk meir føreseieleg enn ein automatisk.

Stadfest med ei ny tilkopling, og hald tilbakemeldinga levande

Ei etablert tilkopling held på MSS-en ho forhandla, så testing i same økt provar ingenting. Opne ei ny tilkopling etter endringa og les den forhandla verdien direkte i staden for å leie han ut frå ein overføring som tilfeldigvis vert fullført.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

Den første kommandoen rapporterer MSS-en til socketen saman med overbelastningstilstanden, noko som er den raskaste stadfestinga på at clampsen verka. Den andre stadfestar at regelen du trur du la til, er regelen som finst, i tabellen der han vart plassert.

Vernda så mekanismen du ikkje retta. path-MTU-oppdaging er avhengig av at ICMP fragmentation-needed-meldingar når avsendaren, så ein brannmur som slepp dei vil halde fram med å øydeleggje store overføringar sjølv med ein korrekt clamp. Tillat desse meldingane for tunnelbanen, eller godta at clamping kompenserer for ein politikk du sjølv valde.

Til slutt må du motstå freistinga til å handsame clampsen som ein justeringsknapp. Han avgrensar segmentstorleiken, noko som kostar gjennomstrøyming på baner som aldri trong det. Brukt etter dei tre sjekkane er han ein målretta reparasjon; brukt først er han ei endring som gøymer den opphavlege feilen og legg til ein annan variabel i kvar seinare test. Den byttehandelen er verdt å gjere medvite, ikkje som standard.

Skriv ned path-MTU-en du målte, tunnel-overheaden du trekte frå, regelen du la til og MSS-en du såg etterpå. Fire tal gjer neste hending til eit oppslag i staden for ei undersøking.