Il peer WireGuard sparisce dopo il riavvio: trovate la configurazione reale

Il peer che avete aggiunto con wg set risponde ai ping per tutto il pomeriggio e sparisce dopo il riavvio. Nulla è stato corrotto: il kernel non ha mai memorizzato quel peer da nessun’altra parte se non nell’interfaccia viva, e tutto ciò che ricrea l’interfaccia all’avvio l’ha ricostruita da un file che non avete toccato. La riparazione non è un altro wg set. Si tratta di scoprire quale componente possiede l’interfaccia, modificare lo stato di quel componente e poi dimostrare che il peer sopravvive esattamente all’evento del ciclo di vita che lo ha rimosso.

Riproducetelo una volta, di proposito

Non correggete un problema di riavvio prima di poterlo vedere accadere. Con un accesso alla console o fuori banda disponibile, annotate l’elenco dei peer, riavviate tramite il servizio che possiede l’interfaccia e confrontate. Se il peer è ancora lì, la vostra modifica ha già raggiunto lo stato persistente e state eseguendo il debug dell’evento sbagliato.

Annotate tre fatti mentre lo fate: il nome dell’interfaccia, l’unità o il profilo che l’ha avviata e se il contatore di handshake del peer sopravvissuto è stato azzerato. Un contatore azzerato significa che l’interfaccia è stata distrutta e ricreata; un contatore invariato con un peer mancante significa che qualcosa ha modificato la configurazione sotto i vostri piedi.

Chi possiede l’interfaccia?

WireGuard stesso non ha né demone né file di configurazione. Qualcosa sopra di esso chiama wg all’avvio, e quella cosa è la fonte di verità. I candidati abituali sono [email protected], un profilo di connessione NetworkManager, un’unità di rete specifica della distribuzione o un pannello di gestione che scrive il proprio database.

Chiedete al sistema, non alla documentazione della vostra distribuzione. systemctl status wg-quick@wg0 e nmcli connection show di solito risolvono la questione con un comando ciascuno. Se entrambi rivendicano l’interfaccia, avete trovato il bug prima di modificare qualsiasi cosa: due proprietari riscrivono lo stesso dispositivo a ogni avvio, e vince l’ultimo che viene eseguito.

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

Lo stato di runtime e lo stato di avvio non sono lo stesso file

wg set manipola il dispositivo vivo tramite netlink. Non scrive /etc/wireguard/wg0.conf, un profilo NetworkManager o il database di un pannello. Un wg show riuscito dopo dimostra che il kernel ha accettato il peer, non che qualcosa lo ripristinerà.

Esiste una seconda trappola nella direzione opposta. L’opzione SaveConfig di wg-quick riscrive lo stato attuale dell’interfaccia nel file di configurazione quando l’interfaccia viene abbassata. Se è attiva, una modifica fatta al file mentre l’interfaccia è su può essere sovrascritta dall’arresto che segue, e giurereste che la riga era lì. Se il peer continua a tornare, leggete il file dopo un arresto, non prima.

NetworkManager si comporta ancora diversamente: possiede il profilo e lo applica all’attivazione, quindi un .conf modificato a mano accanto a una connessione NetworkManager attiva è solo decorativo. Scegliete un unico proprietario per l’interfaccia e lasciate che l’altro gestore non la tocchi.

Fate in modo che la modifica arrivi in entrambi i posti

Modificate prima lo stato persistente, lasciate che il proprietario lo applichi, poi verificate lo stato vivo. Quest’ordine fa sì che un guasto a qualsiasi passo punti a una cosa invece che a tre.

# 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 stampa la configurazione viva con la stessa sintassi usata dal file, il che rende le due direttamente confrontabili. Trattate quell’output come un segreto: contiene chiavi private, quindi non incollatelo in un ticket o in un canale di chat. Confrontate le chiavi pubbliche dei peer e gli IP consentiti, e controllate che il peer che avete rimosso di proposito non sia tornato.

Dimostrate che sopravvive all’evento del ciclo di vita

Riavviate tramite il proprietario una seconda volta, poi confermate tre cose distinte: il peer appare in wg show, il contatore di handshake aumenta dopo il traffico e l’applicazione che dipende dal tunnel risponde davvero. Un peer elencato con un handshake vecchio è un problema di routing o di chiave, non di persistenza, e questa distinzione risparmia una modifica di configurazione inutile.

Infine, controllate cosa ha ripristinato il riavvio. Un riavvio che resuscita un peer che avete rimosso deliberatamente è lo stesso bug con il segno opposto, e di solito significa che una vecchia copia della configurazione viene ancora caricata da qualche parte. Annotate il proprietario, il percorso del file, la chiave pubblica del peer e i comandi di verifica accanto alla configurazione, così la prossima persona non lo riscopra riavviando un host di produzione.