WebRTCの候補リストがVPNについて明かすこと

WebRTCのテストページに172.20.4.15と表示されたとき、そのページはそのネットワークにローカルインターフェースが存在することを知っただけです。これは確かな開示ですが、「メディアがVPNの出口から出た」という結論とは別のものです。候補の探索とパケットの経路制御は別の仕組みであり、多くのリーク報告は両者を一つの判定にまとめてしまいます。どちらを見ているかが、対処法を決めます。

収集は何かを送る前に終わる

ブラウザはローカルインターフェースを列挙し、STUNサーバーへバインド要求を送り、TURNサーバーへ割り当てを求め、その結果をセッション記述に候補行として書き込みます。これらはすべて、通話もメディアも相手もないまま完了します。したがって候補の一覧は、転送ではなく発見の記録です。

現代のブラウザは、ホスト候補の実際のアドレスをmDNS名.localに置き換えることがあり、その場合ページはプライベートIPを読めません。ローカルネットワークはその名前を解決するマルチキャスト問い合わせを依然として見ているので、アドレスは回線から消えたのではなく、アプリケーションから隠れているだけです。

順序も重要です。ページを読み込み直すと新しい集合が集められ、TURNの割り当ても反射マッピングも変わる可能性があり、結果が食い違う二回の実行が必ずしも二つの異なる設定とは限りません。

三種類の候補、三種類の証拠

各行はそれぞれ異なる観測から導かれます。種類ごとに答える問いが異なり、表は何を立証できて何を立証できないかでそれらを分けています。

リレー候補はしばしば利用者のインターネットアドレスと取り違えられます。これはTURNサーバーに属するもので、その存在はリレーが利用可能だったことを示すだけで、ブラウザがそれを選んだことを示しません。同じ混同はホスト候補では逆方向に起こり、mDNS名がページからアドレスを隠す一方で、ネットワークは問い合わせを運び続けます。値を読む前に種類を読んでください。

選択されたペアが経路の問いに答える

ICEは各ローカル候補を各リモート候補と組み合わせ、各ペアで接続確認を実行し、勝者を指名します。ブラウザ自身の診断に表示されるその指名されたペアが、メディアを運びます。一覧のその他はすべて、負けた可能性です。

勝者は経路の形を教えてくれます。リレー対リレーはTURNサーバーを通り、ホスト対ホストはローカルネットワークに留まり、サーバー反射のペアはNATを直接通ります。これがVPNの確認に必要な事実であり、アドレス一覧とは別の事実です。同じ候補一覧を持つ二つの通話が、異なるペアを使うこともあります。

選ばれなかった候補も収集されており、収集は端末から出ていくネットワーク通信です。最終的にリレーを使った通話だからといって、一覧の構築中に何も開示されなかったことにはなりません。

制御はリークの点数ではなく目的に対応する

WebRTCのIP処理仕様は、既定ルートを運ぶインターフェースだけを使う、すべてのインターフェースを使う、そしてプロキシされないUDPを無効にして通信をリレーかプロキシ経由に強制する、といういくつかの方針を説明しています。どれも接続性と遅延を、異なる種類の露出と引き換えにします。どの方針をどの名前で実装するかは、プラットフォームとバージョンによって異なります。

方針は目的から選びます。ページからローカルアドレスを隠すことが一つの目的、直接のピア間通信を防ぐことがもう一つ、すべてのパケットをトンネル内に保つことが三つ目です。一つ目は主にアプリケーションが何を知るか、二つ目はどの経路が許可されるか、三つ目はプラットフォームやVPNの境界でも強制する必要があります。

どの制御を選んでも、収集テストを実行して候補の種類を記録し、その後、実際のセッション中に選択されたペアを調べることで、両方の半分を確認してください。直接のメディア経路を伴うきれいなアドレス一覧も、意図しなかった経路のままです。