MANUAL: Mikrotik, OSPF sobre túneles WireGuard site to site

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.


grafo_ospf.jpg


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/30


Site 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/30

Segundo 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/30


Site 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/30

Segundo 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/30


Site 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/30


Si hebéis seguido al detalle la configuración, deberíamos tener el siguiente esquema de routers interconectados entre sí.


grafo_ospf-2.jpg


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=v2

Una 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=backbone

Como 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=backbone

Si 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=ptp

O, 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=ptp

Si 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 passive

Site B
Código:
# Anunciamos la subred LAN de B
/routing ospf interface-template
add area=backbone networks=192.168.21.0/24 passive

Site 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 passive

Si 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
FlagDst. AddressGatewayDistance
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
FlagDst. AddressGatewayDistance
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
FlagDst. AddressGatewayDistance
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


grafo_ospf-3.jpg



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=111

Site B
Código:
/ip route
add dst-address=192.168.20.0/24 gateway=172.16.0.1 distance=111

Estas 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!
 
Gracias @pokoyo
Vaya trabajo que te has metido.
Para no perder la costumbre, cada vez más subiendo el nivel.
A leerlo y a disfrutarlo, ya tenemos para entretenernos un buen rato.
Saludos.
 
Gracias @pokoyo
Vaya trabajo que te has metido.
Para no perder la costumbre, cada vez más subiendo el nivel.
A leerlo y a disfrutarlo, ya tenemos para entretenernos un buen rato.
Saludos.
Ha venido Papá Noel con otro regalito, en forma de manual, jeje. He intentado hacerlo lo más sencillo y escueto posible, porque llevo semanas documentándome y trasteando con el protocolo… y tela marinera lo que se puede complicar.
Creo que he conseguido al menos dar pinceladas de lo que hace, aunque haya omitido en gran parte el cómo lo hace, con un ejemplo práctico que más de uno tenemos y/o podemos aprovechar. Porque, de poco o nada me valía lo contrario, contaros la teoría, si luego no le sacábamos aplicación en nuestras redes domésticas.

Saludos!
 
¡Impresionante curro te has pegado @pokoyo!

Enrutamiento dinámico y protección por redundancia... lo más!
Estas redes se parecen cada vez más a Internet.

Gracias por compartir!
S@lu2.
 
¡Impresionante curro te has pegado @pokoyo!

Enrutamiento dinámico y protección por redundancia... lo más!
Estas redes se parecen cada vez más a Internet.

Gracias por compartir!
S@lu2.
De nada majo, que lo disfrutéis! Estos cacharros parecen casi infinitos a la hora de exprimirlos y sacarles partido.

Y ojo, que esto corre hasta en el chisme más pequeño de la marca. Mientras la tablas de rutas no sean gigantescas, lo mueve sin problemas.

Saludos.
 
Otra Masterclass del compi @pokoyo !!

Voy a echarle un rato de lectura a ver si aclaro conceptos, y le sacamos partido a OSPF sobre nuestros setup's.

Una vez más, mil gracias por tus aportes


Saludos!
 
Espectacular @pokoyo!!

Conocía un poco la teoría pero sin entenderlo muy bien, viéndolo con un ejemplo práctico y sencillo mucho mejor.

Muchas gracias por tu trabajo
 
Buenas tardes,

Bueno, al final me he animado con esta asignatura pendiente que tenía sobre el OSPF, he aprovechado que tengo el mini-router mAP en un tercer site y me he puesto manos a la obra con este magnífico tuto de @pokoyo.

Sobre el mismo gráfico del tuto:

1647881072026.png


Parto que Site A y Site C son los dos sites que tengo compartiendo subredes y que necesitan si o si estar interconectados por temas de trabajo, compartición de ficheros, iptv, etc. Y por otro lado Site B sería el nuevo router mAP que utilizaría para cerrar el anillo y poder tener redundancia en caso de caída del túnel wireguard entre A-C.

Lo he configurado tal cual viene en el tuto, he creado túneles WG nuevos en cada site (wg-sts-a, wg-sts-b y wg-sts-c) sólo para OSPF y he dejado los túneles anteriores operativos para que con mucho cuidado no perder conectividad (tengo conexiones rw por si acaso).

La verdad es que me ha sorprendido como en la tabla de enrutamiento cambian los caminos cuando tiro algún enlace. En este caso tengo deshabilitado el túnel WG que tengo fijo entre A y C y el túnel wg-sts-c (ospf) que sale de A para forzar que vaya de A a C a través de B.

Bien, los resultados a nivel de conectividad IP son buenos, el ping OK desde A hasta C y responde sin problema, la pelea la tengo con la gestión de RouterOS de C (ni por ssh, ni winbox). Tengo permitido en el chain de imput el acceso de 172.16.0.0/24 (aunque yo estoy trabajando desde 192.168.88.0/24) y en IP->Services también el mismo rango. Los túneles creados para OSPF, tengo los peers con "Allowed Address" a 0.0.0.0/0.

Otro tema que no paro de darle vueltas es como adaptaría los túneles EoIP que tengo actualmente funcionando encima de los túneles WG fijos, porque en OSPF dependiendo del lado que esté funcionando tendrá una IP u otra, por ejemplo en el grafo adjunto, el router de C puedes acceder a través de la 172.16.0.9 o bien por la 172.16.0.6 dependiendo de la ruta establecida.

¿Algún consejo? gracias.
 
En este tipo de setup lo único que tienes que diferenciar muy muy bien es cuál es la red punto a punto que interconecta los equipos sobre la que se propaga OSPF y cual la red LAN de cada site, las cuáles participan en OSPF

No es necesario que montes una segundo túnel para OSPF, pero sí te conviene adaptarlo para que luego puedas sumarizar las redes y te quede un setup más limpio. Si me enseñas cómo tenías unidos A y B, te digo cómo añadir C a la ecuación, respetando lo que ya tienes.

Por otro lado te recomiendo no propagar el segmento LAN de ninguno de los extermos al otro lado, a menos que esa extrictamente necesario. Cada site tendría una LAN distinta y, en algún caso puntual, puede que un equipo de un site necesite estar por EoIP como si estuviera en el otro lado, pero eso es un caso residual, no la norma. Siempre que puedas, intenta trabajar con segmentos de red distintos, tal que independices el broadcast, y luego anuncia las subredes LAN que necesites en OSPF, para que las rutas dinámicas se instalen en los equipos involucrados y sepan cómo se llega a ellas.

Saludos!
 
En este tipo de setup lo único que tienes que diferenciar muy muy bien es cuál es la red punto a punto que interconecta los equipos sobre la que se propaga OSPF y cual la red LAN de cada site, las cuáles participan en OSPF

No es necesario que montes una segundo túnel para OSPF, pero sí te conviene adaptarlo para que luego puedas sumarizar las redes y te quede un setup más limpio. Si me enseñas cómo tenías unidos A y B, te digo cómo añadir C a la ecuación, respetando lo que ya tienes.

Por otro lado te recomiendo no propagar el segmento LAN de ninguno de los extermos al otro lado, a menos que esa extrictamente necesario. Cada site tendría una LAN distinta y, en algún caso puntual, puede que un equipo de un site necesite estar por EoIP como si estuviera en el otro lado, pero eso es un caso residual, no la norma. Siempre que puedas, intenta trabajar con segmentos de red distintos, tal que independices el broadcast, y luego anuncia las subredes LAN que necesites en OSPF, para que las rutas dinámicas se instalen en los equipos involucrados y sepan cómo se llega a ellas.

Saludos!

Te enseño como tenía unido A (Despacho) con C (Apartamento) y como tengo B (mAP)

Bash:
# Despacho

/interface wireguard
add listen-port=57588 mtu=1420 name=wireguard
add listen-port=54321 mtu=1420 name=wireguard-sts-iptv
add listen-port=57591 mtu=1420 name=wireguard-sts-to-apto

/interface eoip
add local-address=172.17.0.2 mtu=1500 name=\
    eoip-iptv remote-address=172.17.0.1 tunnel-id=1
add local-address=192.168.88.1 mtu=1500 name=\
    eoip-iptv2 remote-address=192.168.88.2 tunnel-id=2
add local-address=172.168.0.1 mtu=1500 name=\
    eoip-to-apto remote-address=172.168.0.2 tunnel-id=0

/interface wireguard peers
add allowed-address=10.10.0.2/32 interface=wireguard
add allowed-address=10.10.0.3/32 interface=wireguard
add allowed-address=172.168.0.2/32,192.168.2.0/24,192.168.100.0/24 \
    endpoint-address=apto.dominio.es endpoint-port=57591 interface=\
    wireguard-sts-to-apto
add allowed-address=172.17.0.1/32,192.168.1.0/24 endpoint-address=\
    map.dominio.es endpoint-port=54321 interface=wireguard-sts-iptv

/ip address
add address=192.168.88.1/24 interface=bridge network=192.168.88.0
add address=10.10.0.1/24 interface=wireguard network=10.10.0.0
add address=172.168.0.1/30 interface=wireguard-sts-to-apto network=\
    172.168.0.0
add address=172.17.0.2/30 interface=wireguard-sts-iptv network=172.17.0.0
add address=192.168.66.1/24 interface=bridge-guests network=192.168.66.0

/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard" dst-port=57588 \
    protocol=udp
add action=accept chain=input comment="vpn: allow wireguard-sts-eoip" \
    dst-port=57591 protocol=udp
add action=accept chain=input comment="vpn: allow wireguard-sts-iptv" \
    dst-port=54321 protocol=udp
add action=accept chain=input comment="iptv: allow gre for eoip" \
    in-interface=wireguard-sts-iptv protocol=gre
add action=accept chain=input comment="allow access to router HQ" \
    src-address=192.168.2.0/24

/ip route
add disabled=no distance=1 dst-address=192.168.2.0/24 gateway=172.168.0.2 \
add disabled=no distance=1 dst-address=192.168.100.0/24 gateway=172.168.0.2 \
add disabled=no dst-address=192.168.1.0/24 gateway=172.17.0.1

/ip service
set ssh address="192.168.88.0/24,192.168.2.0/24"
set winbox address="192.168.88.0/24,192.168.2.0/24" port=32420


# Apartamento

/interface eoip
add local-address=172.17.10.2 mtu=1500 name=eoip-iptv-to-paco \
    remote-address=172.17.10.1 tunnel-id=10
add local-address=172.168.0.2 mtu=1500 name=eoip-to-despacho \
    remote-address=172.168.0.1 tunnel-id=0

/interface wireguard
add listen-port=57587 mtu=1420 name=wireguard
add listen-port=57591 mtu=1420 name=wireguard-sts-eoip
add listen-port=54322 mtu=1420 name=wireguard-sts-iptv

/interface wireguard peers
add allowed-address=10.20.0.2/32 interface=wireguard
add allowed-address=10.20.0.3/32 interface=wireguard
add allowed-address=10.20.0.4/24 interface=wireguard
add allowed-address=172.168.0.1/32,192.168.88.0/24 \
    endpoint-address=despacho.dominio.es endpoint-port=57591
    interface=wireguard-sts-eoip
add allowed-address=172.17.10.1/32,192.168.1.0/24 endpoint-address=\
    map.dominio.es endpoint-port=54322 interface=wireguard-sts-iptv

/ip address
add address=192.168.2.10/24 interface=bridge-local network=192.168.2.0
add address=192.168.100.2/24 interface=ether1-wan network=192.168.100.0
add address=192.168.3.10/24 interface=vlan100 network=192.168.3.0
add address=10.20.0.1/24 interface=wireguard network=10.20.0.0
add address=172.168.0.2/30 interface=wireguard-sts-eoip network=172.168.0.0
add address=172.17.10.2/30 interface=wireguard-sts-iptv network=172.17.10.0

/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard RW" dst-port=\
    57587 protocol=udp
add action=accept chain=input comment=\
    "vpn: allow wireguard-sts-eoip to Despacho" dst-port=57591 protocol=udp
add action=accept chain=input comment="vpn: allow wireguard mAP" dst-port=\
    54322 protocol=udp
add action=accept chain=input comment="iptv: allow gre for eoip" \
    in-interface=wireguard-sts-iptv protocol=gre
add action=accept chain=input comment="allow Winbox access from LAN Despacho" \
    src-address=192.168.88.0/24

/ip service
set ssh address="192.168.2.0/24,192.168.88.0/24"
set winbox address="192.168.2.0/24,192.168.88.0/24" port=32420


# mAP

/interface eoip
add local-address=172.17.0.1 mtu=1500 name=\
    eoip-iptv remote-address=172.17.0.2 tunnel-id=1
add local-address=172.17.10.1 mtu=1500 name=\
    eoip-iptv-to-apto remote-address=172.17.10.2 tunnel-id=10

/interface wireguard
add listen-port=54323 mtu=1420 name=wireguard-rw
add listen-port=54321 mtu=1420 name=wireguard-sts-iptv
add listen-port=54322 mtu=1420 name=wireguard-sts-iptv-apto

/interface wireguard peers
add allowed-address=172.17.0.2/32,192.168.88.0/24 \
    endpoint-address=despacho.dominio.es endpoint-port=54321 interface=wireguard-sts-iptv
add allowed-address=172.17.10.2/32,192.168.2.0/24 \
    endpoint-address=apto.dominio.es endpoint-port=54322 interface=\
    wireguard-sts-iptv-apto
add allowed-address=172.17.20.2/32 interface=wireguard-rw \

/ip address
add address=172.17.0.1/30 interface=wireguard-sts-iptv network=172.17.0.0
add address=172.17.10.1/30 interface=wireguard-sts-iptv-apto network=\
    172.17.10.0
add address=172.17.20.1/30 interface=wireguard-rw network=172.17.20.0

/ip route
add dst-address=192.168.88.0/24 gateway=172.17.0.2
add disabled=no dst-address=192.168.2.0/24 gateway=172.17.10.2

Y así lo he configurado esta tarde con OSPF

Bash:
# Despacho

/interface wireguard
add listen-port=13231 mtu=1420 name=wg-sts-b
add listen-port=13232 mtu=1420 name=wg-sts-c
add listen-port=57588 mtu=1420 name=wireguard
add listen-port=54321 mtu=1420 name=wireguard-sts-iptv
add listen-port=57591 mtu=1420 name=wireguard-sts-to-apto

/interface eoip
add local-address=172.17.0.2 mtu=1500 name=\
    eoip-iptv remote-address=172.17.0.1 tunnel-id=1
add local-address=192.168.88.1 mtu=1500 name=\
    eoip-iptv2 remote-address=192.168.88.2 tunnel-id=2
add local-address=172.168.0.1 mtu=1500 name=\
    eoip-to-apto remote-address=172.168.0.2 tunnel-id=0

/interface wireguard peers
add allowed-address=10.10.0.2/32 interface=wireguard
add allowed-address=10.10.0.3/32 interface=wireguard
add allowed-address=172.168.0.2/32,192.168.2.0/24,192.168.100.0/24 \
    endpoint-address=apto.dominio.es endpoint-port=57591 interface=\
    wireguard-sts-to-apto
add allowed-address=172.17.0.1/32,192.168.1.0/24 endpoint-address=map.dominio.es \
    endpoint-port=54321 interface=wireguard-sts-iptv
add allowed-address=0.0.0.0/0 endpoint-address=map.dominio.es endpoint-port=\
    13231 interface=wg-sts-b
add allowed-address=0.0.0.0/0 endpoint-address=apto.dominio.es endpoint-port=\
    13232 interface=wg-sts-c

/routing ospf instance
add name=v2 router-id=0.0.0.1

/routing ospf area
add instance=v2 name=backbone

/routing ospf interface-template
add area=backbone networks=172.16.0.0/24 type=ptp
add area=backbone networks=192.168.88.0/24 passive

/ip address
add address=192.168.88.1/24 interface=bridge network=192.168.88.0
add address=10.10.0.1/24 interface=wireguard network=10.10.0.0
add address=172.168.0.1/30 interface=wireguard-sts-to-apto network=\
    172.168.0.0
add address=172.17.0.2/30 interface=wireguard-sts-iptv network=172.17.0.0
add address=172.16.0.1/30 interface=wg-sts-b network=172.16.0.0
add address=172.16.0.10/30 interface=wg-sts-c network=172.16.0.8

/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard" dst-port=57588 \
    protocol=udp
add action=accept chain=input comment="vpn: allow wireguard-sts-eoip" \
    dst-port=57591 protocol=udp
add action=accept chain=input comment="vpn: allow wireguard-sts-iptv" \
    dst-port=54321 protocol=udp
add action=accept chain=input comment="vpn: allow wg-sts-b" dst-port=13231 \
    protocol=udp
add action=accept chain=input comment="vpn: allow wg-sts-c" dst-port=13232 \
    protocol=udp
add action=accept chain=input comment="iptv: allow gre for eoip" \
    in-interface=wireguard-sts-iptv protocol=gre
add action=accept chain=input comment="allow access to router HQ" \
    src-address=192.168.2.0/24
add action=accept chain=input comment="allow access to router from OSPF" \
    src-address=172.16.0.0/24

/ip route
add disabled=no distance=1 dst-address=192.168.2.0/24 gateway=172.168.0.2
add disabled=no distance=1 dst-address=192.168.100.0/24 gateway=172.168.0.2
add disabled=no distance=1 dst-address=10.20.0.0/24 gateway=172.168.0.2
add disabled=no distance=111 dst-address=192.168.1.0/24 gateway=172.17.0.1

/ip service
set ssh address="192.168.88.0/24,192.168.2.0/24,172.16.0.0/24"
set winbox address="192.168.88.0/24,192.168.2.0/24,172.16.0.0/24" port=32420



# Apartamento

/interface eoip
add local-address=172.17.10.2 mtu=1500 name=\
    eoip-iptv-to-paco remote-address=172.17.10.1 tunnel-id=10
add local-address=172.168.0.2 mtu=1500 name=\
    eoip-to-despacho remote-address=172.168.0.1 tunnel-id=0

/interface wireguard
add listen-port=13232 mtu=1420 name=wg-sts-a
add listen-port=13233 mtu=1420 name=wg-sts-b
add listen-port=57587 mtu=1420 name=wireguard
add listen-port=57591 mtu=1420 name=wireguard-sts-eoip
add listen-port=54322 mtu=1420 name=wireguard-sts-iptv

/interface wireguard peers
add allowed-address=10.20.0.2/32 interface=wireguard
add allowed-address=10.20.0.3/32 interface=wireguard
add allowed-address=172.168.0.1/32,192.168.88.0/24 \
    endpoint-address=despacho.dominio.es endpoint-port=57591 interface=\
    wireguard-sts-eoip
add allowed-address=10.20.0.4/24 interface=wireguard
add allowed-address=172.17.10.1/32,192.168.1.0/24 endpoint-address=\
    map.dominio.es endpoint-port=54322 interface=wireguard-sts-iptv
add allowed-address=0.0.0.0/0 endpoint-address=router.dominio.es endpoint-port=\
    13232 interface=wg-sts-a
add allowed-address=0.0.0.0/0 endpoint-address=map.dominio.es endpoint-port=\
    13233 interface=wg-sts-b

/routing ospf instance
add name=v2 router-id=0.0.0.3

/routing ospf area
add instance=v2 name=backbone

/routing ospf interface-template
add area=backbone networks=172.16.0.0/24 type=ptp
add area=backbone networks=192.168.2.0/24,192.168.100.0/24 passive

/ip address
add address=192.168.2.10/24 interface=bridge-local network=192.168.2.0
add address=192.168.100.2/24 interface=ether1-wan network=192.168.100.0
add address=192.168.3.10/24 interface=vlan100 network=192.168.3.0
add address=10.20.0.1/24 interface=wireguard network=10.20.0.0
add address=172.168.0.2/30 interface=wireguard-sts-eoip network=172.168.0.0
add address=172.17.10.2/30 interface=wireguard-sts-iptv network=172.17.10.0
add address=172.16.0.6/30 interface=wg-sts-b network=172.16.0.4
add address=172.16.0.9/30 interface=wg-sts-a network=172.16.0.8

/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard RW" dst-port=\
    57587 protocol=udp
add action=accept chain=input comment=\
    "vpn: allow wireguard-sts-eoip to Despacho" dst-port=57591 protocol=udp
add action=accept chain=input comment="vpn: allow wireguard mAP" dst-port=\
    54322 protocol=udp
add action=accept chain=input comment="vpn: allow wg-sts-a" dst-port=13232 \
    protocol=udp
add action=accept chain=input comment="vpn: allow wg-sts-b" dst-port=13233 \
    protocol=udp
add action=accept chain=input comment="iptv: allow gre for eoip" \
    in-interface=wireguard-sts-iptv protocol=gre
add action=accept chain=input comment="allow Winbox access from LAN Despacho" \
    src-address=192.168.88.0/24
add action=accept chain=input comment="allow Winbox access from OSPF" \
    src-address=172.16.0.0/24

/ip service
set ssh address="192.168.2.0/24,192.168.88.0/24,172.16.0.0/24"
set winbox address="192.168.2.0/24,192.168.88.0/24,172.16.0.0/24" port=32420


# mAP

/interface wireguard
add listen-port=13231 mtu=1420 name=wg-sts-a
add listen-port=13233 mtu=1420 name=wg-sts-c
add listen-port=54323 mtu=1420 name=wireguard-rw
add listen-port=54321 mtu=1420 name=wireguard-sts-iptv
add listen-port=54322 mtu=1420 name=wireguard-sts-iptv-apto

/interface eoip
add local-address=172.17.0.1 mtu=1500 name=\
    eoip-iptv remote-address=172.17.0.2 tunnel-id=1
add local-address=172.17.10.1 mtu=1500 name=\
    eoip-iptv-to-apto remote-address=172.17.10.2 tunnel-id=10

/routing ospf instance
add name=v2 router-id=0.0.0.2

/routing ospf area
add instance=v2 name=backbone

/interface wireguard peers
add allowed-address=172.17.0.2/32,192.168.88.0/24,10.10.0.0/24 \
    endpoint-address=despacho.dominio.es endpoint-port=54321 interface=\
    wireguard-sts-iptv
add allowed-address=172.17.10.2/32,192.168.2.0/24,10.20.0.0/24 \
    endpoint-address=apto.dominio.es endpoint-port=54322 interface=\
    wireguard-sts-iptv-apto
add allowed-address=172.17.20.2/32 interface=wireguard-rw
add allowed-address=0.0.0.0/0 endpoint-address=despacho.dominio.es endpoint-port=\
    13231 interface=wg-sts-a
add allowed-address=0.0.0.0/0 endpoint-address=apto.dominio.es endpoint-port=\
    13233 interface=wg-sts-c

/ip address
add address=192.168.79.1/24 interface=bridge-local network=192.168.79.0
add address=172.17.0.1/30 interface=wireguard-sts-iptv network=172.17.0.0
add address=172.17.10.1/30 interface=wireguard-sts-iptv-apto network=\
    172.17.10.0
add address=172.17.20.1/30 interface=wireguard-rw network=172.17.20.0
add address=172.16.0.2/30 interface=wg-sts-a network=172.16.0.0
add address=172.16.0.5/30 interface=wg-sts-c network=172.16.0.4

/ip route
add dst-address=192.168.88.0/24 gateway=172.17.0.2
add dst-address="" gateway=172.17.10.2
add disabled=no dst-address=192.168.2.0/24 gateway=172.17.10.2
add disabled=no dst-address=10.10.0.0/24 gateway=172.17.0.2
add disabled=no distance=1 dst-address=10.20.0.0/24 gateway=172.17.10.2

/routing ospf interface-template
add area=backbone networks=172.16.0.0/24 type=ptp
add area=backbone networks=192.168.1.0/24 passive

Cómo lo ves?, gracias.

S@lu2.
 
Vale, creo que te sobra mucha config. Si el tema del IPTV se va a mover entre los mismos sitios que ya van a estar interconectados por los túneles que has creado para OSPF, reusa esos mismos túnel para pasar la IPTV, como las direcciones de los extremos del EoIP. Lo único que quedaría aparte, por limpieza, sería el tema del servidor para RW. Es decir, si todo se comparte entre esas 3 sedes, en cada una habría un LAN y dos servidores wireguard para unir con los otros dos sites. Intenta mantener, para la unión de las sedes, una misma subred. En mi ejemplo yo usaba la 172.16.0.0/24, y la hice "cachitos" /30 para unir las sedes (dos IP's para hosts + red y broadcast), de tal manera que pudiera "sumarizar" todas esas redes en ese /24, y que la config punto a punto de OSPF quedase mucho más sencilla (en todas las sedes una única regla, en lugar de tener que meter una regla por cada túnel). Ese mismo túnel por donde se intercambia la información OSPF, se puede usar para chutar el túnel EoIP o cualquier otra cosa. Yo, por simpleza, tengo metidas las interfaces de los site to site en la lista LAN, tal que no necesito ninguna regla adicional en input para que el tráfico de los mensajes OSPF vuelen entre sedes. Eso, unido a permitir todo el tráfico (0.0.0.0/0) desde el allowed-address, hace que todo se pueda intercambiar entre esos tres sitios, como si de una LAN enorme se tratase, solo que con el broadcast limitado para cada extremo (salvo por el de la IPTV que se manda por motivos obvios)

De hecho, si me aprietas, con un único servidor de road-warrior sería suficiente para que llegases a los tres equipos, cuando estos se interconectan entre sí. Aunque, por seguridad, no está demás que lo tengas en los tres sites. Para conseguir esto, lo único que tienes que hacer es anunciar la subred de la VPN de tipo road-warrior como si de una LAN se tratase, y las rutas correspondientes se chutarán a los otros dos extremos.

Luego, anunciarías las 3 redes LAN (cada una desde el equipo que la posee) y las rutas se propagarían entre los tres sitios. Obviamente tendrías que borrar las rutas estáticas que tienes, porque sino no serviría de nada lo que estamos haciendo (las rutas OSPF tienen distancia 110, mucho mayor que las que tú tienes creadas a mano con distancia 1)

Así que, hazlo como mejor te parezca: o bien aprovechas lo que tenías y le pones OSPF encima, o bien monta OSPF siguiendo el manual, y sobre esos túneles chuta el resto. Pero no hagas ambas cosas, que es innecesario.

Saludos!
 
Lo que comentas ya lo tenía más o menos claro con tu manual para construir el OSPF, de hecho ha funcionado bien, aparecen los equipos en las pestañas Neighbors y LSA y hago ping a todos sitios.

Lo que sigo sin entender es como puedo hacer funcionar los EoIP que tengo montados sobre WireGuard: dos para IPTV en mAP (el famoso Router de Paco) para llevar la TV al site A y site C y otro EoIP para llevar el dominio de broadcast desde A a C. Más que nada por que en la configuración de cada EoIP sólo puedes ponerle una IP local y otra remota, entonces si algún día cambia (por una caída de red) el enlace wireguard del lado East (nomenclatura de buen teleco) a West entonces se quedaría caído el EoIP y ya se me fastidia el invento al ser IPs distintas. (Lo puedes comprobar en los exports que he enviado)

Y en cuanto a la gestión de los equipos vía SSH o Winbox pues no entiendo por qué no funciona.la verdad porque lo he permitido en el firewall y en IP->Services. Solucionado.

Edito: Otra cosa que he pensado, en los peers wg hay que declarar las subredes en el "allowed address" (yo lo tengo a 0.0.0.0/0 para que funcione) ¿y hay que declarar las mismas subredes en /routing ospf interface-template ? no entiendo bien que hace lo de "anunciar" las redes.

S@lu2.
 
Última edición:
Lo que sigo sin entender es como puedo hacer funcionar los EoIP que tengo montados sobre WireGuard: dos para IPTV en mAP (el famoso Router de Paco) para llevar la TV al site A y site C y otro EoIP para llevar el dominio de broadcast desde A a C. Más que nada por que en la configuración de cada EoIP sólo puedes ponerle una IP local y otra remota, entonces si algún día cambia (por una caída de red) el enlace wireguard del lado East (nomenclatura de buen teleco) a West entonces se quedaría caído el EoIP y ya se me fastidia el invento al ser IPs distintas. (Lo puedes comprobar en los exports que he enviado)
Espera, que creo que ya te sigo. Partiendo de esta foto, la cual ha seguido a rajatabla y tienes los tres sitios conectados por dos túneles Wireguard de tipo site to site en cada uno de ellos (aparte de lo que ya tuvieras antes)

1647881072026.png


Vamos a construir la siguiente tabla, para yo aclararme.

Site​
Descripción​
LAN​
Equipo​
Modo router / switch​
Direcciones OSPF
A​
Despacho​
Router​
172.16.0.1/30 -> to B
172.16.0.10/30 -> to C
B​
Paco (fuente IPTV)​
192.168.1.0/24​
mAP​
Switch​
172.16.0.2/30 -> to A
172.16.0.5/30 -> to C
C​
Apartamento​
Router​
172.16.0.6/30 -> to B
172.16.0.9/30 -> to A

Si esa foto es cierta, me queda por saber los equipos que tienes en A y C y las direcciones LAN que se manejan en ellos (LAN que puede ser una, dos o diez). De la misma forma, si en el despacho tienes una VPN de tipo road warrior a la que te conectas con un móvil o un equipo remoto desde el que quieres llegar a los sites B y C, cuando estás en esa conexión VPN, dímelo, porque la añadimos también.

Doy por hecho que el router B no es un router, sino un switch en casa de Paco, y que por tanto maneja como LAN la que el operador de turno tenga por defecto (corrígela si no es así).

Ahora mismo deberías tener dos túneles EoIP que nacen de B, hacia A y C, cada uno con un túnel ID, el cual me invento. Yo no me metería en el fregado que tienes en la cabeza (que creo que ya te he entendido), pero si quieres hacer redundancia conexión para la IPTV, necesitarías propagar esos dos túneles por el enlace A - C.

Partiríamos de esta situación


Site​
Descripción​
EoIP ID​
Destino​
Tunel​
Direcciones​
A​
Despacho​
1​
B​
eoip-to-b​
local: 172.16.0.1
remote: 172.16.0.2​
B​
Paco (fuente IPTV)​
1​
A​
eoip-to-a​
local: 172.16.0.2
remote: 172.16.0.1​
B​
Paco (fuente IPTV)​
2​
C​
eoip-to-c​
local: 172.16.0.5
remote: 172.16.0.6​
C​
Apartamento​
2​
B​
eoip-to-b​
local: 172.16.0.6
remote: 172.16.0.5​

Y acabaríamos teniendo esta otra, haciendo un doble anillo encima de cada enlace punto a punto, uno por cada ID Eoip que quieras redundar.

Site​
Descripción​
EoIP
Túnel ID​
Destino​
Tunel​
Direcciones​
A​
Despacho​
1​
B​
eoip-to-b​
local: 172.16.0.1
remote: 172.16.0.2​
A​
Despacho​
2​
B​
eoip-to-b-failover-bc​
local: 172.16.0.1
remote: 172.16.0.2​
A​
Despacho​
1​
C​
eoip-to-c-failover-ba​
local: 172.16.0.10
remote: 172.16.0.9​
A​
Despacho​
2​
C​
eoip-to-c-failover-bc​
local: 172.16.0.10
remote: 172.16.0.9​
B​
Paco (fuente IPTV)​
1​
A​
eoip-to-a​
local: 172.16.0.2
remote: 172.16.0.1​
B​
Paco (fuente IPTV)​
1​
C​
eoip-to-c-failover-ba​
local: 172.16.0.5
remote: 172.16.0.6​
B​
Paco (fuente IPTV)​
2​
C​
eoip-to-c​
local: 172.16.0.5
remote: 172.16.0.6​
B​
Paco (fuente IPTV)​
2​
A​
eoip-to-c-failover-bc​
local: 172.16.0.2
remote: 172.16.0.1​
C​
Apartamento​
2​
B​
eoip-to-b​
local: 172.16.0.6
remote: 172.16.0.5​
C​
Apartamento​
1​
B​
eoip-to-b-failover-ba​
local: 172.16.0.6
remote: 172.16.0.5​
C​
Apartamento​
2​
A​
eoip-to-c-failover-bc​
local: 172.16.0.9
remote: 172.16.0.10​
C​
Apartamento​
1​
A​
eoip-to-c-failover-ba​
local: 172.16.0.9
remote: 172.16.0.10​
Como ves, la cosa se empieza a complicar bastante.

Lo que sigo sin entender es como puedo hacer funcionar los EoIP que tengo montados sobre WireGuard: dos para IPTV en mAP (el famoso Router de Paco) para llevar la TV al site A y site C y otro EoIP para llevar el dominio de broadcast desde A a C. Más que nada por que en la configuración de cada EoIP sólo puedes ponerle una IP local y otra remota, entonces si algún día cambia (por una caída de red) el enlace wireguard del lado East (nomenclatura de buen teleco) a West entonces se quedaría caído el EoIP y ya se me fastidia el invento al ser IPs distintas. (Lo puedes comprobar en los exports que he enviado)
Yo no extendería el dominio de broadcast de niguno de los segmentos, a menos que sea estrictamente necesario, como es en el caso del IPTV. La gracia de todo esto es que, sin extender el dominio de broadcast, teniendo A y C los suyos independientes (incluso B si me aprietas), seas capaz de llegar a todos ellos, da igual en el equipo que te encuentres. Eso es lo que significa "anunciar" una subred. Si tú eres un nodo de la red y en ese nodo se maneja la LAN con segmento 192.168.X.0/24, tú anuncias que esa la tienes tú (la metes en OSPF de forma pasiva), y se enviarán mensajes al resto de nodos OSPF, usando las conexiones punto a punto, para decirles al resto de los routers "si quieres llegar a esa LAN, instálate esta ruta que yo te digo, que yo sé cómo llevarte a ella", siendo esa ruta siempre una de las conexiones punto a punto que interconectan OSPF. Imagínate esto mismo con 20 routers, y obviamente donde NO todos están conectados con todos.

Por eso insisto que es muy importante separar la red donde corre OSPF (normalmente túneles punto a punto) de la red LAN del segmento que sea, que simplemente participa de forma pasiva (se anuncia) usando OSPF. Si no consigo explicarme de forma clara, dime, y te lo pinto de otra manera.

Edito: Otra cosa que he pensado, en los peers wg hay que declarar las subredes en el "allowed address" (yo lo tengo a 0.0.0.0/0 para que funcione) ¿y hay que declarar las mismas subredes en /routing ospf interface-template ? no entiendo bien que hace lo de "anunciar" las redes.
Exacto. Tú en el allowed addresses básicamente declaras de quien aceptas tráfico cuando te viene por ese enlace. La idea de poner el 0.0.0.0/0 es simplificarlo, pero bien hecho, tú aceptarías en cada enlace sólo los segmentos de red que tú conoces. ¿pero qué pasa si yo mañana doy de alta uno nuevo (lo anuncio)? Pues que te cargas la gracia del automatismo de OSPF, puesto que vas a tener que ir al Peer y modificarlo para que ese tráfico "pase" (se permita) por ese enlace.

Te pongo mi ejemplo práctico: el mismo esquema que ves de los tres nodos lo tengo yo montado con otros dos familiares. La idea es que cada uno tiene una LAN distinta en el router de su casa, pero que todos lleguemos a las otras dos LAN de los otros dos routers remotos. Además de eso, yo "anuncio" (participo) con una LAN extra, la de mi segmento VPN, tal que si yo quiero acceder a cualquiera de los equipos de B y C y estoy fuera de casa, no me tengo que montar una conexión roadwarrior nueva contra ninguno de esos dos equipos, yo uso la que ya tengo en A (mi router) y, como la subred que uso para la VPN participa de forma pasiva en OSPF, los otros routers opuestos ya saben cómo llegar a ella, y por tanto tengo comunicación con B y C estando conectado a A.

La gracia del asunto es esa, en lugar de propagar el broadcast, cada lado tiene el suyo, pero OSPF se encarga de intercomunicarlos todos. Obviamente si estás usando algún protocolo que no te quede más huevos que usar el mismo segmento de broadcast (se me ocurre un DLNA) entre A y C, esta solución no te vale, pero para todo lo demás que simplemente necesites un acceso por IP, te vale.

Saludos!
 
Espera, que creo que ya te sigo. Partiendo de esta foto, la cual ha seguido a rajatabla y tienes los tres sitios conectados por dos túneles Wireguard de tipo site to site en cada uno de ellos (aparte de lo que ya tuvieras antes)

1647881072026.png


Vamos a construir la siguiente tabla, para yo aclararme.

Site​
Descripción​
LAN​
Equipo​
Modo router / switch​
Direcciones OSPF
A​
Despacho​
Router​
172.16.0.1/30 -> to B
172.16.0.10/30 -> to C
B​
Paco (fuente IPTV)​
192.168.1.0/24​
mAP​
Switch​
172.16.0.2/30 -> to A
172.16.0.5/30 -> to C
C​
Apartamento​
Router​
172.16.0.6/30 -> to B
172.16.0.9/30 -> to A

Si esa foto es cierta, me queda por saber los equipos que tienes en A y C y las direcciones LAN que se manejan en ellos (LAN que puede ser una, dos o diez). De la misma forma, si en el despacho tienes una VPN de tipo road warrior a la que te conectas con un móvil o un equipo remoto desde el que quieres llegar a los sites B y C, cuando estás en esa conexión VPN, dímelo, porque la añadimos también.

Doy por hecho que el router B no es un router, sino un switch en casa de Paco, y que por tanto maneja como LAN la que el operador de turno tenga por defecto (corrígela si no es así).

Ahora mismo deberías tener dos túneles EoIP que nacen de B, hacia A y C, cada uno con un túnel ID, el cual me invento. Yo no me metería en el fregado que tienes en la cabeza (que creo que ya te he entendido), pero si quieres hacer redundancia conexión para la IPTV, necesitarías propagar esos dos túneles por el enlace A - C.

Partiríamos de esta situación


Site​
Descripción​
EoIP ID​
Destino​
Tunel​
Direcciones​
A​
Despacho​
1​
B​
eoip-to-b​
local: 172.16.0.1
remote: 172.16.0.2​
B​
Paco (fuente IPTV)​
1​
A​
eoip-to-a​
local: 172.16.0.2
remote: 172.16.0.1​
B​
Paco (fuente IPTV)​
2​
C​
eoip-to-c​
local: 172.16.0.5
remote: 172.16.0.6​
C​
Apartamento​
2​
B​
eoip-to-b​
local: 172.16.0.6
remote: 172.16.0.5​

Y acabaríamos teniendo esta otra, haciendo un doble anillo encima de cada enlace punto a punto, uno por cada ID Eoip que quieras redundar.

Site​
Descripción​
EoIP
Túnel ID​
Destino​
Tunel​
Direcciones​
A​
Despacho​
1​
B​
eoip-to-b​
local: 172.16.0.1
remote: 172.16.0.2​
A​
Despacho​
2​
B​
eoip-to-b-failover-bc​

local: 172.16.0.1
remote: 172.16.0.2​
A​
Despacho​
1​
C​
eoip-to-c-failover-ba​
local: 172.16.0.10
remote: 172.16.0.9​
A​
Despacho​
2​
C​
eoip-to-c-failover-bc​
local: 172.16.0.10
remote: 172.16.0.9​
B​
Paco (fuente IPTV)​
1​
A​
eoip-to-a​
local: 172.16.0.2
remote: 172.16.0.1​
B​
Paco (fuente IPTV)​
1​
C​
eoip-to-c-failover-ba​
local: 172.16.0.5
remote: 172.16.0.6​
B​
Paco (fuente IPTV)​
2​
C​
eoip-to-c​
local: 172.16.0.5
remote: 172.16.0.6​
B​
Paco (fuente IPTV)​
2​
A​
eoip-to-c-failover-bc​
local: 172.16.0.2
remote: 172.16.0.1​
C​
Apartamento​
2​
B​
eoip-to-b​
local: 172.16.0.6
remote: 172.16.0.5​
C​
Apartamento​
1​
B​
eoip-to-b-failover-ba​
local: 172.16.0.6
remote: 172.16.0.5​
C​
Apartamento​
2​
A​
eoip-to-c-failover-bc​
local: 172.16.0.9
remote: 172.16.0.10​
C​
Apartamento​
1​
A​
eoip-to-c-failover-ba​
local: 172.16.0.9
remote: 172.16.0.10​
Como ves, la cosa se empieza a complicar bastante.


Yo no extendería el dominio de broadcast de niguno de los segmentos, a menos que sea estrictamente necesario, como es en el caso del IPTV. La gracia de todo esto es que, sin extender el dominio de broadcast, teniendo A y C los suyos independientes (incluso B si me aprietas), seas capaz de llegar a todos ellos, da igual en el equipo que te encuentres. Eso es lo que significa "anunciar" una subred. Si tú eres un nodo de la red y en ese nodo se maneja la LAN con segmento 192.168.X.0/24, tú anuncias que esa la tienes tú (la metes en OSPF de forma pasiva), y se enviarán mensajes al resto de nodos OSPF, usando las conexiones punto a punto, para decirles al resto de los routers "si quieres llegar a esa LAN, instálate esta ruta que yo te digo, que yo sé cómo llevarte a ella", siendo esa ruta siempre una de las conexiones punto a punto que interconectan OSPF. Imagínate esto mismo con 20 routers, y obviamente donde NO todos están conectados con todos.

Por eso insisto que es muy importante separar la red donde corre OSPF (normalmente túneles punto a punto) de la red LAN del segmento que sea, que simplemente participa de forma pasiva (se anuncia) usando OSPF. Si no consigo explicarme de forma clara, dime, y te lo pinto de otra manera.


Exacto. Tú en el allowed addresses básicamente declaras de quien aceptas tráfico cuando te viene por ese enlace. La idea de poner el 0.0.0.0/0 es simplificarlo, pero bien hecho, tú aceptarías en cada enlace sólo los segmentos de red que tú conoces. ¿pero qué pasa si yo mañana doy de alta uno nuevo (lo anuncio)? Pues que te cargas la gracia del automatismo de OSPF, puesto que vas a tener que ir al Peer y modificarlo para que ese tráfico "pase" (se permita) por ese enlace.

Te pongo mi ejemplo práctico: el mismo esquema que ves de los tres nodos lo tengo yo montado con otros dos familiares. La idea es que cada uno tiene una LAN distinta en el router de su casa, pero que todos lleguemos a las otras dos LAN de los otros dos routers remotos. Además de eso, yo "anuncio" (participo) con una LAN extra, la de mi segmento VPN, tal que si yo quiero acceder a cualquiera de los equipos de B y C y estoy fuera de casa, no me tengo que montar una conexión roadwarrior nueva contra ninguno de esos dos equipos, yo uso la que ya tengo en A (mi router) y, como la subred que uso para la VPN participa de forma pasiva en OSPF, los otros routers opuestos ya saben cómo llegar a ella, y por tanto tengo comunicación con B y C estando conectado a A.

La gracia del asunto es esa, en lugar de propagar el broadcast, cada lado tiene el suyo, pero OSPF se encarga de intercomunicarlos todos. Obviamente si estás usando algún protocolo que no te quede más huevos que usar el mismo segmento de broadcast (se me ocurre un DLNA) entre A y C, esta solución no te vale, pero para todo lo demás que simplemente necesites un acceso por IP, te vale.

Saludos!

Al final después de todas las pruebas que he realizado esta tarde, he dejado el anillo OSPF exclusivamente para la gestión de los equipos (winbox + ssh) y para compartir las redes LAN de los demás sites. Más o menos así:
1647979916519.png

La redundancia ha funcionado genial, recuperando tanto gestión como acceso a las LAN por el lado que quedaba levantado, no daba tiempo a que se cortara la conexión con los equipos. Muy contento la verdad.

En cuanto a la parte de IPTV, me ha pasado lo que te comenté ayer, en cuanto conmuta, se cae el EoIP afectado al no estar disponibles las IPs local y remote. Al final he creado unos enlaces wg "exclusivamente" para la IPTV
(sin redundancia entre A y C), no es importante si se cae algún enlace,

Respecto al doble anillo EoIP que comentas es muy interesante, pero hay algo que no entiendo:
- ¿los túneles tipo "eoip-to-x" es el primer anillo donde irían los datos tipo LAN y de gestión?
- ¿los túneles tipo "eoip-to-x-failover-xx" es el segundo anillo para meterlos en los bridge-iptv de cada site?

Es complicadillo, mañana lo analizaré al detalle.

Muchas gracias @pokoyo por tu gran ayuda!

S@lu2.
 
Última edición:
El doble anillo de EoIP lo necesitas porque, desde un mismo punto (nodo), no puedes crear dos EoIPs con el mismo túnel ID. Ahora mismo desde B nacen dos EoIPs con IDs distintos para Este y Oeste. Sería como si continuaras cada uno de ellos, en su sentido (uno horario y otro en sentido opuesto a las agujas del reloj). Lo que no tengo tan claro es si no la vamos a liar cuando empalmemos ambos IDs en un nodo (cuando metas las dos interfaces EoIP en un mismo bridge con un puerto físico de acceso). Pero en fin, todo es probarlo.

Saludos!
 
Buenos días @pokoyo,

Sigo investigando sobre la forma de que un túnel EoIP funcione con redundancia sobre OSPF. Parece ser por lo que he leído que la mejor manera de no perder conectividad cuando cambia de ruta es que los extremos del EoIP apunte a la "Loopback Address" origen y destino de los nodos (no a los extremos de los túneles sts wireguard) que es lo que comentabas en tu manual como segunda opción a la hora de configurar el router ID.

¿Llegaste a montar el OSPF con loopbacks? Es que la info que he visto hasta ahora en internet es sobre RouterOS v6.x y cambian los menús de OSPF con respecto a v7.x.

Ahora, como te comenté más atrás la parte IPTV la tengo con los túneles EoIP sobre otros WG-STS independizada del OSPF y cerrada con otro WG-STS entre Despacho<->Apartamento (A-C). ¿sobre este mismo seudo-anillo IPTV se podría crear otro OSPF de pruebas con otra Área backbone? (no tengo claro si se puede crear un segundo backbone u otra instancia apuntando como router ID a los loopbacks) He hecho alguna prueba pero no veo a los Neighbors y tampoco los otros nodos en LSA.

S@lu2.
 
Sí, la probé igualmente. Si defines una IP /32 sobre un bridge vacío, ya tienes una dirección de loopback. Esa misma dirección la puedes meter como router ID y andando.

Saludos!
 
Sí, la probé igualmente. Si defines una IP /32 sobre un bridge vacío, ya tienes una dirección de loopback. Esa misma dirección la puedes meter como router ID y andando.

Saludos!
Eso he hecho, he creado los bridges loopback con las IPs: 10.252.252.1 (A), 10.252.252.2 (B) y 10.252.252.3 (C) y esas mismas IPs las he asignado como Router ID de los nodos.

1648459067587.png


Ahora en LSA salen duplicados con los anteriores
1648459127004.png

1648459511918.png


Ahora bien, ¿hay que tener algo más en cuenta? ¿Esos segmentos de loopback hay que "anunciarlos" también? porque desde las terminales extremas no me responde el ping a esas IPs de loopback.

EDITO: Efectivamente, hay que anunciarlo en modo passive para que el segmento loopback se propague por las tablas de enrutamiento dinámicas. Ya hay conectividad.

1648462476589.png


S@lu2.
 
Última edición:
Coooorrecto. Todo lo que no sea la red propia de ospf, lo tienes que anunciar como pasivo, si quieres que se creen rutas dinámicas que lleguen a esas IPs.

Saludos!
 
Arriba