Cómo instalar un servidor VPN WireGuard en Linux (Ubuntu, guía paso a paso 2026)

Montar tu propio servidor WireGuard en un VPS Linux barato te da un túnel cifrado privado, bajo tu control total, por unos pocos dólares al mes. No sustituye al grupo de IP ni al desbloqueo de streaming de un VPN comercial, pero para asegurar tu propio tráfico en Wi-Fi público o acceder a tu red doméstica en remoto, es una opción realmente sólida. Aquí va la instalación completa en Ubuntu.

Lo que necesitas antes de empezar

Un VPS con Ubuntu 22.04 o 24.04 (cualquier proveedor económico sirve: el plan más barato es suficiente para uso personal de WireGuard), acceso root o sudo por SSH, y unos quince minutos. Los mismos pasos funcionan con pequeños ajustes en Debian.

¿Quieres comparar todos los VPN uno al lado del otro? Consulta nuestra tabla comparativa completa con puntuaciones en 18 criterios.

Paso 1: actualizar el sistema e instalar WireGuard

Conéctate por SSH a tu VPS y ejecuta:

sudo apt update && sudo apt upgrade -y
sudo apt install wireguard qrencode -y

qrencode no es necesario para WireGuard en sí, pero permite generar un código QR para escanearlo directamente en la app móvil más adelante, así evitas copiar claves a mano en el teléfono.

Paso 2: generar el par de claves del servidor

cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key

umask 077 importa aquí: garantiza que los archivos de claves no sean legibles por otros usuarios del sistema. Conserva ambos archivos; la clave privada se referenciará en la configuración del servidor, y la clave pública no se entrega a nadie (se queda en el servidor).

Paso 3: crear la configuración del servidor

Crea /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <pega aquí el contenido de server_private.key>
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = false

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Sustituye eth0 por el nombre real de la interfaz de red pública de tu VPS si es distinto (compruébalo con ip a). Las líneas PostUp/PostDown son las que permiten que el tráfico de los clientes conectados salga por la IP pública del servidor; sin ellas tendrías un túnel funcional que no lleva a ninguna parte.

Paso 4: activar el reenvío de IP

WireGuard necesita que el núcleo reenvíe paquetes entre interfaces:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Salta este paso y los clientes se conectarán pero no podrán llegar a internet a través del túnel, uno de los fallos más habituales al configurar WireGuard.

Paso 5: abrir el puerto en el cortafuegos

Con UFW:

sudo ufw allow 51820/udp
sudo ufw allow OpenSSH
sudo ufw enable

Revisa también el panel de tu proveedor de VPS por si hay un cortafuegos en la nube o un grupo de seguridad aparte; algunos proveedores bloquean puertos a nivel de red al margen de lo que permita UFW en la propia instancia, y es un paso fácil de pasar por alto cuando una conexión falla en silencio más adelante.

Paso 6: generar un par de claves para el cliente y añadir el peer

En el servidor, genera un par de claves para tu primer dispositivo cliente:

wg genkey | tee client1_private.key | wg pubkey > client1_public.key

Añade el cliente como peer al final de /etc/wireguard/wg0.conf:

[Peer]
PublicKey = <pega aquí el contenido de client1_public.key>
AllowedIPs = 10.8.0.2/32

Paso 7: arrancar el servidor

sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0

Confirma que está activo y en marcha antes de seguir. Si no arranca, revisa el nombre de interfaz del paso 3 y la sintaxis del archivo de configuración; una sola línea mal colocada suele ser la causa.

Paso 8: crear la configuración del cliente

En tu dispositivo (o en un archivo de texto que transferirás de forma segura), crea una configuración con la clave privada del cliente del paso 6:

[Interface]
PrivateKey = <contenido de client1_private.key>
Address = 10.8.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <contenido de server_public.key>
Endpoint = <IP pública de tu VPS>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0 enruta todo el tráfico del cliente a través del túnel, el comportamiento estándar de un VPN completo. Si solo quieres llegar a tu red doméstica o VPS sin enrutar todo el tráfico de internet, limita este campo a esa subred concreta.

Para móvil, genera un código QR a partir de esta configuración y escanéalo directamente en la app de WireGuard:

qrencode -t ansiutf8 < client1.conf

Paso 9: probar la conexión

Activa el túnel en el cliente y comprueba tu IP pública (una búsqueda rápida de «cuál es mi IP» o un curl ifconfig.me desde el cliente) para confirmar que ahora muestra la dirección de tu VPS, no la original. Comprueba también que la resolución DNS no se filtra fuera del túnel.

Añadir más dispositivos

Repite los pasos 6 a 8 para cada dispositivo adicional, usando una dirección 10.8.0.x nueva para cada uno (.3, .4 y así sucesivamente) y un par de claves nuevo por dispositivo. Nunca reutilices una clave privada en varios dispositivos: si uno se ve comprometido, una clave compartida compromete a todos los demás.

Reforzar la configuración

Una instalación estándar de WireGuard ya es razonablemente segura por sí sola, el propio protocolo tiene una base de código pequeña y bien auditada, pero unos pasos extra cierran vías de ataque habituales en el VPS que lo aloja.

Cambia el puerto SSH por defecto y desactiva la autenticación por contraseña. WireGuard protege el túnel, no el servicio SSH que usaste para montarlo todo. Cambia a un inicio de sesión SSH por clave y plantéate salir del puerto 22 para reducir el ruido de escaneos automatizados.

Instala fail2ban. sudo apt install fail2ban banea de forma automática y temporal las IP tras intentos fallidos repetidos de inicio de sesión SSH, una capa de protección barata en un VPS expuesto públicamente.

Mantén el sistema parcheado. Ejecuta sudo apt update && sudo apt upgrade -y con regularidad, o activa unattended-upgrades para los parches de seguridad. Un servidor autoalojado solo es tan seguro como su dependencia peor parcheada.

Restringe AllowedIPs por peer cuando puedas. Si un dispositivo solo necesita llegar a tu red doméstica en vez de a todo internet, limita su AllowedIPs a esa subred en vez de 0.0.0.0/0. Un acceso más restringido limita lo que un dispositivo comprometido podría alcanzar a través del túnel.

Problemas frecuentes y soluciones

El handshake falla, no hay conexión en absoluto: casi siempre es un problema de cortafuegos, ya sea UFW en el propio VPS o un grupo de seguridad en la nube aparte que bloquea el UDP 51820. Revisa ambos, se configuran en sitios distintos y es fácil arreglar uno y olvidar el otro.

Se conecta pero no hay acceso a internet a través del túnel: es el paso de reenvío de IP visto antes. Confirma que net.ipv4.ip_forward está realmente en 1 y que las reglas NAT PostUp/PostDown referencian el nombre real de tu interfaz pública, no un marcador de posición olvidado al copiar la configuración.

Funciona en Wi-Fi pero falla con datos móviles: algunos operadores móviles bloquean o limitan puertos UDP no estándar. Si ocurre de forma constante, cambiar ListenPort en la configuración del servidor a un puerto común como el 443 (y actualizar la configuración del cliente en consecuencia) suele resolverlo, ya que el filtrado a nivel de operador rara vez toca un puerto que también transporta tráfico HTTPS normal.

Lo que el autoalojamiento no te da

Esta configuración cifra y enruta tu tráfico a través de un servidor que tú controlas, algo realmente valioso para asegurar el Wi-Fi de un hotel o un aeropuerto y para llegar a tu red doméstica en remoto. Lo que no te da es un gran grupo de IP para desbloquear streaming, ya que siempre sales por la misma IP única de tu VPS, ni la negación plausible que ofrece compartir una dirección IP con miles de otros usuarios como hacen los servidores compartidos de un VPN comercial. Una IP dedicada única también es más fácil de detectar y poner en lista negra con el tiempo por parte de los servicios que un grupo que rota con frecuencia en un proveedor comercial.

Si tu objetivo es el acceso a streaming, la flexibilidad geográfica, o mezclarte con una base de usuarios amplia en vez de controlar tu propia infraestructura, un VPN comercial sigue siendo la mejor herramienta para ese trabajo concreto; un servidor WireGuard autoalojado y un VPN comercial resuelven problemas distintos y se complementan más que competir.

Sigue leyendo

Para una instalación autoalojada similar en hardware más barato, ver Instalar un servidor VPN WireGuard en Raspberry Pi con PiVPN. Para hacer funcionar WireGuard en tu router doméstico en vez de un VPS, lee Cómo instalar un VPN en un router OpenWrt. Y si aún dudas entre protocolos, ver Protocolos VPN explicados 2026: WireGuard, OpenVPN, IKEv2 comparados.