Hai rimosso il peer. wg show conferma che non c'è più. Una settimana dopo il portatile che hai
revocato si riconnette, e niente nei tuoi log lo spiega.
Non è andato storto niente. WireGuard ha semplicemente due stati, e il comando che hai usato ne ha modificato solo uno.
I due stati
| cos'è | cosa lo modifica | |
|---|---|---|
| stato attivo | ciò che il kernel accetta in questo momento | wg set, wg syncconf |
| file di configurazione | ciò che viene caricato al prossimo avvio | il tuo editor, wg-quick save |
wg set wg0 peer PUBLIC_KEY remove agisce sul primo. È immediato, lascia connessi tutti gli altri
peer e non tocca mai /etc/wireguard/wg0.conf. La chiave pubblica che passi è la chiave Curve25519
da 32 byte stampata come 44 caratteri base64, ed è per questo che un peer si identifica con quella
stringa e non con un nome: WireGuard non memorizza alcun nome per lui.
Quindi il successivo wg-quick down wg0 && wg-quick up wg0 (un riavvio, un aggiornamento di
pacchetti, un restart di systemd a cui non avevi pensato) legge un file che contiene ancora il peer,
e lo rimette al suo posto. Nessuno viene avvisato. L'accesso riprende e basta.
Rimuoverlo per sempre
Due sequenze di operazioni, ed è la seconda quella da preferire.
Quella rapida, quando il file non contiene niente a cui tieni:
sudo wg set wg0 peer PUBLIC_KEY remove
sudo wg-quick save wg0
wg-quick save riscrive lo stato attivo nel file. Funziona, e riscrive il file dal punto di vista
del kernel. I tuoi commenti spariscono. Su un server con una dozzina di peer, quei commenti sono
di solito l'unica traccia di quale peer corrisponde a quale portatile. Perderli trasforma una
configurazione leggibile in un elenco di chiavi pubbliche anonime.
Quella da preferire, che mantiene il file come fonte autorevole:
sudo nano /etc/wireguard/wg0.conf # delete the whole [Peer] block
sudo wg syncconf wg0 <(wg-quick strip wg0)
wg syncconf applica il file all'interfaccia attiva senza abbatterla: viene toccato solo ciò
che è cambiato, e gli altri tunnel mantengono le loro sessioni. wg-quick strip rimuove le
direttive che il kernel non capisce (Address, DNS, PostUp) e stampa ciò che resta.
La distinzione conta su un server con diversi client: wg-quick down && up disconnette tutti per un
paio di secondi per revocare un solo peer. L'implementazione nel kernel accetta fino a 1.048.576
peer per dispositivo, quindi il primo limite che incontri è la tua capacità di distinguerli, non
quella del protocollo.
Due chiavi piatte su un unico anello, appese a una placca di metallo chiaro avvitata a una porta di legno chiaro. La chiave superiore porta incise le iniziali « R.M.I. ». Toni caldi, venatura del legno ben visibile.
Verifica in entrambi i posti, non in uno solo
sudo wg show wg0 peers # what the kernel accepts now
grep PublicKey /etc/wireguard/wg0.conf # what loads next time
Una chiave assente dal primo e presente nel secondo è una revoca con una data di scadenza. È esattamente la situazione per cui esiste questo articolo, ed è invisibile fino al giorno in cui l'interfaccia si riavvia.
I comandi a caldo usati qui (wg set wg0 peer <pubkey> remove, wg show wg0 latest-handshakes, wg show wg0 endpoints) stanno su un'unica pagina A4 stampabile nel nostro WireGuard Cheat Sheet gratuito, accanto alle chiavi [Peer] e al comando che aggiunge di nuovo un peer a caldo. Download diretto, senza registrazione. Scarica il cheat sheet.
Cosa non fa la revoca
Rimuovere il peer significa che il server rifiuta l'handshake. Il materiale crittografico sul dispositivo perso diventa inutile contro questo server. È un effetto reale, ed è lì che si ferma.
La revoca non è del tutto istantanea, e il ritardo è limitato dai timer del protocollo stesso. Una
chiave di sessione viene rifiutata dopo 180 secondi (REJECT_AFTER_TIME), e un nuovo handshake
viene normalmente avviato dopo 120 secondi (REKEY_AFTER_TIME). Quindi una sessione già stabilita
al momento della rimozione del peer può continuare a trasportare traffico per un massimo di tre
minuti prima che il kernel la scarti. Se quella finestra conta, abbatti l'interfaccia invece di
aspettare.
Il file di configurazione è ancora su quel dispositivo. Così come la sua chiave privata e tutto ciò che il dispositivo conteneva: una sessione ancora aperta, un password manager lasciato sbloccato, la casella di posta che può reimpostare gli altri tuoi account. Revocare il tunnel è la prima mossa giusta. Non è l'intera risposta, e trattarla come tale è il modo in cui si finisce perfettamente sicuri di sé e ancora esposti.
Valuta la tua superficie di attacco: 10 domande, circa tre minuti, nessun account, nessuna email, nulla memorizzato. Il risultato indica l'unico cambiamento che riduce di più la tua esposizione, e per chi fa self-hosting raramente è un'altra regola del firewall.
In breve
| Cosa hai fatto | Cosa ha cambiato davvero |
|---|---|
wg set … peer … remove | solo lo stato attivo, torna indietro al riavvio |
wg-quick save | anche il file, al prezzo dei tuoi commenti |
modificare il file, poi wg syncconf | entrambi, senza disconnettere gli altri peer |
| revoca dopo la perdita di un dispositivo | il tunnel, non ciò che il dispositivo contiene ancora |
Una frase da tenere a mente: un peer rimosso dalla memoria e lasciato nel file non è rimosso, è rimandato.
Quando il dispositivo revocato va sostituito, genera una nuova coppia di chiavi invece di riusare quella vecchia: il nostro generatore di configurazioni WireGuard scrive il nuovo file client e il suo codice QR, più un file server il cui blocco [Peer] copi nel tuo prima di wg syncconf. Il generatore è gratuito fino a 10 dispositivi; oltre, WireGuard Pro (un nostro prodotto, 9 EUR una tantum, nessun abbonamento) alza il limite a 250 e aggiunge un unico ZIP con ogni .conf client e il suo codice QR in PNG, comodo per configurare un intero ufficio o una famiglia in un colpo solo.
★ Datacenter GDPR di Norimberga · ✓ IPv4 dedicato incluso · porta da 200 Mbit/s
Ospita la tua VPN sul tuo VPS → ContaboAccesso root completo · IPv4 pubblico · scegli la tua regione→
