OpenVPN avisa de un uso incoherente del MTU: qué compara el aviso

Ese aviso informa de una comparación entre las opciones de los pares, no de una medición de la ruta entre ellos. La gente lo lee como «el MTU está mal» y cambia el número hasta que la línea desaparece. Eso trata una comparación de configuración como una medición de red, y a menudo empeora el túnel mientras deja el registro más silencioso. El primer paso útil es decidir cuál de esos dos problemas tiene realmente.

Tres condiciones deciden la respuesta: qué comparan los pares, si el valor es heredado y qué síntoma existe más allá del aviso.

El aviso compara opciones, no paquetes

Los pares de OpenVPN intercambian sus cadenas de opciones durante el saludo y las comparan como parte de la comprobación de coherencia de opciones. Cuando un lado informa de link-mtu o tun-mtu de forma distinta al otro, la discrepancia se registra con ambos valores. Ese intercambio nunca envía un paquete grande para ver qué pasa, así que el aviso describe configuración, no capacidad. Un túnel puede transportar tráfico de tamaño completo y aun así imprimirlo, o fallar con paquetes grandes y no imprimir nada.

Conserve el aviso completo con sus valores local y remoto. El par es la prueba; el número suelto que recuerda, no.

Por qué link-mtu está obsoleto

OpenVPN 2.6 marca link-mtu como obsoleto porque las cabeceras variables y los cifrados negociados hacen que un valor de enlace fijo no sea fiable. La opción suponía una disposición de paquete que el protocolo ya no garantiza, así que un perfil antiguo con un link-mtu literal describe una intención que el código actual no puede cumplir. Copiar ese número a un perfil nuevo propaga una suposición obsoleta. Léalo como parte de la historia del perfil antiguo, no como una recomendación.

La comprobación de coherencia también tiene un valor OCC opcional ligado a tun-mtu, que cambia qué se compara sin cambiar qué transporta la red. Fijarlo no hace que quepan paquetes mayores.

Repare el perfil antes de probar la ruta

Corrija una discrepancia no intencionada a través de quien posee los perfiles, y recuerde que un cambio en el servidor afecta a todos los clientes. Edite el perfil que la instancia carga realmente, no una exportación que está en una carpeta de descargas. Después reconecte un cliente de prueba y anote qué aviso sobrevive. Si el mensaje cambia de forma en vez de desaparecer, está comparando opciones distintas de las que cree.

Un servidor compartido necesita que se revise su inventario de clientes antes de mover un valor global, porque el valor que sirve a un sitio puede romper otro.

Después pruebe el síntoma que tiene de verdad

Si las transferencias grandes se atascan mientras las peticiones pequeñas funcionan, mida el tamaño de paquete contra un destino controlado. Una sonda que fija el bit de no fragmentar y aumenta el tamaño de la carga encuentra el MTU utilizable de la ruta mucho más fiablemente que un ping que simplemente acierta. Incluya la aplicación que falla en la prueba: un tiempo de espera ICMP puede reflejar filtrado, y un ping pequeño exitoso no dice nada sobre un paquete de aplicación de tamaño completo.

mssfix limita el MSS anunciado para las sesiones TCP dentro del túnel, lo que ayuda a TCP y no hace nada por una carga UDP interna. La fragmentación y el offload tienen sus propias condiciones de compatibilidad. Elija un mecanismo para el problema demostrado en lugar de cambiar varios a la vez para silenciar una línea del registro.

Conserve los valores efectivos con el resultado

Anote los valores efectivos originales y corregidos junto al resultado de una transferencia real. Ese emparejamiento es lo que separa una opción de perfil obsoleta de un problema de MTU en la ruta que existe de forma independiente. Sin él, el siguiente lector ve un aviso que desapareció y supone que la red cambió.

Suprimir la comprobación de coherencia no concilia nada. Elimina la observación y deja ambas configuraciones como estaban.