top of page

Tuneles GRE para enrutamiento dinámico

  • jogofus
  • 11 sept 2024
  • 4 Min. de lectura

Hoy traigo una entrada que -considero- es bastante interesante.

Siguiendo el hilo de la anterior entrada, continuamos configurando nuestro propio router. En ella hablabamos de OSPF entre Debian (con FRR) y Fortigate. Ahora vamos a ir un paso más allá:

Vamos a configurar una VPN IPsec y vamos a configurar las rutas de forma dinámica.


¿Cómo vamos a hacer esto? La respuesta es obvia. Como he dicho antes, vamos a hacer uso de OSPF.


-Vaya locura, OSPF no funciona a través de IPsec. No va a funcionar en la vida.


Razón no falta a la sentencia anterior. Nos encontramos con un pequeño problema, y es que IPsec es un protocolo que solo permite el tráfico unicast, y OSPF usa el tráfico multicast para propagar las rutas a los routers adyacentes.


-¿Entonces? ¿Esa introducción era mentira?


No. Y me explico: para poder hacer el laboratorio de hoy vamos a necesitar hacer uso de un protocolo de encapsulamiento llamado GRE.


Túneles GRE: ¿qué son?

ree

GRE son las siglas de Generic Routing Encapsulation y se trata de un protocolo para el establecimiento de túneles a través de Internet. Este protocolo se definió eni la RFC 1701 y RFC 1702, y puede transportar hasta 20 protocolos de la capa 3 del modelo OSI. Estamos hablando de un protocolo que data de 1994 (estandarizado desde esa fecha, pero ya entró en funcionamiento anteriormente).


¿Qué nos ofrece GRE? Con este protocolo podemos encapsular paquetes que no son compatibles en la red.

Gracias a GRE podremos enrutar tráfico multicast, algo que IPsec no permite. ¿Se entiende donde quiero llegar a parar, verdad?

ree

GRE añade dos encabezados a cada paquete: el encabezado GRE, de 4 bytes, y un encabezado IP, de 20 bytes. El encabezado GRE indica el tipo de protocolo utilizado por el paquete encapsulado. El encabezado IP encapsula la cabecera y la carga útil del paquete original. Esto significa que un paquete GRE suele tener dos encabezados IP: uno para el paquete original y otro añadido por el protocolo GRE. Solo los enrutadores de cada extremo del túnel GRE harán referencia al encabezado IP original, que no es GRE.

ree
ree

Sumando GRE a IPsec: funcionando OSPF a través de internet

El defecto de GRE es que no cifra el tráfico, por lo que sería susceptible de un ataque MITM y que el atacante viera todo el tráfico que estamos mandando a través de la red. En una red local esto podría "importar menos" (y lo pongo entre comillas porque en términos de seguridad NUNCA hay que escatimar, ya que los malos nunca lo harán), pero cuando salimos a internet y estamos expuestos a que cualquiera pueda verlo, la cosa cambia.


Imaginemos que tenemos dos sedes, una en Valencia y otra en Barcelona, y queremos interconectarlas para que ambas sedes puedan compartir recursos.


-Pues se crea una VPN IPsec (o incluso Wireguard) y se definen las rutas, ya ves tú.


Razón no le falta a esa frase siempre y cuando tengamos pocas rutas.

Ahora pongamos que pasamos de tener 3 redes en cada sede a tener 50 un mes, en dos meses cambiamos las redes a otras (quitamos unas, añadimos otras), pasado el tiempo pasamos a tener 100 redes. Y lo mismo en la sede de Barcelona.


¿En serio te vas a poner a definir rutas manualmente cada vez que haya un cambio? No es óptimo para nada. Y además, susceptible de error humano al no definir alguna de las redes (y ponte a buscar en una tabla de 100 rutas a ver cuál falta o si está bien definida).


Para eso vamos a hacer uso IPsec para cifrar el tráfico. Dentro de ese túnel vamos a hacer que pase un túnel GRE (que como he dicho permite el tráfico multicast para OSPF). Una vez hecho esto, vamos a propagar las rutas a través de OSPF.


Manos a la obra.


Montando el laboratorio

Para este laboratorio no he hecho uso de nada virtualizado, aunque se puede hacer (claro que sí, dios bendiga a la virtualización).


Haremos uso de dos dispositivos con Debian y FRR y strongswan instalado. Para la instalación de FRR puedes ir a mi anterior entrada o a la página oficial de FRR.


El esquema es el siguiente:

ree

WAN A: 192.168.50.10

WAN B: 192.168.60.10

LAN A: 10.10.10.0/24

LAN B: 10.10.20.0/24


Solo se ha definido una LAN para hacerlo más simple, pero se pueden añadir todas las redes que necesitemos.


Configuración de las interfaces de red en FRR:


Debian1:

vtysh
configure terminal
interface enp2s0
ip address 192.168.50.10 255.255.255.0
no shutdown
!
interface enp4s0
ip address 10.10.10.1 255.255.255.0
no shutdown
!

Debian2:

vtysh
configure terminal
interface enp2s0
ip address 192.168.60.10/24
no shutdown
!
interface enp4s0
ip address 10.10.20.1/24
no shutdown
!

Ahora deberemos crear la vpn IPsec. Para ello haremos uso de dos ficheros: /etc/ipsec.conf, donde pondremos la configuración de todos los túneles, y /etc/ipsec.secrets,donde pondemos los preshared keys.


Debian1:

ree

Debian2:

ree

Ejecutamos el siguiente comando para reiniciar el tunel en uno de los dos routers:

ipsec restart

Y podremos ver el estado del tunel con:

ipsec status
ipsec statusall
ree
ree

Una vez hecho esto, vamos a configurar el tunel GRE:


Debian1:

ip tunnel add gre1 mode gre local 192.168.50.10 remote 192.168.60.10 ttl 255
ip link set gre1 up
ip link set dev gre1 mtu 1400

Debian2:

ip tunnel add gre1 mode gre local 192.168.60.10 remote 192.168.50.10 ttl 255
ip link set gre1 up
ip link set dev gre1 mtu 1400

Ahora vamos a configurar OSPF tal y como lo hicimos en la entrada anterior, pero primero debemos darle una IP a la interfaz gre1 desde FRR.


Debian1:

vtysh
configure terminal
interface gre1
ip address 10.0.0.1/30
no shut
!

Debian2:

vtysh
configure terminal
interface gre1
ip address 10.0.0.2/30
no shut
!

Ya tenemos levantado el tunel gre y podemos hacer ping a 10.0.0.2 desde Debian1 y viceversa. Si hacemos una captura con Wireshark, veremos que el tráfico va cifrado por IPsec.

ree
ree

Debian1:

router ospf
ospf router-id 1.1.1.1
network 10.0.0.0/30 area 0.0.0.0
network 10.10.10.0/24 area 0.0.0.0
!

Debian2:

router ospf
ospf router-id 2.2.2.2
network 10.0.0.0/30 area 0.0.0.0
network 10.10.20.0/24 area 0.0.0.0
!

Dejamos pasar unos segundos para que se haga la propagación de las rutas y comprobamos las tablas de rutas.

ree
ree
ree

Ahora podemos hacer ping a cualquier red que esté anunciada por el router adyacente sin tener que añadirlas manualmente.



NOTA: Para simplificar el laboratorio se ha dejado el firewall iptables con políticas en ACCEPT por defecto. Lo suyo sería establecer qué puertos están abiertos y hacer un DROP de todo lo demás.


 
 
 

Comentarios


bottom of page