Agujero negro de MTU: por qué las peticiones pequeñas funcionan pero las subidas se atascan

Una página carga, una llamada API pequeña regresa y luego una subida de archivo se cuelga hasta que el cliente se rinde. Nada en el registro del servidor lo explica, porque los paquetes se descartaron en medio del camino sin enviar una respuesta útil. Ese patrón es un agujero negro de MTU: un enlace más estrecho de lo que supone el emisor, más una negativa silenciosa a decirlo. El tamaño que falla es repetible, y eso es lo que lo hace diagnosticable.

Qué hace negro el agujero

Cada enlace tiene una unidad máxima de transmisión, y un paquete mayor que el límite del siguiente salto debe fragmentarse o rechazarse con un mensaje ICMP que lo diga. El descubrimiento de la MTU del camino depende de que ese mensaje llegue y se respete. Filtrarlo o ignorarlo deja al emisor repitiendo un paquete que nunca cabe.

La encapsulación hace que esto sea habitual en los VPN, porque un túnel añade una cabecera externa a un paquete que ya estaba dimensionado para el enlace físico. El paquete interno es legal a 1500 bytes y el encapsulado no, así que muere en la frontera mientras los paquetes pequeños pasan. Un handshake completado y una página de inicio que funciona solo demuestran que los paquetes pequeños funcionan. El paquete más grande que la aplicación intenta enviar es el que importa.

Encuentra el tamaño donde se rompe

Busca por bisección el tamaño de la carga con una prueba sin fragmentación, desde un equipo a un lado del túnel hacia un equipo al otro. La carga mayor que tiene éxito es tu MTU de camino utilizable menos la sobrecarga de la cabecera.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Una carga de 1472 bytes tiene éxito en un camino Ethernet limpio de 1500 bytes una vez añadidos los 28 bytes de las cabeceras IPv4 e ICMP. Cuando la misma prueba solo tiene éxito con una carga menor una vez levantado el túnel, la diferencia es la sobrecarga de encapsulación, y la frontera del túnel es donde debería haberse generado el mensaje de rechazo. Anota ambos números, antes y después de conectar, porque ese par es la prueba. Repite la prueba para IPv6 cuando la aplicación lo use, ya que la cabecera es mayor y el umbral de fallo se desplaza.

Lee las pruebas antes de culpar al túnel

Los errores de aplicaciones remotas, la congestión y la pérdida ordinaria también atascan las subidas, así que una transferencia fallida no identifica un agujero negro. Lo que los separa es la relación de tamaños: un éxito repetible a 1200 bytes y un atasco repetible a 1400 bytes, en la misma dirección, por el mismo punto final.

Una captura en ambos extremos muestra los paquetes grandes saliendo y sin llegar nunca, sin rechazo entre medias. Ese es el momento de mirar el dispositivo de frontera en lugar del servidor, que responde a cada petición que recibe de verdad. La congestión también atasca, pero atasca tamaños distintos en momentos distintos, y eso es una firma diferente.

Comprueba la reparación en ambos transportes

La reparación admitida es dejar que la frontera informe del límite real, o fijar allí el tamaño máximo de segmento de TCP para que no se intente ningún segmento demasiado grande. Bajar cada MTU de la red, o desactivar el cortafuegos, oculta el síntoma y deja una configuración sobre la que nadie podrá razonar después.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Verifícalo con la misma prueba de tamaño, luego con la aplicación que falló, y comprueba un segundo protocolo, porque las aplicaciones UDP nunca reciben la corrección de tamaño de segmento de TCP. Guarda los valores originales en el ticket, porque una reparación que no se puede revertir es un segundo problema esperando a ocurrir. Si la prueba de tamaño pasa y la subida sigue atascada, el agujero negro no era la causa, y la investigación debe seguir adelante en lugar de ampliar el cambio.