WireGuard の鍵ペアをローカルで生成する：コマンドと注意点

WireGuard の鍵ペアは二つのコマンドで生成でき、どちらも標準ツールに含まれているので、鍵を作ってくれるウェブサイトは必要ない。失敗するのは曲線の計算ではなく、パーミッションのビット、ファイルの置き場所、そしてその後に相手側へ送る内容である。以下の手順は空のディレクトリから始まり、通信を運ぶピアで終わる。実行前に一度読み通してほしい、というのも最初の行は次の行が同じシェルで動く場合にしか意味を持たないからだ。

一つのシェルでペアを生成する

文書化された手順は、秘密の値が存在する前にファイル作成を制限し、そのうえで公開の値を導出する。三行は同じシェルセッションにまとめて置く：

umask 077  # applies to files created next, so keep the next line in this shell
wg genkey | tee privatekey | wg pubkey > publickey
wg pubkey < privatekey  # re-derive and compare with publickey

wg genkey は 32 バイトの Curve25519 秘密鍵を base64 で書き出し、wg pubkey はそれを読んで対応する公開鍵を導出し、tee は秘密の値をパイプに流しながら保存する。この順序だからこそパーミッションの行が最初に来るのであり、パイプラインを別の端末に貼り付けるとその行が黙って失われる。ファイル名は例示であり、重要なのは 二つのファイルが所有デバイスの管理下に置かれることだ。秘密鍵のファイルがすでに既定のパーミッションで存在する場合、chmod 600 privatekey は現在のファイルを直すが、以前に作られたコピーには何もしない。

秘密の半分を 一台のデバイスに置く

秘密の値は、そのアイデンティティを所有するマシンの、そのマシンが保護しバックアップが資格情報として扱うディレクトリに置く。共有フォルダ、自分宛てのメッセージ、サポートチケットに添付した抜粋に置くものではなく、埋め込まれたコピーは設定ファイルを鍵と同じくらい機密にする。三か所を渡り歩いた鍵は後から筋道立てて考えられないので、一か所に置く実務上の理由はそこにある。

引退させたファイルを意図的に破棄するのも同じ習慣の一部だ。誰かが気づくまでダウンロードフォルダに残しておくのはそうではない。

ピアの運用者に渡すもの

相手側が必要とするのは公開の値と、その運用者が選んだアドレスの構成だけで、それ以外は要らない。その公開文字列を運用者が想定する経路で送り、誰かが試す前にどのピア項目に紐づけたかを確認する。正しい鍵でも節を間違えれば鍵の問題に見える形で失敗するので、折り返さず一行で送り、二行に割れた鍵は設定ファイルに文句もなく貼り付いたまま二度と一致しない。

鍵を生成しただけでは何も許可されない。ピア側で受け入れる設定が必要であり、その設定はその端を運用する人の仕事である。

実際の交換でペアを確かめる

鍵ペアが特定するのはトンネルの片端だけで、ルートもリゾルバの項目も転送規則もファイアウォールの許可も作らない。ピアを用意したら、ファイルではなく交換を試す。すなわち wg show に現れるハンドシェイク、トンネル内部で応答するアドレス、ルートに依存するアプリケーション要求の三つであり、この三点で誤った鍵と、正しい鍵だが経路が欠けている状態を切り分けられる。

配備が許すなら一台につき一つのアイデンティティを保ち、失った端末だけを取り消せるようにする。全員に鍵を作り直させる必要はなく、その判断が以下の交換手順を安全に実行できる理由でもある。

間を空けずに鍵を交換する

端末で代替の鍵を生成し、新しい公開鍵を追加のピアとして加え、通信を運ぶことを確認してから、はじめて古い鍵を外す。この順序ならトンネルに有効なアイデンティティのない瞬間は生まれず、切り戻しは追加した項目を消すだけで済む。

新しいピアが確認できるまで置き換え前の秘密鍵ファイルを残し、そのあと意図的に破棄する。WireGuard のクイックスタート はコマンド自体の参照資料であり、始める前に全文を読めるほど短い。