VPNを貫通する「透明な壁」：WebRTC IP Leakの正体と深層防御のエンジニアリング
VPNを導入した。完璧な暗号化トンネルの中に身を置き、公共Wi-Fiの脅威から解放された……そう信じて疑わないテックリードの諸君、あるいはインフラの守護者たちよ。もし君がブラウザのデフォルト設定を放置しているなら、そのVPNトンネルは、特定の条件下で「ザル」と同義だ。
今回は、VPNの構築技術そのものよりも、エンドポイントであるブラウザが抱える暗部――WebRTCによるIPアドレス漏洩（WebRTC IP Leak）について、パケットレベルの挙動から叩き込んでいこうと思う。
—
1. なぜ「トンネル」はバイパスされるのか：STUN/ICEの挙動
WebRTCは、ブラウザ間でのリアルタイム通信を実現するために設計されたプロトコルスタックだ。ここで重要な役割を果たすのが、NAT越えのためのICE（Interactive Connectivity Establishment）フレームワークと、その背後で動くSTUN（Session Traversal Utilities for NAT）プロトコルである。
問題の核心はここにある。WebRTCは「最も効率的な通信経路」を自律的に発見しようとする。この探索プロセスにおいて、ブラウザは自身のネットワークインターフェース情報を列挙し、STUNサーバを介してパブリックIPアドレスを特定しようとするのだ。
この挙動が厄介なのは、ブラウザがVPNトンネル（仮想NIC）を無視して、OSのルーティングテーブルに存在する物理インターフェース（物理NIC）のIPをWebRTCスタックに引き渡してしまう場合があるからだ。
パケットレベルの視点
パケットキャプチャを覗けば一目瞭然だ。STUNバインディングリクエストは、VPNの仮想インターフェースを通らず、OSのデフォルトゲートウェイを直接叩くように発信されることがある。アプリケーション層（WebRTC）が、ネットワーク層（VPN）のポリシーを考慮せず、ホストの全インターフェースに対して「自分は誰か？」を問いかけてしまうためだ。結果として、VPNで隠したはずのグローバルIPが、JavaScriptのRTCPeerConnection APIを通じてWebサイト側のサーバへと送出される。
—
2. 脆弱性としてのWebRTC：対策のアーキテクチャ
この事象は「脆弱性」というよりは「ブラウザの仕様」に近い。しかし、ゼロトラストの文脈では、許可していないインターフェースからの通信はすべて拒否対象だ。
ブラウザ設定による封じ込め
最も即効性があるのは、ブラウザ側のAPI制御だ。Firefoxであればabout:configから、Chrome系であれば拡張機能やポリシー設定で制御を行う。
Firefoxの設定例
media.peerconnection.enabled を false に設定するのが最も手っ取り早い。しかし、Web会議システムが動かなくなるというトレードオフがある。そこで、より細やかな制御を行う。
# 物理IPの漏洩を防ぐためのFirefox設定
# media.peerconnection.ice.proxy_only: true にすると、
# プロキシ経由の通信のみを許可する（VPN環境で有効）
user_pref("media.peerconnection.ice.proxy_only", true);
# STUNサーバを介したローカルIPの列挙を抑制
user_pref("media.peerconnection.ice.no_host", true);エンタープライズレベルの防御：iptables/nftablesによる強制遮断
ブラウザの設定変更をクライアントに強要できない場合、OSレベルでWebRTCのトラフィックを制御する必要がある。特に、VPNクライアントが特定のポート範囲でSTUN通信を行う場合、それを物理NIC経由で流さない設定が有効だ。
# VPN接続中にWebRTCによる物理NIC経由の通信を破棄するポリシー（例）
# 仮想インターフェース(tun0)以外からのSTUN通信(3478/udp)をドロップ
sudo iptables -A OUTPUT -o eth0 -p udp --dport 3478 -j DROP
sudo iptables -A OUTPUT -o wlan0 -p udp --dport 3478 -j DROP—
3. パフォーマンスとセキュリティの最適化：その先の視座
VPNとWebRTCの併用は、単にIPを隠せば良いというものではない。TCPバッファのチューニングやTLSハンドシェイクの最適化を怠れば、WebRTC特有の「パケット揺らぎ」が顕著になり、QoS（Quality of Service）が著しく低下する。
特に、MTU（Maximum Transmission Unit）の不一致には注意が必要だ。VPNトンネルによるヘッダー付与でオーバーヘッドが増大し、WebRTCのDTLS-SRTPパケットがフラグメント化されると、CPU負荷が急増しRTT（Round Trip Time）が跳ね上がる。
推奨するネットワークスタックのチューニング
Linuxカーネルにおいて、VPN経由のストリーミング性能を向上させるための設定パラメーターの一例を挙げる。
# TCPウィンドウサイズの拡大（高レイテンシ環境でのスループット改善）
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# パケットロス耐性の強化と輻輳制御の最適化（BBRアルゴリズムの適用）
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbrBBR（Bottleneck Bandwidth and Round-trip propagation time）は、WebRTCのようなリアルタイム通信において、パケットロスを輻輳と誤認させないための強力な武器となる。VPNという「論理的なボトルネック」を抱える環境において、これらは必須のチューニングと言える。
—
結びに代えて：境界防御の哲学
WebRTC IP Leakは、我々に「境界防御の終焉」を突きつけている。どれほど堅牢なVPNトンネルを構築しても、ブラウザという「巨大なアプリケーション層」が穴を開ければすべてが水の泡だ。
真のセキュリティスペシャリストであれば、VPNの導入だけで満足してはならない。エンドポイントの挙動をパケットレベルで解釈し、OSのネットワークスタックとアプリケーションの協調を制御する――。その泥臭い積み重ねこそが、現代のインフラにおける唯一の防壁となる。
君のネットワークが次に通信するのは、信頼できるピアであるか、それとも覗き見をしている誰かであるか。パケットは、嘘をつかない。
コメント