Eliminaste el peer. wg show confirma que ya no está. Una semana después, el portátil que revocaste
vuelve a conectarse, y nada en tus logs lo explica.
No ha fallado nada. WireGuard simplemente tiene dos estados, y el comando que usaste solo cambió uno de ellos.
Los dos estados
| qué es | qué lo cambia | |
|---|---|---|
| estado en ejecución | lo que el kernel acepta en este momento | wg set, wg syncconf |
| archivo de configuración | lo que se carga en el siguiente arranque | tu editor, wg-quick save |
wg set wg0 peer PUBLIC_KEY remove actúa sobre el primero. Es inmediato, deja conectados a todos los
demás peers y nunca toca /etc/wireguard/wg0.conf. La clave pública que pasas es la clave Curve25519
de 32 bytes representada en 44 caracteres base64, y por eso un peer se identifica por esa cadena y no
por un nombre: WireGuard no guarda ningún nombre para él.
Así que el siguiente wg-quick down wg0 && wg-quick up wg0 (un reinicio, una actualización de
paquetes, un restart de systemd en el que no pensaste) lee un archivo que todavía contiene el peer, y
lo vuelve a añadir. Nadie recibe aviso. El acceso simplemente se reanuda.
Eliminarlo para siempre
Dos órdenes de operaciones posibles, y el segundo es el preferible.
El rápido, cuando el archivo no contiene nada que te importe:
sudo wg set wg0 peer PUBLIC_KEY remove
sudo wg-quick save wg0
wg-quick save vuelve a escribir el estado en ejecución en el archivo. Funciona, y reescribe el
archivo desde el punto de vista del kernel. Tus comentarios desaparecen. En un servidor con una
docena de peers, esos comentarios suelen ser el único registro de qué peer corresponde a qué portátil.
Perderlos convierte una configuración legible en una lista de claves públicas anónimas.
El preferible, que mantiene el archivo como fuente de verdad:
sudo nano /etc/wireguard/wg0.conf # delete the whole [Peer] block
sudo wg syncconf wg0 <(wg-quick strip wg0)
wg syncconf aplica el archivo a la interfaz en ejecución sin bajarla: solo se ve afectado lo que
ha cambiado, y los demás túneles conservan sus sesiones. wg-quick strip elimina las directivas que
el kernel no entiende (Address, DNS, PostUp) e imprime lo que queda.
La diferencia importa en un servidor con varios clientes: wg-quick down && up desconecta a todo el
mundo durante un par de segundos para revocar un solo peer. La implementación del kernel admite hasta
1.048.576 peers por dispositivo, así que el límite con el que te topas primero es tu propia capacidad
para distinguirlos, no el del protocolo.
Dos llaves planas en una sola anilla, colgadas de una placa metálica clara atornillada a una puerta de madera clara. La llave superior lleva grabadas las iniciales «R.M.I.». Tonos cálidos, veta de la madera visible.
Comprueba en los dos sitios, no en uno
sudo wg show wg0 peers # what the kernel accepts now
grep PublicKey /etc/wireguard/wg0.conf # what loads next time
Una clave ausente en el primero y presente en el segundo es una revocación con fecha de caducidad. Es justo la situación para la que existe este artículo, y es invisible hasta el día en que la interfaz se reinicia.
Los comandos en caliente usados aquí (wg set wg0 peer <pubkey> remove, wg show wg0 latest-handshakes, wg show wg0 endpoints) caben en una página A4 imprimible de nuestra WireGuard Cheat Sheet gratuita, junto a las claves de [Peer] y el comando que vuelve a añadir un peer en caliente. Descarga directa, sin registro. Descargar la cheat sheet.
Lo que revocar no hace
Eliminar el peer significa que el servidor rechaza el handshake. El material de claves del dispositivo perdido deja de servir contra este servidor. Eso es real, y es ahí donde termina el efecto.
La revocación no es del todo instantánea, y el retraso está acotado por los propios temporizadores
del protocolo. Una clave de sesión se rechaza al cabo de 180 segundos (REJECT_AFTER_TIME), y
normalmente se inicia un nuevo handshake al cabo de 120 segundos (REKEY_AFTER_TIME). Así que una
sesión ya establecida cuando eliminaste el peer puede seguir transportando tráfico hasta tres minutos
antes de que el kernel la descarte. Si esa ventana importa, baja la interfaz en lugar de esperar.
El archivo de configuración sigue en ese dispositivo. También su clave privada, y todo lo demás que contenía: una sesión que seguía abierta, un gestor de contraseñas desbloqueado, el buzón de correo que permite restablecer tus otras cuentas. Revocar el túnel es el primer paso correcto. No es la respuesta completa, y tratarlo como tal es la manera en que la gente acaba perfectamente confiada y aun así expuesta.
Sitúa tu propia superficie de ataque: 10 preguntas, unos tres minutos, sin cuenta, sin email, nada almacenado. El resultado señala el cambio que más reduce tu exposición, y para quien aloja sus propios servicios rara vez es otra regla de firewall.
En resumen
| Lo que hiciste | Lo que cambió en realidad |
|---|---|
wg set … peer … remove | solo el estado en ejecución, se revierte al reiniciar |
wg-quick save | también el archivo, a costa de tus comentarios |
editar el archivo y luego wg syncconf | ambos, sin desconectar a los demás peers |
| revocado tras perder un dispositivo | el túnel, no lo que el dispositivo todavía contiene |
Una frase que conviene recordar: un peer eliminado de la memoria y que sigue en el archivo no está eliminado, está aplazado.
Cuando el dispositivo revocado necesite un sustituto, genera un par de claves nuevo en lugar de reutilizar el antiguo: nuestro generador de configuración WireGuard escribe el nuevo archivo de cliente y su código QR, además de un archivo de servidor cuyo bloque [Peer] copias en el tuyo antes de wg syncconf. 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 cada .conf de cliente y su código QR en PNG, práctico para configurar una oficina o una familia entera de una sola vez.
★ 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→
