MSS-clamping VPN-yhdyskäytävässä: mitä se korjaa ja mitä ei
Clamping kirjoittaa MSS:n uudelleen TCP-kättelyissä, jotta segmentit mahtuvat tunneliin. Se ei koskaan korjaa UDP:tä eikä rikkinäistä path-MTU-tarkistusta. Kolme tarkistusta, järjestyksessä.
Pienet pyynnöt toimivat, suuret lataukset jumittuvat, ja joku ehdottaa MSS-clampingia. Ehdotus on riittävän usein oikeassa, että se kannattaa kokeilla oikeassa järjestyksessä, ja riittävän usein väärässä, että sokeasti sovellettuna menettää iltapäivän. Alla olevat kolme tarkistusta erottavat todellisen TCP-koko-ongelman UDP-ongelmasta, rikkinäisestä path-MTU-havainnosta ja clampista, joka ei koskaan näe kättelyä, jonka se olisi määrä kirjoittaa uudelleen.
Aloita vian muodosta
Koko ongelmalla on allekirjoitus: yhteys muodostuu, todennus ja pienet vastaukset onnistuvat, ja sitten siirto pysähtyy määräämättömäksi ajaksi, kun se tarvitsee täysikokoisen segmentin. Sivut, jotka lataavat tekstiä mutta eivät koskaan saa kuvaa valmiiksi, ovat sama vika pienemmässä mittakaavassa. Jos mitään ei yhdistä lainkaan, ongelma on polulla aiemmin eikä clamping auta. Clamp ei voi korjata kättelyä, joka ei koskaan saapunut.
Allekirjoitus on olemassa siksi, että kättely on paikka, jossa segmentin koosta sovitaan. Kumpikin osapuoli ilmoittaa suurimman segmentin koon TCP-asetuksena, ja lähettäjät kunnioittavat vastapuolen ilmoitusta. Jos polku ei kanna niin suurta segmenttiä, vika ilmenee myöhemmin, kun lähettäjä lopulta yrittää sellaista.
Pidä kuljetus näkyvissä, kun luet tuota oiretta. Clamping on TCP-asetuksen uudelleenkirjoitus, joten saman tunnelin alla jumittuva puhelu tai videopuhelu ei ole MSS-ongelma eikä parane siitä. Kirjoita kuljetus muistiin ennen kuin kosket TCP-asetukseen.
Hinnoittele polku ja vertaa sitä sitten tunneliin
Kaksi lukua merkitsevät, ja ne sekoitetaan usein. path-MTU on suurin paketti, jonka polku kantaa ilman pirstoutumista, ja IPv4:n ilmoitettu MSS on tämä arvo miinus 40 tavua IP- ja TCP-otsikoita, tai miinus 60 IPv6:lle. Tunnelointi syö osan budjetista jo ennen kuin sisempi paketti edes alkaa.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20Ping do-not-fragment-bitillä kertoo, säilyykö kyseisen hyötykuorman kokoinen paketti; säädä kokoa, kunnes se epäonnistuu, ja olet löytänyt polun rajan empiirisesti. tracepathin tuloste ilmoittaa reitillä havaitun MTU:n, mikä on nopeampaa, kun se toimii, ja vähemmän luotettavaa, kun välihyppy suodattaa kokeet.
Vähennä nyt tunnelin ylikuorma. Ulompi IP-otsikko, UDP-otsikko ja tunnelikohtainen otsikko tulevat kaikki samoista 1500 tavusta, joten käytettävissä oleva sisempi MTU tyypillisessä Ethernet-aluksessa on pienempi kuin fyysinen linkki antaa ymmärtää. Jos laskettu sisempi MTU on pienempi kuin vastapuolten ilmoitus, olet löytänyt todellisen clamp-ehdokkaan etkä arvauksen. Jos laskettu arvo on jo ilmoituksen yläpuolella, pysähdy tähän ja katso muualle.
Sijoita clamp sinne, missä kättely kulkee
Clamp toimii kirjoittamalla MSS-asetuksen uudelleen SYN- ja SYN-ACK-paketeissa niiden ylittäessä yhdyskäytävää. Jos sääntö istuu liittymässä, jota kumpikaan suunta ei koskaan ylitä, neuvottelu päättyy muuttumattomana ja oire jatkuu, minkä vuoksi sijoittelu ratkaisee lopputuloksen enemmän kuin arvo.
| 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 |
Suunta on toinen puoli. Yhden suunnan clampaus korjaa puolet virroista ja jättää loput epäonnistumaan tavalla, joka näyttää ajoittaiselta, joten käytä sitä edelleenlähetetyn liikenteen molempiin suuntiin. Klassinen Linux-muoto tunneliliittymälle on mangle-sääntö, joka osuu SYN-paketteihin:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuHuomaa, mitä --clamp-mss-to-pmtu oikeastaan tekee: se johtaa arvon reitin MTU:sta, mikä ei aina ole tunnelin todellinen hyötykuormabudjetti. Reittipohjaisessa tunnelissa, jossa sisempi reitti ja ulompi polku eroavat, aiemmassa tarkistuksessa laskettu eksplisiittinen arvo on ennustettavampi kuin automaattinen.
Vahvista uudella yhteydellä ja pidä palaute elossa
Muodostettu yhteys pitää neuvotellun MSS:n, joten samassa istunnossa testaaminen ei todista mitään. Avaa muutoksen jälkeen uusi yhteys ja lue neuvoteltu arvo suoraan sen sijaan, että päättelet sen siirrosta, joka sattuu valmistumaan.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSEnsimmäinen komento ilmoittaa socketin MSS:n yhdessä ruuhkatilansa kanssa, mikä on nopein vahvistus siitä, että clamp vaikutti. Toinen vahvistaa, että sääntö, jonka luulet lisänneesi, on olemassa oleva sääntö, siinä taulussa, johon se sijoitettiin.
Suojaa sitten mekanismi, jota et korjannut. path-MTU-havainto riippuu siitä, että ICMP fragmentation-needed -viestit saavuttavat lähettäjän, joten palomuuri, joka pudottaa ne, rikkoo suuria siirtoja edelleen, vaikka oikea clamp olisi paikallaan. Salli nämä viestit tunnelin polulle tai hyväksy, että clamping kompensoi valitsemaasi käytäntöä.
Vastusta lopuksi kiusausta kohdella clampia säätönuppina. Se rajoittaa segmentin kokoa, mikä maksaa läpäisyä poluilla, jotka eivät sitä koskaan tarvinneet. Kolmen tarkistuksen jälkeen sovellettuna se on kohdennettu korjaus; ensin sovellettuna se on muutos, joka piilottaa alkuperäisen vian ja lisää toisen muuttujan jokaiseen myöhempään testiin. Se vaihtokauppa kannattaa tehdä tietoisesti, ei oletuksena.
Kirjoita muistiin mitattu path-MTU, vähentämäsi tunnelin ylikuorma, lisäämäsi sääntö ja sen jälkeen näkemäsi MSS. Neljä lukua tekevät seuraavasta tapauksesta haun tutkimuksen sijaan.