Proxmox の LXC か VM で WireGuard を動かすなら、どこに置くべきか
WireGuard は Proxmox ホスト、コンテナ、VM のいずれでも動かせます。決め手はカーネルの所有権、インターフェースの制御、復旧のしやすさです。
WireGuard は、そのインターフェースを所有するカーネルをちょうど一つ必要とします。この事実だけで、性能の話に入る前に Proxmox での配置の議論の大半は決着します。LXC コンテナはホストカーネルの名前空間ビューであり、VM は自前のカーネルを起動します。したがって有益な問いは、どの選択肢が軽いかではなく、どのカーネルを変更する覚悟があるか、どの復旧経路と共存できるかです。そこに答えれば、ホスト・コンテナ・VM のどれにするかはおおむね自然に決まります。
LXC ゲストはホストカーネルの内側で動く
コンテナ内に wireguard-tools を導入しても手に入るのは制御プログラムであり、専用カーネルではありません。作成した wg0 インターフェースはホストのネットワークスタックに登録され、ホストのモジュール一覧に現れます。そのためホストカーネルにモジュールがなければ、コンテナはパッケージ検査をすべて通過しても最初の wg コマンドで失敗します。そして Proxmox のコンテナリファレンス は、その共有カーネルの仕組みと、作業する名前空間・権限の境界を説明しています。
第二の制約は権限です。インターフェースを立ち上げてアドレスを付けるには、それを所有する名前空間の中でのネットワーク管理権限 が必要で、非特権コンテナはその権限を直接持つのではなくユーザー名前空間を通して写像します。最初の答えとして完全な特権に手を伸ばしてはいけません。コンテナに実際に何をさせるのかを見て、それだけを与えます。
ホストカーネルもまた共有の依存先です。Proxmox のカーネル更新は全コンテナの下の WireGuard 実装を一度に変えます。これは更新とコンテナの期待が食い違うまでは便利です。
ホスト・コンテナ・VM:各配置が実際に何を所有するか
ホスト配置は VPN をハイパーバイザー自身のネットワークに置く。ルート、ファイアウォール規則、トンネルがホストの復旧の一部になり、そこの誤りは管理インターフェースも巻き込みます。コンソールで到達できるホストのインフラルーティングなら許容できますが、アウトオブバンドアクセスのない遠隔機では苦痛です。
コンテナはサービスをパッケージ化して再起動可能に保ちながら、ホストカーネルを借ります。意図的に共有カーネルを使うサービスに向き、作り直せる小さな単位を与えます。独立したカーネルは与えないので、特定のモジュールビルドが必要なものはこの選択肢から外れます。
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM はより多くのメモリと、もう一つのパッチ適用対象を要しますが、その代わりにトンネルは専用カーネル、専用ルーティングテーブル、スナップショットの境界を得ます。まずい変更の後に VPN を巻き戻すなら、そのスナップショットは追加コストに見合います。
あなたの代わりに選んでくれる三つの条件
トンネルが Proxmox ホストにないカーネル版や WireGuard 機能を必要とするなら、ここで止めて VM を使ってください。コンテナに新しいカーネルを入れられませんし、一つのゲストのためにハイパーバイザーのカーネルを置き換えるべきでもありません。
トンネルが実 LAN プレフィックスのサイトゲートウェイなら、戻りのルートをすでに誰が持つかを尋ねてください。コンテナもトラフィックをルーティングできますが、そのインターフェースはホストのスタックに載るため、計画していなくてもホストが設定の一部を背負います。ホスト配置はこの点で正直です。コンテナ配置はしばしばそうではありません。
次に、誤りの影響範囲を量ります。コンテナの再起動は安く、VM スナップショットの復元は予測でき、ホストのネットワーク修復は物理的またはコンソールアクセスを要することがあります。正しい選択は、起きたその時間に最悪の場合から本当に復旧できるものです。
四つ目の問いは決め手になることは少ないものの、述べておく価値があります。ホスト上の他の何かがトンネルインターフェースを見る必要があるか。あるなら、ホスト配置かコンテナ配置がその可視性を局所に保ち、VM はゲストとホストの間のルーティングを強います。
トラフィックを通す前に配置を証明する
導入後に、どのカーネルが実際にインターフェースを提供しているか、コンテナにそれを保つだけの権限が与えられたかを確認します:
$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0次にホストから転送側を確認します。ハンドシェイクだけではトンネルが上がっていることしか示さないからです。クライアントアドレスには ip route get を使い、次のホップとインターフェースが設計と一致すること、遠端に戻り経路があることを確かめます。
配備は書面の所有者とともに残してください。どのカーネルが実装を担い、どの名前空間がインターフェースを保持し、どのプレフィックスをゲートウェイが転送してよいのか。その一文は、三つの配置のどんなベンチマーク比較よりも多くの事故を防ぎます。