Ajuste de MSS de TCP en una puerta de enlace Linux IPsec: qué corrige

El ping funciona, el SSH funciona, una página pequeña se carga y, entonces, cada respuesta grande se queda colgada hasta agotar el tiempo. El patrón clásico apunta al tamaño del paquete y no a la accesibilidad: la ruta transporta el handshake y los primeros kilobytes, y después un segmento de tamaño completo desaparece. En una puerta de enlace Linux IPsec, una regla TCP MSS suele ser la solución, pero solo si entiende qué cambia y dónde está realmente el paquete que toca. El orden de abajo sigue al paquete desde el síntoma hasta la colocación de la regla, para que pueda detenerse en cuanto la explicación deje de encajar.

El síntoma que sugiere MSS

TCP negocia un tamaño máximo de segmento en el handshake. Si ese valor es mayor de lo que la ruta puede transportar tras la encapsulación, el emisor sigue produciendo segmentos que nunca llegan, y la conexión se atasca tras el primer intercambio. Las respuestas pequeñas caben; las grandes no.

La retroalimentación ICMP puede rescatar la conexión mediante el descubrimiento del MTU de la ruta, y un cortafuegos que descarta esos mensajes convierte el atasco en un agujero negro silencioso. Por eso el mismo túnel funciona para una aplicación y falla para otra sin ninguna diferencia evidente en la configuración.

Qué hace una regla TCPMSS y qué no hace

La regla reescribe la opción MSS en los paquetes del handshake TCP a su paso. No fija el MTU de la interfaz del túnel, no cambia la política IPsec y, en los núcleos actuales, solo baja un valor anunciado en lugar de subir uno que ya es menor. Además solo toca TCP; las cargas UDP, el comportamiento de DNS y los selectores de tráfico negociados quedan fuera de su alcance.

Como el cambio ocurre durante el handshake, una conexión existente establecida antes de la regla conserva su valor antiguo. Pruebe con una conexión nueva y espere que el primer intento tras el cambio sea el que le diga algo. Nada de la regla llega a una conexión que ya está abierta. Por eso una corrección aplicada en mitad de un incidente puede parecer que no hizo absolutamente nada.

Ponga la regla en la ruta TCP interna

En una puerta de enlace Linux basada en políticas, el paquete reenviado sigue pareciendo TCP normal cuando lo ve el cortafuegos. La política IPsec decide que el paquete será protegido; el cortafuegos no ve una cabecera ESP para el flujo interno, así que comparar con ESP aquí describe un paquete completamente distinto. Esa discordancia es la razón de que algunas reglas parezcan correctas y nunca coincidan.

En términos de iptables, la regla pertenece a la tabla mangle en la ruta de reenvío, restringida a los paquetes del handshake: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. El número es un ejemplo, no una constante universal; dedúzcalo del coste de encapsulación y del MTU real de la ruta. Un equivalente de nftables fija el tamaño máximo de segmento en una cadena forward o postrouting.

Mantenga las reglas de escucha externas para IKE y ESP separadas de las reglas de reenvío internas. Una sola regla que intenta autorizar tanto el flujo de la aplicación como el protocolo externo acaba sin coincidir de forma fiable con ninguno de los dos.

Respete al propietario del cortafuegos y el orden de NAT

Si UFW gestiona el cortafuegos del host, añada los cambios de mangle y reenvío mediante su configuración persistente compatible en lugar de escribir un comando que desaparece en la siguiente recarga. Una regla insertada en la tabla equivocada o después de una regla terminal no tiene efecto, y la tabla activa se lo oculta.

La traducción de origen es una decisión aparte que a menudo interactúa con esta. Una excepción colocada antes de una regla general de masquerade evita que el tráfico protegido pierda el origen que exige su política; no repara un problema de tamaño, y una regla de tamaño no repara un problema de traducción.

Verifique de forma estrecha y luego deténgase

Abra una conexión nueva al servicio que falla y observe tanto la aplicación como los contadores de la regla. Si el atasco desaparece, tiene pruebas sobre esa ruta TCP con esa encapsulación. No tiene pruebas de que encaje cada protocolo VPN, de que esté arreglada cada aplicación UDP ni de que un servicio concreto aguas arriba fuera la causa original.

Deje que la retroalimentación de tamaño por ICMP siga funcionando donde la política lo permita, y trate con cuidado el ajuste automático basado en el MTU de la ruta cuando la ruta IPsec externa no está representada por la ruta interna. Cuanto más estrecha sea la conclusión, más fácil será diagnosticar el siguiente incidente.