初回起動時における WireGuard デバイス群の登録

共通イメージ、ボードごとの鍵、そしてデバイス自身の主張を信用しない承認手順。起動から確定済み peer までの四段階。

ボードは共通イメージから起動し、DHCP リースを取得し、誰もデバイスに触れる前にプロビジョニングスクリプトが実行される。そのスクリプトのどこかで、このボードだけに属し他のどのボードにも属さない WireGuard アイデンティティを取得し、そのアイデンティティを承認させ、ゲートウェイが受け入れるプロファイルを書き込む必要がある。イメージはクライアントソフトウェア、レビュー済みのテンプレート、ゲートウェイの公開鍵を運ぶことができる。決して運んではならないのは、フリート全体で共有される一つの秘密鍵であり、それでは盗まれたボード一枚がフリート全体のインシデントになる。以下の順序はアイデンティティをローカルに保ち、承認を明示的にする。

イメージが運ぶもの、運ばないもの

パッケージ、プレースホルダー入りのテンプレート、ゲートウェイの公開鍵、登録クライアントを同梱する。テンプレートは形であって秘密ではなく、プロビジョニングユーザーが読めるべきであり、鍵素材を含んではならない。

秘密鍵は初回起動時にデバイス上で生成され、決して外に出ない。外を移動するのは公開半分だけで、デバイス自身が自分は誰かと主張する以外の何かによって承認される登録リクエストの中に入る。この区別が、盗まれたボードをフリート全体の問題にしない。そしてこれが、ほとんどの初回起動スクリプトが間違える部分でもある。

ステップ 1: 鍵をローカルで生成する

基盤となるネットワーク接続が承認され動作した後に、保護されたディレクトリで生成を実行する。サブシェルは umask の変更をこの操作に限定し、set -C は既存ファイルの上書きを拒否する:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

WireGuard クイックスタート は、この二つのコマンドが依存する鍵生成の関係を文書化している。生成が中断された場合は、デバイスを未登録のままにし、ワークフローにファイルを整合させる。スクリプトを最初からきれいに通すためだけに既存のアイデンティティを削除してはならない。

再試行をまたいで保留中の鍵を保持する。一時的なネットワーク障害のたびにアイデンティティを再生成することは、フリートが誰もデバイスと照合できない孤立した peer を抱える理由である。

ステップ 2: デバイスレコードを承認する

インベントリがこのボードを device-042 と呼び、10.90.0.42/32 を割り当てているとする。登録サービスは、この要求者がそのレコードの権利を持つことを検証しなければならない。フォームに入力されたシリアル番号は、箱の外側に印刷されているのだから証明にならない。

デバイスごとのブートストラップ資格情報、オペレーターの承認、またはハードウェアに裏打ちされたアテステーションが主張を確立できる。要求の完全性と応答の真正性を保護し、一つの共有 VPN シークレットを一つの共有ファクトリー資格情報で置き換えてはならない。

登録されたレコードは、デバイス、その公開鍵、割り当てられたアドレス、許可された管理ロールを結びつける。WireGuard 自体は登録 API を定義していないため、そのサービスは意図的に構築し運用するものになる。

ステップ 3: 対応する二つの設定を書く

デバイスには管理プレフィックスをトンネルへルートするプロファイルが必要であり、ゲートウェイにはこのデバイス自身の送信元アドレスだけを許可する peer エントリが必要である。ゲートウェイが 10.90.0.1、管理ネットワークが 10.60.0.0/16 の場合、デバイス側は次のようになる:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

角括弧内の値はプレースホルダーであり、鍵ではない。keepalive はボードが NAT の背後にあり到達可能であり続ける必要がある場合に重要だが、どこでも必要というわけではなく、習慣で追加すると理由もなく無線を起動したままにする。

ゲートウェイ側では、peer エントリは意図的に狭い:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

デバイスの宛先リストをゲートウェイの peer にコピーしてはならない。デバイスではそのリストは何をトンネルへルートするかを示し、ゲートウェイではこの peer がどの送信元アドレスを使えるかを示す、別の表明だからだ。

転送、ファイアウォール規則、管理ネットワークへの戻り経路は、依然として承認されたアクセスを許可しなければならない。登録済みの peer は、その背後のすべてのアプリケーションに対する許可ではない。

ステップ 4: 登録をライフサイクルの状態として確定する

ゲートウェイのレコードとデバイスプロファイルを、それぞれの設定を所有する主体を通して適用し、意図したアイデンティティとアドレスが受け入れられたときにだけ登録を完了と印付ける。再試行は二つ目の peer や二つ目のアドレスを割り当てるのではなく、同じレコードを整合させるべきである。

中断したプロビジョニングのための復旧経路を、ゲートウェイが鍵を受け入れたのにデバイスがプロファイルを書かなかった場合も含めて用意する。

ボードが交換または退役するときは、その公開鍵と承認をまとめて削除する。新しい鍵は意図的な再登録イベントであり、再イメージの副作用ではない。作業順序: ローカルで生成し、インベントリに対して承認し、両側を書き、状態を確定し、その後トンネル経由で管理リクエストを一つ試す。

関連記事