OpenVPN と WireGuard、どちらを選ぶ？ 身元と転送方式から決める

鍵、ログインの流れ、UDP のみの転送が、スループットよりはるかに早く選択を形づくる。四つの確認を行い、測定を誠実に保つ。

これら二つのプロトコルを比べるのは、実際に運用するもの同士を比べるときだけ意味がある。WireGuard はピアを公開鍵で識別し、UDP 上でプロトコルを運び、一方で OpenVPN は認証の方式をより広く備え、サーバーが両方を提供していれば UDP でも TCP でも動く。これらの違いは、スループットを形づくるよりずっと早く、構築と代替経路を形づくる。以下の四つの確認を順番に行い、最初の二つがたいてい選択を決め、最後の二つがその判断が正しかったかを教えてくれる。

暗号の一覧ではなく、身元から始める

WireGuard のピアは秘密鍵を一つ持ち、到達できる公開鍵を列挙する。提供者はその周りにアカウントポータルをかぶせられるが、プロトコル自体にユーザー名とパスワードのやり取りはないので、アカウントのライフサイクルは鍵を配る仕組みの中に住む。OpenVPN は証明書、既存のディレクトリに対するプラグイン、検証スクリプトを使えるので、身元の仕組みを持つ組織はしばしばこちらを好む。どちらの設計も、失った端末をどう外すかという問いを消しはしない。

DecisionOpenVPNWireGuard
IdentityCertificates, plugins or scripts against an existing directoryOne private key per peer, public keys listed for the peers it may reach
TransportUDP or TCP profiles when the server offers bothUDP only in the native protocol
Routing and DNSServer pushes routes and DNS optionsAllowedIPs maps ranges to peers, and tooling installs the routes
Where it usually breaksProfile mismatch, expired certificate, failing pluginBlocked UDP, wrong AllowedIPs, key not installed

短い設定は、簡単な構築と同じではない。一つの秘密鍵を複数の人に渡すと、鍵を取り消せば全員が一度に外れるため、後からの解除が曖昧になる。選ぶ前に、人と鍵または証明書の対応を書き出しておけば、プロトコルの判断はずっと楽になる。

次に、転送方式が何を許すかを見る

WireGuard のプロトコルは UDP を使う。OpenVPN のサービスは UDP と TCP の両方のプロファイルを用意できることがあり、UDP を遮断したり劣化させたりする網では、その二つ目の選択肢が理論ではなく実用的な代替経路になる。サーバーが選んだプロファイルに対応している必要があり、ポート番号を変えてもトンネルが HTTPS になるわけでも、ファイアウォールが通すようになるわけでもない。

TCP の中に TCP を運ぶと、損失時の振る舞いも変わる。両方の層が独立に再送と並べ替えを行うためで、制限の厳しい網で動く TCP プロファイルでも損失のある網では性能が悪いままになるからこそ、片方を優れていると宣言するのではなく、両方のプロファイルを用意しておく理由になる。

次に、経路と名前解決を確認する

WireGuard の AllowedIPs はアドレス範囲をピアに対応づけ、プロトコル内部の経路判断として働き、周辺の道具は経路を入れるときにその範囲を使う。OpenVPN はサーバーから経路と DNS の設定を押し出す。どちらの場合も、意図した方針が半分しか適用されていないのにクライアントが上がってくることがある。

ip route show
ip -6 route show
resolvectl status
wg show

接続済みの表示を信じる前に出力を読む。ip route show はクライアントが IPv4 向けに何を入れたかを一覧し、IPv6 の版は片方の一族しか運ばないトンネルを捕まえる。resolvectl status はクライアントが実際に問い合わせる解決器を示し、wg show は WireGuard が自分のものと考える AllowedIPs を印字する。経路が全面の被覆を主張しているのに解決器がまだローカル網を指しているなら、DNS はトンネルの外に出ている。

次に、気にかけている作業を測る

端末、網、宛先を一定に保ち、使ったクライアントと端点を記録する。二つのサービスが別の都市から出ていたり、別のハードウェアで動いていたりするなら、その結果はプロトコルではなくそれらのサービスを語るので、そう書く。

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

両方のコマンドを二度ずつ、プロファイルの組ごとに一度、同じ網と同じ端末で実行する。iperf3 はスループットの数字を与え、mtr は経路と損失がどこに出るかを与え、どちらもダウンロードの数字一つでは示せない。ダウンロードの数字は、増えた遅延や揺らぎ、再接続にかかる時間といった、通話が気づくものも落とす。これらは、スループットで勝つプロトコルが実際に走らせる作業では負けることがあるため、別に記録する。

管理された接続では、互換性、支援、更新の手間が小さな比較の差を上回ることがある。個人の出口では、事業者の記録と司法管轄がプロトコルの名札より重い。どちらのプロトコルも良い接続を運べるが、何が得られるかはサービスとその設定が決める。

試す前にプロファイルの組を書き出す

測る前にプロトコルごとに一つのプロファイルを選び、それぞれが何をするべきか——私的な部分網だけか、それとも特定の出口を通る全通信か——を書く。分割トンネルのプロファイルと全体トンネルのプロファイルを比べる試験は、プロトコルではなくプロファイルを測っている。クライアント名、クライアントの版、出口の場所を同じ覚え書きに入れる。

次に同じ作業を両方で、同じ網で、同じ対話の中で実行する。片方がまったく接続できないなら、その失敗が結果であり、理由とともに記録に入る。記録はサービスの文書と一緒に置き、次の人が最初からやり直すのではなく同じ組を比べられるようにする。

関連記事