Mitos del MTU en VPN: por qué se encogen tus paquetes y adónde va el espacio

Alguien te dice que la VPN «pierde paquetes por culpa del MTU», pones el túnel en 1400 y la transferencia vuelve a funcionar. Ese resultado parece un diagnóstico. Normalmente es una coincidencia aritmética: elegiste un número lo bastante pequeño para caber bajo un límite que nunca identificaste, y volverás a encontrarte el mismo límite en la próxima red con un presupuesto distinto.

Dos mitos causan la mayor parte de esto. El primero es que el MTU de la interfaz del túnel es el MTU de la ruta. El segundo es que la encapsulación cuesta «una cabecera» y que PPPoE no cuesta nada que merezca contarse. Ambos son falsos de formas que hacen que el número que eliges parezca arbitrario cuando en realidad está determinado.

Mito uno: el MTU del túnel es el MTU de la ruta

El valor que pones en una interfaz de túnel es una promesa local sobre el paquete interno más grande que la implementación entregará hacia abajo. La capacidad real de la ruta es una propiedad de cada enlace entre tú y el extremo remoto, y puede cambiar cuando cambia una ruta, cuando una conexión móvil hace traspaso o cuando el tráfico toma otro emparejamiento. Un 1500 configurado te dice qué construirá tu host, no qué transportará la red.

El descubrimiento del MTU de ruta existe para conciliar ambos y depende de la realimentación. Con IPv4, un router que no puede reenviar un paquete de tamaño completo debería enviar un mensaje ICMP «fragmentation needed», y el emisor baja su estimación. Con IPv6, el equivalente es un mensaje Packet Too Big y los routers no fragmentan en tránsito en absoluto. Cuando esa realimentación se filtra, el emisor sigue produciendo paquetes que la ruta no puede transportar, y nada le dice por qué.

Mito dos: la encapsulación cuesta una cabecera

Cuenta las capas externas con honestidad. Una cabecera IP externa son 20 bytes en IPv4 o 40 en IPv6. La encapsulación UDP para atravesar NAT añade 8. El protocolo del túnel añade su propia cabecera, un vector de inicialización o nonce, relleno hasta el límite de bloque o alineación del cifrado, un tráiler y un valor de comprobación de integridad. Según el protocolo y el cifrado, el total se sitúa cómodamente en decenas de bytes antes de que el paquete interno siquiera empiece.

Luego resta otra vez las cabeceras del propio paquete interno. Un segmento TCP dentro del túnel lleva su propia cabecera IP de 20 bytes y su cabecera TCP de 20 bytes, y el MSS de TCP se deriva del MTU, no de la carga útil nominal del túnel. Por eso ping con una carga menor puede triunfar mientras una transferencia de archivos se atasca: las herramientas prueban cosas distintas y solo una de ellas ejercita un segmento TCP de tamaño completo.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

El primer comando informa del MTU configurado del túnel. Las dos pruebas envían una carga de 1472 bytes, que con 28 bytes de cabeceras IPv4 e ICMP es un paquete de 1500 bytes, y luego una menor. Si la prueba grande falla del todo y la pequeña triunfa, tienes un fallo dependiente del tamaño y no un problema general de enrutamiento.

Mito tres: PPPoE todavía te da 1500 limpios

Un enlace de acceso PPPoE convencional no transporta un paquete IP de 1500 bytes. La cabecera PPPoE más el campo de protocolo PPP consumen 8 bytes dentro de la trama Ethernet, lo que deja 1492 para el paquete IP. Ese es el límite tradicional descrito en el RFC 2516. Si ejecutas una VPN sobre ese enlace, la sobrecarga del túnel sale de esos 1492, no de 1500.

El RFC 4638 define una forma de negociar una carga PPP mayor cuando tanto el concentrador de acceso como el equipo del cliente lo admiten, por eso «esta conexión usa PPPoE» por sí solo no demuestra un número concreto. Un ajuste local no puede hacer que un dispositivo intermedio acepte un paquete para el que nunca se configuró, así que la pregunta útil es qué negoció realmente el enlace, no qué dice la etiqueta.

Por qué el fallo parece selectivo

Que las peticiones pequeñas triunfen y las transferencias grandes se atasquen es la firma clásica de un agujero negro del MTU de ruta. El saludo, la consulta DNS y la llamada a la API caben todos; la transferencia masiva produce segmentos de tamaño completo que mueren en un enlace, y el mensaje ICMP que debía informar del problema nunca llega. La conexión parece bien y la descarga se cuelga, lo que lleva a la gente a mirar el servidor en vez de la ruta.

Un segundo error relacionado es confundir tres números: el MTU de la interfaz, el MSS de TCP y el ajuste de fragmentación o relleno del propio protocolo. El pinzamiento de MSS en un router reescribe el MSS anunciado para que el emisor construya segmentos más pequeños; no cambia el MTU del túnel ni ayuda al tráfico UDP. Poner el mismo número a los tres porque parecen relacionados es como una configuración que funciona se rompe por un cambio bienintencionado.

Qué cambiar y en qué orden

Empieza con pruebas. Confirma con las pruebas anteriores que el fallo depende del tamaño y luego encuentra el tamaño más pequeño que pasa y el más grande que falla. Comprueba el MTU real del enlace de acceso antes de culpar al túnel; un enlace PPPoE limita el presupuesto antes de que la VPN lo toque. Anota los valores originales para que el cambio se pueda revertir.

Luego aplica el ajuste más pequeño que documente el cliente. Muchos clientes ofrecen un MTU de túnel más una opción de arreglo de MSS, y la opción de MSS suele ser la mejor palanca para TCP porque llega al emisor sin reducir cada paquete. Vuelve a probar el mismo destino y la misma transferencia, y anota los números con los que te quedaste. Un valor de túnel que funciona en una red de acceso no es una constante universal, y el próximo sitio tendrá su propio presupuesto.