O par de WireGuard desaparece tras reiniciar: atope a configuración real

O par que engadiu con wg set responde aos ping toda a tarde e desaparece tras o reinicio. Nada se corrompeu: o kernel nunca almacenou ese par noutro sitio que a interface activa, e o que recrea a interface ao arrincar reconstruíuna desde un ficheiro que vostede non tocou. A reparación non é outro wg set. Consiste en descubrir que compoñente posúe a interface, editar o estado dese compoñente e logo demostrar que o par sobrevive exactamente ao evento do ciclo de vida que o eliminou.

Repródeo unha vez, a propósito

Non corrixa un problema de reinicio ata poder velo ocorrer. Con acceso por consola ou fóra de banda dispoñible, anote a lista de pares, reinicie a través do servizo que posúe a interface e compare. Se o par segue aí, o seu cambio xa chegou ao estado persistente e está depurando o evento incorrecto.

Anote tres feitos mentres o fai: o nome da interface, a unidade ou o perfil que a iniciou e se se reiniciou o contador de handshake do par supervivente. Un contador reiniciado significa que a interface foi destruída e recreada; un contador sen cambios cun par ausente significa que algo editou a configuración baixo os seus pés.

Quen posúe a interface?

WireGuard en si non ten demonio nin ficheiro de configuración. Algo por riba chama a wg ao arrincar, e ese algo é a fonte da verdade. Os candidatos habituais son [email protected], un perfil de conexión de NetworkManager, unha unidade de rede específica da distribución ou un panel de xestión que escribe a súa propia base de datos.

Pregunte ao sistema, non á documentación da súa distribución. systemctl status wg-quick@wg0 e nmcli connection show adoitan resolvelo cun comando cada un. Se ambos reclaman a interface, atopou o fallo antes de editar nada: dous propietarios reescriben o mesmo dispositivo en cada arrinque, e gaña o último que se executa.

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

O estado en execución e o estado de arrinque non son o mesmo ficheiro

wg set manipula o dispositivo activo mediante netlink. Non escribe /etc/wireguard/wg0.conf, un perfil de NetworkManager nin a base de datos dun panel. Un wg show correcto despois demostra que o kernel aceptou o par, non que algo vaia restauralo.

Hai unha segunda trampa na dirección oposta. A opción SaveConfig de wg-quick escribe o estado actual da interface de volta no ficheiro de configuración cando a interface se baixa. Con esa opción activa, unha edición feita no ficheiro mentres a interface está arriba pode ser sobrescrita polo apagado seguinte, e vostede xurará que a liña estaba alí. Se o par volve unha e outra vez, lea o ficheiro despois dunha parada, non antes.

NetworkManager compórtase outra vez de forma distinta: posúe o perfil e aplícao ao activarse, así que un .conf editado a man xunto a unha conexión activa de NetworkManager é só decorativo. Escolla un único propietario para a interface e deixe que o outro xestor non a toque.

Faga que a edición chegue a ambos os sitios

Edite primeiro o estado persistente, deixe que o propietario o aplique e despois verifique o estado activo. Esa orde fai que un fallo en calquera paso apunte a unha cousa 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 a configuración activa coa mesma sintaxe que usa o ficheiro, o que fai que ambas sexan directamente comparables. Trate esa saída como un segredo: contén claves privadas, así que non a pegue nun ticket nin nunha canle de chat. Compare as claves públicas dos pares e as IP permitidas, e comprobe que o par que eliminou a propósito non volveu.

Demostre que sobrevive ao evento do ciclo de vida

Reinicie a través do propietario unha segunda vez e logo confirme tres cousas separadas: o par aparece en wg show, o contador de handshake aumenta tras o tráfico e a aplicación que depende do túnel responde de verdade. Un par listado cun handshake antigo é un problema de enrutamento ou de clave, non de persistencia, e esa distinción aforra unha edición de configuración inútil.

Por último, comprobe que restaurou o reinicio. Un reinicio que resucita un par que vostede eliminou deliberadamente é o mesmo fallo co signo contrario, e adoita significar que aínda se está cargando unha copia antiga da configuración desde algún sitio. Anote o propietario, a ruta do ficheiro, a clave pública do par e os comandos de verificación xunto á configuración, para que a seguinte persoa non o descubra de novo reiniciando un host de produción.