Tor の回線を変えることと VPN サーバーを切り替えることは、どちらも新しい経路を得たように感じられますが、同じボタンとして扱うと壊れる場所が違います。前者は Tor クライアントにサイト用の別の経路を作らせ、後者は VPN クライアントに別の端点へ接続させます。どちらもリセットではなく、サイトが最終的に見るアドレスは、二つのうちどちらが目的地に近いかで決まります。どちらの操作を選び、その後何を確認するかを以下に示します。

二つの異なる層での二つの操作

Tor は上位の層です。クライアントはガードリレー、中間リレー、出口リレーを選び、その回線で TCP ストリームを運びます。目的地が見るのは出口だけで、それ以外は見えません。回線の変更は、どのリレーがストリームを運ぶかという Tor 内部の決定です。

VPN はその下のトンネルです。クライアントは端点を選び、通信を外側の層で包み、その後に続くものは端点のアドレスを見ます。サーバーの切り替えは、外側の経路がどこで終わるかという決定です。

層が独立しているため、一方の操作は接続の遠い端では見えないことがあります。この非対称性が、この二つの操作をめぐる混乱の大半を説明します。

「このサイト用の新しい Tor 回線」がすること

サイト情報パネルの「このサイト用の新しい Tor 回線」は、Tor がそのサイト用に運んでいるストリームを閉じ、次のリクエスト用に新しい回線を作ります。タブ、Cookie、ログイン、その他のセッションはそのまま残ります。セッションを保ったまま経路だけを変えるのが要点です。

そのため、限定的な不具合に適した道具になります。目的地に遮断された出口リレー、出口を追いかける captcha ループ、他のサイトは問題ないのに一つだけ止まる場合です。同じパネルの回線表示には三つのリレーが並ぶので、出口が本当に変わったかを推測ではなく確認できます。

ガードに注目してください。Tor は少数の入口ガードを保持し、回線の変更は通常同じガードを再利用するため、ネットワーク上の最初のホップは動きません。「新しい ID」はより大きなリセットで、タブを閉じ、閲覧状態を消してから新しい回線を作ります。ID の制御が別に文書化されているのには理由があり、別のコストを持つ別の操作だからです。

VPN サーバーの切り替えがすること

クライアントはトンネルを破棄し、別の端点に接続します。トンネルの外側の次のホップは、Tor のガードであれ目的地そのものであれ、別の送信元アドレスを見ます。トンネル内の接続は切れて再確立が必要なため、ページはきれいに再読み込みされるのではなく、タイムアウトまで固まることがあります。

トンネルの上側は書き換えられませんが、破棄は見えないわけではありません。VPN が先の構成では出口は依然として Tor が選びますが、トンネルが落ちると Tor がガードに対して持つ TCP 接続が切れ、Tor はその回線を破棄して新しい回線を作り、出口を選び直します。そのためサイトは切り替え後に別の出口アドレスを見ることがありますが、切り替え自体が出口を選んだわけではありません。切り替えが決めるのはガードが見るアドレスであり、出口を選び直すのは再構築された回線です。Tor が前にある状態でサイトに見えるものを変えるためだけにサーバーを切り替えたなら、サイトが直接観測しない層を動かしたことになり、サイトが気づく変化は切り替えではなく再構築から来ています。

切り替えはクライアントが持つ経路にしか影響しません。開いた接続を再利用するブラウザは、再接続するまで古い経路に固まって見えることがあり、キャッシュされた DNS 応答もよくある原因です。まず再読み込みし、それから判断してください。

順序が目的地に見えるものを決める

二つの順序は別の問いに答えます。VPN が Tor の前にある場合、ガードとリレーは VPN の端点を見て、目的地は Tor の出口を見ます。Tor が VPN の前にある場合、目的地は VPN の端点を見ます。通信が最後に通るのがトンネルだからです。

SetupSwitch VPN serverChange Tor circuit
VPN, then TorGuard sees the new address; the rebuilt circuit re-chooses the exit, so the site may see a different exit, not necessarily the same one.Site sees a new exit; the VPN endpoint is untouched.
Tor, then VPNSite sees the new VPN address immediately.Circuit is rebuilt, but the site still sees the VPN address.

つまり IP の確認が報告するのは目的地が見たものであり、それを運んだ経路ではありません。ある構成では出口を、別の構成では VPN を示すサービスは正しく動いており、漏えいではありません。

どちらの操作もしないこと

どちらもアカウントの identity を消しません。ログイン済みのセッションは Cookie とサーバー側の記録であり、経路の変更はどちらにも触れません。安定したブラウザプロファイル、同じログイン、同じ指紋はどちらの操作でも残ります。

どちらも証拠にはなりません。サイトが報告するのはリクエスト中に観測したアドレスであり、あなたのリレー経路や、十分前に VPN が落ちたかどうかは報告できません。その時間軸が必要ならその場で書き留めてください。後から遠い端で再構成することはできません。

操作を症状に合わせる

どのボタンがより徹底して見えるかではなく、何が失敗したかから始めます。

  • 一つのサイトに遮断され、captcha が繰り返され、一つのサイトだけ遅い:そのサイト用の新しい回線。
  • VPN だけの構成で別の見えるアドレスが必要:サーバーを切り替える。
  • 出口を期待したのにサイトが VPN を報告する:順序を確認する。Tor がトンネルの後ろにある。
  • タブが閉じてすべてリセットされた:「新しい ID」を使ったのであり、回線の変更ではない。
  • 回線変更後も出口が変わらないように見える:リレーは正当に繰り返すことがあり、ガードはまったく動かない。

他を変える前に、行った操作と直すはずだった症状を書き留めてください。二つの切り替えを続けて行うと解釈できない比較になり、片方の層だけが不調なのに両方を繰り返すと、五分の確認が丸一日の作業になります。

関連記事