OpenVPN sobre PPPoE: ¿bajar link-mtu, tun-mtu o mssfix?

Los pings responden, el DNS resuelve y toda página que necesita un segmento de tamaño completo se cuelga. En un enlace que añade su propia encapsulación, la ruta pierde en silencio unas pocas decenas de bytes de presupuesto, y un perfil escrito para Ethernet limpio sigue pidiendo paquetes que la línea no puede transportar. La conexión no es lenta; está descartando exactamente los paquetes que importan.

Tres opciones pueden solucionarlo, y actúan en capas diferentes. Elegir la incorrecta o no hace nada o vuelve el túnel frágil de una forma nueva, así que la decisión empieza por lo que la ruta admite de verdad.

Tres controles, tres capas distintas

link-mtu es el presupuesto externo: la carga cifrada más la cabecera de OpenVPN, la cabecera UDP y la cabecera IP externa. Describe lo que sale de la máquina, y por eso es el número que limita la ruta física.

tun-mtu es el presupuesto interno: la interfaz que ve su tráfico. Es mayor que lo que la ruta puede transportar exactamente en la sobrecarga del túnel, y OpenVPN normalmente lo deduce en lugar de obligarle a fijarlo.

mssfix es un mecanismo completamente distinto. Reescribe el tamaño máximo de segmento anunciado durante las negociaciones TCP, para que los pares TCP elijan segmentos que quepan tras la encapsulación. No cambia la MTU de la interfaz y no tiene ningún efecto sobre UDP.

Si fija link-mtu explícitamente, OpenVPN resta su propia sobrecarga para deducir la MTU interna. Esa sobrecarga no es una constante fija; depende del cifrado y de la autenticación, y por eso un valor copiado de un foro puede ser erróneo en otro perfil. Fijar tanto link-mtu como tun-mtu entrega al cliente dos instrucciones contradictorias.

Mida la ruta antes de elegir cualquier número

Mida desde la interfaz física, no desde dentro del túnel, y recuerde que ping informa de la carga útil, no del tamaño del paquete. Sume 28 bytes para las cabeceras IPv4 e ICMP antes de comparar la carga con una trama de 1500 bytes, y tenga presente esa corrección cuando un par informe de un número distinto.

En un cliente Linux, ping -M do -s 1472 prohíbe la fragmentación y falla si el paquete es demasiado grande. Baje la carga útil hasta que pase y luego sume 28 para obtener la MTU de la ruta. PPPoE cuesta 8 bytes, así que 1492 es normal en DSL. DS-Lite y algunas rutas móviles cuestan 40 o más, y la respuesta suele ser inferior a lo que sugiere la velocidad nominal del enlace.

Si todos los tamaños de ping tienen éxito pero las transferencias grandes siguen atascándose, sospeche un agujero negro en lugar de un simple límite de tamaño. Un mensaje ICMP de fragmentación necesaria se está filtrando en algún punto de la ruta, así que el emisor nunca aprende a reducir, y solo los flujos que necesitan un segmento grande lo notan.

Primero limite TCP, después encoja el túnel

Las negociaciones TCP son lo único que toca mssfix, lo que suele convertirlo en el control menos invasivo para probar primero. Fíjelo un poco por debajo del presupuesto real de la ruta, envíe el mismo valor desde el servidor para que ambos extremos coincidan y vuelva a probar una descarga grande. Si el atasco desaparece, el problema era el tamaño de segmento TCP y no hace falta cambiar nada más.

Baje la MTU interna cuando el tráfico afectado no sea TCP. Un servicio UDP, un túnel dentro del túnel o una aplicación que envía datagramas de tamaño completo seguirán fallando tras un límite de MSS porque nada reescribe el tamaño de sus paquetes. Reduzca tun-mtu para ese caso, o fije link-mtu y deje que el cliente deduzca el valor interno, pero nunca ambos.

No recurra a la antigua opción de fragmentación. Dividía paquetes dentro del túnel, añadía sobrecarga y ha quedado obsoleta por buenas razones; el OpenVPN moderno espera que la ruta se describa con precisión.

Por qué las sondas pequeñas siguen funcionando

Las consultas DNS, los ecos ICMP y las negociaciones TCP están muy por debajo del tamaño que falla. El túnel parece sano en cualquier prueba rápida mientras las negociaciones TLS y las respuestas HTTP fallan en silencio. Esa combinación, un traceroute que funciona y un navegador que se cuelga en la primera respuesta grande, es la señal que hay que buscar. Recurra a una sonda de tamaño completo antes de recurrir a un perfil nuevo.

Verifique con el tráfico que falló. Cargue una página grande, envíe un datagrama UDP de tamaño completo si ese es el servicio afectado, y repita desde un segundo cliente en otro enlace. Anote la MTU de ruta medida y el valor que eligió, porque la siguiente persona que toque el perfil tratará el número como arbitrario de lo contrario.

Nunca baje la MTU interna por debajo de 1280 cuando IPv6 va sobre el túnel, porque ese es el mínimo que todo enlace IPv6 debe transportar. Una MTU menor es un hecho sobre la ruta, no un ajuste de rendimiento que se calibra a ojo.