【実務・中級編】 WebRTCリークの仕組みとブラウザにおけるSTUN/TURNの制御 – サイバーセキュリティとプライバシー保護実践ガイド

はじめに：VPNを過信しているエンジニアが直面する「WebRTCの罠」

おい、ちょっと聞いてくれ。先週、あるクライアントのセキュリティ診断を手伝っていたんだが、そこで面白い（いや、エンジニアとしては冷や汗ものの）現象に遭遇した。

その企業は、リモートワーク中の社員に強固な有料商用VPNを強制し、社内リソースへのアクセスはすべてトンネル経由で行わせていた。完璧なゼロトラストの布陣……に見えた。しかし、私がブラウザを開き、とある検証用の一行スクリプトを走らせた瞬間、画面にはその社員の「ISPから割り当てられた生グローバルIPアドレス」と、なんと社内LANの「プライベートIPアドレス（192.168.xxx.xxx）」が綺麗に露出しやがったんだ。

VPNの接続ランプは青々と光り、IP確認サイトを見てもVPNのロケーションが表示されている。なのに、だ。なぜこんなことが起きたのか？

犯人は、現代のブラウザに標準実装されているリアルタイム通信規格、WebRTC（Web Real-Time Communication）だ。

今回は、インフラエンジニアやWebアプリケーション開発者なら絶対に知っておくべき、WebRTCの裏側とIPアドレスリークのメカニズム、そして現場で即座に使える対策について、実務の視点から徹底的に解説しよう。

—

1. なぜVPNを貫通するのか？WebRTCとSTUN/TURNの仕組み

そもそも、なぜVPNがバイパスされてしまうのか。原因を理解するには、WebRTCがブラウザ上でどうやってピア間の通信経路を確立しているかを知る必要がある。

WebRTCは、プラグインなしでブラウザ間での音声・動画通話やデータ共有を実現するための強力なAPIだ。サーバーを介さずに直接ピア同士で通信（P2P）するためには、双方の「到達可能なネットワークアドレス」を迅速に見つけ出さなければならない。

ここで登場するのが、以下のプロトコルとサーバー群だ。

  • ICE (Interactive Connectivity Establishment): 最適な通信経路（候補＝ICEカディデート）を動的に見つけ出すためのフレームワーク。
  • STUN (Session Traversal Utilities for NAT): クライアントが「自分自身のグローバルIPアドレスとポート（NATの外部からどう見えているか）」を調べるためのプロトコル。
  • TURN (Traversal Using Relays around NAT): 対称型NATなどの厳しいルーター環境でP2Pが直接結べない場合に、中継サーバーとしてパケットをフォワードするプロトコル。

通信フロー（シーケンス）の裏側

ブラウザでWebRTCのセッションが初期化されると、ICEエージェントは裏側で以下のプロセスを高速で実行する。

1. ホスト候補の収集: ホスト自身のOSが持つネットワークインターフェース（有線、Wi-Fi、仮想VPNアダプターなど）から、すべてのローカルIPアドレス（プライベートIP）を列挙する。
2. サーバ反射候補の収集: 設定されたSTUNサーバーへUDPのバインド要求を投げ、NAT越えした先の「サーバー側から見た自分のグローバルIPとポート」を学習する。
3. シグナリングサーバー経由の交換: 収集したこれらのアドレス情報（ICEカディデート）を、WebSocketなどのシグナリングチャネルを介して通信相手に教え合う。

ここで重要なのは、WebRTCのIPアドレス収集プロセスは、OSのルーティングテーブルやVPNのルーティングポリシーを完全に無視して、直接NICやSTUNサーバーへリクエストを飛ばす仕様になっている点だ。

つまり、OSレベルで「すべてのトラフィックをVPNインターフェースへ強制」していても、ブラウザのJavaScriptエンジンが直接ローカルのハードウェアインターフェースを叩いてSTUNサーバーと通信してしまうため、VPNのトンネルの脇をすり抜けて本当のIPが露出してしまうのである。これが、いわゆる「WebRTCリーク」の正体だ。

—

2. 実践：ブラウザからIPが漏洩する瞬間をコードで確認する

百聞は一見にしかず。実際にブラウザ上でどのようにIPアドレスが列挙されるのか、ミニマムなJavaScriptコードを使って確認してみよう。

実務のデバッグや、自社サービスの脆弱性診断の際にブラウザのコンソール（F12キーを押してConsoleタブ）に貼り付けて実行してほしい。

// STUNサーバーを指定してRTCPeerConnectionを初期化する
const rtcConfig = {
    iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
};

const pc = new RTCPeerConnection(rtcConfig);
const ips = new Set();

// ダミーのデータチャネルを作成してICEプロセスの収集トリガーを引く
pc.createDataChannel("leak-test");

// ICEカディデートが生成されるたびにイベント発火
pc.onicecandidate = (event) => {
    if (!event.candidate) {
        console.log("--- 収集完了 ---");
        console.log("検出されたすべてのIP/候補:", Array.from(ips));
        return;
    }

    // カディデート文字列から正規表現でIPアドレスを抽出
    const candidateStr = event.candidate.candidate;
    const ipMatch = candidateStr.match(/([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9:]+:+[a-f0-9:]+)/);
    
    if (ipMatch) {
        const ip = ipMatch[1];
        if (!ips.has(ip)) {
            ips.add(ip);
            console.log(`[検出] タイプ: ${event.candidate.type}, IP: ${ip}`);
        }
    }
};

// オファーを作成してローカルディスクリプションに設定（ICE収集開始）
pc.createOffer()
    .then(offer => pc.setLocalDescription(offer))
    .catch(err => console.error("エラー発生:", err));

このスクリプトをコンソールで実行すると、ほんの数秒で次のようなログが出力されるはずだ。

  • [検出] タイプ: host, IP: 192.168.1.50 （ローカルのプライベートIP）
  • [検出] タイプ: srflx, IP: 203.0.113.195 （ISPやVPNをバイパスした実際のグローバルIP）

これが、VPNユーザーがWebサービスにアクセスした際、意図せず自身のネットワーク環境を露呈してしまうメカニズムだ。

—

3. インフラ・アプリ開発者が打つべき「決定的な対策」

さて、この問題に対して、インフラエンジニアやWebアプリケーション開発者はどうアプローチすべきか。ユーザー側のブラウザ設定に依存する方法と、サーバーサイド・ネットワーク設計で担保する方法の2つがある。

A. ブラウザおよびクライアント側の対策

エンドユーザー（特にセキュリティに敏感なリモートワーカー）に対しては、以下の対策を指導、あるいはポリシーとして強制する必要がある。

1. ブラウザ拡張機能の利用:

  • FirefoxやChrome向けに、WebRTCのIPリークを防ぐ拡張機能（「WebRTC Leak Prevent」など）を導入し、iceServer のリクエストをブロックまたは制御する。

2. ブラウザのフラグ（設定）変更:

  • Chromeの場合: フラグやエンタープライズポリシーで WebRTCIPHandlingPolicy を設定する。
  • ポリシー値として default_public_interface_only （プライベートIPを隠す）や disable_non_proxied_udp （プロキシ経由以外のUDPを無効化し、STUNを実質的に遮断）を指定する。

Chromeエンタープライズポリシー（JSON）の例

社内PCを一括管理している情報システム部門であれば、レジストリやポリシーファイルで以下のように強制するのが最も確実だ。

{
  "WebRTCIPHandlingPolicy": "disable_non_proxied_udp"
}

> 実務Tips: このポリシーを適用すると、VPN接続時にUDPトラフィックがプロキシ（またはVPNのルーティング）経由に強制されるため、WebRTCによるローカルIPおよび真のグローバルIPのリークを根絶できる。

—

B. Webアプリケーション設計におけるSTUN/TURNサーバーの制御

もしあなたが自社でWebRTCを用いたリアルタイムコミュニケーションアプリ（ビデオ会議システムやオンラインサポートツールなど）を設計・運用している立場なら、サーバーサイドのコードや設定でセキュリティを担保しなければならない。

特に、クライアントに任意のSTUNサーバーを勝手に使わせず、自社で制御されたTURNサーバーを経由させる設計が必須だ。

以下は、Python（Flask等）を想定した、クライアントへセキュアな一時的TURN認証情報（Ephemeral Credentials）を発行するAPIのサンプルコードだ。

import hmac
import hashlib
import base64
import time
from flask import Flask, jsonify

app = Flask(__name__)

# coturnなどのTURNサーバー設定で共有されるシークレットキー
TURN_SECRET_KEY = "your_super_secret_turn_key_here"
TURN_SERVER_URL = "turn:turn.example.com:3478"

def generate_turn_credentials(username_prefix, ttl_seconds=86400):
    """
    coturnのREST API認証方式に則った一時的なユーザー名とパスワードを生成する
    """
    timestamp = int(time.time()) + ttl_seconds
    username = f"{timestamp}:{username_prefix}"
    
    # HMAC-SHA1でパスワードを署名する
    message = username.encode('utf-8')
    secret = TURN_SECRET_KEY.encode('utf-8')
    signature = hmac.new(secret, message, hashlib.sha1).digest()
    password = base64.b64encode(signature).decode('utf-8')
    
    return {
        "username": username,
        "password": password,
        "ttl": ttl_seconds
    }

@app.route('/api/get-ice-servers', methods=['GET'])
def get_ice_servers():
    """
    クライアントからの要求に応じて、安全に制御されたTURN/STUNサーバーのリストを返す
    """
    creds = generate_turn_credentials("enterprise_user")
    
    ice_config = {
        "iceServers": [
            {
                "urls": ["stun:stun.example.com:3478"]
            },
            {
                "urls": [f"{TURN_SERVER_URL}?transport=udp", f"{TURN_SERVER_URL}?transport=tcp"],
                "username": creds["username"],
                "credential": creds["password"]
            }
        ],
        # プライバシー保護のため、ICEのポリシーをリレー（TURN）のみに制限することも検討する
        "iceTransportPolicy": "all" 
    }
    
    return jsonify(ice_config)

if __name__ == '__main__':
    app.run(port=5000, debug=False)

この設計のポイントは、クライアントに生のネットワークトポロジーを直接露出させず、自社の管理下にあるTURNサーバーを強制する（あるいは iceTransportPolicy を relay に絞る）ことで、プライベートIPや直のグローバルIPの露出を防ぐという点にある。セキュリティとリアルタイム性のトレードオフにはなるが、エンタープライズ向けの厳格な環境では検討すべきアーキテクチャだ。

—

おわりに：境界防御の幻想を捨て、エンドポイントと仕様の本質を見極めよ

「VPNに入っているから安全だ」という神話は、現代の多様化したブラウザ機能の前に何度も打ち砕かれてきた。WebRTCのIPリークはその氷山の一角に過ぎない。

ネットワークスペシャリストやインフラエンジニアである我々は、「パケットが実際にどのレイヤーを通り、どのAPIによってカプセル化され、どのハードウェアインターフェースを叩いているのか」を常に想像力を持って追わなければならない。

教科書通りの設定だけで満足せず、自分の手でブラウザのコンソールを開き、パケットをキャプチャし、仕様の隙間を突き詰めること。それこそが、真にセキュアなシステムを作り上げる唯一の道なのだ。さあ、今すぐ自分のブラウザでもWebRTCリークが起きていないか、試してみるといい。

スポンサーリンク

コメント

タイトルとURLをコピーしました