Cómo desplegar un servidor VPN WireGuard en Ubuntu con UFW y Split Tunneling

Gestionar servidores de producción mediante puertos SSH o consolas web expuestas directamente a direcciones IP públicas representa un vector de ataque que ningún equipo de operaciones debe asumir.

Frente a tecnologías tradicionales como OpenVPN, el protocolo WireGuard opera como un módulo integrado en el propio kernel de Linux, eliminando sobrecargas de procesamiento y ofreciendo un rendimiento cercano a la velocidad física del enlace. Implementar un concentrador VPN bajo esta tecnología permite crear un perímetro de acceso seguro para administrar clústeres hiperconvergentes como los documentados en nuestra Guía de virtualización en Proxmox VE 8 y proteger el flujo de eventos hacia nuestra plataforma SIEM con Wazuh sin publicar servicios críticos a Internet.

// EJECUCIÓN RÁPIDA (TL;DR) – RESUMEN DE DESPLIEGUE

# 1. Preparar paquetes y habilitar forwarding en el sistema operativo:

sudo apt update && sudo apt install wireguard qrencode -y
sudo sysctl -w net.ipv4.ip_forward=1

# 2. Generar pares criptográficos para servidor y primer cliente:

wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee client.key | wg pubkey > client.pub

# 3. Arrancar servicio tras redactar configuraciones:

sudo systemctl enable --now wg-quick@wg0

1. Activación de Enrutamiento en el Kernel y Políticas UFW

Para que el sistema Ubuntu funcione como pasarela entre los clientes remotos y los recursos de red internos, debemos autorizar el reenvío de paquetes IPv4 de forma permanente.

Configurar el parámetro sysctl

Crea un archivo de configuración modular para evitar sobreescrituras en futuras actualizaciones del kernel:

echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/60-wireguard-forward.conf
sudo sysctl -p /etc/sysctl.d/60-wireguard-forward.conf

Ajustar la política de reenvío por defecto en UFW

Edita el archivo /etc/default/ufw y localiza la directiva DEFAULT_FORWARD_POLICY. Cambia su valor de DROP a ACCEPT para permitir que el cortafuegos encamine el tráfico entre la interfaz del túnel y la tarjeta de red física.

2. Estructura de Configuración del Servidor (‘wg0.conf’)

Crea el archivo principal del servicio en la ruta /etc/wireguard/wg0.conf asegurando que solo el usuario root tenga permisos de lectura (chmod 600):

[Interface]
Address = 10.88.0.1/24
ListenPort = 51820
PrivateKey = <INSERTAR_CONTENIDO_DE_SERVER.KEY>
SaveConfig = false

# Definición del primer cliente remoto (Peer)
[Peer]
PublicKey = <INSERTAR_CONTENIDO_DE_CLIENT.PUB>
AllowedIPs = 10.88.0.2/32

Para automatizar las tablas de traducción de direcciones (NAT) sin saturar la configuración básica, podemos añadir ganchos de ejecución con el cortafuegos. Suponiendo que tu interfaz física hacia Internet se llama eth0:

PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = ufw route delete allow in on wg0 out on eth0
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

3. Implementación de Split Tunneling en Clientes Remotos

Una de las mayores ventajas en entornos de ingeniería es el Split Tunneling (Túnel Dividido). Esta técnica evita canalizar todo el tráfico del usuario (como navegación web externa o streaming) a través de la VPN, limitando el túnel exclusivamente a las subredes de servidores corporativos.

Fichero de configuración para el cliente (‘client.conf’)

[Interface]
PrivateKey = <INSERTAR_CONTENIDO_DE_CLIENT.KEY>
Address = 10.88.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = <INSERTAR_CONTENIDO_DE_SERVER.PUB>
Endpoint = vpn.tudominio.com:51820

# SPLIT TUNNELING: Solo viaja por la VPN la red del túnel y la red de servidores
AllowedIPs = 10.88.0.0/24, 192.168.10.0/24

# Nota: Si quisieras canalizar absolutamente todo el tráfico de Internet,
# configurarías: AllowedIPs = 0.0.0.0/0

Para distribuir la configuración de forma rápida a dispositivos móviles o técnicos de campo, genera un código QR visualizable en la consola:

qrencode -t ansiutf8 < client.conf

4. Verificación de Estado y Diagnóstico de Tráfico

Una vez iniciado el servicio con systemctl start wg-quick@wg0, puedes auditar las sesiones activas mediante la utilidad nativa:

sudo wg show

La salida te informará del último apretón de manos completado (latest handshake) y la cantidad de bytes transferidos en ambas direcciones. Si el handshake se produjo hace menos de 2 minutos, la comunicación criptográfica es completamente operativa.

Integración con la Seguridad del Ecosistema

El uso de WireGuard como perímetro defensivo previene intentos de intrusión que habitualmente desencadenan bloqueos de autenticación en entornos corporativos de directorio activo, tales como el error 1722 del Servidor RPC en Windows Server. Asimismo, centralizar el acceso tras una red privada facilita el mantenimiento de tus bases de datos críticas, permitiendo recuperaciones transaccionales mediante nuestra guía para reparar bases de datos MySQL InnoDB corruptas sin exponer los puertos SQL a redes externas.

Preguntas Frecuentes

¿Por qué el cliente se conecta pero no puede alcanzar los servidores internos?

Comprueba que la máquina destino dentro de tu red local sepa cómo responder a la subred de la VPN (10.88.0.0/24). Si la regla de MASQUERADE en iptables está activa, el tráfico llegará con la IP local del servidor VPN, resolviendo este problema de enrutamiento asimétrico.

¿Qué puerto se debe abrir en el router o cortafuegos perimetral?

Únicamente es necesario redirigir el puerto UDP 51820 hacia la dirección IP privada del servidor Ubuntu que aloja el servicio WireGuard.


Manual técnico de seguridad perimetral y redes privadas elaborado por Gustavo Dulcey, Ingeniero de Sistemas especializado en Ciberseguridad y Administración de Infraestructura Linux.

Deja un comentario