Dos dispositivos, una clave WireGuard: qué se rompe de verdad y por qué parece aleatorio

Configuras WireGuard en un portátil, funciona, y copiar esa misma config a un móvil lleva diez segundos. Los dos se conectan. Durante un tiempo nada parece ir mal.

Luego los dos están conectados a la vez, y uno de ellos deja de recibir tráfico. Sin error, sin regularidad, y normalmente mientras intentas hacer otra cosa.

La solución es un par de claves por dispositivo. Nuestro generador de configuración WireGuard gratuito crea un par de claves, una dirección y una config independientes para cada peer en tu navegador, y si todavía tienes que alquilar el servidor, un Contabo Cloud VPS 4 a 5,50 €/mes (enlace de afiliado) viene con su propia IPv4 pública. Si prefieres un proveedor estadounidense con garantía de devolución de 30 días, Ultahost VPS Basic cuesta 5,52 $ al mes con un compromiso de 24 meses (1 GB de RAM, IPv4 dedicada, consultado el 21 de octubre de 2026), suficiente para un servidor WireGuard de unos pocos dispositivos. El generador es gratuito hasta 10 dispositivos; a partir de ahí, WireGuard Pro (nuestro propio producto, 9 EUR en un único pago, sin suscripción) sube el límite a 250 y añade un ZIP con cada .conf de cliente y su código QR en PNG, práctico para configurar toda una oficina o una familia de una sola vez.

Lo que ve el servidor

WireGuard identifica a un peer por su clave pública. No por IP, no por dispositivo, no por nombre. Dos dispositivos con la misma clave privada son, para el servidor, un único peer que no para de moverse.

Cada handshake actualiza el endpoint registrado para ese peer, la dirección y el puerto a los que el servidor envía las respuestas. El móvil hace handshake, las respuestas van al móvil. El portátil hace handshake, las respuestas van al portátil. El que no hizo el handshake más reciente sigue enviando paquetes que llegan bien, y deja de recibir nada de vuelta.

Ese es todo el mecanismo, y explica el síntoma exactamente: una conectividad que salta entre dos dispositivos a intervalos que nadie controla, porque el intervalo de handshake no es algo que tú programes.

Las tres consecuencias, por orden de lo que te van a costar

No puedes distinguirlos. wg show lista un peer, un tiempo de handshake, un contador de transferencia. El tráfico del móvil y del portátil se suma. Si algún día necesitas saber qué dispositivo hizo algo, esa información no existe.

No puedes revocar uno solo. Quitar la clave del servidor elimina el acceso de todos los dispositivos que la tienen. Un móvil perdido significa cortar también el portátil y volver a emitir claves para los dos.

AllowedIPs se vuelve ambiguo. En el servidor, AllowedIPs es lo que asocia un paquete a un peer. Dos dispositivos detrás de una única entrada de peer comparten una dirección de túnel, así que cualquier cosa enrutada a esa dirección llega al dispositivo que tenga el endpoint en ese momento.

La solución: una clave y una dirección por dispositivo

En el cliente, o en el servidor si generas para otra persona:

wg genkey | tee phone.key | wg pubkey > phone.pub

En el servidor, añade un bloque de peer por dispositivo, cada uno con su propia dirección:

[Peer]
# laptop
PublicKey = <laptop.pub>
AllowedIPs = 10.10.0.2/32

[Peer]
# phone
PublicKey = <phone.pub>
AllowedIPs = 10.10.0.3/32

Añádelo en caliente, sin desconectar a nadie:

wg set wg0 peer <phone.pub> allowed-ips 10.10.0.3/32

⛔ Después escríbelo también en el archivo de configuración. wg set cambia la interfaz en ejecución y nada en disco; un reinicio lo pierde. Esa trampa, y el resto del ciclo de vida de un peer, se tratan en añadir un peer en WireGuard.

Eliminar un dispositivo más adelante es entonces un único comando, y no toca nada más:

wg set wg0 peer <phone.pub> remove

La línea de comentario no es decoración

Nada en el protocolo lleva un nombre de dispositivo, así que una lista de doce claves públicas es ilegible seis meses después. Un comentario # phone encima de cada bloque es la única etiqueta que va a existir nunca, y el día que necesites revocar uno con prisa será el día que la eches de menos.

Dos casos cercanos que no son esto

Una clave precompartida se comparte a propósito. PresharedKey es simétrica y debe ser idéntica en los dos extremos de un mismo par de peers. Eso no es reutilizar una clave entre dispositivos, y es fácil confundir ambas cosas: consulta la guía de la clave precompartida.

Un dispositivo, varios túneles también está bien. Un portátil puede tener claves distintas para servidores distintos sin conflicto, porque la identidad es por túnel y no por máquina.

Si emites configs para dispositivos con regularidad, generar el código QR es la parte rápida, y merece la misma disciplina: el código QR de WireGuard contiene la clave privada completa, así que un código por dispositivo y nunca uno compartido.