Tor の前に VPN：順序が実際に変えるもの

先に VPN を接続すると、特定の連鎖が生まれる。デバイス、VPN の終端点、Tor の入口、Tor 回線、宛先である。ローカルネットワークは VPN への暗号化された接続を一つ見、Tor の入口ノードは提供事業者のアドレスの代わりに VPN の出口を直接の送信元として見る。VPN 運営者は逆に、Tor 入口基盤への接続を見て、宛先から Tor の利用を推測できる。どの観測者も何かを失い何かを得るので、この順序は改善ではなく交換である。

その連鎖の中の何も、ウェブサイトがアカウントや Cookie、入力した情報から学ぶことを変えない。

順序が変えるもの

ローカルネットワークと ISP は、最初のホップが事業者への暗号化トンネルになったため、Tor 通信を直接見ることを失う。Tor 入口ガードは自宅のアドレスを失い、VPN の出口を見る。VPN 事業者は、以前は ISP が持っていた、どのアドレスにいつどれだけのデータが動くかというメタデータを得る。

入口ガードより先では、回線は以前と同じように振る舞う。リレーは入口・中間・出口の役割を依然として分け、VPN は最終的な内容を ISP 以上には見ない。

実際に使われる経路を確認する

分割トンネリングが、意図した連鎖が実際の連鎖でない通常の理由である。Tor Browser がトンネルから除外されている場合、または二つ目のプロファイルが別の経路を通る場合、インターフェースは接続中に見えても入口ガードは再び事業者のアドレスを見る。アイコンではなく経路と観測された出口を確認する。

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

ポート 9150 経由の SOCKS 要求に応答するのは Tor Browser 自身のクライアントなので、IsTor true という応答が確認するのはブラウザの回線であり、他のすべてのアプリがそれを使うことではない。リゾルバの出力は記録する価値がある。DNS はトンネルが覆わない経路から出ることがあるからだ。両方の出力を時刻とともに残す。それらが次の比較の基準になる。

通常の端末からの直接要求と比較し、それも Tor を報告するなら、何か別のものが通信を迂回させており、連鎖は設計が想定したものではない。

トンネルが切れたときに何が起きるかを見る

ローカルインターフェースに黙って戻るクライアントは、入口ガードが見る送信元を変える。ページはまだ読み込まれるので、利用者は通常気づかない。試す価値があるのはその障害であり、順調な経路ではない。トンネルを意図的に切断し、Tor 通信が止まるか、保護なしで続くかを観察する。

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

トンネルの外への送信通信を遮断するファイアウォール規則だけが信頼できるフォールバック制御であり、ブラウザの SOCKS クライアントと、気にかける他のあらゆるアプリを覆わなければならない。ブラウザ拡張はデバイス VPN ではなく、他のプログラムや外部の観測者に影響しない。

追加の層が信頼に値するか決める

Tor Project は、自分で設定を評価できない限り、Tor の下に VPN を重ねることを勧めていない。彼らが挙げる理由は追加の依存である。もう一つの当事者、もう一つのアカウント、もう一つの故障モードだ。目的が ISP に Tor の使用を見せないことなら、VPN はまさにその観測者に対処する。目的がグローバルな観測者に対するより強い匿名性なら、VPN はそれを提供しない。

逆の順序もあり、名前は交換できない：Tor over VPN と VPN over Tor は異なる信頼関係を表すそして異なる故障時の振る舞い。混ぜる前に比較を読むこと。

どの観測者を動かそうとしているかを書き、次に実際の経路が設計と一致することを確認し、次に故障時の振る舞いを確認する。その三つの答えが追加のアカウントと設定を正当化しないなら、文書化された Tor Browser の設定の方が間違えられる部分が少ない。