WireGuard se atasca: ¿un límite de MTU o una regla de reenvío ausente?

La costumbre es bajar el MTU en cuanto WireGuard empieza a comportarse mal, y esa costumbre oculta otra avería. Una pasarela que no reenvía y un camino que no transporta paquetes grandes producen patrones distinguibles: uno falla en ambas direcciones y en todos los tamaños, el otro sobrevive a las peticiones pequeñas y muere con las grandes. Identifique qué forma tiene antes de cambiar cualquier número. La prueba es barata y elimina la mitad de las causas posibles.

Dos fallos, dos formas distintas

Un problema de reenvío aparece justo después del servidor. El apretón de manos funciona, la dirección del túnel responde, y nada detrás de la pasarela es accesible ni con una petición diminuta. El paquete llegó al servidor y no se pasó, o la respuesta no tenía ruta de vuelta.

Un problema de tamaño solo aparece por encima de un umbral. El DNS, un apretón TCP y una llamada pequeña a la API funcionan, mientras que la descarga de un archivo o una respuesta grande se cuelgan. Los paquetes que cabían viajaron de extremo a extremo, y los que no cabían se descartaron en algún punto sin un informe útil.

Esas descripciones apuntan a personas distintas y a archivos de configuración distintos, por eso medir la forma vale más que una conjetura. Un solo ping a la pasarela no puede separarlas.

Descarte el reenvío antes de encoger nada

Pruebe un destino más allá de la pasarela, no la pasarela misma. Un ping a la dirección del túnel del servidor solo demuestra que la interfaz está activa y que puede llegar a la máquina que termina el túnel. El tráfico para la red más amplia depende de que el reenvío IP esté activado en esa máquina y de un cortafuegos que permita el flujo reenviado. Ambas cosas deben ser ciertas, y si una es falsa se produce el mismo silencio.

El enrutamiento de vuelta importa lo mismo. Si la red de destino no sabe cómo llegar a la dirección del túnel del cliente, la petición llega y la respuesta desaparece, y el cliente informa de un tiempo de espera que parece idéntico a un reenvío descartado.

Donde el diseño usa traducción de direcciones, la regla de traducción forma parte de ese camino de vuelta. Quitarla mientras se persigue un problema de MTU convierte un diseño que funciona en uno roto, así que lea las reglas existentes antes de editarlas.

Mida dónde empieza la rotura

Primero lea el estado del reenvío y las reglas de filtrado. Son comprobaciones de solo lectura y responden a la pregunta barata:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Después pruebe tamaños con el bit de no fragmentar, desde el cliente, hacia un equipo más allá de la pasarela:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Si la primera prueba funciona y la segunda falla con un error de fragmentación, el camino le está diciendo su tamaño utilizable. Si no funciona ninguna, está mirando un reenvío o un enrutamiento, y el MTU no es la variable que hay que cambiar.

Repare la capa que ha demostrado

Cuando el reenvío es la avería, la corrección es una regla de reenvío o una ruta, expresada con la estrechez que el diseño permita. Cuando el tamaño es la avería, la corrección es un MTU que tiene en cuenta la encapsulación en este camino concreto, aplicado a la interfaz que lo necesita y no a cada adaptador de la flota.

En cualquier caso, después repita la misma tarea contra el mismo destino. Si la transferencia grande original ahora se completa, el cambio abordó la capa que fallaba. Si solo mejoró la prueba pequeña, trató un síntoma y el límite real sigue en su sitio.

Anote qué forma observó antes del cambio. Esa única línea, registrada junto a la corrección, es lo que impide que la siguiente persona baje un MTU que nunca fue el problema.