VPNとTURNリレーの違い：WebRTC通話を実際に運ぶのはどちらか
トンネルはICEが見る経路を変えるだけで、リレーを割り当てたりシグナリングを提供したりはしません。VPN出口とTURNサーバーがそれぞれ何を提供するかを比較します。
ページはVPN経由で読み込まれるのに通話は決してつながらない——同じアドレスバーに潜む二つの別の障害である。トンネルが変えたのはブラウザが使う経路だけであり、シグナリングサービスにもSTUNサーバーにもリレーにもなっていないし、ICEがどの候補ペアを選ぶかも決めない。各コンポーネントが担う仕事を切り分けることこそが、曖昧な「WebRTCがブロックされている」を具体的な障害に変える。
四つの仕事のうち、トンネルが触れるのは一つだけ
アプリケーションは何らかのシグナリングの仕組みでセッション情報を交換し、これが第一の仕事である。ICEは候補アドレスを集め、どれかが機能するまでペアを試し、これが第二の仕事である。STUNは相手が自分の通信を外からどう見えるか知ることを可能にし、TURNは直接経路が存在しない場合にリレーを割り当てる。これら四つの役割は別物であり、VPNはそれらが出会うアドレスとフィルタリングに影響するだけで、どれかを提供するわけではない。
だからログインが成功しても、メディアの経路については何もわからない。シグナリングは通常、ページがすでに使っているHTTPSをポート443で流れ、メディアはUDPでまったく別の宛先へ向かうことがある。
プライベートアドレスは混乱を悪化させる。トンネルアドレスは、相手にそこへ戻る意図した経路がある場合にだけ相手にとって有用であり、プライベートであることは相互到達性の証拠ではなく、検査できない候補を捨てるときにブラウザもそうは扱わない。あなたにローカルに見える候補が、相手側からは検査できないこともある。トンネルがメディアを落としていると結論づける前に、その隙間を除外しておく価値がある。
VPN出口とTURNリレーを比較する
どちらもパケットを転送するので混同されるが、上の比較表は機能の一覧としてではなく列ごとに読むべきである。リレーの割り当ては認証された要求によって作られるセッション単位のオブジェクトであり、トンネルは経路である。一方には失効する資格情報があり、他方には到達できるかできないかのどちらかである相手アドレスがある。
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
ポート番号が違いを具体的にする。TURNは既定でUDPとTCPには3478、TLSには5349で待ち受け、443を許可しつつこれらのポートを落とすネットワークでは、閲覧は普通に続くのにリレー経由の通話は失敗する。VPNのポートを変えても、重要なポートはトンネルではなくリレーサービスに属するため、それは何も設定されない。
診断を読み、それから通話を試す
ブラウザはパケットキャプチャなしで必要な情報を公開する。ブラウザのWebRTC診断ページを開き、通話を行い、集めた一覧ではなく選択された候補ペアを読む：どのローカル候補とリモート候補の種類が選ばれ、どのトランスポートとアドレスファミリーを通り、経路が直接かリレー経由かを見る。
二つの読み方を前もって知っておく価値がある。選択されたペアがプライベートアドレスのhost-to-hostならメディアは推論できる経路にとどまっており、relay-to-relayなら通話はリレーの容量を消費しそのサービスの可用性に依存する。選択されたペアがないまま「確認中」で止まる障害は、候補は集まったが接続性チェックを通ったものが一つもないことを意味する。
次に同じ通話で同じ二つの端点を、承認された条件を一つだけ変えて比較し、結果は「接続済み」の表示ではなく双方向のメディアやデータで判断する。候補の収集は、音声を一フレームも運ばない多くの場合に成功する。変更の反対側でも通話を繰り返し両方の診断キャプチャを保存するが、二回の実行を比べるほうがどちらか一方だけを読むより情報が多い。同じ端点、同じコーデック、変えた変数は一つ。
ICEトランスポートポリシーを意図的にrelayに設定したアプリケーションは、リレー候補だけを要求している。その設定はリレーを作らず欠けた資格情報も直さないが、要件を明示するだけであり、サイトが選んだポリシーのせいでVPNが疑われるときに役立つ。
プライバシーの主張は証拠と同じだけ狭く保つ
候補の露出はトンネルの状態だけでなく、ブラウザとアプリケーションのポリシーに依存し、W3Cのピア接続仕様はIPの扱いをそれ自体の関心事としている。したがって接続中のVPNは、通話が選ばれた一つのアドレスしか明かさないと約束する根拠としては弱い。同じトンネルの背後の二者は、ホストを一切出ない経路を選ぶことさえあり、それは同時にプライバシーの改善と接続性の制約である。
正確に言えるのはもっと狭く、もっと有用である：どの候補ペアが選ばれ、どのトランスポートがそれを運び、その経路がトンネル内にとどまったかどうか。動く通話と失敗する通話についてこの三つの事実を記録すれば、違いはたいてい直すべきコンポーネントを名指しする。
接続性が機能したら、性能と到達性を分けて考える。損失、遅延、待ち行列、MTUはすべて正しい候補ペアの下流にあり、途切れる通話を接続性の障害として扱うと、理由もなく候補一覧へ戻ることになる。