DNSリーク
サイトにアクセスする前に、デバイスはドメインをIPに名前解決します。この段階でプロキシを経由しないと、その後の接続が暗号化され正しくプロキシを経由していても、ISPのリゾルバーにはアクセスしたすべてのドメインが見えてしまいます。
よくある原因は、システムレベルのDNS設定がプロキシのルールより優先されている、またはプロキシクライアントがそもそもDNSを引き受けていないことです。
TLS接続のフィンガープリント
JA4 / JA3 — クライアントのTLSハンドシェイクの特徴
TLSハンドシェイクのフィンガープリントを取得中…
使い方
IPリークとは何か、プロキシをオンにしていても起こる理由
リークとは、プロキシやVPNを経由しているはずの通信の一部がそれを迂回してローカルネットワークから送信され、相手に実際のIPを渡してしまうことです。プロキシクライアントが「接続済み」と表示していても、すべてのリクエストがその管理下にあるとは限りません。
WebRTCリーク
WebRTCはブラウザーに組み込まれたピアツーピア通信の仕組みで、ビデオ通話や画面共有はこれで動いています。直接接続を確立するため、WebRTCはSTUNサーバーに「自分のグローバルアドレスは何か」を問い合わせますが、このリクエストはプロキシを迂回することがあります。
その結果、ページにはプロキシのIPが見える一方で、WebRTCは実際のIPを渡してしまいます。これは典型的なリークで、最も見落とされやすいものです。
IPv6リーク
多くのプロキシはIPv4しか処理しません。ネットワークにIPv6もあり、接続先が対応している場合、ブラウザーはIPv6の直接接続を優先することがあり、プロキシはまったく関与しなくなります。
見分け方は簡単です。このページにIPv4とIPv6が両方表示され、それぞれ別のネットワークに属していれば、通信が2つのスタックに分かれています。
タイムゾーンと整合性
厳密にはこれはリークではなく矛盾です。システムのタイムゾーン、ブラウザーの言語、IPの位置は一致しているべきです。アメリカのIPなのに時計がUTC+8であれば、それだけで強いシグナルになります。リスク判定システムに必要なのはあなたの実際のIPではなく、IPを偽装している証拠だけです。
よくある質問
リークが見つからなければ安全ですか？
このチェックの対象となる経路が、現時点でクリーンであることを意味します。拡張機能、ほかのアプリケーション、システムアップデートによって新たなリーク経路が生じることもあるため、何かを変更したら再テストしてください。
DNSリークはどう修正すればよいですか？
まず、プロキシクライアントで「プロキシ経由でDNSを解決する」などのオプションを有効にしてください。それができない場合は、システムのDNSをプロキシが提供するアドレスに向けてください。ブラウザーのセキュアDNS設定を変更しても、効果があるのはそのプロセスだけです。
WebRTCはオフにすべきですか？
オフにすることはおすすめしません。WebRTCのないChromium系ブラウザーは、それ自体が識別されやすくなります。代わりに、使える経路を制限してください。Chrome / Edgeでは企業ポリシーWebRtcIPHandlingをdisable_non_proxied_udpに設定し、Braveでは「プロキシを経由しないUDPを無効化」を選択し、Firefoxではabout:configでmedia.peerconnection.ice.proxy_only_if_behind_proxyを有効にします。最も確実なのは、プロキシクライアントのTUNモードを使うことです。
IPv6リークにはどう対処すればよいですか？
プロキシにIPv6も処理させるか、システムのネットワーク設定でIPv6を無効にしてください。後者のほうが確実ですが、IPv6専用のサービスが使えなくなります。