1. リレーポートに到達できることを確認する
ファイアウォールを使用している場合は、ファイアウォールを開放し、着信接続がリレーに使うポート (ORPort) に到達できるようにしてください。
また、あなたのリレーが他の Tor リレー、クライアント、および送信先に到達できるように、すべての発信接続も許可するようにしてください。
特定の ORPort TCP ポート番号は、セットアップページ (OS 別セクション) で確認できます。
2. リレーの動作の確認
tor デーモンの起動後、ログファイル (syslog) に以下のようなエントリーがあれば、リレーは正常に動作しているはずです。
Self-testing indicates your ORPort is reachable from the outside. Excellent.
Publishing server descriptor.
リレーを開始してから約 3 時間後に、メトリクスポータルのリレー検索に表示されるはずです。
Nickname または IP アドレスを使用してリレーを検索できます。
3. Tor リレーのライフサイクルについて知る
リレートラフィックが増加するには時間がかかります。これは特にガードリレーに当てはまりますが、出口リレーの場合も同様です。このプロセスを理解するために新しいリレーのライフサイクルをご覧ください。
4. 構成の管理
複数のリレーを運用する予定の場合、大容量のリレー (サーバーごとに複数の Tor インスタンス) を実行する場合、あるいはオフラインマスターキーなどの強力なセキュリティ機能を手動で追加手順を実行することなく使用する場合は、構成管理を使用して保守性を向上させることができます。
Unix ベースのオペレーティングシステム用の構成管理ソリューションは複数あります (Ansible、Puppet、Salt など) 。
以下の Ansible Role は、特に Tor リレーオペレーター用に開発されており、複数のオペレーティングシステムをサポートしています: Ansible Relayor
5. 重要: 複数の Tor インスタンスを運用する場合
Tor クライアントを危険にさらさないため、複数のリレーを運用する場合は、torrc で適切な FamilyID 値を設定し、有効な ContactInfo を記載する必要があります。
FamilyID 設定は、どの Tor リレーが単一のオペレーター/組織によって管理されているかを Tor クライアントに伝えるものであり、これにより、一つの回線でこうしたリレーが複数使用されることを防ぎます。
大規模なオペレーターの場合は、FamilyID を手動で設定するのではなく、構成管理ソリューションを使用して設定を自動化することをお勧めします。
大規模なリレーグループで FamilyID を手動で管理するのはミスが発生しやすく、Tor クライアントを危険にさらす可能性があります。
なお、以前のファミリー設定方法であった MyFamily は廃止されたのでご注意ください。
6. DDoS 攻撃から保護するためのファイアウォールルールの追加
過剰な同時接続を阻止するようにファイアウォールを設定することは、リレーに対する DDoS 攻撃への対処に非常に役立つことが示されています。
以下のメカニズムのいずれかを実装することを検討してください。
注意:これらはコミュニティが提供するリソースです。
システムに適用する前に、慎重に確認してください。
また、これらのルールは、過去に発生した特定の攻撃に対して有効であることが示されているに過ぎないことにご注意ください。
攻撃は常に進化しており、新しいルールが必要になることがよくあるので、関連するプロジェクトを定期的に確認するか、tor-relays メーリングリストを購読することで、必要に応じてこれらを更新してください。
7. オプション: 帯域幅の使用 (およびトラフィック) の制限
Tor はデフォルトでは帯域幅の使用を制限しませんが、使用帯域幅とトラフィック量を制限する複数の方法をサポートしています。
これは、Tor リレーが 1 日/ 1 週間/ 1 か月の一定の帯域幅または総トラフィック量を超えないようにしたい場合に便利です。
以下の torrc 構成オプションを使って、帯域幅とトラフィックを制限できます。
- AccountingMax
- AccountingRule
- AccountingStart
- BandwidthRate
- BandwidthBurst
- RelayBandwidthRate
月全体にわたり低速なリレーを運用するよりも、一部の時期だけ高速なリレーを運用する方が良いです。
また、FAQ の帯域幅の項目もご覧ください。
8. IPv6 の可用性の確認
リレーで IPv6 を有効にすることを推奨します。これは、特に出口リレーとガードリレーで重要です。
ただし、Tor には IPv4 接続が必要であり、IPv6 のみで Tor リレーを運用することはできません。
IPv6 を有効にする前に、基本的な IPv6 接続テストを行うことをおすすめします。
以下のコマンドラインは、サーバーから Tor ディレクトリー管理機関の IPv6 アドレスに ping を送ります。
ping6 -c2 2a02:16a8:662:2203::1 && ping6 -c2 2620:13:4000:6000::1000:118 && ping6 -c2 2001:67c:289c::9 && ping6 -c2 2001:678:558:1000::244 && ping6 -c2 2001:638:a000:4140::ffff:189 && echo OK.
出力の最後に「OK.」と表示されるはずです。もし表示されない場合は、IPv6 が実際に動作するようになるまで torrc 構成ファイルで IPv6 を有効にしないでください。
IPv6 接続が機能していない状態で IPv6 を有効にすると、IPv4 が正常に機能していても、リレーが使用されなくなってします。
IPv6 が機能している場合、リレーはすでに IPv6 経由で到達可能である可能性が高いです。
Tor 0.4.5 以降、IPv6 アドレスの検出はデフォルトで有効になっています。明示的なアドレスが指定されていない ORPort 行は、IPv4 と IPv6 の両方 (0.0.0.0:9001 および [::]:9001) にバインドされ、Tor は IPv4 アドレスを検出するのと同じように IPv6 アドレスの自動検出を試みます。
有効な IPv6 アドレスが見つからない場合は、IPv4 のみを公開します。
Tor がどのアドレスにバインドし、どのアドレスを検出したかは、通知ログで確認できます (Opened OR listener の行と到達可能性チェックの結果を確認してください) 。
自動検出で誤ったアドレスが検出されるなどして、IPv6 アドレスを明示的に指定したい場合は、ORPort 行をもう 1 行追加します:
ORPort [IPv6-address]:9001
注意: 自動検出されたアドレスは、到達できない場合そのまま破棄されますが、明示的に設定された IPv6 ORPort は、到達可能性チェックに失敗すると、リレーが記述子を一切公開できなくなります。そのため、確実に機能することが分かっているアドレスのみを設定してください。
IPv6 アドレスは角括弧で囲んで明示的に指定する必要があります。
構成ファイル内のこの行の位置は関係ありません。
torrc ファイルの最初の ORPort 行の隣に追加するだけです。
グローバル IPv6 アドレスがある場合は、以下のコマンドの出力で確認できます。
ip -6 addr | grep global | sed 's/inet6//;s#/.*##'
IPv6 を完全に無効化し、自動検出も無効にするには、torrc で AddressDisableIPv6 1 を設定してください。
IPv6 接続に対応した出口リレーの場合、クライアントが IPv6 の宛先に到達できるよう、tor デーモンが IPv6 経由での出口通過を許可するように設定します。
IPv6Exit 1
9. リレーの保守
Tor ID キーのバックアップ
tor デーモンを最初にインストールして起動したら、リレーの長期 ID キーのバックアップを取ることをお勧めします。
これらのキーは DataDirectory の「keys」サブフォルダーにあります (フォルダー全体をコピーし、安全な場所に保管します) 。
リレーには立ち上げ時間があるため、ディスク障害後にリレーを回復できるように ID キーをバックアップすることは理にかなっています。そうしないと、再び立ち上げをする必要があります。
キーが盗まれた場合、理論的にはトラフィックの復号化やなりすましが可能になるため、キーの保管場所が非常に安全な場合にのみ、この作業を行ってください。
鍵フォルダーのデフォルトの場所:
- Debian/Ubuntu:
/var/lib/tor/keys
- FreeBSD:
/var/db/tor/keys
- OpenBSD:
/var/tor/keys
- Fedora:
/var/lib/tor/keys
tor-announce メーリングリストの購読
このメーリングリストはトラフィックが非常に少なく、tor の新しい安定版リリースや重要なセキュリティアップデートに関する情報を得ることができます: tor-announce
障害に関する通知の設定
一度リレーをセットアップすれば、その後はほとんど何もしなくても動作するでしょう。
何か問題が発生した場合に、自動的に通知されるのはとても便利ですよね。
そのため、Tor Project が開発した通知サービスである Tor Weather をぜひご利用ください。
これにより、リレーやブリッジがオフラインになったときや、その他のインシデントが発生したときに、リレーオペレーターに通知してくれます。
もう一つのオプションは、リレーの ORPort に到達可能かチェックし、接続できなくなった場合にメールを送ってくれる無料サービスを使うことです。
UptimeRobot は、任意のポートの TCP リスナーを監視できるサービスの 1 つです。
これはリスナーのみをチェックし、Tor プロトコルは使用しません。
リレーの状態を監視するには、帯域幅グラフを確認することをお勧めします。
システムヘルスモニタリング
リレーが正常で過負荷になっていないことを確認するには、基本的なシステムモニタリングを実施して、以下の指標を監視することをお勧めします。
- 帯域幅
- 確立された TCP 接続
- メモリー
- スワップ
- CPU
こうしたデータを監視するためのツールはたくさんありますが、munin はその 1 つで、比較的簡単に設定できます。
警告: プライベートなモニタリングデータのグラフを絶対に公開しないでください。これは攻撃者が Tor ユーザーの匿名化を解除するのに役立つ可能性があります。
以下にいくつかのアドバイスを挙げます:
- トラフィックの統計を公開する場合は、少なくとも 1 日以上にわたってリレーのトラフィックを集計するか、可能であれば帯域幅の集計ウィンドウを大きくして、複数のリレーのグラフ/統計を組み合わせてください。
- 個々のリレーのレポートは、リレーのグループの合計のレポートよりも良くないです。将来的には、tor は帯域幅の統計を安全に集計するようになるため、個々のリレーの帯域幅のレポートは、tor の統計よりも安全性が低くなります。
- 期間が短いほど良くないです。
- グラフよりも数値の方が良くないです。
- リアルタイムデータは履歴データよりも良くないです。
- カテゴリー (IP バージョン、受信/送信など) のデータは、合計データよりも良くないです。
ツール
このセクションでは、Tor リレーオペレーターにとって便利なツールをいくつかご紹介します。