Come ripristinare un server VPN senza duplicare le identità

Avete ripristinato il backup, il servizio è partito e un client si è connesso al primo tentativo. Quel successo è la trappola. Un ripristino restituisce i file che il server aveva al momento dello snapshot, non lo stato di accesso cambiato da allora, e se l’endpoint vecchio è ancora raggiungibile ora avete due macchine che rispondono a una sola identità. La soluzione non è un backup migliore; è decidere che cosa può essere l’host ripristinato prima che risponda a una sola stretta di mano.

Un backup restituisce file, non autorità

Lo snapshot contiene la configurazione del server, le chiavi private, l’autorità di certificazione, l’elenco dei peer e le regole del firewall come erano quando è partito il backup. Non può contenere ciò che è cambiato dopo: il dispositivo che avete revocato, la chiave che avete riemesso, il peer che avete rimosso alla vendita di un portatile, la sottorete che avete spostato. Il ripristino riavvolge i file a quel momento. Non riavvolge le decisioni che le persone hanno preso da allora.

Il danno nasce proprio da questo divario. Un portatile rubato e revocato due settimane dopo il backup presenta un certificato che si convalida ancora contro la CRL più vecchia nell’albero ripristinato, e il server accetta un dispositivo che avete dismesso. WireGuard è più diretto: un peer è autorizzato perché è elencato, quindi un peer eliminato dopo lo snapshot è semplicemente di nuovo presente. Nessuno ha riapprovato quell’accesso. Il vecchio file l’ha fatto.

L’identità del server e l’identità del client falliscono in modi diversi

Su WireGuard l’identità del server è la chiave privata in wg0.conf, quindi copiare quel file su un secondo host raggiungibile crea due server con la stessa identità e che non si conoscono. Ognuno tiene il proprio elenco di peer. Rimuovete un peer sull’host nuovo e quello vecchio lo accetta ancora; controllate wg show su uno e vedete metà della verità. Nemmeno i client commutano da soli: un profilo porta un solo Endpoint, quindi un dispositivo continua a parlare con l’indirizzo con cui è stato configurato, che può essere l’host che volevate dismettere.

OpenVPN si duplica allo stesso livello con un certificato server, la sua chiave privata e la chiave statica tls-auth o tls-crypt. Copiate tutte tre e un client non distingue le istanze; se entrambe sono raggiungibili, una riconnessione può finire su una o sull’altra, e ogni file di log racconta una storia parziale. L’autorità di certificazione è la copia più profonda. Un albero easy-rsa ripristinato è una seconda fonte di verità che può emettere un certificato valido per qualsiasi nome gli diate.

Anche i client vengono duplicati, di solito durante la migrazione stessa. Copiare un profilo su un dispositivo di riserva «solo per provare» produce un secondo dispositivo con la stessa chiave e lo stesso nome comune. Con duplicate-cn entrambe le sessioni possono restare attive insieme, e un’assegnazione statica di indirizzo in ccd o ifconfig-pool-persist può entrare in collisione con il dispositivo originale. Sono due macchine con una sola identità, e nulla nella configurazione del server le distingue.

Scegliete uno dei tre stati per l’endpoint vecchio

Un ripristino è sicuro solo quando il destino dell’endpoint vecchio è deciso. Dismettetelo: il servizio vecchio deve smettere di accettare la porta VPN prima che parta l’host nuovo, e se non riuscite a raggiungere la macchina, bloccate quella porta al bordo della rete per tutto tranne la vostra origine amministrativa. Riparate lo stesso host: riusare l’identità va bene perché una sola macchina la detiene, ma poi distruggete la copia su disco o lo snapshot della VM della vecchia chiave perché non possa tornare. Costruite una coppia di disponibilità: due host hanno bisogno di identità host distinte più un endpoint condiviso, come un indirizzo flottante, un bilanciatore di carico o un DNS che potete spostare. Copiare la chiave privata non è un progetto di failover; sono due server che rivendicano un solo nome.

Confermate in quale stato siete davvero prima di toccare i client. L’host vecchio che risponde sulla porta VPN è quello che accetterà il dispositivo revocato, anche se il DNS si è spostato. Controllate gli ascoltatori e la chiave pubblica:

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Riconciliate prima i peer, le revoche e gli indirizzi

Elencate ciò che il ripristino rivendica rispetto a ciò che è attualmente autorizzato. Su WireGuard wg show wg0 dà chiave, endpoint, ultima stretta di mano e contatori di trasferimento di ogni peer, abbastanza per notare un dispositivo che non possedete più. Rimuovetelo a caldo con wg set wg0 peer <key> remove, poi modificate anche la configurazione, altrimenti il peer torna all’avvio successivo. wg show wg0 allowed-ips svela il secondo problema: due peer su un indirizzo, o un indirizzo che avete già riassegnato.

Su OpenVPN l’elenco di revoca è un file con una data, e un ripristino può riportarne uno vecchio. Controllatelo prima che i client si connettano:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

Se l’ultimo aggiornamento precede la revoca, il server sta ancora onorando un certificato che avete revocato. OpenVPN 2.4 e successivi rileggono il file CRL a ogni nuova connessione, quindi sostituire il file ferma le nuove sessioni, ma i tunnel stabiliti persistono fino alla rinegoziazione; il valore predefinito di reneg-sec è 3600 secondi, e abbassarlo o riavviare il servizio è ciò che vi dà subito il cambiamento. Le build più vecchie potrebbero non leggere il file con la stessa affidabilità, quindi riavviate quando non potete confermare il comportamento della versione. Il manuale di wg(8) copre la rimozione dei peer e la sintassi allowed-ips usate sopra.

Pulite anche le assegnazioni statiche dei dispositivi che non esistono più. Riusare l’indirizzo di un dispositivo dismesso per uno nuovo mentre il vecchio profilo è ancora installato crea esattamente il duplicato che cercate di evitare.

Verificate con un client che avete revocato

Eseguite i controlli in ordine, da una rete fuori dal tunnel. Prima un dispositivo autorizzato si connette, risolve il DNS tramite il resolver inviato e raggiunge una risorsa privata. Poi il dispositivo revocato deve fallire, usando il proprio profilo esistente e non uno nuovo. Poi provate l’endpoint vecchio dall’esterno: se la porta VPN completa ancora una stretta di mano, l’host vecchio è vivo e la duplicazione è reale, non teorica.

Riavviate l’host ripristinato e ripetete i controlli autorizzato e revocato, perché è allora che il file di configurazione vince su ciò che avete cambiato a caldo. Confrontate la chiave pubblica o l’impronta del certificato dell’host con quella usata dalla macchina dismessa. Impronte uguali su due macchine vive significano che il ripristino ha clonato l’identità; impronte uguali su una sola macchina sono normali. Annotate le versioni ripristinate, le impronte delle chiavi e il numero di serie o la chiave del peer revocati, poi fate il backup successivo dopo questa riconciliazione, perché rappresenti il servizio com’è ora. Il test che funziona non è che un client si connetta. È che il client che avete rimosso resti fuori mentre l’endpoint vecchio resta chiuso.