Tabla de Contenidos
Wireguard sobre OpenBSD-6.7
[Referencia-1](https://blog.jasper.la/wireguard-on-openbsd.html)
[Referencia-2](https://www.alextsang.net/articles/20200307-133918/index.html)
Hace pocos días se importó un port para WireGuard en el árbol de puertos de OpenBSD.
Por el momento tenemos el daemon userland y las herramientas disponibles. La implementación en el núcleo solo está disponible para Linux. Al momento de escribir, hay paquetes disponibles para -current.
A partir de junio de 2020, el soporte para WireGuard se ha comprometido con el kernel como wg(4) junto con el soporte en ifconfig(8). Consulte estas dos publicaciones en la lista de correo WireGuard sobre cómo configurarlo o cómo migrar desde una configuración como se describe a continuación: configurar y migrar desde Linux.
Jason A. Donenfeld (autor de WireGuard) ha trabajado para apoyar OpenBSD en WireGuard y, como tal, su publicación en ports @ el año pasado me interesó en WireGuard, desde entonces otros han jugado con WireGuard en OpenBSD antes y, como tal, he usado el artículo de Ted como una referencia. Sin embargo, tenga en cuenta que algunas de las opciones mencionadas allí ya no son válidas. Además, usaré dos pares de OpenBSD aquí.
La configuración será la siguiente: dos pares de OpenBSD, de los cuales doblaremos wg1 el servidor y wg2 el cliente. El servicio WireGuard en wg1 está escuchando en 100.64.4.3:51820.
Dentro de la subred VPN, los nodos usarán las siguientes direcciones:
- wg1: 10.0.0.1
- wg2: 10.0.0.2
En ambos nodos usaremos el dispositivo `tun2` para tunelizar el tráfico WireGuard.
Configuración
Primero necesitamos instalar los paquetes requeridos en ambos nodos:
# pkg_add wireguard-go wireguard-tools
Actualmente esto instala wireguard-go-0.0.20200320v0 y wireguard-tools-1.0.20200319v0, en el momento de escribir esto.
wg1 (server)
En el nodo servidor generaremos los pares de claves para ambos nodos:
wg genkey | tee server-private.key | wg pubkey > server-public.key wg genkey | tee client-private.key | wg pubkey > client-public.key
Para que el servidor reenvíe paquetes, necesitamos habilitarlo a través de sysctl:
# sysctl net.inet.ip.forwarding=1
Y dependiendo de la configuración exacta de su firewall, puede evitar agregar algo como lo siguiente a pf.conf del nodo del servidor a NAT el tráfico del túnel:
pass out on egress inet from (tun2:network) nat-to (egress:0)
También es posible que deba permitir el tráfico entrante a 51820/udp (o el puerto que elija para ListenPort).
Ahora cree la interfaz del túnel:
ifconfig tun2 up 10.0.0.1 10.0.0.2 netmask 255.255.255.0 rcctl enable wireguard_go rcctl set wireguard_go flags tun2 rcctl start wireguard_go
Finalmente, necesitaremos la configuración real en la que declaramos la clave privada para el nodo y la clave pública de su peer.server.conf:
[Interface] PrivateKey = sEw/H2BjShZovIn54a6un/sGjMsXl6hzBzEDvqIYrUk= ListenPort = 51820 [Peer] PublicKey = jCmA1Kvq/0/uhi1+uX4OLWIodgtqiFyMfJ4DTqbWDWWs= AllowedIPs = 10.0.0.2/32
Obviamente, debe usar las claves que generó anteriormente en lugar de las indicadas arriba.
Ahora aplique la configuración a la interfaz `tun2` como tal:
wg setconf tun2 server.conf
Puede ejecutar `wg` para asegurarse de que se aplica correctamente.
wg2 (cliente)
Para wg2 la configuración requerida es:
ifconfig tun2 up 10.0.0.2 10.0.0.1 netmask 255.255.255.0 rcctl enable wireguard_go rcctl set wireguard_go flags tun2 rcctl start wireguard_go
Y la configuración de client.conf es básicamente la misma que para wg1, excepto que omitimos ListenPort (por lo que el cliente usará un puerto aleatorio para escuchar) y configuramos el Endpoint para que coincida con el IP/puerto en el que podemos alcanzar wg1:
[Interface] PrivateKey = oNqEAeMDpnCVVU+lz/G0zEAR3/OlssGg87/Hruy5WVg= [Peer] PublicKey = GhBU6Sqss+s/ZqMuJhVM1RBIDdG5YQ9bK0EwcZNxU2Q= AllowedIPs = 0.0.0.0/0 Endpoint = 100.64.3.2:51820
Aplicar la configuración:
wg setconf tun2 client.conf
Y ahora que se ha establecido el túnel WireGuard, intente hacer ping al otro extremo del túnel para verificar y ejecute wg:
# wg interface: tun2 public key: jCmA1Kvq/0/uhi1+uX4OLWIoctqhiyMfJ4DTqbWDWWs= private key: (hidden) listening port: 21373 peer: GhBU6Sqss+s/ZqMuJhVM1RBIDdG5YQ9bK0EwcZNxU2Q= endpoint: 100.64.3.2:51820 allowed ips: 0.0.0.0/0 latest handshake: 22 minutes, 17 seconds ago transfer: 2.54 KiB received, 3.25 KiB sent
Enrutamiento (routing)
Lo que ahora podemos hacer es enrutar todo el tráfico sobre el túnel WireGuard. Para que esto funcione, primero debemos agregar una ruta más específica a nuestro servidor en el cliente:
route add -priority 2 100.64.3.2 $IP_OF_DEFAULT_GATEWAY
Finalmente, agregamos la ruta predeterminada al otro extremo del túnel usando una prioridad más baja para asegurarnos de que no intentemos enrutar el tráfico al otro extremo sobre el túnel que todavía es necesario para ir a la dirección que aparece en el extremo.
route add -priority 7 default 10.0.0.1
La prioridad 7 es inferior a la predeterminada de 8. Al enrutar todo el tráfico a través de WireGuard, es posible que deba ajustar el campo AllowedIP para el peer, ya que también el tráfico que se origina desde su IP que no es un túnel se enrutará sobre el túnel y se mostrará el siguiente mensaje por el servidor:
IPv4 packet with disallowed source address from peer
Conclusiones
WireGuard tiene como objetivo ser más fácil de configurar y más rápido que OpenVPN y, aunque no he podido verificar esto último, lo primero es cierto … una vez que lo haya descubierto.
La mayoría de la documentación disponible es para Linux, así que tuve que descubrir el servicio wireguard_go y los parámetros de tun.
Pero en general, seguro, es más fácil. Especialmente la configuración del cliente en iOS que no cubrí aquí porque es esencialmente:
# pkg_add libqrencode # cat client.conf | qrencode -t ansiutf8
Escanee el código con la aplicación WireGuard y listo. Lo que es particularmente bueno es que WireGuard en iOS es compatible con Always-on.
