MSS-clamping op een VPN-gateway: wat het oplost en wat niet

Kleine verzoeken werken, grote downloads blijven hangen, en iemand stelt MSS-clamping voor. Dat voorstel is vaak genoeg juist om het in de juiste volgorde te proberen, en vaak genoeg onjuist om een middag te verpesten als je het blind toepast. De drie controles hieronder scheiden een echt TCP-grootteprobleem van een UDP-probleem, van een kapotte path-MTU-ontdekking en van een clamp die de handshake die hij moet herschrijven nooit ziet.

Begin bij de vorm van de storing

Een groottestoring heeft een signatuur: de verbinding komt tot stand, authenticatie en kleine antwoorden slagen, en dan blijft een overdracht oneindig hangen zodra er een segment op volle grootte nodig is. Pagina's die tekst laden maar nooit een afbeelding afmaken zijn dezelfde storing op kleinere schaal. Als er helemaal niets verbindt, zit het probleem eerder in het pad en helpt clamping niet. Een clamp kan geen handshake repareren die nooit is aangekomen.

De signatuur bestaat omdat de handshake de plek is waar de segmentgrootte wordt afgesproken. Elke kant adverteert een maximale segmentgrootte als TCP-optie, en verzenders respecteren de advertentie van de tegenpartij. Als het pad zo'n groot segment niet kan dragen, verschijnt de storing later, wanneer de verzender er eindelijk een probeert.

Houd het transport in het oog terwijl je dat symptoom leest. Clamping is het herschrijven van een TCP-optie, dus een spraak- of videogesprek dat onder dezelfde tunnel blijft hangen is geen MSS-probleem en wordt er niet beter van. Schrijf het transport op voordat je een TCP-optie aanraakt.

Bepaal de prijs van het pad en vergelijk die met de tunnel

Twee getallen zijn belangrijk en ze worden vaak verward. De path-MTU is het grootste pakket dat het pad zonder fragmentatie draagt, en de geadverteerde MSS voor IPv4 is die waarde min de 40 bytes IP- en TCP-headers, of min 60 voor IPv6. Tunnel-encapsulatie verbruikt een deel van het budget voordat het binnenste pakket zelfs begint.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

De ping met de do-not-fragment-bit vertelt je of een pakket van die payloadgrootte overleeft; pas de grootte aan totdat het mislukt en je hebt de padlimiet empirisch gevonden. De uitvoer van tracepath meldt de MTU die onderweg is ontdekt, wat sneller is als het werkt en minder betrouwbaar als een tussenliggende hop de probes filtert.

Trek nu de overhead van de tunnel af. Een buitenste IP-header, een UDP-header en een tunnelspecifieke header komen allemaal uit dezelfde 1500 bytes, dus de bruikbare binnenste MTU op een typische Ethernet-onderlaag is lager dan de fysieke link suggereert. Als de berekende binnenste MTU onder wat je tegenpartijen adverteren ligt, heb je een echte clamp-kandidaat gevonden en geen gok. Als de berekende waarde al boven de advertentie van de tegenpartijen ligt, stop hier en kijk elders.

Plaats de clamp waar de handshake langskomt

Een clamp werkt door de MSS-optie in de SYN- en SYN-ACK-pakketten te herschrijven terwijl ze de gateway passeren. Als de regel op een interface staat die geen van beide richtingen ooit passeert, wordt de onderhandeling ongewijzigd afgerond en blijft het symptoom bestaan, daarom bepaalt de plaatsing het resultaat meer dan de waarde.

De richting is de andere helft. Clamping in één richting lost de helft van de stromen op en laat de rest op een manier falen die intermittent lijkt, dus pas het toe op beide richtingen van het doorgestuurde verkeer. De klassieke Linux-vorm voor een tunnelinterface is een mangle-regel die SYN-pakketten matcht:

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

Let op wat --clamp-mss-to-pmtu werkelijk doet: het leidt de waarde af uit de MTU van de route, wat niet altijd het echte payloadbudget van de tunnel is. Op een routegebaseerde tunnel waar de binnenste route en het buitenste pad verschillen, is een expliciete waarde die in de vorige controle is berekend voorspelbaarder dan een automatische.

Controleer met een nieuwe verbinding en houd de feedback levend

Een bestaande verbinding behoudt de MSS die is onderhandeld, dus testen in dezelfde sessie bewijst niets. Open na de wijziging een nieuwe verbinding en lees de onderhandelde waarde direct, in plaats van die af te leiden uit een overdracht die toevallig klaarkomt.

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

Het eerste commando meldt de MSS van de socket samen met de congestiestatus, wat de snelste bevestiging is dat de clamp heeft gewerkt. Het tweede bevestigt dat de regel waarvan je denkt dat je hem hebt toegevoegd de regel is die bestaat, in de tabel waar hij is geplaatst.

Bescherm daarna het mechanisme dat je niet hebt gerepareerd. Path-MTU-ontdekking hangt ervan af dat ICMP fragmentation-needed-berichten de verzender bereiken, dus een firewall die ze laat vallen blijft grote overdrachten breken, zelfs met een correcte clamp. Sta die berichten toe voor het tunnelpad, of accepteer dat clamping een beleid compenseert dat je zelf hebt gekozen.

Weersta ten slotte de verleiding om de clamp als afstelknop te behandelen. Hij beperkt de segmentgrootte, wat doorvoer kost op paden die het nooit nodig hadden. Na de drie controles toegepast is het een gerichte reparatie; als eerste toegepast is het een wijziging die de oorspronkelijke fout verbergt en aan elke latere test een tweede variabele toevoegt. Die ruil is het waard bewust te doen, niet standaard.

Noteer de gemeten path-MTU, de afgetrokken tunnel-overhead, de toegevoegde regel en de MSS die je daarna zag. Vier getallen maken het volgende incident een opzoekactie in plaats van een onderzoek.