Un VPN WireGuard autoalojado da a tu portátil y a tu teléfono una ruta cifrada hacia un servidor que tú controlas. Resulta útil cuando quieres una IP de salida estable, acceso seguro en redes Wi-Fi no confiables o una ruta privada hacia otra red. No te vuelve anónimo: los sitios web siguen viendo una única dirección del VPS y el proveedor de hosting sigue operando la red subyacente.
Esta guía construye un VPN IPv4 de túnel completo en Ubuntu Server. Instalarás WireGuard, generarás claves con permisos restrictivos, habilitarás el enrutamiento, añadirás reglas de firewall y NAT, conectarás clientes de escritorio y móviles y verificarás el túnel. El mismo diseño puede admitir IPv6, pero solo después de que el VPS tenga espacio IPv6 enrutado y configures por separado el reenvío y las reglas de firewall IPv6.
¿Qué es WireGuard?
WireGuard es un protocolo VPN moderno y multiplataforma, junto con su implementación, que transporta paquetes IP cifrados sobre UDP. La especificación del protocolo WireGuard define un conjunto fijo de primitivas criptográficas, entre ellas ChaCha20-Poly1305, Curve25519, BLAKE2s, SipHash24 y HKDF. Ese diseño deliberadamente reducido hace que la configuración y la auditoría sean más sencillas que en protocolos con muchas suites de cifrado intercambiables.
WireGuard no tiene un sistema central de cuentas ni un directorio de usuarios integrado. Cada dispositivo es un par con su propio par de claves, su dirección de túnel y sus reglas AllowedIPs. En un VPS, un par suele actuar como la pasarela expuesta a internet, mientras que portátiles y teléfonos inician las conexiones hacia él.
¿Por qué usar WireGuard en un VPS?
- Modelo de pares sencillo: Cada dispositivo obtiene un par de claves y una entrada de par.
- Superficie de ataque reducida: WireGuard usa un protocolo compacto y una suite criptográfica fija, en lugar de exponer un largo menú de opciones heredadas.
- Buen rendimiento: La integración en el kernel de Linux y una criptografía eficiente pueden ofrecer un alto rendimiento, aunque el resultado sigue dependiendo de la CPU, la capacidad de red, la latencia y el tamaño de los paquetes.
- Clientes multiplataforma: Hay clientes oficiales para Windows 10 y 11, macOS, Android e iOS, mientras que Linux y varios sistemas BSD ofrecen herramientas o paquetes nativos.
- Itinerancia: Un par puede cambiar de red y de dirección IP de origen sin recibir una nueva identidad de WireGuard; el servidor aprende el último extremo autenticado.
- Control de enrutamiento claro: AllowedIPs determina tanto qué destinos usan el túnel como qué direcciones de túnel pertenecen a cada par.
Lectura relacionada: la guía de Cloudzy sobre VPS para VPN. Para despliegues más antiguos, consulta la guía de configuración de PPTP de Cloudzy; no elijas PPTP para un VPN nuevo en el que la seguridad importe.
Sáltate la instalación manual: WireGuard en un clic
Si no tienes formación técnica, o prefieres no encargarte tú mismo de la instalación, Cloudzy ofrece un despliegue de WireGuard VPN en un clic. El resto de esta guía cubre la instalación manual; esta sección cubre el atajo.
- Inicia sesión en el panel de control de Cloudzy.
- Selecciona WireGuard en la lista de aplicaciones.
- Crea un VPS en la ubicación que quieras con el plan que prefieras. Basta con una máquina Ubuntu de especificaciones básicas.
Cuando tu VPS esté listo, inicia sesión y ejecuta el siguiente comando para mostrar tu configuración:
cat client.confVerás algo como esto:
Usa esa configuración para crear un túnel nuevo en el cliente WireGuard de tu PC y la conexión quedará lista. Si prefieres entender cada pieza, o necesitas un montaje que la imagen de un clic no cubre, continúa con la instalación manual de abajo.
Cómo configurar WireGuard en Ubuntu
Los comandos siguientes están pensados para una versión actual de Ubuntu Server. Ejecútalos por SSH con un usuario que tenga sudo. Mantén la sesión SSH abierta hasta confirmar el firewall y haz antes una instantánea del VPS si tu proveedor lo permite.
Requisitos previos
- Un VPS Ubuntu con una dirección IPv4 pública
- Una cuenta que no sea root y tenga acceso sudo
- Acceso SSH y los datos de la consola de recuperación del proveedor del VPS
- Un dispositivo cliente con la aplicación oficial de WireGuard o las herramientas de línea de comandos
No necesitas un segundo servidor Ubuntu. El cliente puede ser un PC con Windows, un Mac, un portátil Linux, un teléfono Android o un iPhone.
Paso 1: instalar WireGuard
sudo apt update
sudo apt install wireguard -yComprueba que las herramientas están disponibles:
wg --versionPaso 2: generar las claves del servidor de forma segura
Crea el directorio de WireGuard y genera el par de claves con un umask restrictivo. La clave privada nunca debe copiarse a un cliente ni aparecer en registros.
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'Muestra las claves cuando necesites pegarlas en archivos de configuración:
sudo cat /etc/wireguard/server.key
sudo cat /etc/wireguard/server.pubPaso 3: crear la configuración del servidor
Abre la configuración de la interfaz:
sudo nano /etc/wireguard/wg0.confPega el siguiente bloque y sustituye SERVER_PRIVATE_KEY por la clave privada del paso anterior:
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEYLa red de túnel 10.8.0.0/24 es solo un ejemplo. Elige otro rango privado si se solapa con una red doméstica, de oficina o en la nube a la que necesites llegar. No añadas SaveConfig = true: puede reescribir el archivo al detenerse la interfaz y borrar los cambios hechos a mano.
sudo chmod 600 /etc/wireguard/wg0.confPaso 4: habilitar el reenvío IPv4
El VPS debe enrutar paquetes entre wg0 y su interfaz de red pública. Coloca ese ajuste en un archivo sysctl específico:
sudo nano /etc/sysctl.d/70-wireguard-routing.confnet.ipv4.ip_forward = 1Aplícalo y verifícalo:
sudo sysctl -p /etc/sysctl.d/70-wireguard-routing.conf
sysctl net.ipv4.ip_forwardEsto sigue el modelo de enrutamiento de la guía de pasarela WireGuard de Ubuntu. IPv6 necesita un prefijo IPv6 enrutado, direcciones de túnel separadas, reenvío IPv6 y reglas de firewall IPv6; no envíes el tráfico del cliente a ::/0 hasta que esa ruta esté completa.
Paso 5: añadir reglas de firewall y NAT
Averigua el nombre de la interfaz pública del VPS. En la salida de abajo, fíjate en el valor que sigue a dev; los nombres habituales son eth0, ens3 y enp1s0.
ip route show defaultVuelve a abrir wg0.conf y añade las siguientes líneas bajo [Interface]. Sustituye eth0 en todas partes si tu interfaz pública tiene otro nombre:
PostUp = iptables -I FORWARD 1 -i %i -o eth0 -j ACCEPT; iptables -I FORWARD 1 -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i %i -o eth0 -j ACCEPT; iptables -D FORWARD -i eth0 -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADESi UFW está activo, permite SSH antes de tocar su estado y luego abre el puerto UDP de WireGuard:
sudo ufw allow OpenSSH
sudo ufw allow 51820/udp
sudo ufw statusSi UFW está inactivo ahora mismo y quieres activarlo, comprueba antes que existe la regla de OpenSSH. No desactives y vuelvas a activar UFW por SSH solo para aplicar estas reglas: añade un riesgo de bloqueo que puedes evitar.
Paso 6: iniciar la interfaz de WireGuard
sudo systemctl enable --now wg-quick@wg0
sudo systemctl status wg-quick@wg0 --no-pager
sudo wg showSi el servicio falla, ejecuta journalctl antes de cambiar cualquier otra cosa:
sudo journalctl -u wg-quick@wg0 -n 50 --no-pagerAñadir un cliente de WireGuard
Cada dispositivo necesita un par de claves y una IP de túnel únicos. Nunca reutilices una misma configuración de cliente en dos dispositivos: las claves y direcciones duplicadas hacen que el enrutamiento sea impredecible e impiden una revocación limpia.
Paso 1: generar las claves del cliente
Las aplicaciones oficiales de escritorio y móvil pueden generar las claves cuando creas un túnel vacío. En un cliente Linux, usa:
umask 077
wg genkey | tee client.key | wg pubkey > client.pubMantén client.key en ese dispositivo. Copia solo client.pub al servidor.
Paso 2: añadir el par en el servidor
sudo nano /etc/wireguard/wg0.confAñade un bloque de par. Sustituye CLIENT_PUBLIC_KEY por la clave pública del cliente:
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32La línea Address = 10.8.0.2/32 asigna la dirección de túnel en el cliente. En el bloque [Peer] del servidor, AllowedIPs = 10.8.0.2/32 asocia esa dirección con este par para el enrutamiento y la validación de origen. Usa 10.8.0.3/32 para el siguiente dispositivo y continúa hacia arriba sin duplicados.
sudo systemctl restart wg-quick@wg0Paso 3: crear la configuración del cliente
Crea client.conf en el cliente y sustituye todos los marcadores de posición:
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.8.0.2/32
DNS = 1.1.1.1
[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = VPS_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25AllowedIPs = 0.0.0.0/0 convierte esto en un túnel completo IPv4. Para acceder solo a la red VPN, usa AllowedIPs = 10.8.0.0/24. PersistentKeepalive es útil para un cliente tras un NAT que necesita que su asignación siga accesible mientras está inactivo; la guía de inicio rápido de WireGuard señala que la mayoría de los pares no lo necesitan.
Paso 4: importar la configuración
Usa la sección guía de instalación de clientes de WireGuard para conseguir el cliente compatible con tu plataforma.
- Windows: Elige Add Tunnel y luego importa client.conf.
- macOS: Elige Import tunnel(s) from file y selecciona client.conf.
- Android o iOS: Importa el archivo o escanea un código QR generado a partir de él.
En un cliente Ubuntu o Debian que tenga client.conf, instala qrencode y muestra el archivo en la terminal de ese cliente:
sudo apt install qrencode -y
qrencode -t ansiutf8 < client.confEl código QR contiene la clave privada del cliente. Muéstralo solo en una terminal de confianza, no guardes capturas de pantalla y limpia la terminal después de que el teléfono lo importe.
Paso 5: verificar el túnel
Activa el túnel, genera tráfico desde el cliente y ejecuta estas comprobaciones en el VPS:
sudo wg show
ip -brief address show wg0Un handshake reciente y unos contadores de transferencia que aumentan confirman que WireGuard está intercambiando paquetes. Después, verifica la salida en túnel completo desde el cliente:
curl -4 https://api.ipify.org; echoEl comando debería devolver la dirección IPv4 pública del VPS. Si no hay handshake, revisa la dirección del endpoint, el puerto UDP, el firewall de la nube, la regla de UFW y las claves. Si hay handshake pero no hay acceso a internet, revisa el reenvío IP, el nombre de la interfaz pública, las reglas de NAT y el DNS.
¿Se puede poner WireGuard detrás de Nginx?
El documentación del módulo stream de NGINX explica cómo NGINX puede retransmitir UDP de un puerto a otro, así que puede reenviar UDP/80 o UDP/443 a WireGuard en UDP/51820. Eso es un relé UDP, no un proxy inverso HTTP. No convierte WireGuard en TCP ni en HTTPS, y no hace que el protocolo parezca tráfico web normal.
Para la mayoría de los despliegues, cambiar el ListenPort de WireGuard y abrir el puerto UDP correspondiente es más sencillo que añadir NGINX. Si una red bloquea el UDP por completo o usa inspección profunda de paquetes, un relé UDP de NGINX no resolverá el problema. La documentación de limitaciones de WireGuard afirma que la ofuscación queda fuera del alcance del protocolo.
Conectar el VPS a una red doméstica
Un VPS puede actuar como concentrador entre un cliente itinerante y un dispositivo de tu casa. El par del lado doméstico inicia una conexión WireGuard saliente hacia el VPS, lo que evita necesitar una IP pública en casa. Configura PersistentKeepalive en ese par doméstico cuando esté detrás de un NAT.
Llegar a toda la LAN doméstica requiere algo más que añadir un par. La entrada de par del VPS correspondiente a la pasarela doméstica debe incluir la subred de casa en AllowedIPs, por ejemplo 192.168.1.0/24. Un cliente remoto con túnel completo (AllowedIPs = 0.0.0.0/0) ya envía ese tráfico por el VPS; añade 192.168.1.0/24 en el cliente solo si usas túnel dividido. La pasarela doméstica también debe reenviar tráfico entre WireGuard y la LAN. Añade una ruta en el router de casa o una regla de NAT bien acotada en la pasarela doméstica. Comprueba antes los solapamientos: un cliente conectado a otra red 192.168.1.0/24 no puede enrutar ambas redes limpiamente sin renumerar o recurrir a enrutamiento por políticas más avanzado.
WireGuard autoalojado frente a un VPN comercial
Autoalojar cambia quién opera el VPN, pero no mejora automáticamente el anonimato. Un VPS personal te da una IP de salida estable, fácil de asociar con una red de hosting. Un servicio comercial suele darte direcciones de salida compartidas y cambio de ubicación sencillo, pero tienes que confiar en sus políticas, su operación y las auditorías independientes que publique.
WireGuard en sí es ligero, y un VPS pequeño suele ser un punto de partida razonable para una persona y unos pocos dispositivos. No tomes una cifra fija de RAM o vCPU como garantía de rendimiento. Prueba con tu número real de dispositivos, tu región, el tamaño de paquete y el ancho de banda previsto, y luego redimensiona si la saturación de CPU, la pérdida de paquetes o la latencia se convierten en el límite.
Elige el autoalojamiento cuando una IP de salida personal estable, el acceso remoto o el control del servidor importen más que poder elegir ubicación y la comodidad. Elige un VPN comercial cuando quieras muchos países, salidas compartidas, amplia compatibilidad con dispositivos de consumo y que sea otro quien se ocupe de las averías.
| Factor de decisión | WireGuard autoalojado | VPN comercial |
|---|---|---|
| Modelo de coste | Un servidor más tu tiempo de administración | Suscripción, a menudo con descuento en plazos largos |
| Ubicaciones de salida | Una ubicación por servidor | Muchas ubicaciones disponibles en la aplicación |
| Instalación | Tú configuras claves, enrutamiento, reglas de firewall y clientes | Instalar la aplicación e iniciar sesión |
| Mantenimiento | Tú parcheas, supervisas, haces copias de seguridad y resuelves problemas | El proveedor opera el servicio |
| Modelo de privacidad | Tú controlas el servidor, pero el proveedor de hosting aún puede observar metadatos | Dependes de las políticas del proveedor y de las auditorías independientes que publique |
| Ideal para | IP de salida personal estable, acceso remoto y control de la infraestructura | Cambio de ubicación, poco mantenimiento y amplia compatibilidad con dispositivos |
Conclusión
Un despliegue fiable de WireGuard se reduce a cinco cosas: claves privadas protegidas, direcciones de par únicas, AllowedIPs correctos, reenvío y NAT que funcionen, y una regla de firewall para el puerto UDP de escucha. Verifica tanto el handshake como la dirección pública de salida antes de confiar en el túnel, y mantén el VPS parcheado después del despliegue.
Si quieres construir el servidor manualmente, empieza con un Solución Cloudzy Ubuntu VPS. Si prefieres saltarte los pasos de instalación, usa el despliegue de WireGuard en un clic de Cloudzy y pasa directamente a la configuración y verificación del cliente.
Preguntas frecuentes
¿Por qué WireGuard muestra un par pero ningún handshake?
Una entrada de par solo demuestra que la configuración se cargó. La ausencia de handshake suele significar que el cliente no llega al servidor o que las claves no coinciden. Revisa el Endpoint del cliente, la IP pública del servidor, el puerto UDP/51820 tanto en el firewall del proveedor como en UFW, y las claves públicas de ambos lados. Genera tráfico desde el cliente antes de comprobarlo, porque WireGuard permanece en silencio cuando está inactivo.
¿Por qué el túnel se conecta pero se corta el acceso a internet?
Un handshake sin acceso a internet suele apuntar al enrutamiento más que al cifrado. Verifica net.ipv4.ip_forward, confirma el nombre de la interfaz pública en la regla de NAT, revisa las reglas FORWARD y prueba el DNS por separado de la conectividad IP en bruto. Asegúrate también de que los AllowedIPs del cliente coinciden con el diseño de túnel completo o dividido que buscabas.
¿Todos los clientes necesitan PersistentKeepalive?
No. Añádelo cuando un par tras un NAT necesite mantener su asignación abierta durante los periodos de inactividad, algo habitual en teléfonos, pasarelas domésticas y algunas redes restrictivas. Omítelo cuando el par se comunique con frecuencia o no necesite que el otro extremo lo alcance mientras está inactivo.
