- Mensajes
- 13,529
Introducción
En este nuevo manual os vengo a presentar OSPF, y cómo aplicarlo para enrutar equipos dinámicamente cuando los unimos por VPN en configuraciones site to site. De OSPF se puede hablar mucho, largo y tendido, pero en este caso voy a hacer justo lo contrario. Al tratarse de un protocolo complejo y con muchísimas opciones de configuración distintas y tecnicismos como para aburrir (AS, ABR, ASBR, Áreas, DR, BDR, etc), nos vamos a centrar en cómo aplicar esto, pero de la manera más simple posible. Este protocolo está pensado para interconectar redes grandes... y quien dice grandes, dice enormes. Vareas áreas, decenas o centenares de routers, y, normalmente, todo interconectado directo entre sí (imaginaos un hospital, una universidad, una empresa enorme, etc). Obviamente, no vamos a meterlo todo en un mismo dominio de broadcast en L2, sino que hacemos "cachitos" y cada router controla su propio dominio, en L3. Para eso se usa OSPF, ahí es donde le sacamos brillo. Es un protocolo de enrutamiento interno (IGP, o Interior Gateway Protocol), al contrario que BGP, que se usa para interconectar los "routers de internet" (EGP, como podéis imaginar, External Gateway Protocol), por decirlo mal y pronto. Este protocolo es homólogo de RIP, y vendría a hacer lo mismo que este, pero usando el estado del enlace para calcular la ruta óptima, en lugar del vector distancia (cantidad de saltos).No obstante, vamos a reducir todo esto a la mínima expresión: nos vamos a imaginar un escenario donde tenemos que interconectar 3 routers entres sí, y simplemente vamos a usar OSPF para no tener que montar las tablas de rutas a mano, sino que se propaguen dichas rutas a todos los equipos automáticamente. Así de simple, sin más historias.
Un poco de culturilla general
¿Qué es OSPF? Sus siglas vienen de Open Shortest Path First que, si lo traducimos literal, viene a significar algo así como por el camino más corto. La idea del protocolo es calcular la ruta más corta para enviar un paquete de A a B. Para ello, construirá unas tablas de enrutamiento, de manera dinámica, para saber cómo enviar los paquetes entre los distintos nodos. Esa información se intercambiará dentro de un sistema autónomo (nuestra red de routers interconectados), sin nuestra interacción, propagándola a todos los nodos. De esta manera, evitamos crear rutas estáticas y solventamos el problema de escalabilidad que ello supone (cada vez que das de alta un router, tener que actualizar las tablas de enrutamiento de todos los anteriores, para que sepan llegar al nuevo). Esto, cuando tienes 2-3 equipos es insignificante, pero cuando tienes 100, es una necesidad imperiosa.OSPF, además, ayuda a eliminar uno de los problemas más grandes que tienen las redes cuando empiezan a crecer: el broadcast. Si bien en una red local el broadcast es algo necesario, e incluso diría que útil, por ejemplo para que funcionen protocolos como el DHCP, DLNA, etc; en redes grandes propagar un mismo dominio de broadcast es un error garrafal. Puedes conseguir que, apagando o perdiendo un router, se te vaya media red al garete. Y, si media red significa el router de tu padre, pues ni tan mal, pero si esto significa que dejas los sistemas de medio hospital sin conexión y con serias dificultades para restablecerla... pues mal.
Si quieres escalar, necesitas olvidarte del L2 (mismo dominio de broadcast, trabajas por direcciones MAC y tablas ARP) y moverte a L3 (routing, trabajas con tablas de rutas y distintos dominios de broadcast, interconectados entre sí).
El protocolo utiliza el algoritmo de Dijkstra (a los informáticos/telecos nos corre un sudor frío por la espalda al oírlo, recordando Álgebra y EDA), para calcular la ruta más corta entre dos nodos, y así elegir el camino más corto para llegar de A a B. Para el ejemplo que nos atañe, esto es irrelevante, porque vamos a trabajar con un grafo de 3 nodos y 6 caminos. Pero si tenéis decenas de equipos y centenares o miles de caminos, esto empieza a cobrar sentido. Usa el protocolo IP 89 y las direcciones multicast 224.0.0.5 y 224.0.0.6 para el intercambio estados y rutas
Al lío, que me enrollo
Vamos a trabajar con el siguiente esquema, sobre el cual iremos metiendo contenido. Un grafo con tres nodos y todos sus nodos interconectados entre sí, por túneles wireguard, previamente establecidos. Si no sabéis cómo hacer este paso, mirad este manual para ver cómo interconectar sedes en un site to site, usando esta VPN.
Vamos a especificar qué tiene cada nodo. Para simplificar la conexión de OSPF, vamos a trabajar con subredes dentro de la red 172.16.0.0/24. Es decir, vamos a hacer "cachitos" ese /24, en pedazos más pequeños de tipos /30, de tal manera que luego podamos sumarizar todas las redes con la subred /24 correspondiente. Si ahora no entendéis esto, no os preocupéis, que veréis como a lo largo del manual lo entendéis. Si no estáis acostumbrados a trocear redes, tirad de un network calculator. Recordad que usamos direcciones /30 porque son dos direcciones útiles para host, más red y broadcast (número de hosts en una subred = 2^n -2). Con 2 bits (los que me sobran de la resta de 32bits del total de una dirección - 30bits para la parte de red) podemos direccionar 2^2-2 = 2 hosts. Es decir, ideal para un túnel con dos extremos.
Para no liarnos, vamos a ir asignando direcciones a los túneles en sentido contrario a las agujas del reloj, empezando por A > B > C > A
Os recomiendo, enfáticamente, dibujar el grafo y asignar las IP's y los puertos que vais a usar en las interfaces wireguard antes de montar nada. Esto os ayudará muchísimo a tener claro el esquema, y sobre todo, a no liarla.
Site A
Primer túnel wireguard con destino B, wg-sts-b
Enlace A-B: subred 172.16.0.0/30
wg-sts-b: 172.16.0.1/30
Código:
/ip address add interface=wg-sts-b address=172.16.0.1/30Site B
Primer túnel wireguard con destino A, wg-sts-a
Enlace B-A: subred 172.16.0.0/30
wg-sts-a: 172.16.0.2/30
Código:
/ip address add interface=wg-sts-a address=172.16.0.2/30Segundo túnel wireguard con destino C, wg-sts-c
Enlace B-C: subred 172.16.0.4/30
wg-sts-c: 172.16.0.5/30
Código:
/ip address add interface=wg-sts-c address=172.16.0.5/30Site C
Primer túnel wireguard con destino B, wg-sts-b
Enlace C-B: subred 172.16.0.4/30
wg-sts-b: 172.16.0.6/30
Código:
/ip address add interface=wg-sts-b address=172.16.0.6/30Segundo túnel wireguard con destino A, wg-sts-a
Enlace C-A: subred 172.16.0.8/30
wg-sts-a: 172.16.0.9/30
Código:
/ip address add interface=wg-sts-a address=172.16.0.9/30Site A
Segundo túnel wireguard con destino C, wg-sts-c
Enlace A-C: subred 172.16.0.8/30
wg-sts-c: 172.16.0.10/30
Código:
/ip address add interface=wg-sts-c address=172.16.0.10/30Si hebéis seguido al detalle la configuración, deberíamos tener el siguiente esquema de routers interconectados entre sí.
Poniendo en marcha OSPF (RouterOS v7.x)
Lo primero que tenéis que comprobar es que los routers aceptan en input el tráfico de las interfaces wireguard site to site. Como explicamos en el manual previo, hay varias maneras de hacerlo, pero aseguraos que esto pasa, o el protocolo no levantará. La manera más sencilla, como os comenté en el manual previo, es considerar las interfaces wg-sts-x como parte de la lista LAN.Para activar el ernutamiento dinámico OSPF en nuestro router, basta con definir la instancia y el área de backbone. En la instancia, definiremos la versión del protocolo (v2 = IPv4, v3 = IPv6; nos ceñimos a la v2 de momento) y el router ID, quizá el punto más importante de OSPF.
A la hora de definir el router ID, tenemos dos maneras de hacerlo:
- Directamente sobre la instancia: asignaremos un router ID en ese mismo menú. Es un identificador, pero con el formato de una IP.
- Vía una interfaz de loopback: crearemos un bridge vacío, le daremos una IP cualquiera /32, no usada (única) y la configuración por defecto usará esa IP como identificador del router. En este caso, la creacción de la instancia sería idéntica, salvo que omitiríamos el parámetro router-id
Yo he optado por la primera opción, porque las IPs de los túneles ya nos pueden hacer de loopback (van a correr sobre interfaces de tipo WireGuard, que siempre está activas), pero en la mayoría de documentación que he leído al respecto, usan una combinación de ambas: definen una IP de loopback sobre un bridge vacío, y, además setean el router ID a esa misma IP (no vaya a ser que le de por coger otra). De cualquiera de las formas es válido, os paso ambas:
Código:
# Definiendo la instancia y el router ID, en el Site A
/routing ospf instance
add name=v2 router-id=0.0.0.1
# Definiendo una interfaz de loopback, con esa misma dirección
/interface bridge
add name=ospf-lo
/ip address
add interface=ospf-lo address=0.0.0.1
/routing ospf instance
add name=v2Una vez hemos optado por cualquiera de las dos opciones, el paso siguiente es definir el área de backbone. El área de backbone es el "core" o núcleo de nuestra red OSPF, de donde va a partir todo, y es siempre el identificador 0.0.0.0. En instalaciones más grandes podéis trabajar con más áreas (mikrotik recomienda que metáis al menos 50 equipos por área, para que no os volváis locos troceando). Todas las áreas han de estar en comunicación, directa o indirectamente, con el área backbone.
El backbone, se activaría de la siguiente manera, haciendo referencia a la instancia previamente creada. Siguiendo con el ejemplo anterior, en Site A tendríamos:
Código:
/routing ospf area
add instance=v2 name=backboneComo los equipos que vamos a configurar van a pertenecer todos a una única área, la de backbone, he decidido etiquetarlos con los ID's 0.0.0.1 (área 0, id 1) para el Site A, 0.0.0.2 (área 0, id 2) para el Site B y 0.0.0.3 (área 0, id 3) para Site C.
Si repetimos los pasos anteriores, en Site B y Site C tendríamos:
Código:
# Definiendo la instancia y el router ID, en el Site B
/routing ospf instance
add name=v2 router-id=0.0.0.2
# ....
# Definiendo el area en Site B
/routing ospf area
add instance=v2 name=backbone
Código:
# Definiendo la instancia y el router ID, en el Site C
/routing ospf instance
add name=v2 router-id=0.0.0.3
# ....
# Definiendo el area en Site C
/routing ospf area
add instance=v2 name=backboneSi tenéis la configuración por defecto de la V7, es posible que ya tengáis la instancia de OSPF creada, con el nombre "default-v2", y el área de backbone "backbone-v2" deshabilitada, apuntando a ella. Podéis usar perfectamente dicha config por defecto, y simplemente definir el bridge con la dirección de loopback. Veréis el ID del router acaba apuntando a esa dirección de loopback (lo podéis ver en Routing -> Router ID). Hecho esto, simplemente habilitar el área y lo tendréis corriendo.
Hecho esto, tenemos casi casi todo hecho. Si navegáis a la pestaña LSA (Link Status Advertisements), veréis vuestro router ID en cada uno de los equipos, con los flags "DS" delante de la entrada (dynamic, self-originated). Esto quiere decir que OSPF ya está corriendo en ese equipo, y que está listo para intercambiar información. En esa tabla irán apareciendo otros ID's, de los distintos routers que participan en el intercambio de información, una vez "hablen" OSPF entre ellos.
Hecho esto, sólo nos queda definirle a nuestro router sobre qué subred queremos que monte OSPF. Si habéis ido siguiendo el manual, en este punto ya podéis intuir cuál es la subred sobre la que se va a intercambiar información: la subred de túneles WireGuard.
Para hacer esto, tenemos dos maneras de hacerlo: o anunciamos en cada router la pareja de subredes de los enlaces que los unen a sus compatriotas, o sumarizamos las redes en una más grande, que los cubra todos (ahora entenderéis por qué usé subredes /30 dentro del mismo segmento). Os pongo ambas opciones, aunque os recomiendo la segunda, puesto que la instrucción es idéntica en todos los routers (de la primera manera, cada equipo tendría que anunciar las dos subredes /30 que usa). Dicho anuncio lo haremos a partir de plantilas, y el tipo de conexión de ellas es PTP (peer-to-peer, o punto a punto, que es la que se ajusta a nuestro esquema).
Código:
# Site A - Anunciamos las subredes por separado, 172.16.0.0/30 (conexión con B) y 172.16.0.8/30 (conexión con C)
/routing ospf interface-template
add area=backbone networks=172.16.0.0/30 type=ptp
add area=backbone networks=172.16.0.8/30 type=ptpO, más sencillo aún, sumarizamos todas las subredes en una red más grande /24, y así la instrucción nos vale para los sites A, B y C, la misma instrucción, para todos.
Código:
# Site A / B / C
/routing ospf interface-template
add area=backbone networks=172.16.0.0/24 type=ptpSi lo hemos hecho bien, OSPF habrá empezado a intercambiar información en dicho segmento de red, y habrá empezado a encontrar "vecinos". Podéis consultar los vecinos de un router en Routing -> OSPF -> Neighbors. Si lo hemos hecho bien, el Site A tendrá como vecino a B (172.16.0.2) y a C (172.16.0.9), con estado "Full". Además, en la pestaña de LSA, habrán aparecido los IDs de los otros equipos que estamos interconectando. De manera parecida, tendréis similitudes en los otros dos equipos, encontrando como vecinos, en cada uno de ellos, a los otros dos.
OSPF - Intercambiando información sobre las rutas
Vale, hasta aquí todo bien, pero diréis... ¿y todo esto... para qué? Si desde A yo llego a B y a C, y desde B yo llego a A y a C, y desde C yo llego a A y a B, vía rutas conectadas, al ser de tipo /30. ¿para qué narices quiero esto? Pues aquí es donde empezamos a sacarle partido el tema. Imaginemos el siguiente supuesto:Site A
Interface LAN: 192.168.20.1/24
Interface VPN Road Warrior: 192.168.19.1/24
Site B
Interface LAN: 192.168.21.1/24
Site C
Interface LAN: 192.168.22.1/24
Interface INVITADOS: 192.168.32.1/24
Digamos que yo quiero llegar la red principal de A (o desde mi VPN) a cualquiera de los segmentos de B o C. ¿cómo lo hacemos? Pues simplemente, le decimos a OSPF que esos equipos tienen esas rutas, y él se encargará de montar el routeo dinámico entre equipos. Una vez publicadas las subredes correspondientes a cada equipo, el protocolo empezará a montar una tabla de rutas común y compartida entre los tres routers, de manera que todos puedan llegar a los segmentos que cada uno anuncia, de manera automática y usando las direcciones de los túneles que hemos creado previamente como gateways.
Comenzamos anunciando las subredes en el Site A. El tipo de anuncio que vamos a hacer es el de una red de broadcast, pero en modo pasivo (esto es muy muy muy importante, si no os queréis volver locos cazando brujas con este protocolo). Pasivo significa que esa subred no pertenece a la red OSPF, donde corre el protocolo, sino que está accesible, se anuncia, vía dicha red. Es decir, se puede llegar a ella por los túneles, pero como tal, la subred/subredes LAN NUNCA participarán en el intercambio de información OSPF.
Site A
Código:
# Anunciamos las subredes accesibles en A (LAN y VPN)
/routing ospf interface-template
add area=backbone networks=192.168.19.0/24,192.168.20.0/24 passiveSite B
Código:
# Anunciamos la subred LAN de B
/routing ospf interface-template
add area=backbone networks=192.168.21.0/24 passiveSite C
Código:
# Anunciamos la subredes LAN e INVITADOS de C
/routing ospf interface-template
add area=backbone networks=192.168.22.0/24,192.168.32.0/24 passiveSi lo hemos hecho bien, en la tabla de rutas de los distintos equipos (IP -> Routes), habrán empezado a aparecer varias entradas dinámicas con distancia 110 y etiqueta DAo (rutas OSPF), que le indicarán a cada equipo cómo llegar a las subredes del vecino. Con esto, nos habremos ahorrado meter, como poco, dos ruta estáticas por cada equipo y segmento LAN.
Las tablas de rutas OSPF de los equipos deberían ser algo así
| Site A |
|---|
| Flag | Dst. Address | Gateway | Distance |
|---|---|---|---|
DAo+ | 172.16.0.4/30 | 172.16.0.2%wg-sts-b | 110 |
DAo+ | 172.16.0.4/30 | 172.16.0.9%wg-sts-c | 110 |
DAo | 192.168.21.0/24 | 172.16.0.2%wg-sts-b | 110 |
DAo | 192.168.22.0/24 | 172.16.0.9%wg-sts-c | 110 |
DAo | 192.168.32.0/24 | 172.16.0.9%wg-sts-c | 110 |
| Site B |
|---|
| Flag | Dst. Address | Gateway | Distance |
|---|---|---|---|
DAo+ | 172.16.0.8/30 | 172.16.0.1%wg-sts-a | 110 |
DAo+ | 172.16.0.8/30 | 172.16.0.6%wg-sts-c | 110 |
DAo | 192.168.19.0/24 | 172.16.0.1%wg-sts-a | 110 |
DAo | 192.168.20.0/24 | 172.16.0.1%wg-sts-a | 110 |
DAo | 192.168.22.0/24 | 172.16.0.6%wg-sts-c | 110 |
DAo | 192.168.32.0/24 | 172.16.0.6%wg-sts-c | 110 |
| Site C |
|---|
| Flag | Dst. Address | Gateway | Distance |
|---|---|---|---|
DAo+ | 172.16.0.0/30 | 172.16.0.5%wg-sts-b | 110 |
DAo+ | 172.16.0.0/30 | 172.16.0.10%wg-sts-a | 110 |
DAo | 192.168.19.0/24 | 172.16.0.10%wg-sts-a | 110 |
DAo | 192.168.20.0/24 | 172.16.0.10%wg-sts-a | 110 |
DAo | 192.168.21.0/24 | 172.16.0.5%wg-sts-b | 110 |
Las rutas de tipo DAo nos indican cómo llegar a los distintos segmentos LAN, mientras que las DAo+ son rutas balanceadas de tipo EMCP, indicando que hay dos o más maneras de llegar a ese segmento. Tal y como tenemos conectado todo, tenemos incluso algo de redundancia, porque si le cayera uno de los enlace entre cualquier par de routers, los tres equipos seguirían conectados entre sí, y todos serían alcanzables, desapareciendo en ese momento las rutas DAo+.
Y, con esto y un bizcocho, tendríamos tres sedes interconectadas entre sí por túneles de tipo Wireguard e intercambiando información de rutas dinámicamente. Siguiendo con el dibujito que hemos usado para ilustrar esto, esta sería nuestra foto finish
Bonus track: rutas flotantes
Imaginemos ahora que la comunicación entre A y B es indispensable, y que tenemos que asegurar que, al menos los dos segmentos LAN de estos dos equipos (192.168.20.0/24 - 192.168.21.0/24) están siempre interconectados entre sí, incluso cuando se caiga OSPF. No obstante, después de la currada que nos hemos pegado con OSPF, queremos darle prioridad al protocolo de enrutamiento dinámico. La manera de hacer esto es metiendo, obviamente, rutas estáticas en la ecuación. Pero, como no queremos que las rutas estáticas tomen prioridad, sino que queremos que sea OSPF quién maneje el tinglado, vamos a hacer que "floten" asignándoles una distancia mayor que las que otorga el propio protocolo, por ejemplo, 111. De esta manera, sólo entrarán en juego si el protocolo se cae o deja de funcionar por cualquier motivo. Sin más, damos de alta dichas rutas
Site A
Código:
/ip route
add dst-address=192.168.21.0/24 gateway=172.16.0.2 distance=111Site B
Código:
/ip route
add dst-address=192.168.20.0/24 gateway=172.16.0.1 distance=111Estas rutas aparecerán en la tabla de rutas con el flag "S" de estáticas, pero no aparecerán como "SA" (Static, Active) hasta que no se caigan las rutas OSPF. Si queremos probar, simplemente podemos tirar el protocolo en uno de los dos nodos, y veréis como empiezan a funcionar.
Y creo que no me dejo nada. Como veis, incluso intentando omitir prácticamente todas las opciones de configuración que otorga el protocolo, aun así ha quedado un manual bastante extenso. La idea es que, prácticamente sin conocimiento previo sobre enrutamiento dinámico, seáis capaces de sacarle partido a OSPF, y aplicarlo en un setup de lo más corriente. Sin más, espero que os guste.
Saludos!
