WireGuard は本番運用に耐えるか？答えはプロトコルではない

人が WireGuard は本番運用に耐えるかを尋ねるとき、それは暗号の話に見えて、実はあなたの環境の話である。プロトコルは何年も検討されてきたが、配備側はいまだに答えなければならない。自社網がそのトランスポートを運ぶのか、誰が端末を登録し廃止するのか、どちらの端でも誰がパッケージに修正を当てるのか。その答えは、一つのラックの二台のサーバーと千台のノート PC では違ってくる。プロトコルはどちらでも同じだが、運用は同じではない。

問いの裏にある問い

人が普通に知りたいのは、半年後に恥をかかない設計に賭けられるかどうかである。これは四つの部分からなる配備の問いであり、各部分は他とは独立に失敗しうる。三つにうまく答えても四つ目を取り戻せない。

公開前スナップショットに関する古い警告は、そのスナップショットについての事実であって、その後に出るすべてのパッケージに貼られた永久の札ではない。同様に、どのブログ記事も、あなたの特定のカーネル・クライアント・網・要員の組み合わせを準備完了とは宣言できない。仕事はその組み合わせを明示し、確かめることである。

準備状況は、通すか、開いたまま記録するかの関門の集合として扱う。そうすれば議論は担当者のいる確認表に変わる。さらに 承認する人に対して未解決項目を見えるようにする。試験報告に埋もれさせるのではなく。

第一の関門：経路が UDP を運ぶこと

WireGuard は自らの通信を UDP で運び、TCP モードも通信の難読化も提供しないと明記している。普通のウェブ通信に見えることに頼る設計や、TCP の挙動を得るためにポートを変える設計は、ソフトウェアが支えない前提の上に成り立っている。

したがって第一の関門は調査であり、一台での試験ではない。利用者が実際に働く接続環境を列挙し、それぞれで承認済みの UDP 経路を確かめ、それが使えないときに何が起きるかを決める。

オフィスからつながることは、ホテルの網、大学のファイアウォール、UDP の扱いが違う携帯事業者について何も証明しない。試験が成功した後に遠隔接続の配備が失敗するのは、こうした環境のせいである。試験は間違っていなかった。狭かったのだ。それを広げることが関門である。

代替経路も書き留める。代替がないという答えなら、出張中に発見するのではなく、あらかじめ宣言する価値のある決定である。

第二の関門：誰かが鍵を所有すること

WireGuard のピアは鍵で認証し、参加者ごとに一対となる。説明は簡単だが運用は厳しい。プロトコルには端末を登録する仕組みも、誰がどの鍵を持つかを追う仕組みも、ノート PC を失ったときに接続を外す仕組みもない。プロトコルは鍵がすでに正しいと前提しており、正しさは誰かの仕事である。

端末を登録する人、公開鍵を人と端末に対応づける記録、削除の手順を名指しする。削除が、設定ファイルの複製をどこに入れたかの記憶に依存しているなら、手順は終わっていない。

試験の間に一台を選び、最初から最後まで廃止してみる。この演習は、もう一度の接続試験より有用な情報を生む。記録の穴が露わになるからだ。

第三の関門：パッケージに保守担当が要る

WireGuard はカーネル内の実装、ディストリビューションのパッケージ、あるいはユーザー空間のクライアントとして届きうる。どれも更新の経路が異なる。運用上の問いは、どれを動かしているのか、どこから来たのか、誰がセキュリティ勧告を当てるのかである。

我々は WireGuard を使っているというのは棚卸しではない。修正すべきパッケージも、ゲートウェイ上の版も、まずい更新を巻き戻せる人も示さない。

第四の関門：受け入れるのは作業負荷であり、ハンドシェイクではない

受け入れ基準は利用者が何をするかを述べるべきである。社内アプリに到達する、その私有名を解決する、許可されない宛先で拒否される、トンネルが落ちているときに定められた挙動に従う。どれも観察でき、成功したハンドシェイクはそのどれでもない。

これらの確認は、網の変更、端末の再起動、ゲートウェイの保守時間帯を通して実行する。配備が壊れるのはそうした移行のときだからだ。

証拠はそれを生んだローカル状態も含め、基準のそばに置く：

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

静かな網で一台のノート PC による緑の試験は、出発点の観察である。信頼性の主張ではなく、そう扱うことこそが、動く設計を信頼される設計に変えてしまう道である。