VPN より先に Tor を準備する: 起動ゲートを正しく並べる

tor プロセスの監視だけを見てから VPN を起動するのは、このスタックを誤って組む最も一般的な方法です。デーモンはクライアントのストリームを運べるようになるはるか前に現れ、固定の待ち時間は依存関係のふりをした推測にすぎません。ゲートは、次のコンポーネントが実際に必要とする状態でなければなりません。以下の四つの手順を順番にたどり、それぞれを調整すべき遅延ではなく独立した条件として扱ってください。

ステップ 1: 実際に持っているトランスポートを選ぶ

設計の残りがそれに依存するため、まずプロトコルから始めます。Tor の SOCKS インターフェイスは UDP ASSOCIATE を実装していないため、それを経由して運ぶものは TCP ストリームでなければなりません。UDP を使う OpenVPN プロファイルは、スーパーバイザがどう書かれていてもこの経路では動作しません。プロファイルを TCP に切り替え、起動ロジックに触れる前にリモートピアがそれを受け入れることを確認してください。

次に、クライアントがそもそも SOCKS プロキシに到達できることを確認します。OpenVPN 2.6 は TCP プロファイル向けの socks-proxy オプションを文書化しており、クライアントごとにプロキシのサポートは異なります。プロキシのオプションを黙って無視するランチャーは直接接続して動作しているように見えるため、失敗するよりも悪い結果になります。

以降のすべての検査がそれに依存するため、選んだトランスポートは runbook に書き留めてください。

ステップ 2: プロセス一覧ではなく bootstrap フェーズを読む

Tor の制御プロトコルは GETINFO status/bootstrap-phase に対して、最新の bootstrap 状態を進捗率とサマリータグ付きで返します。この応答が役立つのは、デーモンが bootstrap を終えた後にコントローラが接続できるからです。イベントだけを待つスーパーバイザは、スーパーバイザの起動前に Tor が準備できていたケースを取り逃します。

制御接続は正しく認証してください。制御ポートは管理用インターフェイスであり、それと話せる者は誰でもデーモンを再設定できます。localhost に置き、Cookie またはパスワードによる認証を有効にしたままにし、起動スクリプトを簡単にするためにどちらも外さないでください。

起動時にフェーズを一度読み、その後はライブ表示のために進捗イベントを購読します。

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

進捗 100 と done タグを含む応答は、デーモンが自身の起動を終えたことを意味します。それはまだ、目的の宛先への利用可能なサーキットが存在することを意味しません。

ステップ 3: クライアントのサーキットイベントを待つ

Tor のイベントプロトコルは CIRCUIT_ESTABLISHED を定義しており、クライアントが利用できるサーキットを持つことを通知します。これは、割合よりも必要な能力にはるかに近いため、キャリアゲートが求める準備完了のシグナルです。そのイベントを購読して遷移を記録し、ログにはプロセスが現れた時刻ではなくキャリアが利用可能になった時刻が残るようにしてください。

イベントは試行の許可として扱い、特定の宛先に対する保証とはみなしません。出口ポリシーは依然としてリモートピアを拒否できますし、VPN 自体のハンドシェイクも Tor とは無関係な理由で失敗することがあります。

二つの条件はコード上で分けてください。ready という単一の真偽値にまとめると、次のインシデントが読めなくなります。

ステップ 4: VPN を自身のハンドシェイクでゲートする

VPN には独自の準備完了条件があり、トンネルが上がったことを証明するのはそれだけです。クライアントが割り当てられたアドレスを伴う接続状態を報告するまで待ち、その後でプロキシの要件が有効なままだったことを確認します。一回の失敗で socks-proxy オプションを捨てる再試行ループは直接接続し、設計全体を静かに無効にします。

ピアに到達できないときに何が起きるかを、知る必要が生じる前に決めてください。可視の失敗を伴う上限付きの再試行は、無限ループより運用しやすく、監視システムに警告の対象を与えます。同じ判断はキャリアにも当てはまり、Tor が再起動したら、VPN は死んだサーキットの上に残すのではなく、分解してゲートし直す必要があります。

最後に、VPN が落ちている間はアプリケーション自身のポリシーを維持してください。正しく待機するスーパーバイザは、無関係なプロセスが直接トラフィックを送ることを防ぎません。

耐えなければならない四つの遷移を確認する

設計は四つのケースで網羅されます。Tor が最初に上がるコールドスタート、すでに準備できた Tor に接続するスーパーバイザ、利用できない VPN ピア、トンネルが上がっている最中のキャリア喪失であり、それぞれ期待される遷移が異なり、ゲートが正しく書かれていれば異なるログ行を生みます。

それらを意図的に一つずつ実行し、プロセス一覧ではなく状態の変化を読んでください。

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

キャリアが落ちたら、VPN は古いトンネルにぶら下がるのではなく、一回の再試行間隔のうちにそれに追従して下がるべきです。Tor が戻ったら、ゲートはプロセスの起動後ではなく、サーキットイベントの後にだけ再び開くべきです。失敗のたびにどの条件が欠けていたかを記録すれば、次の当番はタイムスタンプから順序を再構成する必要がありません。