Cómo instalar WireGuard y crear tu propia VPN

Instalar y generar claves

sudo apt update
sudo apt install -y wireguard
umask 077
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee client.key | wg pubkey > client.pub

No publiques los archivos .key. Copia cada privada solo al equipo que corresponde.

Configurar el servidor

Crea /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = CLAVE_PRIVADA_SERVIDOR

[Peer]
PublicKey = CLAVE_PUBLICA_CLIENTE
AllowedIPs = 10.8.0.2/32

Activa reenvío en /etc/sysctl.d/99-wireguard.conf con net.ipv4.ip_forward=1 y aplica sudo sysctl --system.

Firewall y NAT

Permite 51820/UDP y crea NAT hacia la interfaz pública. Su nombre puede ser ens3, eth0 u otro; obténlo con ip route. No copies una interfaz inexistente.

Inicia el túnel:

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

Configurar el cliente

[Interface]
Address = 10.8.0.2/24
PrivateKey = CLAVE_PRIVADA_CLIENTE
DNS = 1.1.1.1

[Peer]
PublicKey = CLAVE_PUBLICA_SERVIDOR
Endpoint = IP_DEL_VPS:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Para acceder solo a servicios privados cambia AllowedIPs por las subredes necesarias. Enruta todo únicamente si quieres que la navegación salga por el VPS.

Diagnóstico

sudo wg show debe enseñar un handshake reciente y bytes transferidos. Si no existe, revisa IP, UDP, firewall y claves. Si hay handshake pero no navegas, revisa forwarding, NAT y DNS.

Una VPN no reemplaza HTTPS, parches ni autenticación. Integra WireGuard con el checklist de seguridad. Un VPS KVM de Terranode ofrece el control de red necesario.

Diseñar las direcciones antes de generar claves

Una VPN estable empieza con un plan de direcciones que no choque con las redes donde se conectarán los usuarios. Si la oficina ya usa 10.8.0.0/24, escoger la misma subred para WireGuard vuelve ambiguas las rutas. Elige un rango privado libre y asigna una dirección única a cada peer.

Un inventario simple puede ser:

La máscara /32 en cada peer del servidor indica exactamente qué dirección puede atribuirse ese dispositivo. No asignes 10.77.0.0/24 a todos: las rutas se solapan y un peer podría representar direcciones ajenas.

Obtén el nombre de la interfaz pública y conserva el resultado para las reglas NAT:

ip -br address
ip route show default

No supongas que se llama eth0; en VPS actuales puede ser ens3, enp1s0 u otro nombre.

Generar un par de claves por dispositivo

La clave privada nunca debe salir del equipo que representa, siempre que puedas generarla allí. En el servidor crea su par con permisos restrictivos:

sudo install -d -m 700 /etc/wireguard/keys
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/keys/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/keys/server.key > /etc/wireguard/keys/server.pub'
sudo ls -l /etc/wireguard/keys

En un cliente Linux genera otro par:

umask 077
wg genkey > client-ana.key
wg pubkey < client-ana.key > client-ana.pub

La pública puede enviarse al administrador. La privada de Ana permanece en su portátil. Si generas todas las privadas en el servidor por comodidad, tendrás que transferirlas de forma segura y borrar las copias; eso aumenta la cantidad de lugares desde los que podrían filtrarse.

Comprueba permisos sin imprimir secretos:

stat -c '%a %U:%G %n' /etc/wireguard/keys/server.key

El modo esperado es 600 o más restrictivo y el propietario debe ser root.

Construir wg0.conf sin exponer la clave en el historial

La configuración del servidor combina su dirección, puerto, privada y peers autorizados. Puedes insertar la clave desde un archivo al crear la configuración, evitando escribirla como argumento del shell:

[Interface]
Address = 10.77.0.1/24
ListenPort = 51820
PrivateKey = CLAVE_PRIVADA_DEL_SERVIDOR

[Peer]
# Portátil de Ana
PublicKey = CLAVE_PUBLICA_ANA
AllowedIPs = 10.77.0.2/32

Guarda el archivo con permisos correctos:

sudo chmod 600 /etc/wireguard/wg0.conf
sudo wg-quick strip wg0

wg-quick strip permite detectar varios errores de sintaxis sin iniciar la interfaz. Evita incluir comillas alrededor de claves y no pongas la clave pública del servidor en PrivateKey.

La configuración no necesita una sección peer para sí misma. Cada cliente obtiene como PublicKey del peer la pública del servidor y como PrivateKey su propia privada.

Activar el reenvío de paquetes

El handshake puede funcionar sin forwarding, pero el servidor no trasladará tráfico entre el túnel y otras interfaces. Crea una configuración persistente del kernel:

sudo tee /etc/sysctl.d/99-wireguard-forward.conf > /dev/null <<'EOF'
net.ipv4.ip_forward=1
EOF
sudo sysctl --system
sysctl net.ipv4.ip_forward

La salida debe terminar en = 1. Si también enrutarás IPv6, necesitas un plan de prefijos y la opción correspondiente; no actives IPv6 a medias y asumas que seguirá el NAT de IPv4.

Forwarding permite que el kernel rote, pero el firewall aún debe decidir qué rutas acepta. Restringe lo que cada peer necesita en lugar de permitir toda comunicación lateral entre clientes.

Añadir NAT y reglas de firewall de forma explícita

Para que un cliente use el VPS como salida a internet, la red del túnel necesita masquerade hacia la interfaz pública. Con UFW puedes habilitar el puerto y añadir una regla de reenvío, pero la configuración exacta depende de cómo administres el firewall. Con nftables, una base explícita es:

table inet wireguard_filter {
    chain forward {
        type filter hook forward priority filter; policy drop;
        iifname "wg0" oifname "ens3" accept
        iifname "ens3" oifname "wg0" ct state established,related accept
    }
}

table ip wireguard_nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 10.77.0.0/24 oifname "ens3" masquerade
    }
}

Sustituye ens3 por la interfaz real. Integra estas reglas en el mecanismo persistente de tu distribución en lugar de pegar otro conjunto que compita con UFW o Firewalld. Antes de aplicar un firewall remoto, conserva una sesión SSH y acceso a consola.

El puerto de escucha sí debe llegar al host:

sudo ufw allow 51820/udp
sudo ufw status numbered

Si usas nftables directamente, no administres simultáneamente las mismas cadenas con UFW. Elige una fuente de verdad y documenta dónde persisten las reglas.

Configurar el cliente para túnel dividido

Un túnel dividido envía solo las redes privadas por WireGuard y deja la navegación habitual por la conexión local. Es una buena primera prueba porque reduce variables:

[Interface]
Address = 10.77.0.2/32
PrivateKey = CLAVE_PRIVADA_ANA

[Peer]
PublicKey = CLAVE_PUBLICA_SERVIDOR
Endpoint = vpn.ejemplo.com:51820
AllowedIPs = 10.77.0.0/24
PersistentKeepalive = 25

PersistentKeepalive ayuda cuando el cliente está detrás de NAT y necesita mantener el mapeo, pero no es obligatorio para peers con conectividad directa. El servidor no necesita configurarlo para clientes que inician el tráfico.

Levanta el cliente y prueba primero la IP del servidor en el túnel:

sudo wg-quick up wg0
ping -c 3 10.77.0.1
sudo wg show
ip route

Si necesitas acceder a otra red detrás del servidor, añade esa subred a AllowedIPs del cliente y una ruta de retorno en la red remota. NAT puede ocultar el origen, pero una ruta explícita conserva visibilidad y suele ser preferible en redes administradas.

Convertirlo en túnel completo

El túnel completo cambia la ruta predeterminada para que la navegación salga por el VPS. En el cliente usa:

AllowedIPs = 0.0.0.0/0
DNS = 1.1.1.1

Si el dispositivo tiene IPv6 activo, incluir solo IPv4 permite que tráfico IPv6 siga saliendo localmente. Puedes añadir ::/0 únicamente si el servidor está configurado para enrutar IPv6 de extremo a extremo; de lo contrario, desactiva ese alcance o diseña la salida IPv6 correctamente.

Comprueba la IP antes y después:

curl -4 https://ifconfig.me
dig example.com

Una IP de salida correcta con nombres que no resuelven apunta a DNS, no al túnel básico. Si no responde ni una dirección IP pública, revisa forwarding y NAT.

El VPS verá destinos y metadatos de tráfico, aunque HTTPS mantenga cifrado el contenido entre el cliente y el sitio. WireGuard no proporciona anonimato absoluto ni filtra malware; es un canal privado y una herramienta de enrutamiento.

Añadir más clientes sin reutilizar identidades

Cada dispositivo recibe una clave y un /32 propios. Añade un bloque al servidor:

[Peer]
# Teléfono de Ana
PublicKey = CLAVE_PUBLICA_TELEFONO
AllowedIPs = 10.77.0.3/32

Aplica cambios sin bajar la interfaz si editaste con cuidado:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show

La sustitución de proceso <(...) requiere Bash. Si tu shell no la admite, reinicia la interfaz durante una ventana controlada. Para configuraciones pequeñas también puedes usar wg set, pero después debes persistir el peer en el archivo; de lo contrario desaparecerá al reiniciar.

Etiqueta cada peer con un comentario y mantén un inventario de responsable, dispositivo, dirección y fecha de revocación. No puedes identificar una pública perdida por el nombre del portátil si nunca lo documentaste.

Limitar qué recursos alcanza cada peer

AllowedIPs funciona como ruta y como control de identidad de origen, pero no reemplaza un firewall entre servicios. En el cliente decide qué destinos entran al túnel; en el servidor, el /32 asocia una dirección al peer. Después usa reglas de forwarding para permitir solo lo necesario.

Por ejemplo, soporte puede necesitar SSH a 10.20.0.10 pero no acceso a toda la red. Añade esa ruta al cliente y una regla que autorice únicamente el puerto 22 desde 10.77.0.4. Así la revocación de su peer corta una identidad individual.

No permitas comunicación cliente a cliente por defecto si no existe un caso. Una VPN plana puede convertir un portátil comprometido en puerta hacia todos los demás dispositivos.

Diagnosticar sin cambiar cinco cosas a la vez

El momento del último handshake divide el diagnóstico entre conectividad criptográfica y enrutamiento. En el servidor:

sudo wg show
sudo ss -lunp | grep 51820
ip address show wg0
sudo journalctl -u wg-quick@wg0 --since '15 minutes ago'

Captura únicamente metadatos necesarios y evita publicar configuraciones con privadas:

sudo tcpdump -ni any udp port 51820
sudo nft list ruleset

Resolver problemas de MTU

Si el handshake funciona y algunas páginas se quedan cargando, el tamaño de paquete puede superar lo que admite el camino. Túneles adicionales, PPPoE o redes móviles reducen el MTU disponible. Prueba temporalmente un valor menor en ambos extremos:

[Interface]
MTU = 1380

No empieces con valores extremadamente bajos. Cambia uno, repite la misma descarga y observa. Un problema de DNS puede parecer similar, por lo que conviene probar una IP y un nombre por separado.

Revocar o rotar una clave

Revocar un dispositivo consiste en eliminar su peer del servidor; cambiar una contraseña en otra parte no invalida WireGuard. Edita wg0.conf, aplica la configuración y confirma que la pública ya no aparece:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show

Para rotar, genera un par nuevo en el cliente, sustituye su pública en el servidor y actualiza la configuración del dispositivo. Durante un cambio coordinado puedes reservar otra dirección temporal, pero no mantengas dos claves indefinidamente sin saber cuál se usa.

Respalda /etc/wireguard cifrado y con permisos restrictivos. La copia contiene la privada del servidor y debe tratarse como una credencial crítica. La restauración también requiere sysctl, firewall y DNS; guardar solo wg0.conf no reconstruye la VPN completa.

Verificar que la VPN vuelve tras reiniciar

La prueba final incluye un reinicio del servicio y, durante una ventana autorizada, del VPS. Comprueba habilitación y estado:

sudo systemctl enable wg-quick@wg0
sudo systemctl restart wg-quick@wg0
systemctl is-enabled wg-quick@wg0
systemctl is-active wg-quick@wg0
sudo wg show

Después prueba desde un cliente una dirección del túnel, un recurso autorizado y un recurso que deba permanecer bloqueado. La prueba negativa confirma que la VPN no abrió más de lo planeado.

Resolver DNS sin crear fugas o bloqueos

La directiva DNS del cliente decide qué resolvedor utilizar mientras el túnel está activo, pero el comportamiento exacto depende del sistema operativo. En túnel completo puedes usar un resolvedor público o uno administrado accesible desde el VPS. Para nombres internos, configura un servidor que conozca esa zona y asegúrate de incluir su dirección en las rutas.

Prueba por capas:

ping -c 2 10.77.0.1
ping -c 2 1.1.1.1
dig @1.1.1.1 example.com
dig example.com

Si la primera prueba falla, el problema está en el túnel. Si llega a una IP pública pero dig no resuelve, enfócate en DNS. Si resuelve y el navegador falla solo en algunos sitios, revisa MTU e IPv6.

En un túnel dividido corporativo, quizá solo quieras que empresa.internal use DNS interno y el resto conserve el resolvedor local. Esa resolución dividida necesita soporte del cliente o configuración del sistema; poner un DNS global puede enviar todas las consultas a la empresa aunque el tráfico web no use el túnel.

Manejar cambios de red y clientes móviles

WireGuard no ata criptográficamente un peer a una IP pública fija: aprende el endpoint desde el último paquete autenticado. Por eso un teléfono puede pasar de Wi-Fi a datos móviles sin cambiar su configuración. PersistentKeepalive = 25 en el cliente mantiene el mapeo NAT cuando necesita recibir tráfico después de periodos ociosos.

Comprueba la dirección aprendida:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Un endpoint cambiante es normal para móviles. Lo importante es que corresponda a un peer conocido y que su AllowedIPs siga limitado a la dirección asignada.

Si dos dispositivos comparten la misma privada y dirección, el servidor actualizará el endpoint hacia el último que hable; parecerá que la VPN salta entre ambos. La solución no es aumentar keepalive, sino generar identidades distintas.

Usar un nombre DNS como endpoint

Un nombre como vpn.ejemplo.com facilita cambiar la IP del VPS, pero los clientes deben volver a resolverlo para aprender el nuevo destino. Reduce el TTL antes de una migración y conserva temporalmente el servidor antiguo si necesitas continuidad.

dig +short vpn.ejemplo.com A
sudo wg show

Después de cambiar DNS, algunos clientes pueden mantener la dirección anterior hasta reiniciar el túnel. Planifica el corte y comunica un procedimiento de reconexión. No cambies simultáneamente IP, puerto y claves si quieres poder distinguir dónde falla.

El DNS del endpoint se consulta fuera del túnel al establecerlo. En un perfil de túnel completo, evita una dependencia circular donde el único resolvedor configurado solo sea accesible después de levantar una conexión cuyo nombre aún no puede resolverse.

Registrar salud sin almacenar tráfico de usuarios

Para monitorear WireGuard basta con handshake, contadores y disponibilidad del puerto; no necesitas inspeccionar contenido. Puedes obtener una salida apta para métricas:

sudo wg show wg0 dump
systemctl is-active wg-quick@wg0

Alerta si un peer que debería estar siempre conectado deja de intercambiar datos, pero no trates a todos igual: un portátil puede pasar días apagado. Los contadores se reinician al recrear la interfaz y no representan por sí solos consumo facturable de largo plazo.

Conserva logs del servicio y cambios de configuración, no privadas. Si adjuntas wg show a un ticket, las públicas no conceden acceso, pero revelan inventario; comparte solo con quienes lo necesiten.

Comprobar rutas antes de culpar al cifrado

WireGuard puede tener un handshake perfecto y enviar los paquetes a una ruta equivocada. En cliente y servidor consulta la decisión del kernel para un destino concreto:

ip route get 10.77.0.1
ip route get 1.1.1.1
ip rule show

La salida indica interfaz y dirección de origen. Si el destino privado no usa wg0, corrige AllowedIPs o una regla de política. Si sale por wg0 pero no vuelve, revisa ruta de retorno y firewall del destino.

Compara contadores antes y después de un ping. Transmisión que crece sin recepción indica que el peer envía pero no recibe respuesta; contadores inmóviles indican que la ruta ni siquiera entrega al túnel. Este método reduce cambios simultáneos en claves, NAT y DNS.

Conectar una red remota completa mediante un peer

Un peer puede representar una subred detrás de él, no solo un dispositivo, siempre que actúe como router. Por ejemplo, una oficina con 10.30.0.0/24 puede anunciar esa red al VPS. En el bloque del peer del servidor:

[Peer]
PublicKey = CLAVE_PUBLICA_ROUTER_OFICINA
AllowedIPs = 10.77.0.10/32, 10.30.0.0/24

El router remoto necesita forwarding y una ruta de retorno hacia los clientes WireGuard. Si la red de oficina ya usa su puerta de enlace principal, añade allí una ruta a 10.77.0.0/24 por el router VPN o aplica NAT de forma consciente.

No anuncies el mismo prefijo desde dos peers en un diseño pequeño sin entender la selección de ruta. WireGuard elige por coincidencia de prefijo y una configuración solapada puede enviar tráfico al peer incorrecto.

Prueba desde ambos lados:

ip route get 10.30.0.20
ping -c 3 10.30.0.20
traceroute -n 10.30.0.20

Limita en firewall qué puertos de la oficina pueden alcanzar los usuarios de la VPN. Conectar redes no implica que todos los dispositivos deban verse. Documenta rangos para evitar choques cuando agregues otra sede.

Evitar que una copia de configuración se convierta en una filtración

Los archivos de cliente contienen la privada y deben tratarse como credenciales, incluso si se muestran como código QR. No envíes una captura del QR por canales permanentes ni la guardes en una galería sincronizada sin protección. Importa el perfil en el dispositivo y elimina la copia temporal cuando la política lo permita.

Si una configuración se expone, retira la pública correspondiente del servidor y genera un par nuevo. Cambiar la IP asignada o el nombre del archivo no invalida la privada. Revisa los handshakes recientes para detectar uso posterior, aunque su ausencia no demuestre que nadie copió la clave.

Un backup cifrado del servidor también contiene su privada. Limita acceso, registra restauraciones y rota si el archivo salió del control del equipo.