El parell de WireGuard desapareix després de reiniciar: trobeu la configuració real

El parell que vau afegir amb wg set respon als ping tota la tarda i desapareix després del reinici. No s’ha corromput res: el nucli no va desar mai aquest parell enlloc més que a la interfície viva, i tot el que recrea la interfície en arrencar la va construir a partir d’un fitxer que no vau tocar. La reparació no és un altre wg set. Cal esbrinar quin component posseeix la interfície, editar l’estat d’aquest component i després demostrar que el parell sobreviu exactament a l’esdeveniment del cicle de vida que el va eliminar.

Reproduïu-ho un cop, expressament

No repareu un problema de reinici fins que el pugueu veure passar. Amb accés per consola o fora de banda disponible, anoteu la llista de parells, reinicieu mitjançant el servei que posseeix la interfície i compareu. Si el parell encara hi és, el vostre canvi ja ha arribat a l’estat persistent i esteu depurant l’esdeveniment equivocat.

Anoteu tres fets mentre ho feu: el nom de la interfície, la unitat o el perfil que la va iniciar i si el comptador de handshake del parell supervivent s’ha reiniciat. Un comptador reiniciat vol dir que la interfície es va destruir i recrear; un comptador intacte amb un parell absent vol dir que algú ha editat la configuració sota els vostres peus.

Qui posseeix la interfície?

WireGuard mateix no té dimoni ni fitxer de configuració. Alguna cosa per sobre seu crida wg en arrencar, i aquesta cosa és la font de veritat. Els candidats habituals són [email protected], un perfil de connexió de NetworkManager, una unitat de xarxa específica de la distribució o un panell de gestió que escriu la seva pròpia base de dades.

Pregunteu al sistema, no a la documentació de la vostra distribució. systemctl status wg-quick@wg0 i nmcli connection show normalment ho resolen amb una ordre cadascun. Si tots dos reclamen la interfície, heu trobat l’error abans d’editar res: dos propietaris reescriuen el mateix dispositiu a cada arrencada, i guanya l’últim que s’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

L’estat d’execució i l’estat d’arrencada no són el mateix fitxer

wg set manipula el dispositiu viu a través de netlink. No escriu /etc/wireguard/wg0.conf, ni un perfil de NetworkManager, ni la base de dades d’un panell. Un wg show correcte després només demostra que el nucli ha acceptat el parell, no que res el restaurarà.

Hi ha una segona trampa en la direcció oposada. L’opció SaveConfig de wg-quick escriu l’estat actual de la interfície de tornada al fitxer de configuració quan la interfície es baixa. Amb aquesta opció activada, una edició feta al fitxer mentre la interfície és aixecada pot ser sobreescrita per l’aturada següent, i jurareu que la línia hi era. Si el parell torna una i altra vegada, llegiu el fitxer després d’una aturada, no abans.

NetworkManager es comporta una altra vegada de manera diferent: posseeix el perfil i l’aplica en activar-lo, així que un .conf editat a mà al costat d’una connexió activa de NetworkManager és només decoratiu. Trieu un sol propietari per a la interfície i deixeu que l’altre gestor no la toqui.

Feu que l’edició arribi als dos llocs

Editeu primer l’estat persistent, deixeu que el propietari l’apliqui i després verifiqueu l’estat viu. Aquest ordre fa que una fallada en qualsevol pas apunti a una cosa en lloc de 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 imprimeix la configuració viva amb la mateixa sintaxi que fa servir el fitxer, cosa que fa que les dues siguin directament comparables. Tracteu aquesta sortida com un secret: conté claus privades, així que no l’enganxeu en un tiquet ni en un canal de xat. Compareu les claus públiques dels parells i les IP permeses, i comproveu que el parell que vau eliminar expressament no ha tornat.

Demostreu que sobreviu a l’esdeveniment del cicle de vida

Reinicieu mitjançant el propietari una segona vegada i confirmeu tres coses separades: el parell apareix a wg show, el comptador de handshake augmenta després del trànsit i l’aplicació que depèn del túnel respon de veritat. Un parell llistat amb un handshake antic és un problema d’encaminament o de clau, no un problema de persistència, i aquesta distinció estalvia una edició de configuració inútil.

Finalment, comproveu què ha restaurat el reinici. Un reinici que ressuscita un parell que vau eliminar expressament és el mateix error amb el signe oposat, i normalment vol dir que encara s’està carregant una còpia antiga de la configuració d’algun lloc. Anoteu el propietari, el camí del fitxer, la clau pública del parell i les ordres de verificació al costat de la configuració, perquè la propera persona no ho torni a descobrir reiniciant un amfitrió de producció.