La mayoría de las guías responden a «¿cómo añado un peer a WireGuard?» con wg-quick down wg0 && wg-quick up wg0. Funciona, y además desconecta a todos los que están usando el túnel en ese momento para añadir una línea a un archivo. En un servidor con un puñado de clientes es una molestia breve. En un servidor del que realmente dependes, es la razón por la que la gente evita directamente añadir peers.
Existe un comando que lo hace en caliente.
¿Cómo se añade un peer a WireGuard?
Una línea, sobre la interfaz en marcha:
wg set wg0 peer <CLIENT_PUBLIC_KEY> allowed-ips 10.0.0.5/32
El peer existe desde ese momento. Sin reinicio, sin handshakes perdidos, sin interrupción para nadie que ya esté conectado. wg set habla directamente con el módulo del kernel y edita la configuración en vivo de la interfaz.
Comprueba que se ha aplicado:
wg show wg0
La nueva clave pública aparece en la lista, todavía sin handshake, y es lo esperado: el handshake se produce cuando el cliente envía tráfico por primera vez.
¿Cómo se añade un peer desde la línea de comandos, de principio a fin?
En la máquina cliente, genera el par de claves:
wg genkey | tee client.key | wg pubkey > client.pub
client.key es la clave privada y nunca sale de esa máquina. client.pub es lo que necesita el servidor.
En el servidor:
wg set wg0 peer "$(cat client.pub)" allowed-ips 10.0.0.5/32
De vuelta en el cliente, el archivo de configuración necesita la clave pública del servidor, su endpoint y la dirección que acabas de asignar:
[Interface]
PrivateKey = <contents of client.key>
Address = 10.0.0.5/32
[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Las dos claves son el paso en el que la gente se equivoca: cada lado guarda la clave pública del otro lado, nunca la suya.
Si el nuevo cliente es un teléfono, o una máquina sin wg instalado, puedes generar su parte sin terminal. Configura nuestro generador de configuración WireGuard gratuito con un cliente y el endpoint y la subred de tu servidor: crea el par de claves en tu navegador y te da el archivo del cliente, su código QR y el bloque [Peer] correspondiente para el servidor. Dos cosas que comprobar antes de usarlo. El generador inventa su propio par de claves de servidor, así que sustituye PublicKey en el bloque [Peer] del cliente por la tuya real, obtenida con wg show wg0 public-key. Y asigna al primer cliente la dirección .2 de la subred, así que cambia Address (y el allowed-ips que pasas a wg set) si esa ya está ocupada. La clave privada del cliente y la clave pública que entregas al servidor están listas tal cual. El generador es gratuito hasta 10 dispositivos; a partir de ahí, WireGuard Pro (nuestro propio producto, 9 EUR en un solo pago, sin suscripción) sube el límite a 250 y añade un ZIP con el .conf de cada cliente y su código QR en PNG, práctico para configurar toda una oficina o una familia de una vez.
¿Qué va en AllowedIPs al añadir un peer?
Depende del lado en el que estés, y esta asimetría es el origen de la mayor parte de la confusión.
| En el servidor, para este peer | En el cliente, para el servidor | |
|---|---|---|
| Qué significa | qué dirección pertenece a este cliente | qué tráfico enviar por el túnel |
| Valor típico | 10.0.0.5/32, una dirección | 0.0.0.0/0 (todo) o la subred de la LAN (túnel dividido) |
| ¿Puede solaparse con otro peer? | No | no aplica |
| Efecto si está mal | los paquetes van al peer equivocado o se descartan | el tráfico esquiva el túnel, o el túnel captura tu LAN |
La regla de no solapamiento es estructural, no una cuestión de orden. AllowedIPs es lo que indica a WireGuard a qué peer pertenece un destino dado, así que una dirección listada en dos peers vuelve ambigua esa decisión, y el síntoma práctico es que añadir un cliente deja silenciosamente fuera de línea al anterior.
En el lado del cliente, el túnel completo 0.0.0.0/0 es fácil; «todo salvo mi LAN» no lo es, porque AllowedIPs no tiene sintaxis de exclusión. Nuestra calculadora de AllowedIPs gratuita convierte «todo salvo X» en la lista más corta de rangos IPv4 e IPv6 para pegar en el bloque [Peer] del nuevo cliente.
¿Cómo hacer que el nuevo peer sobreviva a un reinicio?
wg set modifica la interfaz en marcha. No toca /etc/wireguard/wg0.conf, así que un reinicio lo olvida. Dos formas de hacerlo persistente:
Añade el bloque al archivo a mano:
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.0.0.5/32
No vuelvas a escribir el estado en vivo con wg showconf wg0 > /etc/wireguard/wg0.conf, un atajo que circula mucho. wg showconf solo sabe lo que sabe el kernel: la clave privada, el puerto de escucha y los peers. No contiene ninguna de las líneas de wg-quick: Address, DNS, MTU, PostUp, PostDown. Si sobrescribes el archivo con él, el siguiente wg-quick up levanta wg0 sin dirección de túnel y sin reglas NAT, de modo que todos los clientes completan el handshake y nada se enruta.
Si quieres que el estado en ejecución se guarde por ti, define SaveConfig = true en [Interface]. wg-quick vuelve a escribir entonces los peers cuando la interfaz se apaga y conserva sus propias líneas. La pega: reescribe el archivo entero en ese momento, así que un comentario o una edición manual hecha con el túnel levantado se pierde. Elige un método, archivo editado a mano o SaveConfig, no los dos.
Para recargar un archivo editado sin cortar sesiones:
wg syncconf wg0 <(wg-quick strip wg0)
syncconf aplica las diferencias. wg-quick down/up no: reconstruye la interfaz desde cero, que es justo lo que intentabas evitar.
¿Cómo automatizar el alta de peers en Linux?
La secuencia no tiene ningún paso interactivo, así que se automatiza directamente:
#!/usr/bin/env bash
set -euo pipefail
NAME="$1"; IP="$2" # ./addpeer.sh laptop 10.0.0.7
umask 077
wg genkey | tee "$NAME.key" | wg pubkey > "$NAME.pub"
wg set wg0 peer "$(cat "$NAME.pub")" allowed-ips "$IP/32"
printf '\n[Peer]\n# %s\nPublicKey = %s\nAllowedIPs = %s/32\n' \
"$NAME" "$(cat "$NAME.pub")" "$IP" >> /etc/wireguard/wg0.conf
echo "added $NAME at $IP"
umask 077 importa: sin él, la clave privada recién escrita es legible por todas las cuentas de la máquina. set -euo pipefail también importa: sin él, un wg set fallido te deja igualmente con los archivos de claves y un alegre mensaje de éxito. La línea printf añade el peer al final del archivo en lugar de reescribirlo, por la razón explicada en la sección anterior.
Una versión más completa de este script está disponible gratis en GitHub: wg-newpeer.sh también genera una clave precompartida, escribe el .conf del cliente en ./clients/, aplica el cambio con wg syncconf e imprime un código QR cuando qrencode está instalado. Viene incluido en nuestro WireGuard Self-Hosting Kit de pago (9 USD), junto a las plantillas de servidor y cliente, la checklist de diagnóstico de 12 causas y la checklist de hardening, si quieres el conjunto completo en archivos.
Una mano apoyada en el teclado mientras el monitor sigue en negro: añadir un peer con wg set no produce ninguna confirmación visible, y por eso wg show es lo único que te dice que ha funcionado.
¿Por qué no conecta el nuevo peer?
El comando ha tenido éxito y no pasa nada. En la práctica casi siempre es una de cuatro cosas, y las cuatro se pueden comprobar en lugar de adivinar.
- Las claves están intercambiadas. El servidor guarda la clave pública del cliente; el cliente guarda la del servidor. Poner una clave privada donde va una pública falla en silencio.
- El cliente está detrás de NAT sin
PersistentKeepalive. El servidor no tiene ruta de vuelta hasta que el cliente habla primero, y el mapeo NAT caduca entretanto.PersistentKeepalive = 25en el lado del cliente lo mantiene abierto. - La dirección ya está ocupada. Dos peers con el mismo
AllowedIPses el caso que parece más misterioso, porque el peer que se rompe es el más antiguo. - El puerto UDP del servidor no es accesible desde fuera. Los peers existentes en la LAN siguen funcionando, así que el servidor parece estar bien, pero un nuevo peer en datos móviles nunca obtiene un handshake. Nuestro verificador de puerto WireGuard gratuito te dice si tu router puede redirigir el puerto (detecta CGNAT y doble NAT) y te da la regla de firewall para tu sistema. Si la respuesta es CGNAT, ninguna redirección de puertos lo arreglará: la salida habitual es ejecutar el servidor en un VPS con su propia IPv4 pública, como un Contabo Cloud VPS (enlace de afiliado), y añadir allí tus peers. Si prefieres un proveedor estadounidense con garantía de reembolso de 30 días, Ultahost VPS Basic cuesta 5.52 $ al mes con un plazo de 24 meses (1 GB de RAM, IPv4 dedicada, leído el 21 de octubre de 2026), suficiente para un servidor WireGuard para unos pocos dispositivos.
Ese tercer fallo es la razón de ser de wg-clients-audit. Lee una carpeta de configuraciones de cliente e informa de direcciones duplicadas, claves privadas reutilizadas y rangos AllowedIPs lo bastante amplios como para tragarse la red local, los tres fallos que producen un túnel que conecta y luego se comporta de forma extraña. Ejecutarlo antes de entregarle una configuración a alguien es más rápido que diagnosticarlo después.
Empieza con wg show wg0. Un peer sin latest handshake nunca completó ninguno, lo que apunta a las claves o a la accesibilidad. Un peer que completa el handshake pero no transporta datos apunta a AllowedIPs.
Mientras editas un bloque de peer, es el momento adecuado para plantearte una clave precompartida: un wg genpsk por pareja de peers, mezclado en el handshake, y debe coincidir en ambos extremos o el túnel se queda mudo.
Una VPN cambia tu IP. No cambia tu navegador.
Un túnel sustituye la dirección que ve un servicio. No cambia nada de lo que tu navegador anuncia por sí solo (fuentes, pantalla, zona horaria, pila gráfica), y esa combinación suele ser lo bastante estable como para reconocerte de una sesión a otra, con túnel o sin él.
Mide la huella de tu navegador: pasiva, sin preguntas, sin cuenta, sin correo electrónico.
Lo que hay que recordar
wg set añade un peer en caliente; wg-quick down/up desconecta a todo el mundo para hacer lo mismo. Lo que añadas en caliente desaparece al reiniciar salvo que también lo escribas en la configuración, y wg showconf no es un archivo de configuración: redirígelo sobre wg0.conf y pierdes Address y PostUp. Un /32 por cliente, sin solaparse nunca. Y cuando un nuevo peer se comporte mal, revisa wg show antes de cambiar nada: la diferencia entre «sin handshake» y «handshake pero sin tráfico» te dice qué mitad de la configuración mirar.
Y si estabas a punto de copiar una misma configuración en un segundo dispositivo en lugar de añadir un peer, el síntoma que viene después está documentado: dos dispositivos, una clave WireGuard (en inglés).
★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · puerto de 200 Mbit/s
Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región→
