Descubrimiento del MTU de la ruta a través de una VPN: dimensionamiento y el hueco de ICMP

Un túnel completa su handshake, las peticiones pequeñas vuelven y la primera transferencia grande se atasca. Ese patrón apunta al MTU de la ruta mucho antes que al rendimiento. Cada enlace de la ruta limita el tamaño del paquete, y la encapsulación gasta parte de ese margen en cabeceras externas, así que el paquete interno debe ser menor de lo que sugeriría la ruta bruta. El fallo es silencioso, y eso es lo que lo hace caro de diagnosticar.

Qué mide realmente el MTU de la ruta

El MTU de la ruta es el MTU de enlace más pequeño en la ruta entre dos hosts, no el MTU impreso en su interfaz local. El valor local es donde empieza la estimación, y la ruta decide dónde debe terminar. Por eso un túnel idéntico puede funcionar en una red de acceso y atascarse en otra: cambió la ruta, no la configuración. Medir una vez y suponerlo en todas partes es el error que mantiene vivo este problema.

Para un túnel, el número que importa es el MTU interno, es decir, el margen de la ruta externa menos todo lo que consume la encapsulación. WireGuard añade una cabecera IP externa y una cabecera UDP; otros transportes añaden las suyas. Si ajusta el tamaño interno demasiado alto, cada paquete de tamaño completo necesitará una fragmentación que puede que nunca ocurra.

Por qué un túnel reduce el paquete utilizable

Si la interfaz del túnel conserva el MTU del enlace físico, cada paquete grande depende de que alguien más abajo esté dispuesto a fragmentarlo. IPv4 lo permite en principio, pero un router al que se le ha dicho que no fragmente devuelve un error en su lugar. Los routers IPv6 nunca fragmentan en tránsito, así que el mismo ajuste se comporta de forma distinta según la familia de direcciones. En cualquier caso, el emisor no aprende nada hasta que algo le informa.

La consecuencia práctica es un tamaño que encaja con el handshake y no con la carga útil. Un TLS ClientHello o una consulta DNS son lo bastante pequeños para cruzar una ruta reducida sin tocarse, mientras que una transferencia masiva no lo es. Por eso los síntomas se agrupan en torno a operaciones concretas y no a hosts concretos.

El descubrimiento solo funciona cuando llega la retroalimentación

El descubrimiento IPv4 se basa en el bit de no fragmentar: un router que no puede reenviar el paquete devuelve ICMP fragmentation-needed con el MTU del siguiente salto, y el emisor baja su estimación. IPv6 usa en su lugar mensajes Packet Too Big, porque los routers no fragmentan en tránsito. Ambos mecanismos suponen que el mensaje encuentra el camino de vuelta al emisor, a través del túnel y más allá de cualquier cortafuegos en la ruta de retorno. Cuando esa suposición falla, el emisor sigue reintentando un tamaño que la ruta no puede llevar.

Un cortafuegos que permite echo request y echo reply no ha permitido necesariamente esos tipos de error. ICMP es una familia, y los miembros que importan aquí son los errores, no el par de echo. Compruebe la política de tráfico de control en ambos extremos del túnel y en la ruta entre ellos, y siga las indicaciones compatibles de la plataforma en lugar de permitir todos los tipos de ICMP en todas partes.

El mismo filtrado puede estar dentro del túnel. Si la ruta interna descarta el error pero la externa lo transporta, el emisor puede adaptarse a un límite que el tráfico encapsulado en realidad nunca ve.

Pruebe la ruta en lugar de adivinar un número

Mantenga fijos el destino, la red de acceso y el túnel, y varíe solo el tamaño del paquete. Una sonda de no fragmentar que falla con un indicio de MTU le da el límite del siguiente salto; repita hasta que pase un tamaño, y anote tanto el tamaño como la familia de direcciones.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Un ping que encaja no demuestra que los segmentos de tamaño completo de una aplicación real encajen, así que repita la prueba con la transferencia que falló de verdad. Compare la sonda más grande que funciona con el MTU del túnel que configuró, y mantenga los dos números separados en sus notas. Si difieren en aproximadamente el valor de una cabecera, ha encontrado la sobrecarga de encapsulación y no una avería.

PLPMTUD, descrito en RFC 4821, sondea hacia arriba y usa confirmaciones del transporte en lugar de confiar en los errores entregados. Ayuda en rutas que filtran ICMP, pero el soporte varía según la pila y la aplicación. Un flujo TCP puede recuperarse solo, mientras que una aplicación UDP con tamaño de datagrama fijo sigue fallando.

Elija un valor y anote el razonamiento

Bajar el MTU del túnel es a la vez un diagnóstico y una corrección legítima una vez que conoce la ruta. No sustituye saber qué ruta y qué mecanismo de retroalimentación intervinieron, porque un valor ajustado para un enlace móvil será innecesariamente pequeño en una conexión de fibra. Anote el tamaño elegido, la sonda que lo justificó y el paso de reversión.

El mecanismo IPv4 se describe en RFC 1191 y la guía de empaquetado IPv6 en RFC 8201; nombrar ambos evita que el siguiente ingeniero vuelva a deducir la suposición. Si la transferencia sigue atascándose con el tamaño que eligió, deje de bajar el número y mire la capa siguiente. Una ruta que falla con cualquier tamaño no es un problema de MTU.