Enrutamiento VPN para múltiples sitios

Enrutamiento VPN para múltiples sitios

Actualmente estoy configurando una VPN para múltiples sitios (3 sitios).

Aquí hay un dibujo rápido:

ingrese la descripción de la imagen aquí

Hasta ahora la configuración está bien y funciona como se esperaba. Hacer ping a 10.10.20.1 <-> 10.10.10.1 y a 10.10.30.1 <-> 10.10.10.1 funciona bien.

Ahora quiero descubrir cómo conectarme de 10.10.20.1 a 10.10.30.1.

Creo que necesito usar iptablespara hacer esto, ¿es correcto?

¡Si alguien puede explicar qué pasos son necesarios y por qué me ayudaría mucho!

Respuesta1

No hagas NAT. NAT es una pifia que debe evitarse siempre que sea posible. Rompe el principio de extremo a extremo utilizado como base de TCP/IP.

Con rutas estáticas necesitas apuntarlas hacia el túnel. Si los enrutadores intercambian información de enrutamiento (OSPF, ...), las rutas deberían aparecer automáticamente. Para poner en funcionamiento los túneles, es posible que se requieran rutas estáticas (el enrutamiento dinámico solo se actualiza una vez que el túnel está en funcionamiento).

Respuesta2

Me lo imaginé. Aquí está mi solución larga y rápida:

solución larga (no del todo)

En el servidor inferior:

iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -i enp2s0 -m policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -o enp2s0 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -i enp2s0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -o enp2s0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT

En el servidor superior izquierdo:

ip route add 10.10.30.0/24 via 138.x.x.1 dev eth0 proto static src 10.10.20.1 table 220
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -i eth0 -m . policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -o eth0 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT

En el servidor superior derecho:

ip route add 10.10.20.0/24 via 108.x.x.1 dev eth0 proto static src 10.10.30.1 table 220
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -i eth0 -m policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -o eth0 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT

Aunque funciona enrutando sabiamente, strongswan prohíbe las conexiones como lo reveló tcpdump.

[bottom]$ tcpdump -nni enp2s0 icmp
15:35:22.512437 IP 109.x.x.x > 85.x.x.x: ICMP host 109.x.x.x unreachable - admin prohibited, length 48

solución rápida

Esta solución es bastante interesante porque strongswan/ipsec administra todas las rutas estáticas y iptables por usted y también permite el acceso a las subredes especificadas.

En el servidor inferior:

# /etc/ipsec.conf
conn top-left-to-bottom
    ...
    leftsubnet=10.10.10.0/24,10.10.30.0/24
    ...

conn top-right-to-bottom
    ...
    leftsubnet=10.10.10.0/24,10.10.20.0/24
    ...

En el servidor superior izquierdo:

# /etc/ipsec.conf
conn top-left-to-bottom
    ...
    rightsubnet=10.10.10.0/24,10.10.30.0/24
    ...

En el servidor superior derecho:

# /etc/ipsec.conf
conn top-right-to-bottom
    ...
    rightsubnet=10.10.10.0/24,10.10.20.0/24
    ...

Así es como debería verse un ping tcpdumped exitoso:

[bottom]$ tcpdump -nni enp2s0 icmp
15:52:37.160859 IP 10.10.20.1 > 10.10.30.1: ICMP echo request, id 1296, seq 1, length 64
15:52:37.164971 IP 10.10.30.1 > 10.10.20.1: ICMP echo reply, id 1296, seq 1, length 64

información relacionada