Túneles GRE para IPv4: cuándo necesitas uno y cómo configurarlo

Un túnel te permite usar direcciones IPv4 en un servidor que de otro modo no podría llevarlas. El bloque lo anuncia una red que puede anunciarlo, y el túnel lleva su tráfico hasta tu servidor y de vuelta. Es la respuesta cuando tu proveedor no ofrece bring your own IP (BYOIP), cuando no tienes número AS o cuando necesitas menos de las 256 direcciones que internet enruta por sí solas.

Lo que hace realmente el túnel

Los paquetes para tu bloque llegan a la red que lo anuncia. Allí cada paquete se envuelve en uno nuevo, dirigido a tu servidor, y se envía por internet normal. Tu servidor lo desenvuelve y ve el paquete original, como si las direcciones estuvieran configuradas en una interfaz local.

Original packet:  [IP header | data]
GRE packet:       [outer IP | GRE header | IP header | data]

Las respuestas hacen el mismo camino a la inversa: tu servidor las envuelve, las envía al otro extremo del túnel y esa red las entrega. Ese camino de vuelta es el paso que más configuraciones hacen mal, y la configuración de abajo muestra por qué.

Cuándo un túnel es mejor que BYOIP

El BYOIP permite que un proveedor cloud o de hosting anuncie tu bloque desde su propia red (qué proveedores lo hacen). Donde está disponible y tienes al menos un /24, es la opción más limpia: sin salto adicional, sin un punto de fallo más y con todo el ancho de banda del proveedor. Un túnel es mejor opción en cuatro casos.

• Tu proveedor no ofrece BYOIP. Scaleway, por ejemplo, lo dice claramente en su documentación, y varios otros solo lo aceptan a petición, para algunos de sus productos, como Infomaniak, TransIP y UpCloud. Otros, entre ellos Contabo, Exoscale, Hostinger y Akamai Cloud, no publican ningún procedimiento.
• Necesitas menos de 256 direcciones. Un /24 es el bloque más pequeño que las redes aceptan en sus tablas de enrutamiento, y el BYOIP de ningún proveedor baja de ahí. Un túnel puede entregar un /29, o una sola dirección.
• No tienes ASN y el proveedor quiere uno. Algunos proveedores solo aceptan tu espacio por una sesión BGP con tu propio número AS. Un túnel no necesita ni lo uno ni lo otro.
• Quieres las mismas direcciones en varios sitios, o libertad para moverte. El anuncio se queda donde está; el túnel va adonde vaya tu servidor.

El precio es un rodeo. El tráfico viaja hasta el otro extremo del túnel antes de llegarte, así que elige un extremo cercano a tu servidor, y recuerda que el techo lo marca la capacidad del túnel, no el puerto de tu servidor.

GRE o WireGuard

Los dos llevan el mismo tráfico; se diferencian en lo que necesita el camino entre los dos extremos.

La propia lista de plataformas de WireGuard y la documentación de RouterOS de MikroTik dicen dónde funciona (comprobado el 22 de octubre de 2026).

Si tu extremo está detrás de NAT, la elección ya está hecha: WireGuard. Lo mismo vale para Azure, que bloquea GRE en sus redes virtuales.

MTU y MSS: el fallo clásico

La encapsulación añade cabeceras, así que el paquete más grande que cabe dentro del túnel es menor que los 1500 bytes de un enlace Ethernet normal: 1476 bytes para GRE sobre IPv4, y WireGuard suele funcionar con 1420. Si te equivocas, ves el síntoma clásico: las peticiones pequeñas funcionan, mientras que las descargas grandes y los handshakes TLS se cuelgan, porque los paquetes que no caben se descartan y los mensajes que deberían avisar de ello a menudo se filtran por el camino.

Dos ajustes lo evitan. Pon la MTU de la interfaz del túnel en el valor correcto, y limita el tamaño máximo de segmento TCP (MSS) en el tráfico que enrutas por el túnel, para que ambos extremos acuerden enviar paquetes que quepan. Enviamos los dos valores con cada túnel, y los cambiamos a petición.

Una configuración mínima en Linux

El ejemplo de abajo lleva un bloque a un único servidor Linux por GRE. Las direcciones son rangos de documentación: 203.0.113.1 es la dirección pública de tu servidor, 198.51.100.1 el otro extremo del túnel y 192.0.2.0/24 el bloque.

# 1. The tunnel, from your server to the far end
ip tunnel add gre1 mode gre local 203.0.113.1 remote 198.51.100.1 ttl 255
ip link set gre1 mtu 1476 up
ip addr add 10.0.0.2/30 dev gre1

# 2. An address from the block on the server itself
ip addr add 192.0.2.10/32 dev lo

# 3. Replies from the block go back through the tunnel
ip rule add from 192.0.2.0/24 lookup 100
ip route add default via 10.0.0.1 dev gre1 table 100

El paso 3 es el que se olvida. Sin él, las respuestas desde 192.0.2.10 salen por el enlace propio de tu proveedor, con una dirección de origen que ese proveedor nunca te dio, y sus filtros antispoofing las descartan. Si tu distribución activa el filtrado estricto de ruta inversa, ponlo también en modo flexible para el túnel (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Si el servidor enruta el bloque hacia máquinas virtuales o contenedores, limita el MSS en el tráfico que reenvía:

iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

BGP por el túnel

Si tienes tu propio número AS y quieres controlar tú mismo el anuncio, puedes usar una sesión BGP por el túnel en lugar de una ruta estática, con BIRD, FRR o el daemon propio de tu router. La mayoría de los clientes no lo necesitan y eligen la configuración estática. Si anuncias desde tu propio ASN, el ROA tiene que indicar ese ASN (RPKI y ROA).

Dónde encaja RTM Networks

Anunciamos el bloque y lo entregamos a tu servidor por GRE o WireGuard, esté donde esté el servidor. Eso funciona donde el BYOIP no, también para menos de 256 direcciones y para proveedores que no aceptan tu espacio en absoluto. Dinos dónde está el servidor y qué ejecuta, y te recomendaremos GRE o WireGuard y te enviaremos la configuración con los valores correctos de MTU y MSS (túneles GRE y WireGuard).