El peer de WireGuard desaparece tras reiniciar: encuentre la configuración real

El peer que añadió con wg set responde a los ping toda la tarde y desaparece tras el reinicio. Nada se corrompió: el kernel nunca almacenó ese peer en otro sitio que la interfaz activa, y lo que recrea la interfaz al arrancar la reconstruyó desde un archivo que usted no tocó. La reparación no es otro wg set. Consiste en averiguar qué componente posee la interfaz, editar el estado de ese componente y luego demostrar que el peer sobrevive exactamente al evento del ciclo de vida que lo eliminó.

Repródalo una vez, a propósito

No corrija un problema de reinicio hasta poder verlo ocurrir. Con acceso por consola o fuera de banda disponible, anote la lista de peers, reinicie a través del servicio que posee la interfaz y compare. Si el peer sigue ahí, su cambio ya llegó al estado persistente y está depurando el evento equivocado.

Anote tres hechos mientras lo hace: el nombre de la interfaz, la unidad o el perfil que la inició y si se reinició el contador de handshake del peer superviviente. Un contador reiniciado significa que la interfaz fue destruida y recreada; un contador sin cambios con un peer ausente significa que algo editó la configuración bajo sus pies.

¿Quién posee la interfaz?

WireGuard en sí no tiene demonio ni archivo de configuración. Algo por encima llama a wg al arrancar, y ese algo es la fuente de la verdad. Los candidatos habituales son [email protected], un perfil de conexión de NetworkManager, una unidad de red específica de la distribución o un panel de gestión que escribe su propia base de datos.

Pregunte al sistema, no a la documentación de su distribución. systemctl status wg-quick@wg0 y nmcli connection show suelen resolverlo con un comando cada uno. Si ambos reclaman la interfaz, ha encontrado el fallo antes de editar nada: dos propietarios reescriben el mismo dispositivo en cada arranque, y gana el último que se ejecuta.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

El estado en ejecución y el estado de arranque no son el mismo archivo

wg set manipula el dispositivo activo mediante netlink. No escribe /etc/wireguard/wg0.conf, un perfil de NetworkManager ni la base de datos de un panel. Un wg show correcto después demuestra que el kernel aceptó el peer, no que algo vaya a restaurarlo.

Hay una segunda trampa en la dirección opuesta. La opción SaveConfig de wg-quick escribe el estado actual de la interfaz de vuelta en el archivo de configuración cuando la interfaz se baja. Con esa opción activa, una edición hecha en el archivo mientras la interfaz está arriba puede ser sobrescrita por el apagado siguiente, y usted jurará que la línea estaba ahí. Si el peer vuelve una y otra vez, lea el archivo después de una parada, no antes.

NetworkManager se comporta otra vez de forma distinta: posee el perfil y lo aplica al activarse, así que un .conf editado a mano junto a una conexión activa de NetworkManager es solo decorativo. Elija un único propietario para la interfaz y deje que el otro gestor no la toque.

Haga que la edición llegue a ambos sitios

Edite primero el estado persistente, deje que el propietario lo aplique y luego verifique el estado activo. Ese orden hace que un fallo en cualquier paso apunte a una cosa en lugar de a tres.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf imprime la configuración activa con la misma sintaxis que usa el archivo, lo que hace que ambas sean directamente comparables. Trate esa salida como un secreto: contiene claves privadas, así que no la pegue en un ticket ni en un canal de chat. Compare las claves públicas de los peers y las IP permitidas, y compruebe que el peer que eliminó a propósito no ha vuelto.

Demuestre que sobrevive al evento del ciclo de vida

Reinicie a través del propietario una segunda vez y luego confirme tres cosas separadas: el peer aparece en wg show, el contador de handshake aumenta tras el tráfico y la aplicación que depende del túnel responde de verdad. Un peer listado con un handshake antiguo es un problema de enrutamiento o de clave, no de persistencia, y esa distinción ahorra una edición de configuración inútil.

Por último, compruebe qué restauró el reinicio. Un reinicio que resucita un peer que usted eliminó deliberadamente es el mismo fallo con el signo contrario, y suele significar que todavía se está cargando una copia antigua de la configuración desde algún sitio. Anote el propietario, la ruta del archivo, la clave pública del peer y los comandos de verificación junto a la configuración, para que la siguiente persona no lo descubra de nuevo reiniciando un host de producción.