在 NGINX-RTMP 上接收 RTMPS 流
RTMP 的標準做法仍然是線上路上輸出純文字流密鑰。
我想接受從編碼器到 NGINX 的 RTMPS 流,但是 RTMP 模組還沒有 RTMPS。
我對所有允許通過 RTMPS 獲取 RTMP 流並發送到 facebook 之類的地方的中繼解決方案不感興趣,因為相同的安全漏洞仍然存在,因為在某些時候您通過純文字傳遞密鑰。
我的問題是在哪裡可以找到 RTMPS 的參考規範?我想知道在 OBS 和 NGINX 等 RTMPS 源之間進行正確握手需要哪些密鑰,然後我將使用與 RTMP 模組的連接。可以在伺服器上使用普通密鑰和 Let’s Encrypt 之類的授權,以便它可以與 RTMPS 編碼器進行握手嗎?
我見過用於在 TLS 中包裝 RTMP 的 stunnel。是否可以反過來 - 使用 stunnel 接收 RTMPS 並將 RTMP 模組轉換回 RTMP?
**更新:這是我的原始答案,很好地描述了使用 Nginx 實現 RTMPS 時可能面臨的問題。但是,我添加了一個改進版本,以實現更精細的訪問控制,我建議使用其中的配置。
是的,這可以通過 stunnel 實現,因為 RTMPS 只是包裝在標準 TLS 會話中的 RTMP 會話。網上的例子大多是RTMP→RTMPS,即stunnel作為純文字伺服器和TLS客戶端工作,配置
client = yes
. 沒有它,client
預設為no
,即伺服器模式。stunnel配置可能如下所示:
[rtmps] accept = 1935 connect = 127.0.0.1:1936 cert=/etc/letsencrypt/live/rtmp.example.com/fullchain.pem key=/etc/letsencrypt/live/rtmp.example.com/privkey.pem
有了這個:
- Nginx 應該在本地環回埠上偵聽 RTMP
1936/tcp
。- 由於您無法使用 RTMP 更新 Let’s Encrypt 證書,因此您可能還需要一個 HTTP 伺服器塊來處理 HTTP-01 質詢。
- 由於與 Nginx 的連接始終來自 stunnel,即來自
127.0.0.1
,因此您不能再使用allow
/deny
指令來限制基於 IP 地址的連接。這意味著您的訪問控制將僅限於密鑰,但同時它不是問題,因為它是加密傳輸的。但是,這仍然會導致問題,因為您會從與使用它的客戶端相同的 IP 推送流,但您不能允許它們發佈到您的流。幸運的是,您不必
push
使用密鑰從應用程序中獲取流,但您也pull
可以從公共應用程序 (/live
) 中獲取。以下Nginx範例配置考慮了這些注意事項:
rtmp { server { listen 127.0.0.1:1936; chunk_size 4096; application app-secret-stream-key { live on; record off; allow publish 127.0.0.1; # for streaming through stunnel allow play 127.0.0.1; # for the pull from /live } application live { live on; record off; deny publish all; # no need to publish on /live allow play all; # playing allowed pull rtmp://127.0.0.1:1936/app-secret-stream-key; } } } http { server { listen 80; server_name rtmp.example.com; location ^~ /.well-known/acme-challenge/ { root /var/www/letsencrypt; } location / { return 404; } } }
但是,這只是一個範例,因此您可以並且應該對其進行修改以滿足您的確切需求。(另外,我沒有測試過這個配置,只是根據文件編寫的,所以如果我有錯誤,請隨時糾正。)