MSS clamping en una passarel·la VPN: què arregla i què no

Les peticions petites funcionen, les baixades grans es pengen i algú suggereix MSS clamping. Aquest suggeriment és prou sovint encertat per valer la pena provar-lo en l'ordre correcte, i prou sovint equivocat per fer perdre una tarda si l'apliques a cegues. Les tres comprovacions de sota separen un problema real de mida TCP d'un problema d'UDP, d'una descoberta path-MTU trencada i d'un clamp que mai no veu el handshake que hauria de reescriure.

Comenceu per la forma de la fallada

Una fallada de mida té una signatura: la connexió s'estableix, l'autenticació i les respostes petites tenen èxit, i després una transferència s'atura indefinidament quan necessita un segment de mida completa. Les pàgines que carreguen text però mai no acaben una imatge són la mateixa fallada a escala menor. Si no s'hi connecta res de res, el problema és més amunt al camí i el clamping no ajudarà. Un clamp no pot reparar un handshake que no ha arribat mai.

La signatura existeix perquè el handshake és on s'acorda la mida del segment. Cada costat anuncia una mida màxima de segment com a opció TCP, i els emissors respecten l'anunci del parell. Si el camí no pot portar un segment tan gran, la fallada apareix més tard, quan l'emissor finalment ho prova.

Tingueu el transport a la vista mentre llegiu aquest símptoma. El clamping és una reescriptura d'una opció TCP, així que una trucada de veu o vídeo que s'atura sota el mateix túnel no és un problema d'MSS i no millorarà per aquesta via. Anoteu el transport abans de tocar cap opció TCP.

Poseu preu al camí i compareu-lo amb el túnel

Dos nombres importen i sovint es confonen. El path-MTU és el paquet més gran que el camí portarà sense fragmentació, i l'MSS anunciat per a IPv4 és aquest valor menys els 40 bytes de capçaleres IP i TCP, o menys 60 per a IPv6. L'encapsulació del túnel consumeix part del pressupost abans que el paquet interior ni tan sols comenci.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

El ping amb el bit do-not-fragment us diu si sobreviu un paquet d'aquesta mida de càrrega; ajusteu la mida fins que falli i haureu trobat el límit del camí empíricament. La sortida de tracepath informa de l'MTU descobert al llarg de la ruta, que és més ràpid quan funciona i menys fiable quan un salt intermedi filtra les sondes.

Ara resteu la sobrecàrrega del túnel. Una capçalera IP exterior, una capçalera UDP i una capçalera específica del túnel surten tots dels mateixos 1500 bytes, així que l'MTU interior utilitzable en una base Ethernet típica és més baix del que suggereix l'enllaç físic. Si l'MTU interior calculat és inferior al que anuncien els vostres parells, heu trobat un candidat real a clamp i no una conjectura. Si el valor calculat ja és superior al que anuncien els parells, atureu-vos aquí i mireu en un altre lloc.

Col·loqueu el clamp on passa el handshake

Un clamp funciona reescrivint l'opció MSS als paquets SYN i SYN-ACK mentre travessen la passarel·la. Si la regla se situa en una interfície que cap de les dues direccions no travessa mai, la negociació es completa sense canvis i el símptoma persisteix, i per això la col·locació decideix el resultat més que el valor.

La direcció és l'altra meitat. Fer clamp en una direcció arregla la meitat dels fluxos i deixa la resta fallant d'una manera que sembla intermitent, així que apliqueu-lo a les dues direccions del trànsit reenviat. La forma clàssica a Linux per a una interfície de túnel és una regla mangle que coincideix amb paquets SYN:

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

Fixeu-vos en què fa realment --clamp-mss-to-pmtu: deriva el valor de l'MTU de la ruta, que no sempre és el pressupost real de càrrega del túnel. En un túnel basat en ruta on la ruta interior i el camí exterior difereixen, un valor explícit calculat a la comprovació anterior és més predictible que un d'automàtic.

Verifiqueu amb una connexió nova i manteniu el retorn viu

Una connexió establerta conserva l'MSS que ha negociat, així que provar a la mateixa sessió no demostra res. Obriu una connexió nova després del canvi i llegiu el valor negociat directament, en lloc d'inferir-lo d'una transferència que acaba per casualitat.

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

La primera ordre informa de l'MSS del sòcol juntament amb el seu estat de congestió, que és la confirmació més ràpida que el clamp ha fet efecte. La segona confirma que la regla que creieu que heu afegit és la regla que existeix, a la taula on s'ha col·locat.

Després protegiu el mecanisme que no heu arreglat. La descoberta path-MTU depèn que els missatges ICMP fragmentation-needed arribin a l'emissor, així que un tallafoc que els descarta continuarà trencant transferències grans fins i tot amb un clamp correcte. Permeteu aquests missatges per al camí del túnel, o accepteu que el clamping compensa una política que heu triat.

Finalment, resistiu la temptació de tractar el clamp com un botó d'ajust. Restringeix la mida del segment, cosa que costa cabal en camins que mai no el van necessitar. Aplicat després de les tres comprovacions és una reparació dirigida; aplicat primer és un canvi que amaga la fallada original i afegeix una segona variable a cada prova posterior. Aquest intercanvi val la pena fer-lo deliberadament, no per defecte.

Anoteu el path-MTU que heu mesurat, la sobrecàrrega del túnel que heu restat, la regla que heu afegit i l'MSS que heu vist després. Quatre nombres fan que el proper incident sigui una consulta en lloc d'una investigació.