Резервна копија VPN сервера: одлучите шта мора бити обновљиво
Идентитет, конфигурација и стање су три различита проблема резервне копије. Прво одлучите циљ поновне изградње, снимите један тренутак, затим тестирајте обнову.
Копирање конфигурационе датотеке није резервна копија, а копија коју нико не може да обнови није план. Архива мора да садржи идентитет услуге, политику око ње и стање које говори којим уређајима је још дозвољено. Такође мора да буде заштићена, јер у већини поставки архива даје тачно оно што даје VPN. Одлука о томе шта мора бити обновљиво долази прва; списак датотека следи из те одлуке.
Почните од циља поновне изградње
Запишите шта обновљени сервер мора да ради пре него што наведете иједну датотеку: прекида исте тунеле, представља исти идентитет и одбија уређаје који су тренутно опозвани. Та реченица искључује већину наивних копија, јер конфигурациони директоријум ретко садржи списак опозива или спољну зависност идентитета. Она такође открива делове који живе изван хоста, попут DNS записа, правила cloud заштитног зида и директоријума према којем гејтвеј проверава аутентичност. План који их занемари даје обновљени сервер који изгледа здраво и никог не пушта.
Групишите материјал у три корпе: идентитет, конфигурација и стање. Идентитет су кључеви, сертификати и орган који их потписује. Конфигурација су подешавања демона, групе, руте и политика заштитног зида, а стање је скуп вршњака, налога и опозива који се мења сваки дан.
Идентитет је део који не можете поново да генеришете
Приватни кључеви не могу поново да се створе из сећања, а сертификати који зависе од њих истичу по распореду који наслеђујете, а не бирате. Направите резервну копију кључа сервера, материјала за снабдевање клијената и цертификационог органа, па забележите који од њих треба да остану изван мреже. Кључ органа који живи само на активном гејтвеју удаљен је један компромис од потпуног ресетовања идентитета за сваког клијента. Забележите шта се намерно чува другде да то нико не дуплира у архиву слабије заштите.
Опозив заслужује свој ред у плану. Обнављање јучерашње конфигурације може да врати идентитет који сте данас уклонили, што обнову претвара у безбедносни инцидент. Држите тренутно стање опозива на месту независном од снимка на који бисте се вратили, и проверите га након сваке обнове.
Снимите стање у једном тренутку
Копија снимљена док услуга пише даје недоследан инвентар, а недоследни подаци идентитета гори су од старије чисте копије. Користите подржани пут извоза за свако складиште, па забележите време снимка, јер свако касније питање о обнови зависи од њега.
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
Прва наредба исписује активно сучеље назад као конфигурацију, што је најбржи начин да ухватите вршњаке додате ручно, а не управљачким алатом; то приручник wg(8) документује. Линија sqlite је узорак за управљачку базу: наредба за резервну копију ствара доследну копију док писац наставља да ради. Копија директоријума чува дозволе, што је важно јер те кључне датотеке може да чита само root. Манифест је оно што вам омогућава да разликујете потпуну архиву од скраћене.
Омогућите обнову, па је испробајте
Шифрујте архиву и чувајте кључ за опоравак негде другде, а не на машини са које је дошао. Резервна копија чија лозинка постоји само на неуспелом серверу је копија коју нико неће отворити. Ограничите добављање на људе који су већ могли да администрирају гејтвеј, и бележите свако добављање. Тестирајте обнову на изолованој мрежи, јер клонирани идентитет подигнут уз продукцију ствара два сервера која одговарају на исти кључ вршњака.
Документујте изузетке једнако пажљиво као садржај. Правила cloud заштитног зида, DNS записи и спољни директоријум могу сваки да захтевају сопствени корак опоравка. Успешно копирање датотека није доказ да се услуга враћа; једини доказ који се рачуна је обновљена крајња тачка која пролази исти прихватни тест као оригинал.