Conexiones redundantes entre sedes: OSPF + IPsec

Cada vez es más común que nuestras empresas tengan sedes distribuidas por todo el territorio nacional, o incluso por varios países, y que todas las sedes puedan conectarse entre ellas para compartir archivos, loguearse contra el controlador de dominio o cualquier otro menester.

Algunos diréis:

-Pero para eso ya está la nube, ¿no?

Si, y no.

Hay empresas que no usan la nube. Algunas porque son reticentes a que su información esté en manos de otro (recordemos que la nube no es más que el ordenador de otro), otros porque por políticas internas no las usan. Quizá tengan una necesidad que la nube no puede cubrir, o simplemente porque no quieren/pueden asumir el sobrecoste que implica tener contratado el cloud.

Y ahí es donde entran las conexiones VPN site-to-site, donde el rey ahora mismo es IPsec, aunque conozco bastantes casos en los que esto se está sustituyendo por Wireguard, el cual tiene un rendimiento muy bueno.

Esto nos ofreció muchas ventajas (antes incluso de que la nube estuviera tan en boga).

Pero conforme la tecnología avanza y las empresas crecen, las necesidades de las mismas también.

Así que, ¿y si de repente una sede pierde la conexión con la sede principal y deja de tener acceso a información importante? Evidentemente es un escenario que muchas empresas no se pueden permitir.

Cuando se trata de una empresa mediana y/o grande, lo más normal es que tenga dos conexiones a Internet, con dos ISP distintos para evitar perder conexión.

Esto nos ayuda a que, si un enlace cae, podamos levantar el segundo a mano, pero esto significa que tenemos que estar constantemente pendientes de la salud del enlace. Aunque para esto ya existen los sistemas de monitorización que nos avisan de todos estos sucesos, y al cual le dedicaré una entrada más adelante.

---

OSPF + IPsec: una gran solución para conexiones redundantes

En esta entrada vamos a poner un escenario en el que dos sedes necesitan estar constantemente conectadas, sin necesidad de intervención humana.

Pero lo primero: ¿qué es OSPF?

Según Cisco:

El protocolo Open Shortest Path First (OSPF), definido en RFC 2328 , es un Internal Gateway Protocol (IGP) que se usa para distribuir la información de enrutamiento dentro de un solo sistema autónomo. El protocolo OSPF se desarrolló debido a la necesidad dentro de la comunidad de Internet de introducir un Internal Gateway Protocol (IGP) no patentado de gran funcionalidad para la familia de protocolos TCP/IP.

El protocolo OSPF está basado en tecnología de estado de link, la cual es una desviación del algoritmo basado en el vector Bellman-Ford usado en los protocolos de ruteo de Internet tradicionales, como el RIP.

Básicamente, OSPF nos añade en la tabla de rutas de nuestro router las redes a las que tiene acceso, sin necesidad de tener que añadirlas manualmente.

¿Cómo funciona? Fácil.

Cada dispositivo que forme parte del área publicará a sus vecinos cuales son las redes que tiene en su tabla de rutas, de tal forma que estos las introducirán en las suyas propias. Así, en caso de tener una red muy grande nos desentenderemos de estar actualizando la tabla de rutas de todos los dispositivos que la compongan.

Pasemos al ejemplo...

Para este ejemplo vamos a utilizar dos fortigate como firewall.

Comenzamos configurando el firewall 1:

config system global
set hostname fortigate1
end

Aquí le decimos el nombre que va a tener el firewall. Ahora procedemos a configurar las interfaces de red. Para este caso vamos a establecer IP's fijas en las interfaces externas.

config system interface
edit port1
set mode static
set ip 172.16.1.1 255.255.255.252
set allowaccess ping
set alias "ISP_1"
next

edit port2
set mode static
set ip 10.1.1.1 255.255.255.252
set allowaccess ping
set alias "ISP_2"
next
end

Ahora vamos a poner IP estática en la interfaz que corresponde con la LAN.

config system interface
edit port3
set mode static
set ip 192.168.10.1 255.255.255.0
set allowaccess ping ssh https http
set alias "LAN - FW1"
next
end

Procedemos a configurar la VPN IPsec hacia el otro extremo:

config vpn ipsec phase1-interface
edit "ISP1-FW2"
set interface port1
set peertype any
set proposal des-sha256
set remote-gw 172.16.1.2
set psksecret Test123
next

edit "ISP2-FW2"
set interface port2
set peertype any
set proposal des-sha256
set remote-gw 10.1.1.2
set psksecret Test123
next
end

config vpn ipsec phase2-interface
edit "ISP1-FW2-ph2"
set phase1name ISP1-FW2
set proposal des-sha256
set auto-negotiate enable
next

edit "ISP2-FW2-ph2"
set phase1name ISP2-FW2
set proposal des-sha256
set auto-negotiate enable
next
end

Ahora tenemos que crear las reglas que permitan el tráfico, pero antes deberemos crear los "Address Object" que te obliga Fortigate para funcionar.

config firewall address
edit "LAN2"
set subnet 10.50.50.0 255.255.255.0
next

edit "LAN1"
set subnet 192.168.10.0 255.255.255.0
next

Ahora sí, creamos las reglas del firewall:

config firewall policy
edit 1
set name "ISP1-in"
set srcintf "ISP1-FW2"
set dstintf "port3"
set srcaddr "LAN2"
set dstaddr "LAN1"
set action accept
set schedule always
set service ALL
next

edit 2
set name "ISP1-out"
set srcintf "port3"
set dstintf "ISP1-FW2"
set srcaddr "LAN1"
set dstaddr "LAN2"
set action accept
set schedule always
set service ALL
next

edit 3
set name "ISP2-in"
set srcintf "ISP2-FW2"
set dstintf "port3"
set srcaddr "LAN2"
set dstaddr "LAN1"
set action accept
set schedule always
set service all
next

edit 4
set name "ISP2-out"
set srcintf "port3"
set dstintf "ISP2-FW2"
set srcaddr "LAN1"
set dstaddr "LAN2"
set action accept
set schedule always
set service all
next

Para poder hacer funcionar OSPF necesitaremos darle una IP a la interfaz virtual del túnel.

config system interface
edit "ISP1-FW2"
set ip 10.10.10.1 255.255.255.255
set remote-ip 10.10.10.2 255.255.255.255
set allowaccess ping
next

edit "ISP2-FW2"
set ip 10.10.11.1 255.255.255.255
set remote-ip 10.10.11.2 255.255.255.255
set allowaccess ping
next
end

Vamos a comprobar que existe la comunicación entre ambos extremos:

Como vemos, la comunicación se ha establecido correctamente.

Ahora vamos a configurar OSPF, en el que vamos a publicar las redes de las que disponemos y a las que pueden acceder los vecinos.

config router ospf
set router-id 1.1.1.1
config area
edit 0.0.0.0
next

config ospf-interface
edit "ISP1-ospf"
set interface "ISP1-FW2"
set cost 10
set network-type point-to-point
next

edit "ISP2-ospf"
set interface "ISP2-FW2"
set cost 20
set networ-type point-to-point
next
end

config network
edit 1
set prefix 10.10.10.0 255.255.255.0
set area 0.0.0.0
next

edit 2
set prefix 10.10.11.0 255.255.255.0
set area 0.0.0.0
next

edit 3
set prefix 192.168.10.0 255.255.255.0
set area 0.0.0.0
next
end

Nota: Como podemos comprobar, se han establecidos costes a las interfaces, para que siempre predomine una sobre la otra. En este caso, predominará ISP1-FW2

Todo lo anterior tendremos que realizarlo también en el forti del otro extremo, adecuando los datos a los que les corresponde.

Desde el forti, vamos a comprobar si se ha establecido con éxito con los siguientes comandos:

diagnose vpn ike gateway list
!
diagnose vpn tunnel list
!
get router info ospf neighbor
!
get router info routing-table ospf
!

Pues parece que hemos conseguido que los túneles estén levantados, así como que los firewall compartan sus rutas con el vecino.

Ahora es momento de comprobar que desde un extremo llegamos al otro.

Si, hemos comprobado que llegamos, pero aún nos queda la prueba de fuego: ¿y si se cae el enlace principal? Tumbamos la interfaz y vemos como, tras 10 segundos, el dispositivo vuelve a ser accesible pero esta vez a través de la otra interfaz.

Aquí sale por la interfaz principal.

Después de tumbar la interfaz principal y de esperar 10 segundos, los firewall vuelven a leer su tabla de rutas y lo manda por la segunda interfaz.

Algunos dirán que 10 segundos pueden ser demasiados, pero mejor tener un delay de 10 segundos que no estar 4 horas sin conexión y que nadie se haya dado cuenta.

Dicho esto, ¡espero que os haya gustado y os sirva para futuros casos!