Por qué un peer de WireGuard borrado vuelve tras reiniciar

La identidad desaparece de la interfaz en ejecución y el cambio parece hecho. Cuando el servicio se reinicia, vuelve, lo que se lee como si WireGuard ignorara la orden. Lo que ocurrió en realidad es más sencillo: la configuración de arranque todavía contiene el peer.

Dos estados mantienen esa lista. La revocación solo es real cuando ambos lo pierden.

Qué cambia realmente wg set

La orden wg set wg0 peer <public-key> remove edita la interfaz en ejecución dentro del núcleo. No escribe nada en disco. El archivo de configuración, el perfil de NetworkManager o el estado guardado del router quedan intactos. Eso es el diseño, no un fallo.

Esa separación es deliberada, porque la herramienta no tiene idea de quién es el dueño de la interfaz. Una orden en tiempo de ejecución debe ser segura contra una interfaz gestionada por otra cosa. No puede adivinar dónde vive la copia duradera. La consecuencia es fácil de decir: una eliminación en tiempo de ejecución es temporal por construcción.

Así que el peer vuelve en el siguiente reinicio, y vuelve con sus prefijos permitidos originales. Todo lo que se enruta a través de él también se recrea. Una identidad supuestamente revocada puede, por tanto, alcanzar sus destinos anteriores tras una recarga. Nada en la salida en tiempo de ejecución había avisado a nadie.

Encuentra al escritor antes de editar un archivo

La interfaz tiene un dueño. Puede ser wg-quick leyendo un archivo, NetworkManager aplicando un perfil, la configuración de interfaz del propio router o un punto de entrada de contenedor que recrea la interfaz al arrancar. Editar un archivo que el dueño nunca lee no produce ningún cambio persistente.

Empieza por la interfaz en ejecución e identifica las claves públicas, ya que los nombres y las direcciones son identificadores más débiles que la propia clave. Después compara esa lista con la configuración guardada que el dueño lee de verdad.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

Una interfaz viva cuya lista de peers y cuyo contenido de archivo no coinciden es todo el diagnóstico. La configuración guardada gana al arrancar, y el estado en ejecución pierde. Compáralos antes de cambiar cualquiera de los dos.

La trampa de SaveConfig

wg-quick añade un pliegue que atrapa a quien edita archivos a mano. Con SaveConfig activado, su comportamiento documentado al apagarse escribe el estado de ejecución actual sobre el archivo de configuración.

Eso invierte la dirección habitual de la persistencia. Quitas un peer del archivo y luego el servicio se detiene. El estado en ejecución se escribe sobre tu edición y restaura el peer que acabas de borrar.

Por eso el orden importa: edita el archivo con la interfaz bajada, o desactiva SaveConfig antes de la edición, luego sube la interfaz de nuevo y confirma qué se cargó. Una edición a mano con la interfaz activa es una carrera con la escritura de apagado.

Cambia ambos estados y recarga

En tiempo de ejecución, quita el peer por clave. En la configuración guardada, quita el mismo bloque mediante la operación soportada del dueño, en lugar de editar alrededor de él.

Después revisa qué llevaba el peer. Una red enrutada que pertenecía a la identidad revocada debería reasignarse deliberadamente o eliminarse, no heredarse en silencio por el peer que se edite después.

Mantén abierto un camino de recuperación si la puerta de enlace también lleva tu acceso administrativo. Un reinicio que elimina el peer equivocado es una caída autoinfligida. Lo mismo vale para un reinicio que elimina la ruta equivocada.

Cómo se ve una prueba superada

Recarga o reinicia el servicio y vuelve a leer la lista de peers. La clave antigua debe faltar, y los peers que querías conservar deben seguir presentes y funcionando.

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

Donde la situación lo permita, confirma que la identidad antigua ya no alcanza sus recursos anteriores. Un listado de interfaz ordenado antes de un reinicio es media prueba. La otra mitad es qué puede hacer la identidad después.

Si un gestor sigue restaurando el peer, deja de repetir la eliminación de bajo nivel. Arregla el inventario que ese escritor lee, porque hasta entonces cada reinicio es otra invitación a que la identidad reaparezca.