MSS clamping en una puerta de enlace VPN: qué arregla y qué no

Las peticiones pequeñas funcionan, las descargas grandes se cuelgan y alguien sugiere MSS clamping. Esa sugerencia acierta con la frecuencia suficiente para merecer una prueba en el orden correcto, y falla con la suficiente para hacerle perder una tarde si la aplica a ciegas. Las tres comprobaciones siguientes separan un problema real de tamaño TCP de un problema de UDP, de un descubrimiento path-MTU roto y de un clamp que nunca ve el handshake que debería reescribir.

Empiece por la forma del fallo

Un fallo de tamaño tiene firma: la conexión se establece, la autenticación y las respuestas pequeñas tienen éxito, y después una transferencia se atasca indefinidamente en cuanto necesita un segmento de tamaño completo. Las páginas que cargan texto pero nunca terminan una imagen son el mismo fallo a menor escala. Si no se conecta nada en absoluto, el problema está antes en la ruta y el clamping no ayudará. Un clamp no puede reparar un handshake que nunca llegó.

La firma existe porque el handshake es donde se acuerda el tamaño del segmento. Cada lado anuncia un tamaño máximo de segmento como opción TCP, y los emisores respetan el anuncio del par. Si la ruta no puede transportar un segmento así de grande, el fallo aparece más tarde, cuando el emisor por fin lo intenta.

Mantenga el transporte a la vista mientras lee ese síntoma. El clamping es una reescritura de una opción TCP, así que una llamada de voz o vídeo que se atasca bajo el mismo túnel no es un problema de MSS y no mejorará por ello. Anote el transporte antes de tocar una opción TCP.

Ponga precio a la ruta y compárela con el túnel

Dos números importan y a menudo se confunden. La path-MTU es el paquete más grande que la ruta transportará sin fragmentación, y el MSS anunciado para IPv4 es ese valor menos los 40 bytes de cabeceras IP y TCP, o menos 60 para IPv6. La encapsulación del túnel consume parte del presupuesto antes de que el paquete interior siquiera empiece.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

El ping con el bit do-not-fragment le dice si sobrevive un paquete de ese tamaño de carga útil; ajuste el tamaño hasta que falle y habrá encontrado el límite de la ruta empíricamente. La salida de tracepath informa del MTU descubierto a lo largo de la ruta, que es más rápido cuando funciona y menos fiable cuando un salto intermedio filtra las sondas.

Ahora reste la sobrecarga del túnel. Una cabecera IP exterior, una cabecera UDP y una cabecera específica del túnel salen todas de los mismos 1500 bytes, así que el MTU interior utilizable en una base Ethernet típica es más bajo de lo que sugiere el enlace físico. Si el MTU interior calculado es inferior al que anuncian sus pares, ha encontrado un candidato real a clamp y no una conjetura. Si el valor calculado ya está por encima de lo que anuncian los pares, deténgase aquí y busque en otro sitio.

Coloque el clamp donde pasa el handshake

Un clamp funciona reescribiendo la opción MSS en los paquetes SYN y SYN-ACK mientras cruzan la puerta de enlace. Si la regla se asienta en una interfaz que ninguna de las dos direcciones atraviesa nunca, la negociación se completa sin cambios y el síntoma persiste, por lo que la colocación decide el resultado más que el valor.

La dirección es la otra mitad. Aplicar clamp en una sola dirección arregla la mitad de los flujos y deja al resto fallando de una forma que parece intermitente, así que aplíquelo a ambas direcciones del tráfico reenviado. La forma clásica en Linux para una interfaz de túnel es una regla mangle que coincide con paquetes SYN:

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

Fíjese en lo que --clamp-mss-to-pmtu hace en realidad: deriva el valor del MTU de la ruta, que no siempre es el presupuesto real de carga útil del túnel. En un túnel basado en ruta donde la ruta interior y la ruta exterior difieren, un valor explícito calculado en la comprobación anterior es más predecible que uno automático.

Verifique con una conexión nueva y mantenga viva la retroalimentación

Una conexión establecida conserva el MSS que negoció, así que probar en la misma sesión no demuestra nada. Abra una conexión nueva tras el cambio y lea el valor negociado directamente en lugar de deducirlo de una transferencia que termina por casualidad.

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

El primer comando informa del MSS del socket junto con su estado de congestión, que es la confirmación más rápida de que el clamp surtió efecto. El segundo confirma que la regla que cree haber añadido es la regla que existe, en la tabla donde se colocó.

Después proteja el mecanismo que no arregló. El descubrimiento path-MTU depende de que los mensajes ICMP fragmentation-needed lleguen al emisor, así que un cortafuegos que los descarte seguirá rompiendo transferencias grandes incluso con un clamp correcto. Permita esos mensajes para la ruta del túnel, o acepte que el clamping compensa una política que usted eligió.

Por último, resista la tentación de tratar el clamp como un mando de ajuste. Restringe el tamaño del segmento, lo que cuesta rendimiento en rutas que nunca lo necesitaron. Aplicado tras las tres comprobaciones es una reparación dirigida; aplicado primero es un cambio que oculta el fallo original y añade una segunda variable a cada prueba posterior. Ese intercambio merece hacerse a propósito, no por defecto.

Anote la path-MTU que midió, la sobrecarga del túnel que restó, la regla que añadió y el MSS que vio después. Cuatro números convierten el siguiente incidente en una consulta en lugar de una investigación.