¿Es más rápida una MTU de VPN más pequeña? Compare la evidencia real
Una MTU más baja puede esquivar un límite de la ruta y aun así costar rendimiento. Compare la restricción real, el coste de las cabeceras y la carga antes de mantener el cambio.
Un túnel descarta las transferencias grandes pero deja pasar los ping, así que el consejo llega rápido: baje la MTU. La solución a veces funciona, y luego se aplica a cada perfil en cada red. Ese es el punto en el que una reparación dirigida se convierte en un impuesto permanente sobre el rendimiento. La comparación que hay que hacer es entre el límite real de la ruta y el coste de encoger cada paquete por debajo de él.
Qué se encoge realmente cuando baja la MTU
Cada paquete lleva cabeceras antes de llevar sus datos. En una ruta Ethernet de 1500 bytes, IPv4 y TCP consumen 40 bytes y dejan 1460 para la carga útil; la encapsulación añade encima cabeceras externas de IP, UDP y túnel, así que el presupuesto interior de carga vuelve a bajar. Bajar la MTU de la interfaz encoge ese presupuesto a propósito.
El coste es proporcional al número de paquetes, no al número de bytes. El mismo archivo dividido en más paquetes necesita más interrupciones, más decisiones de enrutamiento y más procesamiento por paquete en cada dispositivo de la ruta. En un router que ya está cerca de su límite de paquetes por segundo, eso es una ralentización real y no un error de redondeo. El coste aparece incluso cuando la transferencia tiene éxito.
Por eso una MTU más pequeña es un rodeo para una restricción, no una optimización general. Compra fiabilidad frente a una ruta que no puede llevar la trama mayor y cobra sobrecoste por cada paquete que no necesitaba la reducción.
Cuándo una MTU más pequeña es la solución correcta
El síntoma clásico es concreto: el apretón de manos TCP se completa, llegan respuestas pequeñas y una descarga grande se atasca o se reinicia. Un ping con el bit de no fragmentar a 1472 bytes falla mientras que un ping de 1400 bytes tiene éxito, lo que apunta a una ruta que no puede llevar un paquete de tamaño completo y no entrega el mensaje ICMP que diría al emisor que encoja.
El descubrimiento de la MTU de la ruta depende de esos mensajes ICMP de fragmentación necesaria. Cuando un cortafuegos los descarta, el emisor sigue reintentando el paquete grande y la conexión parece colgarse. Bajar la MTU del lado del túnel evita el reintento, y eso es una reparación legítima para esa red.
Las tecnologías de acceso también imponen sus propios límites: PPPoE suele limitarse a 1492, algunas rutas móviles y DSL son más bajas, y los túneles anidados restan sobrecoste dos veces. Mida la ruta real en lugar de copiar un número de una guía, y recuerde que IPv6 exige al menos 1280 bytes de MTU en cualquier enlace que lo transporte, como especifica RFC 8200.
Compare los tres controles antes de cambiar uno
MTU, MSS y fragmentación son controles distintos en capas distintas, y cambiar el equivocado deja el síntoma en su sitio.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
Limitar la MSS suele ser la reparación menos invasiva porque solo afecta a TCP y deja la interfaz libre para otro tráfico. Una MTU de interfaz más baja es más amplia y más fácil de razonar, por eso es habitual en routers de consumo, pero cobra a cada protocolo el problema de un solo protocolo.
Desactivar el comportamiento de no fragmentar oculta el síntoma al permitir la fragmentación, y normalmente empeora la latencia a la vez que rompe la retroalimentación que habría encontrado el tamaño correcto. Evítelo como solución permanente.
Mida el compromiso en lugar de un solo número
Encuentre el límite de la ruta con una sonda de no fragmentar, empezando alto y bajando hasta que llegue la respuesta:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Después compare la tarea real con ambos ajustes: la misma transferencia de archivo, el mismo extremo y la misma red. Registre el tiempo de finalización y las retransmisiones, por ejemplo con nstat -az TcpRetransSegs, y vigile la CPU del dispositivo si el túnel termina en un router pequeño. Una prueba sintética corta de rendimiento puede no ver el atasco que solo aparece tras varios megabytes.
Los contadores de paquetes subirán tras una reducción porque la misma transferencia ahora usa más paquetes. Eso es esperable y no es prueba de mayor rendimiento. Compare los datos de aplicación completados, el número de retransmisiones y la capacidad de respuesta, no solo la tasa de paquetes.
Introduzca el cambio por etapas y manténgalo acotado
Anote el valor original, cambie un control y repita la medición antes de hacerlo permanente. Si la evidencia no muestra un beneficio, restaure el valor anterior con el mismo comando de interfaz que usó para fijarlo:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Acoja el resultado a la red que lo necesitaba. Un perfil que debe funcionar en un Wi-Fi de hotel, un punto de acceso móvil y una LAN de oficina no debería heredar el valor más bajo que exija cualquiera de ellos, salvo que el cliente no pueda detectar la ruta.
El valor correcto es la MTU más grande que sobrevive a la ruta, no la más pequeña que hace desaparecer el síntoma. Documente la ruta, el resultado de la sonda y la reversión, y revise el ajuste cuando cambie la red de acceso.