私たちがホスティングしている場合、これはあなたのサイトにすでに事前設定されています。このガイドは、Discourseをセルフホスティングしている管理者向けです。
Discourse Liveは、音声およびビデオ通話のためにWebRTCを使用しています。参加者が直接接続できるように、公開STUNサーバーが同梱されています。管理者はこれらのサーバーを置き換え、TURNを追加して、直接接続が失敗するネットワークをサポートできます。
コミュニティ専用のサーバーの場合、STUNサーバーとTURNサーバーの両方としてcoturnを実行し、TURNには共有シークレット認証を使用することをお勧めします。 これにより、永続的なTURNパスワードを配布したり、サードパーティのSTUNサーバーに依存したりすることなく、グローバルアドレスの検出とリレーフォールバックが提供されます。
このガイドは、Liveのピアツーピア通話に適用されます。LiveKitを使用する部屋は、代わりにLiveKit独自のICE/TURN構成を使用します。 LiveのLiveKit構成について学ぶ。
STUNとTURNは何をしますか？
- STUN は、ブラウザが公開IPアドレスとポートを検出し、直接接続を試行できるようにするのに役立ちます。
- TURN は、直接接続を確立できない場合にメディアを中継します。
公開アドレスを検出したブラウザは、それを サーバーリフレクシブ (srflx) 候補 として提案できます。これにより、家庭やオフィスのNAT経由での直接接続が可能になります。これがない場合、ほとんどの通話はTURNリレーにフォールバックし、レイテンシとリレー帯域幅が増加します。
TURNを実行していても、STUNは開いていなければなりません。 TURN割り当て応答にもブラウザの公開アドレスが含まれますが、一部のブラウザ（Firefoxなど）のみがそれを候補として使用します。ChromiumベースのブラウザとSafariは、個別のSTUNバインディングリクエストからのみ公開アドレスを検出し、ブラウザはバインディングリクエストに認証情報を添付しません。サーバーがSTUNを無効化している場合（no-stun）、または認証を要求している場合（secure-stun）、これらのブラウザは srflx 候補を取得せず、参加するすべての通話が残存されることになります。
共有シークレットTURNが構成されている場合、Liveは直接接続とリレー接続の両方を許可します。 TURNの構成は、すべての通話をリレーに強制するものではありません。 LiveのICE構成.
1. TURNサーバーの準備
TURN REST API共有シークレット認証 をサポートするマネージドTURNサービスを使用するか、coturn 自体を実行できます。
セルフホスティング構成の場合、以下を準備します：
- グローバルIPアドレスと、リレー通話に十分な帯域幅を備えたサーバー。
turn.example.comなどのホスト名で、そのサーバーを直接指すもの。- TURNリスナーとUDPリレーポート範囲へのファイアウォールアクセス。
- TLS経由でTURNを提供する場合の有効な証明書。
参加者のブラウザはTURNに直接接続します。通常のHTTPリバースプロキシやCDNプロキシでは、TURNトラフィックを運ぶことはできません。
coturn構成の例
ランダムなシークレットを生成します：
openssl rand -hex 32
結果は非公開にしてください。同じ値をcoturnとDiscourseに入力します。
グローバルIPアドレスが直接割り当てられたサーバーでは、/etc/turnserver.conf の開始点として以下を使用します：
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REPLACE_WITH_YOUR_RANDOM_SECRET
# Do not add no-stun or secure-stun: browsers send STUN Binding requests
# without credentials, and many rely on them to discover their public address.
min-port=49152
max-port=65535
no-multicast-peers
# This example starts without TLS.
no-tls
no-dtls
ホスト名とシークレットを置き換え、構成ファイルを保護し、coturnを再起動します。矛盾する no-auth または静的な user= 構成は削除します。Coturnの共有シークレットモードは、内部で必要な認証メカニズムを有効にします。 Coturn構成リファレンス.
匿名STUNは、クライアント自身のアドレスをクライアントに返すだけであり、トラフィックを中継できないため、サーバーをオープンリレーにはしません。最近のcoturnバージョンでは、オプションのRFC 5780および MAPPED-ADDRESS 応答属性がデフォルトで無効になっており、バインディング応答のリクエストサイズに近い大きさを保ち、リフレクション攻撃への有用性を限定します。rfc5780 と stun-backward-compatibility は無効のままにしてください。
以下へのインバウンドトラフィックを許可します：
| ポート | プロトコル | 目的 |
|---|---|---|
3478 |
UDP | STUNとTURN |
3478 |
TCP | TURN |
49152–65535 |
UDP | リレーメディア |
対応するアウトバウンドトラフィックも許可します。リレー範囲は min-port と max-port に一致する必要があります。
サーバーがNATの後ろにある場合、coturnの external-ip=PUBLIC_IP/PRIVATE_IP マッピングを構成し、リスナーとリレーポートを転送します。リレーポートはNATを通じてポート番号を保持する必要があります。 Coturnデプロイメントオプション.
制限的なネットワークのためのTLS追加
TLS経由のTURNは、UDPをブロックするネットワークの参加者にもう一つの接続オプションを提供します。
no-tls を削除し、以下を構成します：
tls-listening-port=5349
cert=/path/to/fullchain.pem
pkey=/path/to/privkey.pem
5349/TCP を開き、coturnが証明書とキーを読み取れるようにし、証明書更新後に再起動します。
TURNサーバーでそのポートが利用可能であれば、代わりに 443/TCP を使用できます。これは制限的なネットワークで役立つ場合がありますが、一部のネットワークではポート443上の非HTTPトラフィックを検査およびブロックすることもあります。ブラウザがTCPまたはTLS経由でTURNに到達する場合でも、UDPリレー範囲は依然として必要です。 Coturnサーバードキュメント.
2. Discourseの構成
管理 → 設定 で、これらのLive設定を検索します：
| 設定 | 値 |
|---|---|
live_stun_servers |
coturnサーバーのSTUN URI — デフォルトのエントリを置き換えます |
live_turn_secret |
coturnの static-auth-secret に使用された値 |
live_turn_secret_servers |
| で区切られたTURN URI |
live_turn_servers |
空 |
live_turn_username |
空 |
live_turn_credential |
空 |
上記の構成の場合、live_stun_servers に以下を入力します：
stun:turn.example.com:3478
そして、live_turn_secret_servers に以下を入力します：
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
TLSを有効にした場合、そのエンドポイントを追加します：
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
// なしの stun:、turn:、turns: URIを使用します。サーバーが実際にサポートしているエンドポイントのみをリストします。
Chromiumベースのブラウザは、リストされたTURNサーバーにもSTUNリクエストを送信するため、coturnが匿名STUNに応答する場合、live_stun_servers が空でも機能する可能性があります。STUN URIを明示的にリストすると、構成が明確になり、他のブラウザに対応し、Liveの接続診断で単独でテストできるようになります。
live_turn_secret_servers リストは、共有シークレットから生成された認証情報を使用します。別の live_turn_servers リストは、固定のユーザー名とパスワードを使用します。 Live設定の定義.
設定を保存した後、参加者に通話から退出し、再参加して新しい構成を取得してもらいます。
3. 構成の検証
家庭用ブロードバンドやモバイルデータなど、異なるネットワーク上の2人の参加者でテストし、複数のブラウザ — 少なくとも1つのChromiumベースのブラウザとFirefoxで実行します。両方向で音声が動作することを確認し、その後、ビデオと画面共有をテストします。
ピアツーピア部屋にいる間に、部屋の ⋮ メニューを開き、接続診断 を選択します：
- STUN/TURNサーバー の下で、各サーバーが 到達可能 と表示されるはずです。TURNサーバーには リレーアドレス がリストされ、UDPサーバーには 公開アドレス がリストされます。「公開アドレス: なし」は、STUNリクエストが応答を得られなかったことを意味します —
no-stun/secure-stunと、3478/UDPが開いているかどうかを確認してください。 - ピア の下で、ルートは各接続がメディアをどのように伝送するかを示します：直接（同一ネットワーク）、直接（STUN経由でNATを通過）、またはTURN経由で中継。通常の家庭ネットワークのほとんどの参加者は直接接続されるはずです。
- レポートのコピー は、トラブルシューティングを担当する人と共有できるテキストレポートを生成します。参加者のIPアドレスが含まれているため、プライベートに共有してください。
Chromiumブラウザでは、chrome://webrtc-internals で同じ詳細がより低いレベルで表示されます：
srflx候補は、検出された公開アドレスを表します。relay候補は、利用可能なTURNリレーを表します。- 選択された候補ペアは、実際にメディアを伝送している接続を示します。
成功した直接通話は、リレーが機能することを証明するものではありません。 TURNが必要になるネットワークからもテストするか、一時的な認証情報と iceTransportPolicy: "relay" を使用したWebRTCテストクライアントを使用してください。
coturnのログを確認し、正常に認証された割り当てがあることを確認します。有効な認証情報なしのリクエストは、リレー割り当てを取得してはなりません。初期の 401 認証チャレンジは正常です。繰り返される認証失敗は調査が必要です。
サーバーをコミュニティ専用に保つ
共有シークレットはDiscourseとTURNサーバー上にあります。参加者には代わりに一時的な認証情報が提供されます。Liveは現在、12時間の割り当て作成に有効な認証情報を生成します。確立された割り当ては、更新されている間継続できます。 Liveの認証情報生成.
これにより、匿名のオープンリレーは防止されますが、TURN認証情報はブラウザのオリジンに紐付けられていません：参加者は一時的な認証情報をコピーして再利用できます。悪用を制限するには：
- Liveアクセスを意図したグループに制限します。
- リレー帯域幅と割り当て数を監視します。
- コミュニティに適したcoturn割り当てクォータと帯域幅制限を設定します。
- TURNホストから到達可能なプライベート、リンクローカル、およびその他の内部宛先へのリレーアクセスをブロックします。
- coturnを最新に保ち、共有シークレットが公開された場合はローテーションします。
このDiscourseデプロイメントには専用のシークレットを使用します。サーバーは誰でもからの匿名STUNリクエストにも応答します。これは期待され、帯域幅をほとんど使用せず、リレーアクセスを付与しません。 Coturn認証とアクセス制御.
代替案
公開STUNサーバーのみを置き換える
live_stun_servers を、| で区切られた独自STUN URIに設定します：
stun:stun.example.com:3478
リレーが必要でない場合、TURN設定は空のままにしてください。STUNだけでは、すべてのネットワークで通話を機能させることはできません。
固定ユーザー名とパスワードでTURNを使用する
プロバイダーが共有シークレット認証をサポートしていない場合、live_turn_servers、live_turn_username、live_turn_credential を構成します。共有シークレット設定は空のままにしてください。
参加者にはこれらの固定認証情報が提供されるため、サイトの外での再利用が容易になります。また、Liveは現在、静的TURNサーバーが構成され、STUNリストが空の場合、リレー接続を強制します。プロバイダーがサポートしている場合は、共有シークレット認証を優先してください。 LiveのICE構成.