Technical Notes
リークテストでは、Webの出口、WebRTC、DNS、IPv6、環境の一貫性をあわせて確認します。ここでは、本当のリークと、正常なルーティングの振り分けやプロキシモードによる見かけ上の現象を見分ける方法を解説します。
WebRTCはブラウザーに組み込まれたリアルタイム通信機能で、ビデオ会議、音声通話、P2Pファイル転送などに使われます。ピアツーピア接続を確立するため、ブラウザーはSTUNサーバーを通じて、インターネット側から見た自分のアドレスを調べます。この問い合わせには通常UDPが使われますが、一般的なHTTP / SOCKSプロキシは必ずしもUDPを処理しません。
STUNリクエストがプロキシを迂回してローカルネットワークから直接送信されると、Webページのスクリプトが実際のグローバルIPを取得できてしまう可能性があります。この処理には通常カメラやマイクの許可が不要で、追加の確認ダイアログも表示されないため、プロキシがリアルタイム通信のトラフィックまで本当にカバーしているかの確認によく使われます。
このページは複数のSTUNサーバーに対してWebRTCのプローブを試み、返されたグローバルアドレスを収集してHTTP出口IPと比較します。返されたアドレスが現在の出口と一致すれば、UDPの経路はプロキシが処理している可能性が高く、ローカルのキャリアのアドレスが返された場合は詳しく調べる必要があります。
UDPはコネクションレス型のトランスポートプロトコルで、音声、ビデオ、ゲーム、リアルタイム通信によく使われます。STUNの役割はシンプルで、サーバーにUDPパケットを送ると、サーバーから見えた送信元IPを返してくれます。WebRTCはこの結果をもとに接続をネゴシエートするため、STUNから見えたアドレスがリークを判断する重要な証拠になります。
スプリットトンネルを設定している場合、STUNサーバーごとに異なるノードを経由することがあります。たとえば、GoogleのSTUNは米国の出口、CloudflareのSTUNは香港の出口を経由する、といった具合です。これは必ずしも危険ではなく、重要なのはルール設計どおりかどうかです。本当に注意すべきなのは、すべてのWebRTCアドレスが物理的な所在地やローカルのISPを示している場合です。
WebRTCリークで露出するのは「実際のIP」、DNSリークで露出するのは「どのドメインを問い合わせたか」です。DNSリクエストがプロキシを経由しない場合、ローカルのキャリアや上流のリゾルバーから、どのサイトにアクセスしたかが見えてしまいます。
このページのDNSリーク検出は実際のプローブを使用しています：CleanIP.ioは米国ユタ州（ns1）と米国ロサンゼルス（ns2）にそれぞれ権威NSを1台ずつ運用し、dp.cleanip.ioゾーンを提供しています。検出のたびに8つの独立した<uuid>.dp.cleanip.ioサブドメインを名前解決します。これらのクエリはシステムのスタブリゾルバー -> ISP / VPN / パブリック再帰リゾルバーを経由して最終的に当社の権威NSに届き、問い合わせ元リゾルバーのIPと（あれば）EDNS Client Subnetを記録したうえで、比較のためにお返しします。
注目すべきシグナルは2つです。①ECSサブネット：再帰リゾルバーがクライアントのサブネットを転送している場合（Google 8.8.8.8でよく見られます）、そのサブネットはクライアントの身元を示す決定的な証拠になります。②リゾルバーの国：パブリック再帰リゾルバー（1.1.1.1 / 8.8.8.8）が国をまたいでエニーキャストされるのは正常です。重要なのは、VPNを有効にしているつもりのときに、リゾルバーの位置がHTTP出口と同じ国かどうかです。
HTTP / SOCKSプロキシは通常TCPしか扱わないため、STUNに必要なUDPを送信できず、ページに「リークなし」と表示されることがあります。これはUDPが安全にプロキシされたことを意味するのではなく、UDPがSTUNサーバーに届かなかっただけです。TUNモードは仮想ネットワークアダプター上でTCPとUDPの両方を引き受けるため、実際のUDPの出口経路をより正確に反映します。
実際に使用しているネットワークモードで再テストすることをおすすめします。普段TUNを使っているならTUNでテストし、ブラウザーのプロキシに頼っている場合は、UDPがブロックされただけなのに安全と誤判定していないかも確認してください。WebRTCリークを判断する際は、返されたIPのASN、位置、そしてスプリットトンネルの想定と一致しているかに注目してください。