OpenVPN mssfix: por qué un cliente se atasca en transferencias grandes

Un solo portátil se atasca en las subidas a través del túnel mientras todos los demás dispositivos del mismo servidor siguen funcionando. Ese patrón apunta a una ruta, no a la configuración del servidor, y es la entrada habitual a la cuestión de mssfix. La opción puede ayudar, pero solo para las conexiones TCP que realmente reescribe. Conocer su alcance evita que cambie un servidor que funciona para rescatar a un cliente.

Qué reescribe la opción

mssfix edita el tamaño máximo de segmento anunciado en los handshakes TCP que atraviesan el túnel, de modo que el lado emisor elige segmentos que caben en el presupuesto encapsulado. Actúa sobre el handshake, lo que significa que una conexión abierta antes del cambio conserva el valor que negoció.

No reduce los datagramas UDP ni fija la MTU del túnel. Dos problemas distintos producen el mismo síntoma: un emisor TCP que ignora el límite de la ruta y una ruta que descarta en silencio paquetes grandes de cualquier tamaño. mssfix aborda el primero y no hace nada por el segundo.

Esa distinción explica los experimentos decepcionantes. Fijar un valor menor en una ruta con agujero negro cambia el tamaño del segmento, pero no la caída que sigue, así que la transferencia falla en otro punto.

El alcance es TCP dentro del túnel

Solo se reescribe el tráfico TCP. Una sesión QUIC, un juego o una aplicación que envía datagramas UDP grandes conservará sus propios tamaños de paquete, y si esas son las transferencias que se atascan, la solución pertenece más bien a la MTU del túnel o de la ruta. Lea qué protocolo usa la transferencia que falla antes de recurrir a una opción TCP, porque la capa equivocada tiene su propia solución.

La dirección también importa. Un ajuste del cliente afecta al tráfico que ese cliente envía al túnel, mientras que el servidor cubre los flujos que reenvía hacia los clientes. Si solo se atascan las descargas entrantes, el valor del lado del cliente no es toda la historia.

El número y la palabra clave no son portables

La versión comunitaria de OpenVPN 2.6 acepta una palabra clave opcional después del valor. Con mtu, el número describe el tamaño del paquete exterior, incluidas las cabeceras IP y UDP; sin ella, el argumento sigue otra convención contable. Por eso, una línea copiada entre versiones no describe el mismo presupuesto de paquetes. Consulte la página del manual que acompaña a la compilación que realmente ejecuta, en lugar de un tutorial para otra versión.

La sintaxis tiene este aspecto:

mssfix 1400 mtu

Trate 1400 como un marcador de posición, no como una recomendación para su ruta. Deduzca el valor de la ruta medida y de la encapsulación que realmente se usa, y recuerde que los clientes con versiones antiguas u otras implementaciones pueden rechazar o reinterpretar la palabra clave.

Confírmelo primero en el único cliente

Mida la ruta desde la máquina que falla antes de cambiar nada. Una carga útil que la ruta pueda transportar sin fragmentación es el número que busca:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

La primera prueba cabe en un paquete de 1500 bytes una vez añadidos los 28 bytes de cabeceras. Si falla con un error de fragmentación y la más pequeña tiene éxito, el tamaño utilizable está en algún punto entre ambas, y la sobrecarga del túnel se resta por arriba.

Después repita la transferencia que se atascó, en una conexión nueva, y compare. Si el cliente único mejora mientras los demás quedan intactos, ha encontrado el alcance del problema. Si se atascan todos los clientes, el valor del lado del servidor es el que hay que revisar. Ninguno de los dos resultados justifica un cambio en hardware que nunca estuvo en la ruta que falla.