Tor経由のVPN：まずトランスポートの確認から

Torファーストとは、VPNクライアントがSOCKSプロキシの背後に置かれ、トンネル自体がTorを通って構築され、アプリケーションの通信がVPNのエンドポイントから出ることを意味する。これは一つの特定の順序であり、ほとんどの人が構築するものではない。Tor Browserを通常のVPNクライアントの隣で開いても、どちらのプログラムも相手の経路を使うようにはならない。

確認は順番に行う。それぞれが次を始める価値があるかを決める。

実際にどちらの順序を構築しているのか

二つの順序は同じ会話の中で混同される。Torファーストとは、VPNクライアントがSOCKSプロキシを通ってサーバーに到達するため、トンネルがTorの上に構築されることを意味する。VPNファーストとは、Torの通信がトンネルから出ることを意味し、ほとんどの人はこれを偶然構築してからもう一方だと説明する。前者は転送の境界をVPN事業者に集中させ、後者はTorの入口と出口に集中させる。どちらも、両方のアプリケーションを同時に開いたままにしても得られるものではない。

何かを設定する前に、その作業がどちらの順序を必要とするかを書き留める。二つの順序は異なるソフトウェア設定を要求し、異なる場所で失敗するからだ。順序を取り違えると一時間にわたって間違った層を調べることになり、以下はすべてTorファーストを前提とする。

何よりも先にトランスポートを確認する

TorのSOCKSインターフェースはTCPストリームを運び、汎用のUDPアソシエーションは提供しない。トランスポートがUDPのVPNは、そのプロキシを通常のネットワークインターフェースとして扱えず、クライアントの設定ではプロキシが転送を許す範囲を変えられない。通常の形のWireGuardは明らかな犠牲者である。TCPモードのOpenVPNプロファイルが一般的な回避策であり、それでもプロキシを使うよう明示的に指示する必要がある。

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

そのプロキシ経由でトンネルを調べる前に、プロキシが待ち受けていて単純なHTTPSリクエストを一つ運べることを確認する。単純なリクエストが失敗するなら、VPNクライアントは決して成功せず、そのログは理由を教えてくれない。

観測者の地図を書き換える

Torの入口は、Torに接続してくる送信元を見ることができるが、それ以前に何かが変えていなければ、そのホップはあなたのアドレスを知る。VPN事業者はTor側から来る接続を受け取るが、それでもトンネル内で送ったアカウント、支払い記録、資格情報を知り得る。VPN経由で到達する先はTorの出口ではなくVPNの出口を見るため、最終的な転送の境界が一つの事業者に集中する。

また、各宛先への分散した経路を再現するわけでもない。Tor Browserはサイトごとに新しい回路を構築するが、Tor上に載せたVPNは一つのトンネルを構築し、その背後のすべてのサイトがそのエンドポイントを共有する。この違いは取り除くべき制約ではなく、設計上の事実として扱う。

壊れたときに障害の層を数える

壊れた構成には少なくとも四つの独立した層がある——SOCKS接続、VPNサーバーとのTLSハンドシェイク、VPN自体のハンドシェイク、そしてトンネル内のルーティングまたは名前解決である。それぞれ異なる症状で失敗し、それぞれ異なる修理を必要とする。トンネルが上がらないからと証明書の確認を緩めるのは典型的な誤診であり、トランスポートの問題をセキュリティの問題に変えてしまう。

失敗した最初の層を記録し、そこで止める。プロキシによる拒否と鍵の拒否は、同じ出来事の変化形ではない。

脅威モデルがTor Browserの防御を必要とするなら止める

Torで運ばれるVPNを通して任意のアプリケーションをルーティングしても、それらのアプリケーションにTor Browserの指紋化と分離の機能は与えられない。それらのアカウント、識別子、独自のネットワーク挙動は依然として重要であり、トンネルはそのどれも正常化しない。目標が他の利用者に紛れるブラウザであるなら、この順序はそれを提供しない。

Tor Project自身が、利用者が正しく設定できない組み合わせについて警告しており、これはほとんどの人に当てはまる。これは狭い脅威モデルのための意図的な設計であり、端末全体の匿名通信への近道ではない。