Perché wg-quick riscrive wg0.conf quando fermate l’interfaccia

Aggiungete un peer a /etc/wireguard/wg0.conf, eseguite systemctl restart wg-quick@wg0, e il peer è sparito dal file quando guardate di nuovo. Niente ha corrotto niente. Un riavvio è un arresto seguito da un avvio, e la fase di arresto può riscrivere lo stato di esecuzione corrente sopra il file che avete appena modificato. L’impostazione responsabile vive nello stesso file che stavate modificando, ed è questo che rende il ciclo così confuso la prima volta che lo incontrate.

Due stati, un file e un salvataggio allo spegnimento

Lo stato di esecuzione di WireGuard e un file di configurazione wg-quick sono correlati ma distinti. Il file è input: wg-quick lo legge, crea l’interfaccia, imposta indirizzi e rotte e configura i peer. Il dispositivo del kernel è l’oggetto vivo, e le modifiche di basso livello fatte con wg non si riscrivono mai da sole.

Tranne in una direzione. Quando SaveConfig = true compare nella sezione dell’interfaccia, wg-quick salva la configurazione viva nel file come parte del portare giù l’interfaccia. Il manuale di wg-quick avverte esattamente di questo: le modifiche fatte al file mentre l’interfaccia è attiva possono essere sovrascritte quando viene rimossa. È un salvataggio allo spegnimento, non un timer in background, quindi scatta solo quando qualcosa ferma l’interfaccia.

Leggete la tabella come un avvertimento sull’ordine. Ogni perdita accidentale in quest’area deriva da una modifica avvenuta prima di un salvataggio invece che dopo.

Prima fermate, poi modificate, infine avviate

Se il file è la vostra fonte di verità, rendete il file autorevole per costruzione invece che per speranza. Portate giù l’interfaccia, confermate che è sparita, poi modificate, poi riportatela su. La regola è semplice: non esiste alcuna modifica mentre un salvataggio può ancora essere eseguito.

sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0

La riga di backup non è una cerimonia. Se il tunnel è il vostro modo di raggiungere questa macchina, la fase di discesa può terminare la sessione, e una copia su disco più una console o un percorso fuori banda è l’unico ripristino che funziona. Controllate quella seconda riga prima di fidarvi: un nome di interfaccia obsoleto in uno script che fallisce in silenzio è il modo in cui le persone modificano un file ancora vivo.

Impostare SaveConfig = false prima di una discesa normale è l’altra via accettata, e va fatto nel file che wg-quick legge davvero. Impedisce quell’unico salvataggio automatico. Non fa ricaricare le vostre modifiche a un profilo NetworkManager separato, a un export del router o a un entrypoint di container, perché quei gestori non leggono affatto questo file.

Applicate le modifiche ai peer senza strappare l’interfaccia

Non ogni modifica richiede un’interruzione. Le modifiche a livello di peer possono essere applicate a un’interfaccia in esecuzione convertendo il file in una configurazione e sincronizzandola, il che evita del tutto la fase di discesa e quindi il salvataggio:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakes

La fase strip conta. Stampa il file con le chiavi esclusive di wg-quick rimosse, così indirizzi, DNS e direttive di routing non finiscono in uno strumento che non le capisce. La sincronizzazione applica poi peer e chiavi al dispositivo vivo senza ricreare l’interfaccia, quindi le sessioni e le rotte esistenti sopravvivono.

Siate precisi sui limiti. Sincronizzare i peer non cambia l’indirizzo dell’interfaccia, le rotte aggiunte da wg-quick né la configurazione del resolver, perché nessuna di queste appartiene al dispositivo WireGuard. Aggiungere una sottorete a AllowedIPs e aspettarsi che il kernel la instradi è la lettura sbagliata classica; la rotta deve essere aggiunta da wg-quick al momento dell’avvio o da voi.

Controllate chi possiede l’interfaccia prima di modificare qualsiasi cosa

Su un desktop o un server gestito da un sistema di configurazione, il file può essere un output invece che un input. Una connessione NetworkManager, un profilo generato da un router o uno script di avvio di un container possono tutti possedere lo stesso nome di interfaccia, e in quel caso una sequenza wg-quick impeccabile modifica comunque l’artefatto sbagliato.

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

Il terzo comando stampa la configurazione viva nello stesso formato del file, chiave privata inclusa, il che è utile per il confronto e pericoloso in un ticket. Oscuratela prima di incollarla; una chiave privata in un thread di supporto è un compromesso permanente, non un refuso.

Se l’unità di servizio è inattiva ma l’interfaccia esiste, qualcos’altro l’ha creata e il file non è autorevole. Quella singola osservazione risparmia un’ora di modifiche a un file che nessuno legge.

Verificate il riavvio successivo, poi conservate un ripristino

Il test che dimostra davvero la correzione è un secondo riavvio, perché è la sequenza che è fallita la prima volta. Confermate che il peer sopravvive e che la configurazione viva corrisponde ancora a quella sul disco:

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

Eseguite il riavvio due volte. Un solo passaggio pulito può essere fortuna: il primo riavvio può consumare una modifica di esecuzione non ancora salvata, quindi il secondo è quello che vi dice che il file e l’esecuzione erano d’accordo alla fine del primo.

Conservate il backup dall’inizio del processo finché non avete fatto il doppio riavvio, poi cancellatelo o spostatelo fuori dalla directory di configurazione. Un wg0.conf.bak smarrito accanto al file vero è innocuo per wg-quick e confonde la persona successiva, che alla fine modificherà quello sbagliato.