MTU por ruta en Linux: tres controles de tamaño, una ruta
La MTU de la interfaz, la MTU de la ruta y el límite MSS actúan en capas distintas. Ata un presupuesto a la ruta que gana la búsqueda y mantén el cambio reversible.
Tres ajustes en un cliente Linux suenan todos a «haz los paquetes más pequeños», y actúan en capas distintas. La MTU de la interfaz limita cada paquete que envía el dispositivo. La MTU de una ruta limita los paquetes que usan esa ruta, que suele ser lo que de verdad quieres para un destino VPN. El límite TCP MSS cambia lo que negocian los dos extremos y no hace nada por UDP.
Tres controles que parecen la misma perilla
Ponlos uno al lado del otro antes de elegir, porque elegir la fila equivocada explica la mayor parte del consejo que no funciona:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Bajar la MTU de Ethernet para toda la máquina es la versión burda de este arreglo. Funciona, y además penaliza a cualquier otra aplicación del host, incluidas las que tenían sus rutas bien. Un valor por ruta expresa la misma intención sin el coste colateral.
La comparación solo vale para el tráfico que genera el propio host. Reenviar un paquete para otro cliente implica la ruta propia de ese cliente y el presupuesto exterior del túnel, y una métrica de ruta en este host no llega al otro lado de esa frontera.
Ata el presupuesto a la ruta que gana la búsqueda
Un registro ilustrativo de ruta IPv4 se ve así:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Lee el registro como una descripción de intención, no como un valor para pegar. El prefijo, el dispositivo y la fuente preferida tienen que coincidir con la configuración real, y el número tiene que venir de pruebas sobre la ruta encapsulada, no de una entrada de blog. La MTU de la ruta limita el paquete IP interior, que no es lo mismo que una carga TCP de 1380 bytes ni un paquete exterior cifrado de 1380 bytes.
Mira dónde se resuelve realmente la búsqueda antes de añadir nada. Un host con reglas de política puede encaminar un destino dado por una tabla distinta de main, y una métrica que solo existe en main es invisible para esa petición. Compara ip -4 route show table all con la respuesta de ip route get, incluido el contexto de marca o de espacio de nombres cuando las reglas los usan. Si los dos no coinciden, la tabla que respondió es la que necesita la métrica, no la que parece más ordenada.
mtu no es mtu lock
Por defecto el núcleo todavía puede actualizar la MTU de la ruta a partir de la realimentación ICMP, que es para lo que sirve el descubrimiento de MTU de ruta. Añadir lock detiene eso. Es una decisión distinta, no una forma más fuerte de guardar el mismo número, y en IPv4 cambia el tratamiento documentado del bit de no fragmentar.
Bloquear es razonable cuando has medido la ruta y quieres que el valor se quede fijo pase lo que pase. Es un mal valor por defecto cuando la red envía realimentación legítima de tamaño, porque el núcleo ya no puede ajustarse y el fallo se traslada a otro síntoma.
Si se filtra ICMP en algún punto de la ruta, ningún ajuste de ruta lo repara. El arreglo corresponde al filtro, y una MTU menor es un apaño que oculta el fallo real hasta el siguiente cambio de ruta.
El software de túnel añade sus propias perillas de tamaño
OpenVPN mssfix ajusta el tamaño de segmento TCP para su caso documentado de túnel UDP. Actúa sobre la conversación TCP, así que no es otra grafía de la MTU de ruta del sistema operativo, y no puede ayudar a un servicio UDP que ignora la negociación.
No apiles una MTU de ruta, un cambio de MTU de interfaz y un límite MSS en la misma ventana de cambios. Si el problema desaparece, no sabrás cuál importó, y los que conserves limitarán el tráfico durante años sin un motivo que alguien recuerde.
Hazlo reversible y luego demuéstralo
El propietario real de la ruta decide si el cambio sobrevive a una reconexión. Un cliente VPN que instala la ruta de forma dinámica normalmente la reconstruirá sin tu métrica, y un ip route add manual entonces parece un arreglo que falló un día después. Pon el valor en la configuración del gestor y, si necesitas un experimento temporal, anota primero la ruta original.
Prueba con una conexión nueva que haga la operación que se atascó, y luego confirma que la ruta privada prevista sigue ganando y que los destinos no relacionados no han cambiado. Reconecta el túnel y vuelve a leer la ruta, porque un valor que desaparece al reconectar no es un arreglo.
Si la evidencia no respalda el cambio, quita la sustitución por su gestor y restaura los atributos originales de la ruta en lugar de borrarla. Después anota qué mediste y en qué ruta, para que la siguiente persona distinga una mejora real de un experimento que se dejó funcionando.