VPN を Tor に、Tor を VPN に：連鎖が切れる理由

VPN、Tor、アプリケーションのプロキシを重ねると、プライバシーが何倍にもなるように感じられますが、実際には接続が死ぬ場所の数が何倍にもなります。よくある結果は、三つの道具がどれも正常だと報告する一方で、ブラウザが回り続けるというものです。三つの設定を一度に変えると、どれが嘘をついているかを示す唯一の手がかりも消えます。

まず意図した経路を順番に描き、どのプログラムが各接続を開き、各段階でどの名前が解決されるのかを書き出します。

層は足し算にならず、互いに作用します

Tor の前に VPN を置くというのは、Tor クライアントの入口接続がトンネルの内側を通るということです。Tor を通して VPN を運ぶというのは、VPN クライアント自身の端点が Tor 経由で到達できなければならないということで、まったく別の要件です。ブラウザのプロキシはさらに一段の跳躍を加えますが、OS はそれを何も知りません。三つの並べ方、三つの別々の依存関係リストです。

それぞれの並べ方は、何を解決でき、何を運べ、誰が最初のパケットを見るかを変えます。そのうちの一つだけが、あなたが意図した構成になり得ます。

図には直接経路も加えます。フォールバック経路、分割トンネルの除外、プロキシの迂回は、試したい連鎖を静かに飛ばしたままページを読み込ませることがあり、そうした成功は失敗よりも人を誤らせます。

順序が、何を運べるかを決めます

Tor は TCP のストリームを SOCKS インターフェイス経由で運び、プロキシにホスト名の解決を求めるクライアントはその問い合わせを回線の内側に留めます。通常の構成では UDP はそのようには通らないため、WireGuard のトンネルを Tor の中に入れ子にするには途中に TCP の中継がもう一段必要です。

OpenVPN は TCP に強制できるので、その並べ方は少なくとも説明できます。ただし遅く、壊れやすくもあり、破綻したときの失敗の見え方はブロックされたポートとまったく同じです。どちらかを直すより、両者を見分けるほうに時間がかかると考えておきましょう。

解決はもう半分です。--socks5-hostname を使うとプロキシが宛先を解決し、素の --socks5 は先にローカルのリゾルバに問い合わせて回路の外へ名前を漏らします。この一つのフラグが、名前の問い合わせが連鎖に属するのか、あなたの ISP に属するのかを決めます。

最初に切れた境界を見つける

パケットが進む順に、無害なリクエストで各段階を試し、最初に失敗したところで止めてください。どのコマンドを先に動かしたかは順序自体が証拠の一部になるので必ず記録しましょう。二つのコマンドで、死んだ回路と死んだ出口を切り分けられます：

curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip
curl -4 -s https://api.ipify.org; echo

一つ目は SOCKS プロキシ経由でリクエストがそもそも完了するかを報告し、二つ目はネットワークが今提示しているアドレスを示します。一つ目が失敗して二つ目が成功すれば、問題は Tor クライアントかその手前にあります。両方成功してブラウザがまだ失敗するなら、アプリケーションはシェルとは別の経路を使っています。

公開 IP のページも、最後に見える出口を説明するだけです。その前に何段の跳躍があったかは分からないので、一つの数字を図とみなすのではなく、各ツールが対応する状態出力と組み合わせてください。

層を足すのをいつやめるか

その層が何の役に立つのか一文で言えないなら、外してください。目的の不明な連鎖は、深夜三時に誰もデバッグできない連鎖であり、説明のつかない一段のプライバシー上の利得は、失う可用性よりふつう小さいものです。

その層が本当に場所に値するなら、まず単独で試し、次を足して同じ二つのコマンドで経路を再確認します。通常利用の前に完全な連鎖に戻し、TLS の検証と認証は入れたままにし、ページを読み込ませるために受け入れた証明書の警告は修理ではなく経路のごまかしだと心得てください。決めた順序は、記憶が新しいうちに書き留めます。

その順序を、各段階で答えるリゾルバも含めて書き出してください。説明できる動作中の連鎖は次の更新を生き延びますが、試行錯誤で組んだ動作中の連鎖はそれとともに消えます。日付とバージョンを添えておけば、後の故障を記憶で論じるのではなく、既知の良い状態と比べられます。テキストファイルの十行が、一晩の当て推量を節約します。