Com restaurar un servidor VPN sense duplicar identitats

Heu restaurat la còpia de seguretat, el servei s’ha iniciat i un client s’ha connectat al primer intent. Aquest èxit és el parany. Una restauració retorna els fitxers que el servidor tenia en el moment de la instantània, no l’estat d’accés que ha canviat des de llavors, i si l’extrem antic encara és accessible ara teniu dues màquines responent a una identitat. La solució no és una còpia millor; és decidir què pot ser l’amfitrió restaurat abans que respongui a un sol intercanvi.

Una còpia de seguretat torna fitxers, no autoritat

La instantània conté la configuració del servidor, les claus privades, l’autoritat de certificació, la llista de parells i les regles del tallafoc tal com eren quan es va fer la còpia. No pot contenir el que va canviar després: el dispositiu que vau revocar, la clau que vau reemetre, el parell que vau eliminar quan es va vendre un portàtil, la subxarxa que vau moure. Restaurar rebobina els fitxers fins a aquell moment. No rebobina les decisions que les persones han pres des de llavors.

El dany ve exactament d’aquest buit. Un portàtil robat revocat dues setmanes després de la còpia presenta un certificat que encara es verifica contra la CRL més antiga de l’arbre restaurat, i el servidor accepta un dispositiu que vau retirar. WireGuard és més directe: un parell està autoritzat pel fet de ser a la llista, així que un parell esborrat després de la instantània simplement torna a ser-hi. Ningú no va tornar a aprovar aquell accés. El fitxer antic ho va fer.

La identitat del servidor i la identitat del client fallen de maneres diferents

A WireGuard la identitat del servidor és la clau privada de wg0.conf, així que copiar aquest fitxer a un segon amfitrió accessible crea dos servidors amb la mateixa identitat i sense conèixer-se. Cadascun manté la seva pròpia llista de parells. Elimineu un parell a l’amfitrió nou i el vell encara l’accepta; comproveu wg show en un i veieu la meitat de la veritat. Els clients tampoc no commuten sols: un perfil porta un sol Endpoint, així que el dispositiu continua parlant amb l’adreça amb què es va configurar, que pot ser l’amfitrió que volíeu retirar.

OpenVPN es duplica a la mateixa capa amb un certificat de servidor, la seva clau privada i la clau estàtica tls-auth o tls-crypt. Copieu les tres i un client no pot distingir les instàncies; si totes dues són accessibles, una reconnexió pot caure en qualsevol, i cada fitxer de registre explica una història parcial. L’autoritat de certificació és la còpia més profunda. Un arbre easy-rsa restaurat és una segona font de veritat que pot emetre un certificat vàlid per a qualsevol nom que li doneu.

Els clients també es dupliquen, normalment durant la mateixa migració. Copiar un perfil a un dispositiu de reserva «només per provar» produeix un segon dispositiu amb la mateixa clau i el mateix nom comú. Amb duplicate-cn les dues sessions poden romandre actives alhora, i una assignació d’adreça estàtica a ccd o ifconfig-pool-persist pot xocar amb el dispositiu original. Són dues màquines amb una identitat, i res a la configuració del servidor no les distingeix.

Trieu un dels tres estats per a l’extrem antic

Una restauració només és segura quan el destí de l’extrem antic està decidit. Retireu-lo: el servei antic ha d’aturar l’acceptació del port VPN abans que arrenqui l’amfitrió nou, i si no podeu arribar a la màquina, bloquegeu aquell port a la vora de la xarxa per a tot excepte la vostra font administrativa. Repareu el mateix amfitrió: reutilitzar la identitat és correcte perquè una sola màquina la té, però després destruïu la còpia en disc o la instantània de la VM de la clau antiga perquè no pugui tornar. Construïu una parella de disponibilitat: dos amfitrions necessiten identitats d’amfitrió diferents més un extrem compartit, com una adreça flotant, un balancejador de càrrega o un DNS que pugueu moure. Copiar la clau privada no és un disseny de failover; són dos servidors que reclamen un sol nom.

Confirmeu en quin estat sou realment abans de tocar els clients. L’amfitrió antic que respon al port VPN és el que acceptarà el dispositiu revocat, encara que el DNS s’hagi mogut. Comproveu els oients i la clau pública:

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

Primer reconcilieu parells, revocacions i adreces

Enumereu què afirma la restauració enfront del que està autoritzat ara. A WireGuard, wg show wg0 dóna la clau, l’extrem, l’últim intercanvi i els comptadors de transferència de cada parell, cosa suficient per detectar un dispositiu que ja no posseïu. Elimineu-lo en viu amb wg set wg0 peer <key> remove, i després editeu també la configuració, o el parell torna a la propera arrencada. wg show wg0 allowed-ips exposa el segon problema: dos parells en una adreça, o una adreça que ja heu reassignat.

A OpenVPN, la llista de revocació és un fitxer amb una data, i una restauració pot recuperar-ne una d’antiga. Comproveu-la abans que els clients es connectin:

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

Si l’última actualització és anterior a la revocació, el servidor encara està respectant un certificat que vau revocar. OpenVPN 2.4 i posteriors rellegeixen el fitxer CRL per a cada connexió nova, així que substituir el fitxer atura les sessions noves, però els túnels establerts persisteixen fins a la renegociació; el valor per defecte de reneg-sec és 3600 segons, i baixar-lo o reiniciar el servei és el que us dóna el canvi ara. Les compilacions antigues poden no recollir el fitxer tan fiablement, així que reinicieu quan no pugueu confirmar el comportament de la versió. El manual de wg(8) cobreix l’eliminació de parells i la sintaxi allowed-ips utilitzades més amunt.

Netegeu també les assignacions estàtiques de dispositius que ja no existeixen. Reutilitzar l’adreça d’un dispositiu retirat per a un de nou mentre el perfil antic encara és instal·lat crea exactament el duplicat que voleu evitar.

Verifiqueu amb un client que hàgiu revocat

Executeu les comprovacions en ordre, des d’una xarxa fora del túnel. Primer un dispositiu autoritzat es connecta, resol el DNS a través del resolutor empès i arriba a un recurs privat. Després el dispositiu revocat ha de fallar, utilitzant el seu perfil existent i no un de nou. Llavors proveu l’extrem antic des de fora: si el port VPN encara completa un intercanvi, l’amfitrió antic és viu i la duplicació és real, no teòrica.

Reinicieu l’amfitrió restaurat i repetiu les comprovacions d’autoritzat i revocat, perquè és llavors quan el fitxer de configuració guanya sobre el que vau canviar en temps d’execució. Compareu la clau pública o l’empremta del certificat de l’amfitrió amb la que va fer servir la màquina retirada. Empremtes coincidents en dues màquines vives volen dir que la restauració va clonar la identitat; empremtes coincidents en una màquina són correctes. Registreu les versions restaurades, les empremtes de les claus i el número de sèrie o la clau de parell revocats, i feu la còpia següent després d’aquesta reconciliació, perquè representi el servei tal com és ara. La prova que funciona no és que un client es connecti. És que el client que vau eliminar quedi fora mentre l’extrem antic queda tancat.