MANUAL: Mikrotik, VPN tipo RoadWarrior usando WireGuard | Mikrotik (2023)

Introducción
Hoy os quiero hablar de un nuevo protocolo para establecer conexiones seguras entre equipos conectados a internet. Un nuevo tipo de VPN que, sin lugar a dudas, viene para quedarse: WireGuard. Sin duda, un avance enorme en cuanto a simplicidad y a rendimiento en túneles VPN diseñado con la idea, a mi juicio, de ser el sustituto natural de los túneles basados en IPSec, e incluso OpenVPN.

Un poco de historia
El nuevo protocolo nace en 2016, hace escasamente cuatro años, de la mano de Jason A. Donenfeld, experimentado desarrollador e investigador en seguridad, participante activo del desarrollo del kernel del linux, y colaborador en el desarrollo de otras maravillas tipo AirTunes2. Y bueno, si queréis ver la lista entera de historias en las que ha estado metido el tipo, sólo hace falta que os deis una vuelta por su web, que hay donde elegir. Y, como se ve que le sobraba tiempo y ganas, funda una consultora de seguridad, Edge Security, y le da por parir esta maravilla.

Algo más de detalle..., ¿de qué va esto?
Como todo protocolo o conexión VPN, el propósito es siempre el mismo: conectar A con B de manera segura. No obstante, para desarrollar esto, se ha tenido una máxima por bandera: KISS (keep it simple, stupid!). Para que os hagáis una idea, OpenVPN tiene la friolera de 600k líneas de código, e IPSec no se queda atrás con 400k. Esto se ha desarrollado con 4000 lineas de código... un 1% de lo anterior. Hasta donde llega el tema que el mismísimo Linus Torvalds lo calificó de obra de arte, en comparación con otros protocolos más complejos como puede ser IPSec (a este es que le tiene especial manía, pero eso es otro tema).
¿Y cómo funciona, os preguntaréis? Pues el principio de funcionamiento es tremendamente sencillo, tanto que hasta cuesta creer que a nadie se le hubiera ocurrido antes: dos extremos A y B generan un par de claves tipo RSA (criptografía asimétrica) e intercambian sus claves públicas, tal y como harías tú para conectarte a un servidor por ssh. En la configuración de un extremo, se da de alta un "peer" o par, que representa a un cliente final del otro extremo. Su identificador es su clave pública y, para él, se dan de alta la lista de direcciones a las que va a tener acceso dicho par, desde las cuales podrá enviar y recibir tráfico. Si un cliente trata de enviar información y no está dado de alta como peer, la información se descarta del tirón (tú quién eres, si yo no te tengo dado de alta y no tengo tu clave pública, no puedes hablar conmigo). Si el par es válido, desencripto los paquetes que me manda con su clave pública y analizo la IP de la que viene el paquete, ¿tiene este peer permitido recibir información de esa IP? si lo está, la comunicación fluye, sino, los paquetes se descartan. Para el envío, muy parecido, compruebo si el peer está dado de alta y si se me permite o no enviar información y a qué endpoint corresponde...así de simple.
Como algoritmos de encriptación, autenticación, intercambio de claves, hashing, etc usa algoritmos bien conocidos y muy seguros como ChaCha20, Poly1305, Curve25519, SipHash, etc (tenéis más detalla en la wikipedia). Para establecer la conexión, todo lo que necesita es un puerto UDP, de nuestra elección. Y, si queréis aún más protección, encima de todo lo anterior, le podéis meter una clave de tipo PSK.

Ahora sí, al grano de verdad:

Lo primero de todo: esto se ha probado sobre una versión de routerOS que NO es estable, es una beta. Lo digo por si a alguien le da por montar esto en algún router de producción... luego los ruegos, lágrimas y plegarias; a la virgen de Lourdes, no a un servidor. Es una beta y, como tal, tiene fallos. No obstante, como me ha costado 15 minutos montarlo, creo que merecía la pena compartirlo.

Dicho esto, y partiendo de un router prácticamente sin configuración y con todas sus interfaces dentro del mismo bridge, como si fuera un switch, (ya explicado en otros manuales), todo lo que tenéis que hacer es esto (ojo que los comandos son ligeramente distintos a los que solemos estar acostumbrados... cosas de la versión 7)

Creamos la interfaz de wireguard

/interface/wireguard/add name=wireguard listen-port=12345

Obtenemos la clave pública del servidor recién creado: nos la guardamos, que la usaremos más adelante

:put [/interface/wireguard/get 0 public-key]

Le damos una dirección a la nueva interfaz creada. Al tratarse de un túnel, vamos a usar IP's poco comunes.

/ip/address/add interface=wireguard address=10.10.0.1/24

La regla de masquerade sólo será necesaria si el equipo hace de AP. Si hace de router, no es necesaria la siguiente instrucción:

/ip/firewall/nat add src-address=10.10.0.0/24 chain=srcnat action=masquerade

Con el servidor, de momento, hemos terminado; volveremos después a dar de alta el peer, pero de momento tenemos todo lo que necesitamos para configurar el cliente. Como extra, quedaría abrir el puerto 12345 (o el que sea que hayáis elegido) y mapearlo a la IP de este equipo. Como eso ya sabéis hacerlo, no me paro en ello.

Pasamos a configurar el cliente. En mi caso, la APP móvil de WireGuard en un iPhone, pero sería idéntico en cualquier equipo:

En la app, seleccionamos "Create from scratch" y rellenamos el cliente con los siguiente datos:

Name: lo que os de la gana
Private / Public key = le dais al botón "Generate keypair" y dejáis que la app genere un par de claves aleatorias. Os guardáis la pública.
Addresses: esta es la dirección del otro lado del túnel. En el router configuramos la 10.10.0.1, así que aquí configuraremos la 10.10.0.2/32
ListenPort: no hace falta que lo rellenéis, lo dejaremos en blanco para que lo genere él en caliente (total, soy un cliente, no servidor)
MTU: Lo dejamos en automático
DNS Servers: esto sí es importante. Le damos la IP que vamos a querer usar como DNS. En mi caso, como tengo un servidor DNS dentro de la red local, le doy una IP del otro extremo del túnel, de mi red local, a la que está conectada este router haciendo de switch. En vuestro caso, podéis poner la pripia IP del router principal de vuestra red, que normalmente ya hace de servidor DNS, o unas DNS públicas, tipo las de cloudflare: 1.1.1.1, 1.0.0.1

El cliente está listo. Bajando un poco en la app, ahora pulsamos en "Add peer", para dar de alta el detalle del par del otro extremo, nuestro servidor. Y rellenamos con los siguientes datos:
Public key: metemos la clave pública que se generó en el router en el primer paso, cuando dimos de alta la interfaz de wireguard. Enviaos el chorizo por correo sin miedo, no me seáis animales y lo copiéis a mano letra a letra. Es una clave pública, se puede enviar de manera insegura sin mayor problema.
Preshared key: es opcional y, como no lo vamos a definir en el otro extremo, lo dejamos vacío. Si queréis aún más seguridad, poned una y darla de alta en ambos extremos. Yo en mi caso, lo dejo vacío.
Endpoint: aquí va la IP pública de nuestra conexión o nuestro dominio ddns, seguido de dos puntos y el puerto elegido. Es decir, algo así: serial.sn.mynetname.net:12345. Donde, como siempre, serial es el número de serie de vuestro equipo mikrotik que tenga activo el servicio de ddns (IP -> Cloud)
AllowedIPs: en este caso, como este cliente no sólo va a querer recibir información del otro extremo del túnel, sino que va a querer navegar por internet y tener pleno acceso a todas las rutas, ponemos una ruta de tipo wildcard: 0.0.0.0/0. Al hacerlo, veréis que se os habilita un botón nuevo para excluir las IP's privadas. Esto último es útil si sólo queréis dar salida a internet a ese equipo y habéis usando una IP pública como servidor DNS. Como no es mi caso y yo quiero acceder no sólo a internet sino a mi LAN con este equipo, NO pulso ese botón.
Persistent keepalive: nada, lo dejamos vacío.
On demand activation: a gusto de consumidor. Una cosa muy chula que tiene este cliente, que le podéis poner reglas para cuando queráis que se levante la VPN automáticamente. Por ejemplo, sólo cuando estoy en cobertura móvil, o cuando estoy en móvil y en redes Wifi, distintas a la de mi casa, etc. Hay varias combinaciones, probadlo que es muy chulo, me gusta mucho el modo automático.

Con las mismas, hemos terminado con el cliente. ¿qué nos queda? Pues dar de alta este peer en el otro extremo, para permitirle conectar con el servidor. Vamos a ello, volvemos de nuevo al mikrotik y ejecutamos:

/interface/wireguard/peers/add interface=wireguard allowed-address=10.10.0.2/32 public-key="CHORIZO"

Siendo "CHORIZO" la clave pública que hemos generado en el móvil, y que nos hemos anotado previamente. Ojo y meterla entre comillas, que no tengáis problemas con caracteres especiales como el "=", muy típico en este tipo de claves.

Y listo. Le damos al botón de conectar y... voilá! ya tenéis montado uno de los servidores VPN más sencillos, a mi juicio, de montar en mikrotik. Cuando os conectéis, veréis que el campo "Endpoint" del peer se actualiza, identificando la IP pública remota del par que conecta en modo RoadWarrior. Esto nos permite hacer roaming entre IP's con una reconexión prácticamente instantánea. En el móvil, veréis que se genera, en caliente, un puerto por el cual escucha peticiones el cliente y, si os metéis en los logs de la aplicación, incluso veréis los mensajes del "keep alive" que se envían para saber que ambos extremos siguen vivos. Desde el servidor, vuestro router que hace de switch, podéis abrir una terminal y ver que, en efecto, la IP 10.10.0.2 responde a un ping.

Para configurar esto en un equipo que haga de router sería exactamente igual, salvo el detalle de abrir el puerto, que en lugar de eso, tendríais que añadir una regla de firewall en el chain de input aceptando el tráfico del puerto UDP que sea que hayáis definido para la conexión. Eso, y tener activado el dominio DDNS es todo lo extra que necesitaríais hacer en un router que haga de router. Eso sí, no os recomiendo que hagáis esto en vuestros equipos principales, hasta que routerOS versión 7 pase a ser una versión estable.

No obstante, si os queréis tirar a la piscina, aquí tenéis el trampolín.

Saludos!