VPNサーバーのバックアップ：何を復元可能にすべきかを決める

構成ファイルをコピーすることはバックアップではなく、誰も復元できないバックアップは計画ではない。アーカイブには、サービスのID、それを取り巻くポリシー、そしてどのデバイスがまだ許可されているかを示す状態が含まれていなければならない。また保護も必要である。ほとんどの配備では、アーカイブはVPNが与えるものとまったく同じ権限を与えるからだ。何を復元可能にすべきかを決めることが先であり、ファイル一覧はその決定から導かれる。

再構築の目標から始める

一つのファイルも列挙する前に、再構築したサーバーが何をすべきかを書き出す。同じトンネルを終端し、同じIDを提示し、現在失効しているデバイスを拒否することだ。この一文だけで、ほとんどの安易なコピーは排除される。構成ディレクトリには失効リストや外部のID依存がほとんど含まれないからだ。さらに、ホストの外にある部分、たとえばDNSレコード、クラウドファイアウォールのルール、ゲートウェイが認証を行うディレクトリも明らかになる。これらを無視した計画は、健全に見えるのに誰も通さない復元済みサーバーを生む。

素材を三つのバケツに分ける。ID、構成、状態である。IDとは鍵、証明書、そしてそれらに署名する機関だ。構成とはデーモンの設定、プール、ルート、ファイアウォールポリシーであり、状態とは毎日変わるピア、アカウント、失効の集合だ。

IDは再生成できない部分である

秘密鍵は記憶から再現できず、それに依存する証明書は選んだのではなく受け継いだスケジュールで失効する。サーバー鍵、クライアントの配備素材、認証局をバックアップし、そのうちどれをオフラインに保つべきかを記録する。稼働中のゲートウェイにしか存在しない機関鍵は、全クライアントのIDを完全にリセットするまであと一つの侵害でしかない。意図的に別の場所に保管しているものも記録し、誰かがより低い保護のアーカイブに複製しないようにする。

失効は計画の中で独自の行を持つべきだ。昨日の構成を復元すると、今日削除したIDが復活しうる。これは復旧をセキュリティ事故に変えてしまう。現在の失効状態は、戻す先のスナップショットとは独立した場所に保ち、復元のたびに確認する。

状態を一瞬でスナップショットする

サービスが書き込み中に取ったコピーは一貫性のない棚卸しを生み、一貫性のないIDデータは古いきれいなコピーより悪い。各ストアでサポートされたエクスポート経路を使い、その後スナップショットの時刻を記録する。復元に関するその後のあらゆる問いはその時刻に依存するからだ。

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だけが読めるため、これは重要だ。マニフェストがあれば、完全なアーカイブと切り詰められたアーカイブを区別できる。

復元を可能にしてから試す

アーカイブを暗号化し、復元鍵はそれが生まれたマシンとは別の場所に置く。パスフレーズが故障したサーバーにしか存在しないバックアップは、誰も開かないバックアップだ。取得はゲートウェイを管理できた人だけに限定し、取得のたびに記録する。復元は隔離されたネットワークで試す。本番の隣で起動した複製IDは、同じピア鍵に応答する二つのサーバーを作ってしまうからだ。

除外項目は内容と同じくらい丁寧に文書化する。クラウドファイアウォールのルール、DNSレコード、外部ディレクトリはそれぞれ独自の復旧手順を必要とするかもしれない。ファイルのコピーが成功しても、サービスが戻る証拠にはならない。意味のある唯一の証拠は、元と同じ受け入れテストを通過する再構築済みのエンドポイントだ。