TorリレーとVPNサーバー：置き換えが効かない理由

アドレスがあり、ポートが応答し、クライアントは何の不平もなくそれを受け入れます。そのどれもTorリレーをVPNのエンドポイントにはせず、プロファイルはきれいにインポートされてあとでハンドシェイクの段階で失敗するため、この間違いは高くつきます。以下では四つの確認を順番に使い、それぞれに停止条件があり、早めに止まることが要点です。最初の確認が失敗したら、残りは助けになりません。

ポートが実際に何を提供しているかを確認する

開いたポートが証明するのはリスナーの存在だけです。リレーのORPortはTLSハンドシェイクの後にTor独自のセルで会話するので、TLS検査が成功しても、そこにVPNプロトコルが受け入れられるかどうかはほとんど分かりません。

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

証明書があるかどうかではなく、証明書そのものを読みます。リレーは意図的に目立たない名前の自己署名証明書を提示し、その通信は通常のHTTPSに似せる必要がある一方、VPNサーバーの証明書はプロファイルが期待する名前を持ちます。相手がVPNプロトコルの最初のパケットに決して応答しないなら、プロファイルをどれだけ編集しても結果は変わりません。

アドレスがクライアントの送るハンドシェイクを完了しないなら、ここで止めてください。それは設定の問題ではなくプロトコルの応答であり、インポートしたプロファイルが延々と「connecting」のままになる最も一般的な理由です。

ネットワークの大きさではなく、リレーの役割を確認する

リレーの役割はそれぞれ異なる仕事をします。guardはクライアントにとって最初の一跳び、middleリレーは他のリレー間で回線を転送し、exitは宛先に触れる役割、bridgeはBridgeDB経由で配布される非公開の入口です。Torの用語集はこれらの定義を分けて保っており、到達可能であることはどの役割にも共通しますが、任意のクライアントにサービスを提供する許可はどの役割にも含まれません。

exitポリシーは、転送ルールに似ている唯一の部分として読む価値があり、exitが外へ出ることを許す宛先を定めるのであって、中へ入ることを許すクライアントを定めるのではありません。ポート25を塞ぐ制限的なexitポリシーは、外向きの悪用対策について何かを語りますが、OpenVPNクライアントをそのマシンに向けてよいかどうかは語りません。

評判に基づく推論——リレーが通信を転送するからそのアドレスもあなたの通信を受け入れるはずだ——はここで止めてください。Torはコンセンサスと独自プロトコルで経路を選び、VPNクライアントは参加者ではないので加わる回線もありません。

SOCKSリスナーがローカルか公開かを確認する

Torのクライアントは同じマシン上のアプリケーションにSOCKSインターフェースを公開し、既定ではループバック上に置きます。そのリスナーはローカルの利便性であって、リレーがインターネットに提供するサービスではなく、公開プロキシとして扱うことが、意図せずオープンリレーを運用してしまう道です。

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

束縛アドレスが手がかりです。127.0.0.1:9050 上のSocksPortは仕事をしており、0.0.0.0 で待ち受け外から到達できるものはオープンプロキシであり、Tor自身のアクセスポリシー制御が存在するのは、まさにその露出が機能ではなく問題だからです。

Torを必要とするアプリケーションは、ループバックポートに向けて名前解決をTorに任せてください（上の socks5h 形式がそれです）。そのポートにリレーのアドレスを代用しないでください——リレーはアプリケーションが求めているインターフェースを提供しないからです。

VPNプロファイルが実在のエンドポイントと一致するか確認する

VPNプロファイルは、OpenVPNにはサーバー証明書かCA・クライアント証明書と鍵・通常はTLS鍵、WireGuardには相手の公開鍵・エンドポイント・許可されたIPが必要だという期待の束です。どれもアドレスと開いたポートから導けないため、そうして作られたプロファイルは接続時ではなく最初のやり取りで失敗します。

プロファイルを渡されたら、自分が制御するエンドポイント、または特定できる提供元に対して検証してください。

wg show
openvpn --config client.ovpn --verb 4

OpenVPNのログではTLSネゴシエーションのエラーが不一致を直接名指しし、wg show ではハンドシェイク行のない相手は一度も完了していません。どちらもクライアントの回転インジケーターより情報が多く、Torではなく鍵素材やプロトコルを指しています。

本当に必要な保護がどれかを確認する

これがアーキテクチャを決める確認です。Tor BrowserはVPNにはない回線の分離と指紋対策を与え、VPNは宛先が見るアドレスを変え、提供元に対してあなたを認証します。どちらを選ぶかは互換性ではなく脅威モデルの問題であり、混同すると私的に見えてそうでない構成になります。

連鎖には順序があります。Torのクライアントは外向きTCPだけを必要とするため、Torの通信を運ぶVPNはサポートされる構成です。Torの内側にトンネルしたVPNクライアントは同じものではなく、Torクライアントが実装しているものでもないので、それを前提に計画しないでください。

何かをインポートする前に、四つすべてを確認してください。

• ポートが、単なるTCP接続ではなくプロトコルのハンドシェイクを完了すること。
• ホストの役割を知り、転送を許可と取り違えていないこと。
• 使うSOCKSリスナーがループバックで自分のものであり、他人のリレー上の公開ポートでないこと。
• プロファイルの鍵や証明書が、接続するエンドポイントのものであること。