Copie de siguranță a serverului VPN: decideți ce trebuie să fie restaurat
Identitatea, configurația și starea sunt trei probleme diferite de copiere. Decideți mai întâi ținta reconstrucției, capturați un singur moment și abia apoi testați restaurarea.
Copierea unui fișier de configurare nu este o copie de siguranță, iar o copie pe care nimeni nu o poate restaura nu este un plan. Arhiva trebuie să conțină identitatea serviciului, politica din jurul lui și starea care spune ce dispozitive sunt încă permise. Trebuie și protejată, pentru că în majoritatea implementărilor arhiva acordă exact ce acordă VPN-ul. Decizia privind ce trebuie să fie restaurat vine prima; lista de fișiere decurge din acea decizie.
Începeți cu ținta reconstrucției
Scrieți ce trebuie să facă un server reconstruit înainte de a lista un singur fișier: să închidă aceleași tuneluri, să prezinte aceeași identitate și să refuze dispozitivele care sunt în prezent revocate. Această frază exclude majoritatea copiilor naive, pentru că un director de configurare conține rareori lista de revocări sau dependența externă de identitate. Ea expune și părțile care trăiesc în afara gazdei, cum ar fi înregistrările DNS, regulile de firewall din cloud și directorul față de care poarta se autentifică. Un plan care le ignoră produce un server restaurat care pare sănătos și nu admite pe nimeni.
Grupați materialul în trei coșuri: identitate, configurație și stare. Identitatea sunt cheile, certificatele și autoritatea care le semnează. Configurația sunt setările demonului, pool-urile, rutele și politica de firewall, iar starea este ansamblul de parteneri, conturi și revocări care se schimbă în fiecare zi.
Identitatea este partea pe care nu o puteți regenera
Cheile private nu pot fi recreate din memorie, iar certificatele care depind de ele expiră după un calendar pe care îl moșteniți, nu îl alegeți. Faceți copie a cheii serverului, a materialului de aprovizionare a clienților și a autorității de certificare, apoi notați care dintre ele trebuie să rămână offline. O cheie de autoritate care trăiește doar pe poarta aflată în funcțiune este la un compromis distanță de o resetare completă a identității pentru fiecare client. Înregistrați ce este păstrat deliberat în altă parte, ca nimeni să nu îl dubleze într-o arhivă cu protecție mai mică.
Revocarea merită propria linie în plan. Restaurarea configurației de ieri poate reinstala o identitate pe care ați eliminat-o astăzi, ceea ce transformă o recuperare într-un incident de securitate. Păstrați starea actuală de revocare într-un loc independent de instantaneul la care ați reveni, și verificați-o după orice restaurare.
Capturați starea într-un singur moment
O copie făcută în timp ce serviciul scrie produce un inventar inconsecvent, iar datele de identitate inconsecvente sunt mai rele decât o copie curată mai veche. Folosiți calea de export acceptată pentru fiecare depozit, apoi înregistrați momentul instantaneului, pentru că orice întrebare ulterioară despre restaurare depinde de el.
wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST
Prima comandă tipărește interfața în execuție înapoi ca configurație, ceea ce este cea mai rapidă cale de a captura partenerii adăugați manual, nu cu un instrument de administrare; acest lucru este documentat în manualul wg(8). Linia sqlite este modelul pentru o bază de date de administrare: comanda de copiere produce o copie consecventă în timp ce scriitorul continuă. Copia directorului păstrează permisiunile, ceea ce contează pentru că acele fișiere de chei pot fi citite doar de root. Manifestul este ceea ce vă permite să distingeți o arhivă completă de una trunchiată.
Faceți restaurarea posibilă și apoi încercați-o
Criptați arhiva și păstrați cheia de recuperare în alt loc decât mașina de pe care a venit. O copie a cărei frază de acces există doar pe serverul defect este o copie pe care nimeni nu o va deschide. Limitați obținerea la persoanele care puteau deja administra poarta, și înregistrați fiecare obținere. Testați restaurarea într-o rețea izolată, pentru că o identitate clonată ridicată lângă producție creează două servere care răspund pentru aceeași cheie de partener.
Documentați excluderile la fel de atent ca și conținutul. Regulile de firewall din cloud, înregistrările DNS și un director extern pot avea fiecare nevoie de propriul pas de recuperare. O copie de fișiere reușită nu este dovada că serviciul revine; singura dovadă care contează este un punct final reconstruit care trece același test de acceptare ca originalul.