Tor は VPN を通っているのか？分割トンネルが変えるもの

ここで検証すべき思い込みは、接続アイコンが点いていれば Tor の通信はまず VPN を通った、というものだ。この推論は本来より頻繁に、しかも静かに破綻する。分割トンネルのマッチャーは、端末が接続したまま Tor プロセスをトンネルの外に置くことができ、二つの観察は同時に成り立つ。アイコンが示すのはインターフェースであり、パケットがたどった経路は別の問いだ。答えるべきはルーティングとマッチャーからであって、アイコンからではない。

接続アイコンが証明すること、しないこと

VPN が接続しているとは、インターフェースが上がり、ピアへのトンネルが存在するという意味だ。Tor の入口接続は別のプロセスが作る別のフローであり、そのトンネルに入るかどうかは、適用されるマッチャーとルーティングテーブルで決まる。プロセスを除外すれば、VPN はつながり、Tor は回路を作り、意図した順序は実現しない。二つの観察は別の問いに答えており、どちらか一方だけでは順序を決められない。

このずれはどちらのツールの不具合でもない。除外ルールはまさにそのためのものであり、そのルールは今も誰かが覚えている理由で書かれたのだろう。

クライアントが接続に適用するマッチャー

経路を決めるのは、プロセス名、宛先プレフィックス、ルートエントリのいずれかでクライアントが各接続に適用するマッチャーだ。デスクトップのショートカットは、ランチャーであってポリシー単位ではないため、どれにも一致しない。Tor を論じる前に、クライアントのルール集合を読み、実際に何を検査しているのかを名指しせよ。クライアントが宛先で照合するなら、問いはどのプレフィックスがトンネル内にあるかであり、どのプログラムが動いているかではない。

社内オフィスのプレフィックスだけを持つ宛先ベースのルールはよくある形で、通常の Tor 入口接続は設計どおり直接のままになる。それは設定どおりに動いているポリシーであり、アイコンがどれほど健全に見えても VPN が先という順序ではない。マッチャーと除外プレフィックスはルールそのものだから、メモの同じ行に書け。

トンネルが落ちたとき Tor に何が起きるか

ネットワークが健全な間しか成り立たないポリシーは説明したポリシーではないので、次にトンネルを外して Tor の振る舞いを見よ。クライアントは落ちている間、直接通信を拒否するかもしれず、黙って許可するかもしれず、少し後に再接続してルールを再適用するかもしれない。手動の切断とクラッシュは別の事象であり、クラッシュこそ誰も練習していないものだ。無害な通信で試し、三つの結果のどれを実際に観察したかを記録せよ。

クライアントの文書化された挙動も読むべきだが、自分の試験が一致するまでは文書を仮説として扱え。ベンダーは既定値を述べ、例外はあなたのプロファイルが決める。

出口アドレスが入口の問いに答えられない理由

Tor 経由で到達したサイトは出口リレーのアドレスを報告し、それは回路がどこから出たかを示すだけで、最初のホップが端末をどう離れたかは何も語らない。人々はそのアドレスを VPN が先という順序の証拠として引くが、その重さは支えられない。入口の問いは局所的で、最初のリレーまで接続を運んだのはどのインターフェースか、VPN のピアがどの送信元アドレスを見たかということだ。ウェブサイトではなく、端末でのルート検索やパケットキャプチャで答えよ。

二つの異なる経路が同じ出口国を生みうるので、一致した結果は見かけ以上に何も証明しない。比べるべきはインターフェースであり、地理ではない。

ブラウザの設定を一度も引き継がなかったアプリ

文書ビューア、同期クライアント、パッケージマネージャーはそれぞれ独自の接続を作り、どれもブラウザのプロキシ設定を引き継がない。それぞれがクライアントのマッチャー、独自の設定、システムプロキシのいずれかに従い、その組み合わせが書かれることはまれだ。例外リストは、一度に一つのアプリ、どの追加ももっともらしく、やがてリストが何を覆うのか誰にも言えなくなる、というふうに育つ。代わりにアプリごとの短い図を保ち、マッチャー、経路、障害時の挙動を名指しせよ。

余分な VPN 層に意味があると言えないなら、例外の長いリストを保つより、層を外すほうが検証しやすい。一方、Tor プロジェクトの VPN に関する注記 も同じ順序の問いを反対側から扱う。可動部品が少なければ、次のクライアント更新後に再検証する前提も少なくなる。