Tor Browser は自分の接続をローカルのプロキシ経由で送って Tor ネットワークへ流し込みますが、マシンの残りは動かしません。メールクライアント、同期のデーモン、そしてふたつ目のブラウザーは、もとからある設定をそのまま保つので、ひとつのウィンドウで清潔な結果が出ていても、その背後に直接接続が残っていることがあります。四つの確認が、覆われているものと、覆われているように見えるだけのものを分けます。まずプロセスの名前を挙げる確認から始めてください。

ブラウザーが実際にプロキシする範囲

ブラウザーの内部では、通信は Tor Browser が自分のために起動するローカルの SOCKS リスナーへ向かい、ブラウザーはそれを使うよう設定されています。回線の選択、身元の分離、指紋対策はすべてその組み合わせの中にあります。ディスクに保存したファイルはそのどれも持ちませんし、そのファイルを外部のビューアーで開けば、独自のネットワーク挙動を持つ新しいプログラムが起動します。

よく知られた公開アドレスのページがほとんど何も証明しないのも、そのためです。そのページは、自分を読み込んだブラウザーが使った出口を報告するだけで、別のアプリケーションを観測することはまったくできません。結果はひとつのプログラムについての証拠として扱い、デバイスについての断定とは考えないでください。

どのプロセスが各接続を持っているか

ソケットと、その背後にあるプロセスを一覧します。ローカルのリスナーと通信しているブラウザー以外のものがないか探してください:

ss -tunp
ss -tunp | grep -E 'tor|firefox'

公開の宛先を持つものは、回線を迂回した接続です。見つけたら、修正はクライアントごとに違うので、ほかを変える前にそのプログラムを特定してください:

curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip

-hostname の形が重要なのは、名前の解決をプロキシに求めるからです。ローカルで解決してプロキシにアドレスを渡すと、接続そのものがプロキシ経由でも、宛先が明らかになります。

プロトコルがそもそも運ばれるかどうか

Tor のリレーが運ぶのは TCP のストリームです。UDP を前提に作られたアプリケーション、たとえば一部の音声通話やゲームのクライアントは、ネットワーク上でウェブページのようには振る舞いませんし、プロキシに無理に通そうとしても、守るどころか失敗するのがふつうです。

Coverage modelWhat it coversWhat it leaves alone
Tor BrowserIts own browsing and downloadsEvery other application
Proxy setting in one appThat app, if it honours the proxyIts DNS behaviour and other programs
System VPNTraffic routed through the tunnelBrowser fingerprint and identity
Whole-device routingThe operating system's trafficApplication-level identity signals

関心のあるアプリが UDP に依存しているなら、ブラウザーの設定は答えになりませんし、アプリが無視するプロキシ変数も答えになりません。要件は、別の失敗の仕方を持つ別の設計になります。

実際に選んだカバレッジ

システム VPN はブラウザーより範囲が広く、目的は狭いものです。経路とプラットフォームの対応が整っていれば複数のアプリケーションを運べますが、指紋への耐性は与えませんし、VPN の出口は匿名ネットワークではありません。

デバイス全体のカバレッジはシステム設計であって、インストーラーではありません。ひとつのプロセスではなく OS の通信を経路づけ、ブラウザーのダウンロードにはない運用上の制約を伴います。

どちらの問いに答えるのか、つまりどのアプリが守られているのか、それともすべてのパケットが守られているのかを決めてください。前者はブラウザーの設定で、後者は経路のポリシーです。このふたつを混同すると、マシンは守られたウィンドウがひとつと、守られていないプロセスが五つという状態になります。ほかをインストールする前に、答えを書き留めてください。

関連記事