NAT環境下でJitsi用の外部TURNサーバーを設定する方法

最も重要な点：外部TURNサーバーは、NATやファイアウォールの制限によりWebRTC接続を確立できないクライアントのフォールバックとして構成する必要があります。これは、通常の複数参加者会議におけるJitsi Videobridge（JVB）の代替となるものではありません。Jitsiサーバー自体がNATの背後にある場合でも、JVBがインターネットからアクセス可能になるように（通常はUDP 10000番ポートを使用）、またはブリッジの公開アドレスを正しく設定する必要があります。

現在の Jitsi の展開では、通常、最もクリーンな設計は、DNS 名が のような公開アクセス可能な coturn ホストturn.example.com、XEP-0215 を介して Prosody から提供される時間制限付き認証情報、および UDP/TCP 上の TURN と制限付きネットワーク用の TLS 上の TURN です。Jitsi の現在の TURN ドキュメントでは、ブラウザの設定に永続的なユーザー名とパスワードを埋め込むのではなく、動的な認証情報を使用することを明示的に推奨しています。Jitsi の公式TURN 設定ドキュメントを参照してください。

外部TURNサーバーが適切なソリューションである場合

TURNは、参加者の一部がJitsiのWebページを開くことはできるものの、特に企業ネットワーク、ホテルのWi-Fi、キャンパス、携帯電話会社、VPN、またはUDPをブロックまたは厳しくフィルタリングするその他の環境から、安定したメディア接続を確立できない場合に使用します。また、TURNは、ピアツーピア接続を直接確立できない場合の1対1のJitsi通話にも役立ちます。

TURN を、設定ミスのある Jitsi Videobridge の最初の解決策として使用しないでください。公式の Jitsi Debian/Ubuntu ガイドによると、サーバーが NAT の背後にある場合、ルーターは必要なポートを転送する必要があり、ブリッジには明示的なローカル アドレスからパブリック アドレスへのマッピングが必要になる場合があります。デフォルトでは、Jitsi が使用する重要なポートは TCP 443 と UDP 10000 です。TURNを追加する前に、 Debian/Ubuntu 用の最新の Jitsi セルフホスティング ガイドを確認してください。

ステップ1：公開TURNホストとDNSを準備する

最もシンプルなトポロジーは、パブリックIPアドレスを持つ独立したVMまたはサーバーです。turn.example.comそのホストに解決されるようなAレコードまたはAAAAレコードを作成します。専用のホスト名は、後でTURN over TLSを提供する場合に特に役立ちます。なぜなら、証明書はクライアントが使用するホスト名と一致する必要があるからです。

TURNホスト自体がNATの背後にある場合、coturnはアドバタイズすべきパブリックアドレスを知る必要があります。coturnはexternal-ip、 などのパブリック/プライベートペアを含むマッピングをサポートしています。また、リレーポートはNATを介して一貫してマッピングする必要があることもドキュメントに記載されています。公式のcoturn設定例external-ip=203.0.113.10/192.168.1.10を参照してください。

ステップ2：coturnをインストールする

サポートされているDebianまたはUbuntuシステムでは、ディストリビューションリポジトリからcoturnをインストールしてください。

sudo apt update
sudo apt install coturn

パッケージのバージョンはオペレーティングシステムのリリースによって異なるため、スクリーンショットや他のサーバーからバージョン番号をコピーしないでください。インストール後、サービスユニットが存在し、パッケージがインストールされていることを確認してくださいturnserver。

ステップ3：共有シークレット認証用にcoturnを設定する

Jitsiの場合、実際の運用環境ではcoturnの共有シークレットメカニズムを使用してProsodyが一時的なTURN認証情報を生成できるようにします。両方の側で同じシークレットを使用してください。最小限の開始点は次のようになります。

listening-port=3478
tls-listening-port=5349
realm=turn.example.com

fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_SECRET

min-port=49160
max-port=49200

no-multicast-peers
no-cli

TURN ホストが NAT の背後にある場合は、適切なexternal-ipマッピングを追加してください。TLS 経由で TURN を有効にする場合は、certとpkeyを の信頼できる証明書で構成してくださいturn.example.com。公式の coturn コンテナのドキュメントでは、TURN はメディアにリレーポート範囲を使用し、その範囲は と で狭めることができると説明されていますmin-port。max-port同じリレーポートの動作については、公式の coturn Docker ドキュメントを参照してください。

ステップ4：リスナーポートとリレーポートを開く

よくある失敗は、リレー範囲を忘れて3478番ポートまたは5349番ポートのみを開放してしまうことです。Coturnのリスナーは最初のTURN接続を受け入れますが、リレーされるメディアは割り当てられたリレーポートを使用します。を選択した場合は49160-49200、ホストファイアウォール、クラウドセキュリティグループ、および上流のNATで同じ範囲を許可してください。

sudo ufw allow 3478/udp
sudo ufw allow 3478/tcp
sudo ufw allow 5349/tcp
sudo ufw allow 49160:49200/udp

企業ネットワークのセキュリティが厳しく制限されている場合、最大限の互換性が必要な場合は、JitsiのTURNガイドでTCP 443番ポートでTLS経由のTURNを提供する方法が説明されています。これには専用のTURNホスト名が必要になる場合があり、Web HTTPSが同じパブリックアドレスを共有する場合はTLS SNI多重化が必要になります。443番ポートを既に何に使用されているかを把握していない限り、安易にTURNを443番ポートに移行しないでください。

ステップ5：Jitsiを設定して外部TURNサービスをアドバタイズする

現在の Debian/Ubuntu Jitsi パッケージ展開では、Prosody はmod_external_servicesSTUN/TURN 情報をクライアントに公開するために使用します。Jitsi の Prosody の例では、external_service_secretとテーブルexternal_servicesを使用しますsecret = true。共有シークレットは coturn と一致する必要がありますstatic-auth-secret。

external_service_secret = "REPLACE_WITH_THE_SAME_LONG_RANDOM_SECRET";

external_services = {
    { type = "stun", host = "turn.example.com", port = 3478 },
    { type = "turn", host = "turn.example.com", port = 3478,
       transport = "udp", secret = true, ttl = 86400, algorithm = "turn" },
    { type = "turns", host = "turn.example.com", port = 5349,
       transport = "tcp", secret = true, ttl = 86400, algorithm = "turn" }
};

Jitsi が生成した Prosody ファイル内の既存のモジュールとサイト固有の設定はそのまま残してください。上記のコードスニペットでファイル全体を置き換えないでください。正確なファイル名は通常、デプロイメント ドメインの . の下に続きます。Jitsiの公式リポジトリ/etc/prosody/conf.d/で、アップストリームの設定例を確認できます。

公式の Docker デプロイメントを使用している場合は、生成された Prosody ファイルを手動で編集するよりも、ドキュメントに記載されている環境変数を使用することをお勧めします。現在の Docker ドキュメントでは、、、、、、およびが公開されています。TURN_CREDENTIALS変数のデフォルト値はリリース間で変更される可能性があるため、最新のJitsi Docker セルフホスティングガイドを確認してください。TURN_HOSTTURN_PORTTURN_TRANSPORTTURNS_HOSTTURNS_PORT

ステップ6：サービスを再起動して検証する

coturnを変更した後、再起動して状態を確認してください。

sudo systemctl restart coturn
sudo systemctl status coturn
sudo ss -lntup | grep -E '3478|5349'

Prosodyの設定を変更した後は、Prosodyパッケージに構文チェッカーが付属している場合は構文検証を行い、その後Prosodyを再起動してください。Jitsiで変更した内容によっては、関連するJitsiサービスを再起動することも適切です。

sudo prosodyctl check config
sudo systemctl restart prosody

coturnサービスのステータスが正常であることは、デーモンが実行されていることを証明するだけです。認証情報が一致していること、リレー範囲に到達可能であること、またはブラウザがリレー候補を取得できることを証明するものではありません。

ステップ7：TURNが実際にメディアを中継できることをテストする

同じ LAN からのテストだけでは不十分です。少なくとも 1 つのクライアントを別のネットワークで使用してください。理想的には、モバイル接続または UDP を制限することがわかっているネットワークを使用してください。ブラウザの WebRTC 診断では、タイプの ICE 候補を探してくださいrelay。リレー候補とは、ブラウザが TURN 認証情報を正常に取得し、TURN 割り当てを作成したことを意味します。

テストユーザーが参加している間、coturnログも監視してください。TURNが選択されている場合、認証済み割り当てとリレートラフィックが表示されるはずです。認証失敗が発生した場合は、coturnログをstatic-auth-secretProsodyまたはDockerのTURN認証情報シークレットと比較してください。割り当ては成功しているもののメディアが依然として失敗する場合は、リレーポートのファイアウォールとNATマッピングを確認してください。

制御されたテスト理由がない限り、サーバーの存在を証明するためだけにTURNを強制実行しないでください。通常の状態では、ICEは最適な動作パスを選択します。したがって、正常に展開された場合、TURNを必要としない会議が多数発生する可能性があります。

ステップ8：JVB NATの設定をTURNのトラブルシューティングとは別に管理する

これは、トラブルシューティングに費やす時間の無駄を最小限に抑えるためのポイントです。NATの背後にあるJitsiサーバーでも、ブリッジのパブリック接続が正しく設定されている必要があります。現在のJitsiクイックスタートガイドでは、ブリッジは通常自動的に設定されるとされていますが、より大きな通話が失敗する場合は、以下の静的マッピングを追加できice4j.harvest.mappingます/etc/jitsi/videobridge/jvb.conf。

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "192.168.1.20"
          public-address = "203.0.113.20"
        }
      ]
    }
  }
}

パブリックエッジからJVBホストへUDPポート10000を転送し、そのパブリックアドレスがリモートクライアントから実際にアクセス可能なアドレスであることを確認してください。TURNは制限の多いネットワーク上のクライアントには役立つ場合がありますが、JVB NATマッピングの不具合を隠蔽するために使用すべきではありません。

簡単なトラブルシューティングチェックリスト

• TURNホスト名が解決されません。Jitsiをテストする前にDNSを修正してください。
• 3478/5349 ローカルではリッスンするがリモートではリッスンしない:ホストファイアウォール、クラウドファイアウォール、ルーターNAT、およびプロバイダフィルタリングを検査します。
• 認証情報にエラーが発生した場合： coturnとJitsi/Prosodyの設定ファイルで共有シークレットが同一であることを確認してください。
• リレー候補は表示されますが、メディアが失敗します。設定されているリレーポート範囲がエンドツーエンドで開いていることを確認してください。
• マルチパーティ通話のみが失敗します。JVB UDP 10000とJVBパブリックアドレス広告を確認してください。
• 企業ネットワークのみが失敗する：適切な場合は、TLS 上で TURN を追加または検証する（多くの場合、TCP 443 を使用）。
• Dockerの変更は再起動後に消えてしまうため、.envコンテナ内の生成ファイルを編集するのではなく、サポートされている変数を設定してください。

正しい結果とはどのようなものか

正常な設定では、3つの動作が観察できます。まず、ネットワークが許せば、一般ユーザーはTURNなしでJitsi Videobridgeに直接アクセスできます。次に、制限のあるネットワーク上のユーザーは、一時的なTURN認証情報を受け取り、relayICE候補を取得できます。最後に、coturnはデフォルトですべての会議を実行するのではなく、必要な場合にのみ認証済み割り当てを表示します。

この組み合わせにより、TURNサーバーを不要な帯域幅のボトルネックにすることなく、有用なフォールバック機能を実現できます。また、トラブルシューティングも簡素化されます。JVB NATの問題はJVBの問題として残り、TURNは直接経路が遮断された場合のWebRTC接続というより限定的な問題を解決します。