WireGuardキーローテーションをゼロダウンタイムで実施する設計

なぜWireGuardのキーローテーションが求められるのか

WireGuardはシンプルさと高速性を武器に普及したVPNプロトコルです。しかし「鍵は一度設定したら変えない」という運用が定着しているサイトも少なくありません。TLSの場合は証明書に有効期限が設けられており、自動的に更新を迫られる仕組みがあります。一方でWireGuardの静的鍵ペアにはそのような仕組みがないため、放置すれば同じ鍵が何年も使われ続ける状況が生まれやすいのです。

セキュリティインシデントの観点から見ると、秘密鍵が漏洩した場合の被害範囲（ブラストラジウス）を最小化するためにも、定期的なローテーションは有効な対策です。ISO 27001やゼロトラストアーキテクチャを意識した社内ポリシーとして「暗号鍵は○か月ごとに更新する」という要件を設けているケースも増えています。また、退職したエンジニアが持ち出した設定ファイルに古い鍵が残っているリスクへの対処としても、定期ローテーションは意義があります。

WireGuardの鍵構造とローテーション時の難所

WireGuardが扱う鍵はいくつかの種類に分類できます。それぞれの役割を整理しておくことが、ローテーション設計の土台になります。

• 静的鍵ペア（PrivateKey / PublicKey）：ピアの身元確認に使われる主要な鍵です。長期間変わらない前提で設計されていますが、これが定期ローテーションの主な対象となります。
• 事前共有鍵（PreSharedKey / PSK）：ポスト量子暗号への対策として任意で設定できる対称鍵です。静的鍵ペアとは別に管理し、こちらも定期更新が推奨されます。

ローテーションの難所は、WireGuardがピアをその公開鍵で識別していることにあります。ピアAがピアBの設定ファイルに書いているのは「ピアBの公開鍵」であり、新しい公開鍵に差し替えた瞬間に既存のトンネルは切断されます。単純に鍵を差し替えるだけでは、両端の設定を同時に更新しない限りダウンタイムが発生してしまいます。

また、systemctl restart wg-quick@wg0のようなサービス再起動を行うと、既存セッションがすべて切断されます。wgコマンドにはリロード機能がありますが、使い方を誤るとやはり通信断が生じます。これがゼロダウンタイムの実現を難しくしている根本的な要因です。

ゼロダウンタイム設計の基本方針：新旧鍵の並走期間を設ける

ダウンタイムなしでキーを交換するための基本的な考え方は、「新旧の鍵を一時的に並走させる」ことです。具体的には、ローテーション対象のピアに対して、リモート側のピア設定に旧公開鍵と新公開鍵の両方を一時的に登録しておき、ローカル側が新しい秘密鍵で接続を確立できたことを確認してから旧鍵のエントリを削除するという流れになります。

このアプローチで重要なのがwg syncconfコマンドです。wg syncconf wg0 /etc/wireguard/wg0.confのように使うと、既存のトンネルを切断せずに設定の差分だけを反映させることができます。wg-quick down / upによるフルリロードとは異なり、セッションを維持したまま設定変更が可能です。これがゼロダウンタイム設計の要となるコマンドです。

もう一つの原則として、手順は必ず「リモート先行・ローカル後」の順序で進めることが重要です。リモート側（接続相手のピア）に新公開鍵のエントリを追加してから、ローカル側の秘密鍵を新しいものに切り替えます。逆の順番にすると、ローカルが新しい秘密鍵で送信し始めた時点でリモートがその公開鍵を認識できず、接続が確立できなくなります。

実際の手順：ピアを止めずに鍵を交換する

以下は、ピアAがピアBの鍵をローテーションする場合の代表的な手順です。

ステップ1：新しい鍵ペアを生成する

ピアBのホスト上で新しい鍵ペアを生成します。wg genkey | tee /etc/wireguard/new_private.key | wg pubkey > /etc/wireguard/new_public.keyを実行し、新しい秘密鍵と公開鍵を安全な場所に保管します。生成した秘密鍵ファイルのパーミッションはchmod 600で必ず制限してください。この段階では既存の設定には一切手を加えません。

ステップ2：リモート側（ピアA）に新公開鍵のエントリを追加する

ピアAの設定ファイルに、ピアBの新しい公開鍵を持つ[Peer]セクションを追加します。このとき、旧公開鍵のエントリは削除しないまま残します。AllowedIPsが重複するとカーネルルーティングで競合が起きるため、スター型のトポロジであればサーバ側の設定に両エントリを一時登録し、wg syncconf wg0 /etc/wireguard/wg0.confで反映させます。この時点では旧トンネルは生きたままです。

ステップ3：ローカル側（ピアB）の秘密鍵を切り替える

ピアBの/etc/wireguard/wg0.conf内のPrivateKeyを新しいものに書き換えます。その後、wg syncconf wg0 <(wg-quick strip wg0)を使ってトンネルを落とさずに設定を反映させます。wg-quick stripはwg-quick専用のディレクティブ（DNS、PostUpなど）を除去して純粋なwgコマンド用の設定に変換してくれるため、このパイプが安全なリロードを実現します。

ステップ4：旧鍵エントリを削除してクリーンアップする

新しい鍵での接続確認が取れたら、ピアAの設定から旧公開鍵のエントリを削除し、再度wg syncconfで反映します。ピアBのホスト上にある旧秘密鍵ファイルもこの段階で安全に削除します。PSKを利用している場合は、このタイミングで新しいPSKも生成・配布することを検討してください。

動作確認と切り戻し手順

ステップ3の後、まずwg show wg0でハンドシェイクの状態を確認します。latest handshakeの行に直近のタイムスタンプが表示されれば、新しい鍵でトンネルが確立できています。表示が更新されない場合はwg show wg0 peersで認識されているピアの公開鍵を確認し、期待する鍵が登録されているかを照合してください。

疎通確認にはpingやcurlなど用途に応じた方法を使いますが、特に重要なのはパケットカウンタの変化をwg show wg0のtransfer行で追うことです。送受信バイトが増加していれば通信は正常に行われています。

切り戻しが必要になった場合は、ピアBの設定ファイルを旧秘密鍵に戻し、wg syncconfで再反映します。ピアAが旧公開鍵のエントリをまだ保持していれば、そのまま旧トンネルが復活します。このため、ステップ4のクリーンアップは接続の安定が確認できるまで少なくとも5〜10分は待ってから実施することが現場での通例です。旧秘密鍵ファイルも、切り戻し期間中は削除せずに保管しておくべきです。

2026年現在の環境差分と自動化ツールの動向

2026年時点では、WireGuardの設定管理を取り巻くエコシステムが成熟しており、手動での鍵ローテーションをそのまま続ける必然性は薄れつつあります。

systemd-networkdのWireGuardサポートは継続的に改善されており、.netdevファイルベースの設定でも動的更新が可能になっています。networkctl reloadコマンドがネットワーク設定の差分反映を担うため、wg-quickに依存しない運用環境でも同様の手順を踏むことができます。

Headscale（Tailscaleのセルフホスト実装）やNetbirdなどのコントロールプレーン実装は、鍵の配布と更新をAPIやコントローラで自動化する仕組みを備えています。これらは内部的にはWireGuardを使いながら、鍵ローテーションをユーザーが意識しない形で実施してくれます。小規模な固定トポロジであれば素のWireGuardを使い続ける合理性はありますが、ピア数が増えてきたサイトではコントロールプレーン層の導入を検討する価値があります。

ポスト量子暗号（PQC）対応という文脈でも鍵ローテーションへの関心は高まっています。WireGuardのPSK機能を活用したポスト量子対応の実験実装が進んでおり、PSKを短いサイクルで更新するユースケースが想定されるようになっています。Harvest Now Decrypt Later攻撃への備えとして、長期鍵のローテーション頻度を引き上げる動きも一部の組織で見られます。

自動化スクリプトを自前で組む場合は、Ansible Roleとして手順を定義し、鍵ファイルをAnsible VaultやHashiCorp Vaultで管理するパターンが実績のある方法です。ロールの中で旧公開鍵の追加・新鍵での接続確認・旧鍵の削除というステップを順番に実行し、各ステップの前後でwg showの出力をパースして状態を検証するロジックを組み込むことで、ローテーション作業を安全に定型化できます。作業ログをきちんと残しておくことも、監査要件への対応という観点から重要です。