☰

Enrutar el tráfico entre dos túneles IPsec

tag-icon • tag-icon vpn ipsec strongswan backend libreswan
Enrutar el tráfico entre dos túneles IPsec

Ejecuto un backend en la infraestructura DO, llámelo sitioyvi, que se conecta a un sitio de tercerosprovinciaa través de un túnel IPsec, con esta configuración de libreswan:

conn prov-client
  ...
  right=$YVI_IP
  rightsourceip=10.31.3.1
  rightsubnet=10.31.3.0/28
  left=$PROV_IP
  leftsubnet=10.70.0.36/28

provinciatiene un servidor ejecutándose 10.70.0.37y puedo interactuar con él desdeyvi.

Mi problema es que estoy configurando un entorno de desarrollo local (un cuadro de Ubuntu en otra red) y cada vez que hago un cambio tengo que implementarlo enyviporque solo desde allí puedo llegar a la API enprovincia. Me gustaría evitar esto conectándomeLocalayviy dirigir ese tráfico aprovinciapara poder llegar a la API enprovinciadeLocaly facilitar el desarrollo.

Me conectoLocalayvicomo guerrero de la carretera con la siguiente configuración:

conn remote-dev-client
  ...
  left=$YVI_IP
  leftsubnet=10.31.3.0/28
  right=%any
  rightaddresspool=10.31.4.1-10.31.4.254

La conexión se establece exitosamente y desdeLocalpuedo 10.31.3.1alcanzaryvi. Lo que quiero es 10.70.0.37llegarprovinciadeLocal. La ruta a la 10.70.0.36/28red no se agrega automáticamente, así que intenté configurar algunas ip xfrmreglas ip routemanualmente enLocal:

# Outgoing
ip xfrm policy add dst 10.70.0.37 src 10.31.4.1 dir out tmpl src $LOCAL_IP dst $YVI_IP proto esp spi $SPI reqid $REQID mode tunnel priority 100000

# Incoming
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir fwd tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir in tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000

ip route add table 220 src 10.31.4.1 10.70.0.37 via $LOCAL_IP dev $LOCAL_IF proto static

ahora sigo ip xfrm monitorcorriendoyviy luego deLocalhacer silbido 10.70.0.37; Puedo ver los paquetes llegando ayvi(desde el monitor xfrm enyvi), pero sólo el mensaje saliente, no la respuesta (como se ve si hago ping a 10.31.3.1, por ejemplo), lo que sugiere queyvirecibe el tráfico pero no lo dirige aprovincia? Realmente no sé cómo interpretar esto.

Creo que tengo que agregar rutas enyviencaminar el tráfico hacia laprovinciaAPI correctamente, pero agregar reglas similares a las anteriores no ha funcionado. Agradecería ayuda para comprender lo que me estoy perdiendo y lo que estoy haciendo mal.

También se aceptan sugerencias para un enfoque diferente, aunque la única forma de conectarseprovincia, que no controlo, es a través de un túnel IPsec desdeyvi, que sí controlo.

Respuesta1

Pude solucionarlo con las reglas NAT de iptables. Las ip xfrmpolíticas no eran necesarias. Esta es una pequeña explicación de lo que hice, para alguien que como yo no es un experto:

DeyviEstoy asignando a los guerreros de la carretera una 10.31.4.0/24subred, por lo que el demonio de claves (libreswan en mi caso) instala automáticamente una ruta para esa red, por lo que agregué reglas NAT enyvi( /etc/ufw/before.rules, ya que estoy usando UFW, pero podrías lograr lo mismo iptablesdirectamente):

*nat
-F
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# PRE 
-A PREROUTING -s 10.31.4.0/24 -d 10.31.3.2 -j DNAT --to-destination 10.70.0.37


# POST
-A POSTROUTING -s 10.31.4.0/24 -d 10.70.0.37 -j SNAT --to-source 10.31.3.1

COMMIT

Le *natdice a iptables que aplique las reglas a la tabla NAT y COMMITrealmente guarda las reglas. Está -Fahí solo por conveniencia, ya que UFW agrega las reglas ufw enablepero no las elimina, ufw disablepor lo que termina con duplicados, de ahí la marca de descarga -F.

La PREROUTINGregla se aplica a los paquetes entrantes desde la subred de Road Warrior destinada a 10.31.3.2, y lo que hace es cambiar la dirección de destino en 10.70.0.37lugar de 10.31.3.2asignar efectivamente esa dirección IP a laprovinciaservidor, desde la perspectiva de los guerreros de la carretera.

La POSTROUTINGregla se aplica a los paquetes entrantes desde la subred del guerrero de la carretera que está a punto de salir 10.70.0.37(es decir, paquetes que acaban de alcanzar la regla de enrutamiento previo) y cambia su dirección de destino de una dirección 10.31.4.0/0a 10.31.3.1. Esto es necesario porque no controlo las rutas, el servidor ni nada enprovincia, Así que siprovinciarecibe una solicitud de la 10.30.4.0/24subred, no sabrá cómo responder. Pero sí lo sabe 10.31.3.1.

¡Y eso es! Ahora puedo alcanzarprovinciadeLocala través deyvien 10.31.3.2.

información relacionada