Introducción
Después del
aperitivo de montar esto en un router secundario que tenía funcionando como switch (o AP, lo mismo me da), ahora que la v7.1 está entre nosotros (como testing-cuasi-estable), vamos a meternos de lleno con la configuración de WireGuard, usando para ello nuestros routers principales.
Manos a la obra
Vamos a plantear los dos tipos de setup más comunes que vamos a encontrar para una VPN, mas uno de regalo que a más de uno le va a gustar. Configuraremos tres interfaces WireGuard en el router HQ con este manual:
- Servidor WireGuard para road warriors (clientes que se conectan desde cualquier sitio)
- Servidor WireGuard para un site-to-site (unir dos o más sedes)
- Servidor WireGuard para montar un túnel, sobre el que montar luego EoIP (tunel in tunel)
WireGuard: Modo Road Warrior
Este setup está prácticamente explicado en el post anterior, con la salvedad de que ahora lo vamos a montar en nuestro router principal. Para ello, simplemente crearemos una nueva interfaz WireGuard, elegiremos un segmento cualquier para la VPN de este tipo, y daremos de alta un peer para que conecte (segundo y siguientes serían idénticos). Vamos al lío:
Creamos la interfaz, en un puerto cualquiera
Código:
/interface wireguard
add listen-port=12345 name=wireguard-rw
Elegimos un segmento de red para estos clientes, por ejemplo el 192.168.50.1/24, y lo asignamos a dicha interfaz.
Código:
/ip address
add address=192.168.50.1/24 interface=wireguard-rw
Damos de alta un peer con la dirección 192.168.50.2/32, indicando su clave pública (traída del servidor del otro extremo, del cliente que se va a conectar)
Código:
/interface wireguard peers
add allowed-address=192.168.50.2/32 comment=PeerRW interface=wireguard-rw \
public-key="0dpuMJZ2Tlpji8ywc/OjupVvKOVxxI00Sn4d7fAkLWc="
Aceptamos el tráfico en input para el puerto seleccionado en la interfaz (si tenéis la config por defecto, el place-before la dejará donde toca, sino, moverla donde corresponda, antes de las reglas de drop generales que tengáis en input)
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-rw" \
dst-port=12345 protocol=udp \
place-before [find comment="defconf: drop all not coming from LAN"]
OPCIONAL: Si queréis que los clientes RW accedan al propio router. Dos maneras, o metéis la interfaz WireGuard en la lista LAN (no le afectará la regla de input que tira el tráfico que no venga de la lista LAN) o creáis una nueva regla de input que acepte el tráfico de la subred road warrior o de la IP concreta que queráis permitir llegar al propio router
Código:
# Usando la lista LAN
/interface list member
add interface=wireguard-rw list=LAN
# Usando una regla de input
/ip firewall filter
add chain=input src-address=192.168.50.0/24 action=accept \
place-before [find comment="defconf: drop all not coming from LAN"]
OPCIONAL: Restringir que el tráfico de los RW sólo acceda a internet, y a nada más en nuestra red. En este caso, haríamos lo mismo que hacemos con las redes de invitados, caparlas en forward, de la siguiente manera:
Código:
/ip firewall filter
add action=drop chain=forward comment="VPN: block road warriors to have only internet" \
out-interface-list=!WAN src-address=192.168.50.0/24
Ejemplo de configuración de un cliente cualquiera en modo RW
Móvil (iPhone, app oficial para WireGuard)
Ver el adjunto 88965
Portátil (Mac, app oficial para WireGuard), mismo ejemplo:
Ver el adjunto 88974
WireGuard: Modo Site to Site
En este modo, uniremos dos routers mikrotik que tengan la V7 corriendo, y permitiremos el acceso de la LAN de ambos equipos desde el otro extremo. Para ello, en cada extremo, manejaremos dos segmentos de red bien diferenciados
- Segmento de red local (normalmente un /24). Suponemos A tiene la 192.168.88.0/24 y B tiene la 192.168.77.0/24
- Segmento del túnel (al ser un túnel punto a punto, usaremos direcciones /30). Usaremos estas dos, por ejemplo: 172.16.1.1/30 en A y 172.16.1.2/30 en B
Para el ejemplo, suponemos que tenemos IP -> Cloud corriendo en ambos extremos, y que las direcciones públicas se resuelven a partir del DDNS propio de mikrotik, siendo serialA.sn.mynetname.net el del extremo A, y serialB.sn.mynetname.net el del extremo B. Con estas consideraciones, tendríamos
Configuración en A
Creamos la interfaz del servidor A (puerto a elegir, pongo uno sucesivo al anterior, por si queréis probar los tres túneles de un golpe)
Código:
/interface wireguard
add listen-port=12346 name=wireguard-sts
Nos apuntamos la IP pública de A, para crear el peer en B (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts] public-key]
Configuración en B
Creamos la interfaz del servidor en B
Código:
/interface wireguard
add listen-port=12346 name=wireguard-sts
Nos apuntamos la IP pública de B, para crear el peer en A (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts] public-key]
Resto de configuración en A
Asignamos la IP /30 sobre la interfaz wireguard-sts
Código:
/ip address
add address=172.16.1.1/30 interface=wireguard-sts
Cremos una ruta estática para decirle a A que el segmento LAN de B se encuentra al otro lado del túnel, por la IP del otro extremo, la .2
Código:
/ip route
add dst-address=192.168.77.0/24 gateway=172.16.1.2
Crearemos el peer que representa al otro extremo en A, con la clave pública de B. Permitiremos el tráfico tanto de la IP .2/30 del otro extremo, como del segmento LAN de B. Nos quedaría algo así:
Código:
/interface wireguard peers
add allowed-address=172.16.1.2/32,192.168.77.0/24 interface=wireguard-sts \
public-key="PUBLIC_KEY_FROM_B" \
endpoint-address=serialB.sn.mynetname.net endpoint-port=12346
Aceptaremos el tráfico en input del puerto 12346, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts" \
dst-port=12346 protocol=udp \
place-before [find comment="defconf: drop all not coming from LAN"]
Resto de configuración en B (Idéntica a A, pero con los términos invertidos)
Asignamos la IP /30 sobre la interfaz wireguard-sts
Código:
/ip address
add address=172.16.1.2/30 interface=wireguard-sts
Cremos una ruta estática para decirle a B que el segmento LAN de A se encuentra al otro lado del túnel, por la IP del otro extremo, la .1
Código:
/ip route
add dst-address=192.168.88.0/24 gateway=172.16.1.1
Crearemos el peer que representa al otro extremo en B, con la clave pública de A. Permitiremos el tráfico tanto de la IP .1/32 del otro extremo del túnel, como del segmento LAN de B. Nos quedaría algo así:
Código:
/interface wireguard peers
add allowed-address=172.16.1.1/32,192.168.88.0/24 interface=wireguard-sts \
public-key="PUBLIC_KEY_FROM_A" \
endpoint-address=serialA.sn.mynetname.net endpoint-port=12346
Aceptaremos el tráfico en input del puerto 12346, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts" \
dst-port=12346 protocol=udp \
place-before [find comment="defconf: drop all not coming from LAN"]
Y con esto y un bizcocho, si lo hemos hecho bien, tendremos ambas sedes unidas por un túnel WireGuard, enrutando las redes LAN de ambos extremos, mientras el resto del tráfico local y la salida a internet se queda en cada sitio. Además, al tener ambos peers configurado el endpoint del otro extremo, da igual qué extremo se venga abajo, cualquiera de los dos será capaz de reconectar el túnel
NOTA MUY IMPORTANTE: para los que vengan de
IKEv2 site-to-site
Me he vuelto mico intentando hacer hoy este setup, puesto que lo estaba montando sobre dos routers que previamente estaban unidos usando IKEv2 en modo site to site. Aunque la conexión no esté levantada, las policy templates siguen funcionando, y hacen que sea imposible comunicar ambas LAN (puedes hacer ping desde el router, pero no desde un equipo de la LAN de un extremo a un equipo de la LAN del otro extremo. Conforme borras las policy templates, el tema empieza a fluir como por arte de magia. Me he dado cuenta al ver que, si enmascaraba el tráfico de la interfaz WireGuard de A, sí que llegaba a los equipos de B, cosa que es innecesaria en este tipo de VPN. Así que no hagáis como yo, si vais a montar esto, desmontar antes IKEv2 site-to-site
BONUS! - WireGuard Site to Site + EoIP
Como habréis podido intuir, montar lo anterior pero poniéndole encima un túnel EoIP es de lo más trivial. Recordemos que, para montar un túnel EoIP, todo lo que necesitamos son IP's locales de ambos extremos, las cuales ya tenemos con los esas IP's /30 que hemos definido antes (usaremos
172.16.0.1/30 y 172.16.0.2/30 en lugar de las de antes) Hecho eso, todo lo que necesitamos es crear ambos túneles EoIP en ambos extremos, añadir esa nueva interfaz EoIP al que sea el bridge donde queremos propagar el dominio de broadcast, y listo. Para este ejemplo vamos a partir de la misma configuración que el site to site, pero en A vamos a meter el EoIP en el bridge principal, y en B vamos a crear un bridge nuevo con el EoIP y un puerto dedicado, por ejemplo, ether5. Así, en B, los puertos del 2 al 4 se comportarán como venían haciendo hasta ahora (obteniendo una IP del segmento de .77 de su LAN) y el puerto 5 obtendrá una IP .88 del mismo dominio de broadcast que hay en A. En este caso, como el túnel sólo lo vamos a montar para eso, omitimos la parte de las rutas estáticas, puesto que la LAN no la vamos a enrutar en esta ocasión, la vamos a tele-transportar directamente.
Configuración en A
Creamos la interfaz del servidor A (puerto a elegir, pongo uno sucesivo al anterior, por si queréis probar los tres túneles de un golpe)
Código:
/interface wireguard
add listen-port=12347 name=wireguard-sts-eoip
Nos apuntamos la IP pública de A, para crear el peer en B (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts-eoip] public-key]
Configuración en B
Creamos la interfaz del servidor en B
Código:
/interface wireguard
add listen-port=12347 name=wireguard-sts-eoip
Nos apuntamos la IP pública de B, para crear el peer en A (con este comando lo imprimís por terminal)
Código:
:put [/interface/wireguard/get [find name=wireguard-sts-eoip] public-key]
Resto de configuración en A
Asignamos la IP /30 sobre la interfaz wireguard-sts-eoip
Código:
/ip address
add address=172.16.0.1/30 interface=wireguard-sts-eoip
Crearemos el peer que representa al otro extremo en A, con la clave pública de B. Permitiremos el tráfico tanto de la IP .2/30 del otro extremo, como del segmento LAN de B. Nos quedaría algo así:
Código:
/interface wireguard peers
add allowed-address=172.16.0.2/32 interface=wireguard-sts-eoip \
public-key="PUBLIC_KEY_FROM_B" \
endpoint-address=serialB.sn.mynetname.net endpoint-port=12347
Aceptaremos el tráfico en input del puerto 12347, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts-eoip" \
dst-port=12347 protocol=udp \
place-before [find comment="defconf: drop all not coming from LAN"]
Creamos un nuevo túnel EoIP en A, con ip local la .1 y remota la .2 de los segmentos usados para el túnel
Código:
/interface eoip
add local-address=172.16.0.1 name=eoip-tunnel-over-wg-sts \
remote-address=172.16.0.2 tunnel-id=0
Añadimos dicho túnel al bridge principal que tengamos ya corriendo en A (supongo un único bridge, llamado "bridge")
Código:
/interface bridge port
add bridge=bridge interface=eoip-tunnel-over-wg-sts
Resto de configuración en B (Idéntica a A, pero con los términos invertidos)
Asignamos la IP /30 sobre la interfaz wireguard-sts
Código:
/ip address
add address=172.16.0.2/30 interface=wireguard-sts-eoip
Crearemos el peer que representa al otro extremo en B, con la clave pública de A. Permitiremos el tráfico únicamente de la IP .1/32
Código:
/interface wireguard peers
add allowed-address=172.16.0.1/32 interface=wireguard-sts-eoip \
public-key="PUBLIC_KEY_FROM_A" \
endpoint-address=serialA.sn.mynetname.net endpoint-port=12347
Aceptaremos el tráfico en input del puerto 12347, que hemos usado para el servidor de este ejemplo
Código:
/ip firewall filter
add action=accept chain=input comment="vpn: allow wireguard-sts" \
dst-port=12347 protocol=udp \
place-before [find comment="defconf: drop all not coming from LAN"]
Creamos un nuevo túnel EoIP, con las IP's del extremo de los túneles (local en B la .2, remote la .1, a la inversa que antes)
Código:
/interface eoip
add local-address=172.16.0.2 name=eoip-tunnel-over-wg-sts \
remote-address=172.16.0.1 tunnel-id=0
Sacamos la interfaz "ether5" en B del bridge principal, para después meterla en el nuevo bridge. Supongo que el bridge principal se llama "bridge"
Código:
interface bridge port remove [find where interface=ether5 and bridge=bridge]
Creamos un nuevo bridge y añadimos en él la interfaz EoIP y el puerto 5 que recién hemos sacado del bridge principal. Metemos también el EoIP en el mismo nuevo bridge
Código:
/interface bridge
add name=bridge-eoip-from-a
/interface bridge port
add bridge=bridge-eoip-from-a interface=ether5
add bridge=bridge-eoip-from-a interface=eoip-tunnel-over-wg-sts
Y, con esto y un bizcocho, si conectamos un equipo a ether5, deberíamos obtener una IP del segmento 192.168.88.0/24 del router principal.
Espero que os guste el manual, tenía muchas ganas de montarlo, y ahora que la RouterOS v7 es una realidad, era casi una obligación.
Saludos, y que lo disfrutéis!
