En este post, el escenario está formado por dos servidores de VPN que actúan, a su vez, como clientes del otro servidor y un equipo en la red interna de cada servidor.

Instalación de WireGuard

Al usar WireGuard, la configuración para una red VPN punto a punto se puede hacer, a la vez, en los dos servidores. En primer lugar, se instala el paquete wireguard.

apt update
apt install wireguard

Creación de las claves

Para configurar la VPN se trabaja en el directorio /etc/wireguard de ambos servidores. Esta configuración es idéntica en ambos casos y se puede establecer de forma simultánea en los dos puntos de la red VPN.

El paquete wireguard incluye una serie de herramientas útiles para la configuración de la VPN. Estas herramientas se gestionan con el comando wg. Así, este comando permite generar las claves públicas y privadas de ambos servidores.

wg genkey > private
wg pubkey < private > pubkey

Configuración de los servidores

En ambos servidores hay que permitir el enrutamiento de paquetes. Para ello, en el fichero /etc/sysctl.conf se descomenta la siguiente línea:

net.ipv4.ip_forward = 1

Y después se aplican los cambios.

sysctl -p

Para configurar la VPN punto a punto entre dos servidores con WireGuard ambos deben contar con una interfaz virtual de tipo wg0. Esta interfaz se puede configurar con un fichero similar al que se ha usado en el punto anterior. En este caso, el fichero del servidor 1 cuenta con el siguiente contenido:

[Interface]
Address = 10.99.99.1
PrivateKey = KJYhzp43mrlBGsFh4KoqJzsUpjdDXG+yjwLvilJAqk8=
ListenPort = 51820

[Peer]
Publickey = TN0YObylxd6vXYCZW+flN71jr93Q/srs6PSYvunUJik=
AllowedIPs = 10.99.99.2/24,172.18.0.0/24
PersistentKeepAlive = 25
Endpoint = 192.168.122.106:51820

En la sección [Interface] del fichero se indica la IP de la interfaz, la clave privada del servidor y el puerto de escucha, en este caso, el 51820, el puerto de escucha por defecto de WireGuard. En la sección [Peer] se recoge la clave pública del servidor en el otro extremo de la VPN, las direcciones IP a las que se permite la conexión al servidor, la dirección IP por la que escucha el servidor VPN del otro extremo del túnel y el parámetro que determina el tiempo durante el cual el túnel se mantendrá activo sin tráfico. En este caso, en el parámetro AllowedIPs incluye la dirección IP de la red privada detrás del segundo servidor VPN con los que los clientes del primero se deben comunicar a través del túnel.

En el fichero del servidor 2 se establece una configuración simétrica a la del primero para permitir la conexión seguraa través del túnel VPN en sentido opuesto.

[Interface]
Address = 10.99.99.1
PrivateKey = iMjkgw+hKJcdbds9mDwCMesC0j18QfNiMvBzHucrfEs=
ListenPort = 51820

[Peer]
Publickey = Op5DIF4tSl+4vWcXcON21DDsHyr5J1P/zDSyyxPOpyU=
AllowedIPs = 10.99.99.2/24,172.19.0.0/24
PersistentKeepAlive = 25
Endpoint = 192.168.122.69:51820

Para levantar estas interfaces en sendos servidores se puede usar la utilidad wg-quick instalada con el paquete wireguard que permite crear y configurar las interfaces.

root@debian:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[ 2495.380857] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[ 2495.383299] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[#] wg setconf wg0 /dev/fd/63
Warning: AllowedIP has nonzero host part: 10.99.99.2/24
[#] ip -4 address add 10.99.99.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 172.18.0.0/24 dev wg0
[#] ip -4 route add 10.99.99.0/24 dev wg0

La ejecución de este comando añade la interfaz, establece su configuración, configura la dirección IP de la interfaz, estable su mtu y añade las rutas necesarias para dirigir el tráfico al otro extremo del túnel VPN.

El mismo comando en el servidor 2 realiza las mismas acciones.

root@debian:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[ 2453.286738] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[ 2453.288837] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[#] wg setconf wg0 /dev/fd/63
Warning: AllowedIP has nonzero host part: 10.99.99.2/24
[#] ip -4 address add 10.99.99.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 172.19.0.0/24 dev wg0
[#] ip -4 route add 10.99.99.0/24 dev wg0

Tras aplicar esta configuración en ambos servidores se crea la interfaz virtual wg0.

En el servidor 1:

4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.99.99.1/32 scope global wg0
       valid_lft forever preferred_lft forever

Y en el servidor 2:

4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.99.99.1/32 scope global wg0
       valid_lft forever preferred_lft forever

Además, en ambos servidores se crean las rutas necesarias para llegar a las redes privadas detrás de cada servidor en el extremo opuesto del túnel VPN.

En el servidor 1:

root@debian:/etc/wireguard# ip r
default via 192.168.122.1 dev ens4 
10.99.99.0/24 dev wg0 scope link 
172.18.0.0/24 dev wg0 scope link 
172.19.0.0/24 dev ens5 proto kernel scope link src 172.19.0.1 
192.168.122.0/24 dev ens4 proto kernel scope link src 192.168.122.69 

Y en el servidor 2:

root@debian:/etc/wireguard# ip r
default via 192.168.122.1 dev ens4 
10.99.99.0/24 dev wg0 scope link 
172.18.0.0/24 dev ens5 proto kernel scope link src 172.18.0.1 
172.19.0.0/24 dev wg0 scope link 
192.168.122.0/24 dev ens4 proto kernel scope link src 192.168.122.106 

Esta configuración permite crear un túnel VPN seguro entre ambos servidores, de manera que los equipos en cada una de las redes pueden comunicarse con cualquier equipo de la otra red. De esta forma, un equipo conectado a la red privada del servidor 1 puede comunicarse con uno de la red privada del servidor 2:

PC1> ping 172.18.0.2

84 bytes from 172.18.0.2 icmp_seq=1 ttl=62 time=2.400 ms
84 bytes from 172.18.0.2 icmp_seq=2 ttl=62 time=2.175 ms
84 bytes from 172.18.0.2 icmp_seq=3 ttl=62 time=1.252 ms
84 bytes from 172.18.0.2 icmp_seq=4 ttl=62 time=1.994 ms
84 bytes from 172.18.0.2 icmp_seq=5 ttl=62 time=1.597 ms

De la misma manera, un equipo de la red privada del servidor 2 se puede comunicar con uno de la red privada opuesta:

PC2> ping 172.19.0.2

84 bytes from 172.19.0.2 icmp_seq=1 ttl=62 time=1.166 ms
84 bytes from 172.19.0.2 icmp_seq=2 ttl=62 time=2.214 ms
84 bytes from 172.19.0.2 icmp_seq=3 ttl=62 time=1.361 ms
84 bytes from 172.19.0.2 icmp_seq=4 ttl=62 time=1.894 ms
84 bytes from 172.19.0.2 icmp_seq=5 ttl=62 time=1.329 ms

La captura de tráfico entre ambos servidores durante el ping del PC2 al PC1 muestra cómo el tráfico circula encriptado por la red. En este caso, se identifican los paquetes como protocolo WireGuard y, en el análisis del contenido de cada paquete se muestra el mensaje “paquete encriptado”. Aunque en la captura se muestra la IP real de origen y destino en el tramo capturado y no las IP virtuales de la VPN, el protocolo y encriptación del mensaje demuestra que está circulando a través de la VPN.