Bandera: Русский Русский Bandera: English English

Problema con el MTU en reg.ru y su solución mediante iptables

Publicado el 05.08.2025


Introducción: Un problema oculto con la red

Desarrolladores y administradores de sistemas que usan servidores en la plataforma OpenStack (por ejemplo, las líneas de tarifa C*-M*-D* en el proveedor de hosting reg.ru) a veces se enfrentan a problemas de red enigmáticos. Parece que Internet funciona, pero al intentar transmitir grandes volúmenes de datos o establecer conexión con ciertos servicios, las solicitudes pueden quedarse colgadas o cortarse por timeout.

El proveedor explica este problema por las particularidades de su infraestructura:

Los servidores en la plataforma OpenStack usan la tecnología VxLAN, que reserva 50 bytes para información de control. Debido a esto, el tamaño máximo de unidad de transmisión (MTU) en la interfaz de red principal del servidor (ens3) es de 1450 bytes.

Al mismo tiempo, Docker por defecto configura las interfaces de red de los contenedores con MTU de 1500 bytes. Esto hace que los paquetes enviados desde el contenedor superen el tamaño permitido y no puedan ser transmitidos a la red global.

Soluciones oficiales y sus limitaciones

La solución propuesta por el proveedor consiste en cambiar manualmente el MTU para los contenedores Docker:

  • En docker-compose.yml hay que añadir para cada red el parámetro com.docker.network.driver.mtu: 1450.
  • Para docker run y docker build es necesario editar o crear el archivo /etc/docker/daemon.json, indicando en él "mtu": 1450.

Estos métodos, sin duda, resuelven el problema, pero tienen desventajas significativas:

  1. No son globales: Requieren cambiar la configuración manualmente para cada proyecto (docker-compose) o para cada nueva instalación de Docker.
  2. No resuelven el problema para contenedores existentes: Es necesario reiniciar y recrear todos los contenedores, lo que puede ser incómodo.
  3. Se olvida fácilmente: Un desarrollador que traslada el proyecto a un servidor con esta particularidad puede no recordar de inmediato la necesidad de cambiar el MTU, lo que llevará a perder tiempo en depuración.

Solución global y elegante con iptables

En lugar de cambiar manualmente la configuración de cada contenedor, se puede resolver este problema una vez y para siempre a nivel del propio servidor, usando iptables.

La idea de la solución es la siguiente: no vamos a cambiar el MTU en Docker, sino que aprovecharemos la capacidad de iptables para modificar automáticamente un valor especial en los paquetes TCP: el MSS (Maximum Segment Size). MSS es el tamaño máximo de la carga útil en un paquete TCP. Es 40 bytes menor que el MTU (20 bytes para la cabecera IP y 20 bytes para la cabecera TCP).

La regla de iptables hará que los paquetes TCP salientes de nuestro servidor “informen” de un MSS correcto, basado en el MTU de la interfaz de salida. De este modo, el host remoto nos enviará paquetes de menor tamaño y el problema de MTU quedará resuelto a nivel de la conexión TCP.

Instrucciones para aplicar iptables

Para aplicar esta regla, necesitamos añadir una línea en iptables.

  1. Determine el nombre de su interfaz de red principal. Normalmente es ens3 o eth0. Puede comprobarlo con el comando ip a. Luego ponga el nombre de la interfaz en la variable IFACE_NAME.

    export IFACE_NAME=ens3
    
  2. Ejecute el siguiente comando:

sudo iptables -t mangle -A POSTROUTING \
    -p tcp --tcp-flags SYN,RST SYN -o $IFACE_NAME \
    -j TCPMSS --clamp-mss-to-pmtu

¿Qué hace este comando?

  • sudo iptables: Ejecuta el comando iptables con privilegios de administrador.
  • -t mangle: Indica que trabajamos con la tabla mangle, que se usa para alterar paquetes.
  • -A POSTROUTING: Añade una regla en la cadena POSTROUTING. Esta cadena procesa paquetes que acaban de salir de la red local y están listos para enviarse a la global.
  • -p tcp --tcp-flags SYN,RST SYN: Filtra solo el primer paquete en la conexión TCP (SYN), que es el que comunica el tamaño máximo del segmento.
  • -o $IFACE_NAME: Indica que la regla se aplica solo a paquetes salientes por la interfaz de red principal del servidor (en nuestro ejemplo ens3).
  • -j TCPMSS --clamp-mss-to-pmtu: La acción es TCPMSS. Esta acción calcula automáticamente el MSS máximo en base al MTU de la interfaz de salida y lo establece. Es una solución más universal que fijar un valor concreto.
  1. Hacer la regla persistente

Las reglas de iptables por defecto son temporales y desaparecen tras reiniciar el servidor. Para guardar la regla, use utilidades del sistema. En la mayoría de distribuciones modernas de Linux (Ubuntu, Debian) se puede usar netfilter-persistent.

Para Ubuntu/Debian:

sudo apt-get install netfilter-persistent
sudo netfilter-persistent save
sudo systemctl enable netfilter-persistent

Conclusión

La solución con iptables es preferible a modificar manualmente la configuración de Docker. Permite:

  • Corregir el problema globalmente: Ahora todos los contenedores, independientemente de cómo fueron creados, funcionarán correctamente.
  • Ahorrar tiempo: Ya no hace falta recordar cambiar docker-compose.yml o daemon.json para cada nuevo proyecto.
  • Evitar tiempos de inactividad: No es necesario recrear los contenedores ya en ejecución.
  • Ser universal: El uso del flag --clamp-mss-to-pmtu hace la solución independiente del valor concreto de MTU.

Esta solución elegante y fiable permite centrarse en el desarrollo en lugar de en problemas de infraestructura, y es ideal para desarrolladores que valoran su tiempo.

Reseñas relacionadas

Muchísimas gracias a Mijaíl por su trabajo, estoy muy satisfecho con el resultado. Agradezco especialmente las recomendaciones durante la configuración: a partir de un pliego de requisitos bastante confuso por mi parte (y yo entiendo poco de servidores), Mijaíl, con preguntas aclaratorias y propuestas, formuló una comprensión clara de qué tareas resolvería la configuración final y cómo organizarlo todo de la mejor manera. ¡Lo recomiendo!

ladohinpy · Configuración de Mikrotik hAP. Configuraré su router Wi‑Fi Mikrotik.

21.07.2025 · ⭐ 5/5

Muchísimas gracias a Mijaíl por el trabajo, estoy muy satisfecho con el resultado. Agradezco especialmente las recomendaciones durante el proceso de configuración; a partir de mi especificación bastante confusa (y yo sé poco de servidores), Mijaíl, con preguntas aclaratorias y propuestas de su parte, formuló una comprensión clara de qué tareas resolverá la configuración final y cómo organizar todo de la mejor manera. ¡Lo recomiendo!

Excelente profesional, experto y persona maravillosa. En una hora nos arregló lo que llevábamos días intentando solucionar. Estoy seguro de que no será la primera vez que recurramos a su excepcional profesionalismo.

Ravenor · MikroTik hAP: configuración del router. Configuraré su router MikroTik Wi‑Fi.

28.05.2025 · ⭐ 5/5

Excelente especialista, un experto con mucha experiencia y una persona maravillosa. En una hora nos arregló aquello por lo que llevábamos días rompiéndonos la cabeza! Estoy seguro de que no será la primera vez que recurramos a su inmenso profesionalismo

¡Un enfoque profesional!

ErlikZ · Configuración del router Mikrotik hAP. Configuraré su router Mikrotik Wi-Fi.

31.03.2025 · ⭐ 5/5

¡Enfoque profesional al asunto!

¿Necesitas ayuda?

Escríbeme y te ayudaré a resolver el problema

Publicaciones relacionadas