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

Enrutamos el tráfico de la subred local a través de un servidor remoto (IPIP + enrutamiento por políticas)

Publicado el 29.10.2025

Esta guía mostrará cómo configurar dos servidores Linux para que todo el tráfico de Internet de una subred local determinada (por ejemplo, 10.100.10.0/24) se envíe no a través de su puerta de enlace por defecto, sino a través de un túnel IPIP hacia un servidor remoto, que se encargará de sacar ese tráfico a Internet.

Esto es útil si necesitas que los servicios en una subred salgan al exterior con la dirección IP de otro servidor —por ejemplo, para sortear bloqueos, NAT centralizado o enmascarar el origen.


Actores (ficticios)

RolNombreIP externa (WAN)Interfaz WANIP interna (Tunnel)Nota
Servidor APasarela local198.51.100.10eth010.254.0.1/30Puerta de enlace de la subred 10.100.10.0/24
Servidor BNodo de salida remoto203.0.113.20eth010.254.0.2/30Expone el tráfico a Internet
  • Subred a enrutar: 10.100.10.0/24
  • Nombre del túnel: ipip0
  • Red del túnel: 10.254.0.0/30

Paso 1: Configuración del Servidor B (Nodo de salida remoto)

Objetivo: Aceptar un túnel IPIP desde el Servidor A y sacar el tráfico de la subred 10.100.10.0/24 a Internet mediante NAT usando la IP externa 203.0.113.20.

1.1. Activar reenvío de IP

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
``` ````

---

### 1.2. Configuración del túnel, firewall y NAT

```bash
#!/bin/sh
set -e

TUN_NAME="ipip0"
REMOTE_IP="198.51.100.10"
LOCAL_IP="203.0.113.20"
TUN_NET="10.254.0.2/30"
TUN_PEER="10.254.0.1"
WAN_IFACE="eth0"
CLIENT_NET="10.100.10.0/24"

echo "[*] Creando túnel $TUN_NAME"
ip tunnel del "$TUN_NAME" 2>/dev/null || true
ip tunnel add "$TUN_NAME" mode ipip remote "$REMOTE_IP" local "$LOCAL_IP" ttl 64
ip addr add "$TUN_NET" dev "$TUN_NAME"
ip link set "$TUN_NAME" up mtu 1480

echo "[*] Configurando iptables"

iptables -I INPUT -p 4 -s "$REMOTE_IP" -j ACCEPT
iptables -A FORWARD -i "$TUN_NAME" -s "$CLIENT_NET" -o "$WAN_IFACE" -j ACCEPT
iptables -A FORWARD -i "$WAN_IFACE" -d "$CLIENT_NET" -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -s "$CLIENT_NET" -o "$WAN_IFACE" -j SNAT --to-source "$LOCAL_IP"

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

echo "[OK] Servidor B listo."

Se establece MTU=1480 y TCPMSS clamp para evitar problemas con el descubrimiento de PMTU.


Paso 2: Configuración del Servidor A (Pasarela local)

Objetivo: Redirigir el tráfico de 10.100.10.0/24 destinado a Internet hacia el túnel al Servidor B.

2.1. Activar reenvío de IP y configurar rp_filter

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.default.rp_filter=2

cat <<EOF >> /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
EOF

rp_filter=2 — modo ’loose’ (relajado), obligatorio en enrutamiento asimétrico.


2.2. Crear el túnel IPIP

#!/bin/sh
set -e

TUN_NAME="ipip0"
REMOTE_IP="203.0.113.20"
LOCAL_IP="198.51.100.10"
TUN_NET="10.254.0.1/30"
TUN_PEER="10.254.0.2"

echo "[*] Levantando túnel $TUN_NAME"
ip tunnel del "$TUN_NAME" 2>/dev/null || true
ip tunnel add "$TUN_NAME" mode ipip remote "$REMOTE_IP" local "$LOCAL_IP" ttl 64
ip addr add "$TUN_NET" dev "$TUN_NAME"
ip link set "$TUN_NAME" up mtu 1480

echo "[OK] Túnel levantado."

2.3. Policy Routing

Añadir la tabla de enrutamiento:

grep -q "100[[:space:]]tunnel_route" /etc/iproute2/rt_tables || echo "100 tunnel_route" >> /etc/iproute2/rt_tables

Añadir ruta por defecto:

ip route add default via 10.254.0.2 dev ipip0 table tunnel_route

Crear la regla:

ip rule add from 10.100.10.0/24 table tunnel_route pref 1000
ip route flush cache

2.4. Configurar Firewall

CLIENT_NET="10.100.10.0/24"
TUN_NAME="ipip0"

iptables -A FORWARD -s "$CLIENT_NET" -o "$TUN_NAME" -j ACCEPT
iptables -A FORWARD -i "$TUN_NAME" -d "$CLIENT_NET" -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t mangle -A FORWARD -o "$TUN_NAME" -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

echo "[OK] Firewall y enrutamiento por políticas configurados."

Paso 3: Comprobación

Comprobamos la ruta normal:

ip route get 8.8.8.8

Se espera:

8.8.8.8 via <tu_puerta_de_enlace> dev eth0 src 198.51.100.10 ...

Comprobamos la ruta desde la subred:

ip route get 8.8.8.8 from 10.100.10.50

Se espera:

8.8.8.8 from 10.100.10.50 via 10.254.0.2 dev ipip0 src 198.51.100.10 ...

🧩 Solución de problemas (diagnóstico y depuración)

1. Comprobación del túnel

ip addr show dev ipip0
ip -s tunnel show
ping -I ipip0 10.254.0.2

Si el ping no responde — verifica que IPIP (protocolo 4) esté permitido en el firewall.


2. Comprobación del policy routing

ip rule show
ip route show table tunnel_route

Debería existir la línea:

1000: from 10.100.10.0/24 lookup tunnel_route

3. Comprobación del NAT

iptables -t nat -L POSTROUTING -v -n

Los contadores SNAT deberían aumentar con tráfico activo.


4. Comprobación de la IP externa desde la subred

curl -4 ifconfig.me

Se espera — 203.0.113.20.


5. MTU y MSS

Si hay bloqueos en TCP:

ip link show ipip0
ping -M do -s 1472 8.8.8.8

Ajusta mtu 1480 y --clamp-mss-to-pmtu.


6. tcpdump

tcpdump -ni ipip0
tcpdump -ni eth0 host 8.8.8.8

7. Registro temporal

iptables -I FORWARD 1 -j LOG --log-prefix "[FORWARD DROP] "
tail -f /var/log/kern.log

8. Comprobación de la ruta de retorno

traceroute -s 10.100.10.10 8.8.8.8

y desde el Servidor B:

traceroute -s 10.254.0.2 10.100.10.10

9. Guardar estado

iptables-save > /etc/iptables/rules.v4
ip rule show > /etc/iprules.conf

⚙️ Recomendaciones adicionales

ElementoRecomendación
MTUEstablece 1480 y habilita TCPMSS clamp
FirewallEn sistemas nuevos es preferible nftables
PersistenciaAutomatiza el arranque del túnel mediante systemd
Monitorizacióntcpdump -i ipip0 mostrará el tráfico en el túnel
SeguridadRestringe el acceso IPIP y añade IPSec/WireGuard si es necesario

✅ Listo

Ahora todo el tráfico de Internet de 10.100.10.0/24 sale a través de la IP del Servidor B (203.0.113.20), mientras que el Servidor A sigue usando su ruta habitual.

Es un esquema sencillo y fiable para NAT centralizado, sortear restricciones o organizar una VPN interna basada en Linux puro.

¿Necesitas ayuda?

Escríbeme y te ayudaré a resolver el problema

Publicaciones relacionadas