Come dismettere un server VPN senza lasciare accessi dietro
Procedete dall’app del client verso l’esterno: revocate chiavi e account, chiudete il listener, poi dimostrate che nessun profilo, record DNS o backup può ancora raggiungerlo.
Il vostro client si connette ancora il giorno in cui si apre il ticket di dismissione. Un profilo siede nell’app, negozia, e il tunnel sale come se nulla fosse cambiato. È il momento di lavorare nella direzione opposta a come avete costruito il servizio: partite dall’elenco dei client, procedete verso l’esterno fino al listener, poi al firewall, e chiudete con le credenziali che sopravvivono a tutto questo. Spegnere la VM è l’ultimo passo, non il primo. Questa guida presuppone che abbiate accesso alla console dell’host e l’autorità per modificare i record dei client e il DNS.
Percorrete prima l’elenco dei client
Aprite qualunque cosa distribuisca i vostri profili e leggete l’elenco prima di toccare il server. Ogni voce è un dispositivo che crede di avere accesso: telefoni, portatili, un router di filiale, un container che si sincronizza ogni notte. Esportate quell’elenco nel ticket, perché una volta sparito l’host non c’è nessun wg show che vi dica chi era connesso.
Classificate ogni dispositivo come endpoint sostitutivo, non più necessario o sconosciuto. Il secchio degli sconosciuti è quello che conta, perché sono i profili che qualcuno troverà in un cassetto fra mesi e proverà. Inviate l’avviso sullo stesso canale che usate per le richieste di accesso, e inserite una data per quando il vecchio endpoint smetterà di rispondere.
Revocate l’identità, non solo il file
Due azioni diverse vengono entrambe chiamate revoca. Su WireGuard, un peer è autorizzato solo dalla sua chiave pubblica che compare in una sezione peer con una voce AllowedIPs, quindi cancellare il file di configurazione dal portatile non cambia nulla sul server. Rimuovete il blocco del peer e riapplicate il file senza far cadere i peer che tenete, come descrive il manuale di wg(8):
wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)wg syncconf è la parte che vi risparmia una finestra di manutenzione. Ricostruisce l’interfaccia dal file sul posto, quindi rimuovere un peer non abbatte il tunnel che tutti gli altri usano. Se dismettete l’intero host invece di un peer, l’ordine conta ancora, perché a quelle chiavi può essere data fiducia altrove.
Con una configurazione X.509 il passo di revoca è il certificato, non il file: openssl ca -revoke client.crt e poi openssl ca -gencrl -out crl.pem. Questo ha effetto solo dove il verificatore lo legge, il che significa che un OpenVPN server con crl-verify configurato e ricaricato dopo. Se questo gateway è l’unico consumatore di quella CA, la CRL smette di contare il giorno in cui muore; se la stessa CA firma per un secondo gateway, un certificato che non avete mai revocato continua a funzionare lì.
Gli account sono il terzo caso e quello più spesso saltato. Quando il gateway si autenticava contro RADIUS, LDAP o un provider di identità ospitato, l’account vive fuori dalla VPN. Disattivatelo nella directory. Eliminare una stanza utente sul server lascia una credenziale valida che l’endpoint sostitutivo accetterà nel momento in cui punterà alla stessa directory.
Chiudete i listener e i percorsi che portano a loro
Fermate il servizio in un modo che sopravviva a un riavvio, poi confermate con un elenco di socket invece che con lo stato dell’unità. systemctl disable --now wg-quick@wg0 ferma l’interfaccia e rimuove le rotte e le regole aggiunte da wg-quick; systemctl disable --now openvpn-server@server fa lo stesso per un’istanza OpenVPN con template. Seguite entrambi con ss -lunp e ss -ltnp. Un risultato vuoto per la vecchia porta è l’unica prova che conta.
Ciò che wg-quick ha aggiunto, wg-quick lo toglie. Ciò che avete aggiunto a mano resta: una regola NAT persistente, un permesso del firewall, un inoltro di porta del router, una regola in ingresso di un gruppo di sicurezza cloud, un listener di bilanciatore. Tutti richiedono una rimozione esplicita, e così il record DNS, cioè l’A, l’AAAA e qualsiasi CNAME che punta al nome. Un nome che risolve su un host morto fallisce in modo diverso da un nome che non risolve, e quella differenza costerà un pomeriggio a qualcuno.
La copia che dimenticate è il clone. Uno snapshot o una VM ripristinata da un backup conserva ancora le chiavi dell’host e il vecchio elenco dei peer, e se qualcosa la riporta allo stesso indirizzo, i client si riconnettono a un servizio che credete dismesso. Etichettate il set di backup come appartenente a un servizio dismesso e tenetelo fuori dai percorsi di ripristino automatico.
Inseguite ciò che punta ancora al vecchio endpoint
I profili in cache sopravvivono al DNS. Una configurazione salvata con un indirizzo numerico continua a comporre dopo che il record è sparito, e un client sempre attivo riprova a ogni cambio di rete. È rumore e non accesso, perché il listener è chiuso, ma sapere quale dei due state guardando decide come rispondete al ticket.
Poi spazzate le dipendenze che nessuno archivia sotto VPN: controlli di uptime che tastano la porta, lavori di backup che tiravano configurazioni dall’host, credenziali di automazione usate per spingere voci dei peer, account di ripristino creati solo per questo endpoint. Ognuna è un percorso di accesso con la propria vita e il proprio proprietario, quindi ognuna riceve una decisione invece di una cancellazione silenziosa.
Verificate, poi mettete per iscritto
La dismissione è finita quando un test dall’esterno fallisce come vi aspettate. Da una rete che non controllate, connettetevi al vecchio indirizzo e alla vecchia porta. Un risultato filtrato o rifiutato è il caso di successo. Nell’app del client, confermate che il profilo è stato rimosso e non solo disattivato, e che nessun profilo di gestione lo riaggiunge in silenzio.
Poi registrate ciò che avete fatto: endpoint, data, chiavi e certificati revocati, account disattivati, dove vivono i backup. Chi troverà la prossima volta una vecchia configurazione deve poter rispondere se è stata revocata o solo cancellata, senza indovinare, e una breve tabella nel ticket lo fa.
Prima di chiudere il ticket:
- profili dei client rimossi o sostituiti, dispositivi sconosciuti risolti
- peer rimossi e la configurazione riapplicata, oppure certificati revocati e la CRL pubblicata
- account della directory disattivati, non solo file locali cancellati
- servizio disattivato, nessun listener rimasto sulla vecchia porta
- firewall, inoltro di porta, gruppo di sicurezza e record DNS rimossi
- backup etichettati, snapshot escluso dai percorsi di ripristino
- credenziali di monitoraggio e automazione dismesse
Verificate il sostituto separatamente, da un client che non ha mai avuto il vecchio profilo. Quell’unico test vi dice se avete dismesso un servizio o solo rinominato il problema.