Perché un peer WireGuard eliminato torna dopo un riavvio

L'identità svanisce dall'interfaccia in esecuzione e la modifica sembra conclusa. Dopo il riavvio del servizio, è di nuovo lì, il che si legge come se WireGuard ignorasse il comando. Ciò che è successo davvero è più semplice: la configurazione di avvio contiene ancora il peer.

Due stati tengono quell'elenco. La revoca è reale solo quando entrambi lo perdono.

Cosa cambia davvero wg set

Il comando wg set wg0 peer <public-key> remove modifica l'interfaccia in esecuzione nel kernel. Non scrive nulla su disco. Il file di configurazione, il profilo NetworkManager o lo stato salvato del router restano intatti. È il progetto, non un difetto.

Questa separazione è deliberata, perché lo strumento non ha idea di chi possieda l'interfaccia. Un comando a runtime deve essere sicuro su un'interfaccia gestita da qualcos'altro. Non può indovinare dove vive la copia durevole. La conseguenza è facile da enunciare: una rimozione a runtime è temporanea per costruzione.

Quindi il peer torna al riavvio successivo, e torna con i suoi prefissi consentiti originali. Tutto ciò che viene instradato attraverso di esso viene ricreato. Un'identità presumibilmente revocata può quindi raggiungere le sue destinazioni precedenti dopo un ricaricamento. Nulla nell'output a runtime aveva avvisato nessuno.

Trova chi scrive prima di modificare un file

L'interfaccia ha un proprietario. Potrebbe essere wg-quick che legge un file, NetworkManager che applica un profilo, la configurazione dell'interfaccia del router stesso o l'entrypoint di un container che ricrea l'interfaccia all'avvio. Modificare un file che il proprietario non legge mai non produce alcun cambiamento persistente.

Parti dall'interfaccia in esecuzione e identifica le chiavi pubbliche, perché nomi e indirizzi sono identificatori più deboli della chiave stessa. Poi confronta quell'elenco con la configurazione salvata che il proprietario legge davvero.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

Un'interfaccia viva in cui l'elenco dei peer e il contenuto del file non concordano è tutta la diagnosi. La configurazione salvata vince all'avvio e lo stato a runtime perde. Confrontali prima di cambiare l'uno o l'altro.

La trappola di SaveConfig

wg-quick aggiunge una piega che cattura chi modifica i file a mano. Con SaveConfig attivo, il suo comportamento documentato allo spegnimento riscrive lo stato a runtime corrente sopra il file di configurazione.

Ciò inverte la direzione abituale della persistenza. Rimuovi un peer dal file, poi il servizio si ferma. Lo stato in esecuzione viene riscritto sopra la tua modifica e ripristina il peer appena eliminato.

L'ordine conta quindi: modifica il file mentre l'interfaccia è spenta, oppure disabilita SaveConfig prima della modifica, poi riaccendi l'interfaccia e conferma cosa è stato caricato. Una modifica a mano con l'interfaccia accesa è una corsa contro la scrittura di spegnimento.

Cambia entrambi gli stati, poi ricarica

A runtime, rimuovi il peer per chiave. Nella configurazione salvata, rimuovi lo stesso blocco tramite l'operazione supportata dal proprietario, invece di modificare intorno ad esso.

Poi esamina cosa portava il peer. Una rete instradata che apparteneva all'identità revocata dovrebbe essere riassegnata deliberatamente o rimossa, non ereditata in silenzio dal peer che verrà modificato dopo.

Mantieni aperto un percorso di ripristino se il gateway porta anche il tuo accesso amministrativo. Un riavvio che rimuove il peer sbagliato è un'interruzione che ti sei inflitto. Lo stesso vale per un riavvio che rimuove la rotta sbagliata.

Come appare un test superato

Ricarica o riavvia il servizio, poi leggi di nuovo l'elenco dei peer. La vecchia chiave deve mancare, e i peer che volevi mantenere devono essere ancora presenti e funzionanti.

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

Dove la situazione lo consente, conferma che la vecchia identità non raggiunga più le sue risorse precedenti. Un elenco dell'interfaccia ordinato prima di un riavvio è metà del test. L'altra metà è ciò che l'identità può ancora fare dopo.

Se un gestore continua a ripristinare il peer, smetti di ripetere la rimozione di basso livello. Correggi l'inventario che quello scrittore legge, perché fino ad allora ogni riavvio è un altro invito per l'identità a riapparire.