如何在NAT後為Jitsi配置外部TURN伺服器

最重要的一點：應配置外部 TURN 伺服器作為備用方案，以應對因 NAT 或防火牆限製而無法建立可用 WebRTC 路徑的用戶端。它不能取代 Jitsi Videobridge (JVB) 用於常規多方會議。如果您的 Jitsi 伺服器本身位於 NAT 之後，您仍然必須使 JVB 可從 Internet 存取（通常使用 UDP 10000 連接埠），或正確設定橋接器的公網位址。

對於目前的 Jitsi 部署，最簡潔的設計通常是：一個可公開存取的 coturn 主機，其 DNS 名稱類似於 `<Jitsi_TORN_NAME>`；turn.example.com由 Prosody 透過 XEP-0215 提供有時效性的憑證；以及基於 UDP/TCP 的 TURN 協議，對於受限網路則使用受限的網路協議。 Jitsi 目前的 TURN 文件明確建議使用動態憑證，而不是在瀏覽器設定中嵌入永久的使用者名稱和密碼。請參閱Jitsi 官方 TURN 設定文件。

網路拓撲圖顯示了 Jitsi 在 NAT 後方，使用 UDP 10000 連接埠進行直接橋接，並使用外部 TURN 伺服器作為 TURN 連接埠的備用方案。 — Jitsi 媒體應盡可能使用正常的橋接路徑，而外部 TURN 伺服器則為受限網路上的用戶端提供備用方案。

何時使用外部 TURN 伺服器才是正確的解決方案

當部分參與者可以開啟 Jitsi 網頁但無法建立可靠的媒體連線時，尤其是在企業網路、飯店 Wi-Fi、校園網路、行動電信商網路、VPN 或其他會封鎖或嚴格過濾 UDP 的環境中，可以使用 TURN 功能。此外，當無法直接建立點對點連線時，TURN 也適用於一對一的 Jitsi 通話。

請勿將 TURN 作為解決 Jitsi Videobridge 配置錯誤的首選方案。 Jitsi 官方 Debian/Ubuntu 指南指出，當伺服器位於 NAT 之後時，路由器必須轉發所需的端口，並且橋接器可能需要明確配置本地地址到公網地址的映射。預設情況下，Jitsi 需要使用的重要連接埠是 TCP 443 和 UDP 10000。在新增 TURN 之前，請先查閱最新的Jitsi Debian/Ubuntu 自託管指南。

症狀或需求	首先要檢查什麼
兩名用戶無法在受限網路上直接連線。	TURN 是一個強而有力的候選者。
三名或三名以上參與者沒有音頻/視頻	在指責 TURN 之前，請先驗證 JVB UDP 10000 及其公網位址。
普通家庭網路使用者可以正常運作，但企業用戶卻無法正常運作。	新增 TURN/TLS，如果您的網路設計允許，最好透過 TCP 443 連接埠存取。
您需要的憑證不會永久暴露在 JavaScript 中。	使用共用金鑰和短期憑證來使用 Prosody 外部服務。

步驟 1：準備一個公共 TURN 主機和 DNS

最簡單的拓樸結構是使用一台獨立的虛擬機器或伺服器，並分配一個公網 IP 位址。建立一個 A 記錄或 AAAA 記錄，指向turn.example.com該主機。如果您之後提供基於 TLS 的 TURN 服務，那麼使用專用主機名稱尤其有用，因為憑證必須與用戶端使用的主機名稱相符。

如果 TURN 主機本身位於 NAT 之後，Coturn 需要知道它應該通告的公有網路位址。 Coturn 支援external-ip映射，包括公網/私網位址對，例如 `<public_address>` 和 `<private_address> external-ip=203.0.113.10/192.168.1.10`。其文件還指出，中繼埠必須透過 NAT 保持一致的對應。請參閱官方的Coturn 範例配置。

示意圖顯示，參與者透過網路使用公共外部 TURN 伺服器連接到位於 NAT 後面的 Jitsi Meet 伺服器。 — 與隱藏在與 Jitsi 相同的私人網路後面的 TURN 服務相比，單獨的公共 TURN 主機通常更容易持續地暴露出來。

步驟 2：安裝 coturn

在受支援的 Debian 或 Ubuntu 系統上，從發行版儲存庫安裝 coturn：

sudo apt update
sudo apt install coturn

軟體包版本因作業系統版本而異，因此請勿從螢幕截圖或其他伺服器複製版本號。安裝完成後，請確認服務單元存在且軟體套件已安裝turnserver。

Ubuntu 終端機顯示 apt update 指令，隨後顯示 apt install coturn 指令。 — 在專用 TURN 主機上使用軟體包管理器安裝 coturn；具體的軟體包版本取決於 Linux 版本。

步驟 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對應。如果啟用 TURN over TLS，請設定cert並pkey使用受信任的憑證。官方 coturn 容器文件解釋說，TURN 使用中繼埠範圍來傳輸媒體，並且turn.example.com可以使用 `--relayport` 和 `--relayport` 來縮小範圍。有關中繼埠行為的更多詳細信息，請參閱官方 coturn Docker 文件。min-portmax-port

文字編輯器顯示了 Coturn 的配置，包括監聽連接埠、共用金鑰認證、中繼連接埠以及公網到私人網路的外部 IP 位址對應。 — 典型的 coturn 設定包括監聽埠、共享金鑰、中繼埠範圍以及 TURN 主機位於 NAT 後方時的外部 IP 對應。

步驟 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 服務與 TURN 服務共用同一個公網位址時，也需要進行 TLS SNI 多重化。除非您了解該連接埠已被哪些服務佔用，否則請勿盲目地將 TURN 服務移轉到 443 連接埠。

Ubuntu 終端機顯示了允許 TURN 監聽連接埠的 UFW 規則以及已配置的 UDP 中繼連接埠範圍。 — 防火牆必須允許 TURN 監聽器和 coturn 中選擇的中繼埠範圍。

步驟 5：設定 Jitsi 以廣播外部 TURN 服務

在目前 Debian/Ubuntu Jitsi 軟體包部署中，Prosody 使用 .mod_external_services向客戶端發布 STUN/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 設定範例可在官方 Jitsi 程式碼庫/etc/prosody/conf.d/中查看。

如果您使用的是官方 Docker 部署，建議使用其文件中提供的環境變量，而不是手動編輯生成的 Prosody 檔案。目前的 Docker 文件公開了`--enable -enable` TURN_CREDENTIALS、 ` --enable- enable`、`--enable - enable`、`--enable- enable` 和 `--enable-enable` 。請查閱最新的Jitsi Docker 自託管指南，因為不同版本之間的變數預設值可能會有所變更。TURN_HOSTTURN_PORTTURN_TRANSPORTTURNS_HOSTTURNS_PORT

終端檢查 TURN DNS 記錄、連接埠 3478 和 5349，以及配置的中繼埠防火牆範圍 — 在變更 Jitsi 之前，請先驗證 TURN 主機名稱是否解析，以及 coturn 是否確實在監聽預期的傳輸連接埠。

步驟 6：重新啟動並驗證服務

更改 coturn 後，重新啟動 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 服務狀態僅證明守護程式正在執行。它並不能證明憑證匹配、中繼範圍可達，或瀏覽器可以取得中繼候選位址。

終端機顯示 coturn 已成功重新啟動並處於作用中狀態，並顯示 TURN 和 TLS 監聽器訊息。 — 使用服務狀態和監聽器檢查作為第一驗證步驟；時間戳記和進程 ID 在您的伺服器上會有所不同。

終端顯示，在配置變更後，與 Jitsi 相關的服務正在重新啟動。 — 僅重新啟動受配置變更影響的 Jitsi 服務，然後使用全新的瀏覽器工作階段進行測試。

步驟 7：測試 TURN 是否能夠實際中繼媒體

僅在同一區域網路內進行測試是不夠的。至少需要使用位於不同網路上的用戶端，理想情況下應使用行動網路連線或已知限制 UDP 的網路。在瀏覽器 WebRTC 診斷中，尋找類型為 `<relay-concept>` 的 ICE 候選位址relay。中繼候選位址表示瀏覽器已成功取得 TURN 憑證並建立了 TURN 分配。

同時，在測試使用者加入時，請觀察 coturn 日誌。選擇 TURN 模式後，您應該會看到已驗證的分配和中繼流量。如果出現驗證失敗，請將 coturn 日誌static-auth-secret與 Prosody 或 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"
        }
      ]
    }
  }
}

將公網邊緣的 UDP 10000 封包轉送至 JVB 主機，並確保公網位址是遠端用戶端實際可存取的位址。 TURN 協定可能有助於受限網路上的用戶端，但不應用於掩蓋損壞的 JVB NAT 映射。

網路拓撲圖，重點展示了透過 UDP 10000 連接埠直接傳輸 Jitsi 橋接媒體，TURN 僅用作備用路徑。 — 理想的架構使 JVB 能夠透過普通媒體直接訪問，而 TURN 則作為無法使用直接路徑的網路的備用方案。

快速故障排除清單

TURN 主機名稱無法解析：請在測試 Jitsi 之前修復 DNS。
3478/5349 監聽本地但不監聽遠端：檢查主機防火牆、雲端防火牆、路由器 NAT 和提供者過濾。
憑證失敗：請驗證 coturn 和 Jitsi/Prosody 設定中的共用金鑰是否相同。
中繼候選連接埠出現，但媒體傳輸失敗：請驗證配置的中繼連接埠範圍是否端對端開放。
只有多方呼叫失敗：檢查 JVB UDP 10000 和 JVB 公網位址通告。
只有企業網路才會出現問題：新增或驗證 TURN over TLS，通常在 TCP 443 連接埠上進行（如果適用）。
Docker 的變更在重新啟動後會消失：配置受支援的.env變量，而不是編輯容器內產生的檔案。

正確結果是什麼樣子的

一個健康的配置應具備三個可觀察的行為。首先，一般使用者在網路允許的情況下無需 TURN 即可直接存取 Jitsi Videobridge。其次，在網路受限的情況下，使用者可以取得臨時 TURN 憑證並取得relayICE 候選連線。第三，coturn 僅在需要時才顯示已認證的分配，而不是預設承載所有會議。

這種組合提供了一個有效的備用方案，同時又不會讓 TURN 伺服器成為不必要的頻寬瓶頸。它還能簡化故障排除：JVB NAT 問題仍然是 JVB 問題，而 TURN 則解決了直接路由被阻塞時 WebRTC 連線的具體問題。