MediaMTX 開 Port 風險與 VPN 收斂架構指南
本指南專注於推流伺服器端的網絡邊界防禦：如何科學評估 MediaMTX 開放公網 Port 的潛在威脅、如何透過 VPN 收斂架構完全下架裸露的 RTMP/SRT 端口，並引入動態 IP 白名單 Hot Reload 機制。
1. 現況架構與網絡拓撲
目前系統對公網曝露的端口分佈如下：
| Port | 網路協定 | 實際用途 |
|---|---|---|
443 |
Xray VLESS Reality | 供中國大陸現場跨越 GFW 使用的代理出口（保持獨立） |
1935 |
RTMP (明碼) | 台灣現場戶外推流 → 曝露於公網的 MediaMTX Ingest 入口 |
8890 |
SRT (特徵明顯) | 備用高丟包現場推流 → 曝露於公網的 MediaMTX Ingest 入口 |
鏈路一：台灣戶外直接推流鏈（本次安全重構核心）
flowchart TD A["手機 PrismLive / Moblin"] -->|未收斂拓撲| E["MediaMTX 公網直接曝露
公網 IP:1935/8890
暴露主要攻擊面"] E --> F["OBS 本機拉流"]
鏈路二：中國大陸現場翻牆鏈（完全獨立，不經過 MediaMTX）
flowchart LR
A["中國現場 iPhone"] --> B["Shadowrocket VLESS Reality"]
B --> C["伺服器 Xray:443 出口"]
C --> D["跨境直推 Twitch 伺服器"]
2. MediaMTX 面臨的安全問題
在安全威脅建模中，網絡邊界防禦遵循「三階段風險模型」。必須正視的是：開放公網端口必然引發探測，隱蔽不等於安全。
核心概念：VPN 收斂架構的核心價值在於降低「攻擊面（Attack Surface）」，將對外的曝露點從多個服務端口收攏至單一高強度加密通道，而非直接提高 MediaMTX 內部應用程式本身的代碼安全性。
| 曝露端口 | 階段 1 背景掃描 | 階段 2 協議識別 | 階段 3 攻擊面風險評估 |
|---|---|---|---|
443 Reality |
必然命中 | 極難看穿 (偽裝真實 TLS 1.3) | 低風險，具備探測防禦 |
1935 RTMP |
必然命中 | 秒級識別 (無任何偽裝機制) | 高風險，易遭突發串流覆蓋與拒絕服務 |
8890 SRT |
必然命中 | 秒級識別 (握手特徵固定) | 高風險，未授權探測與頻寬消耗 |
3. MediaMTX 加密現況檢查
檢查伺服器部署的 mediamtx.yml 核心傳輸層配置：
rtmpEncryption: "no" # RTMP 明文傳輸
rtspEncryption: "no" # RTSP 明文傳輸
srtReadPassphrase: # 未配置文件加密密鑰
srtPublishPassphrase: # 未配置文件加密密鑰
hlsEncryption: false # HLS 切片未啟用靜態加密4. MediaMTX 認證漏洞缺陷
原配置檔案中關於發布端權限的宣告存在極大安全隱患：
authInternalUsers:
- user: any
pass:
ips: []
permissions:
- action: publish
path: live/key15. 方案 A：VPN 收斂架構（攻擊面最小化）
為了阻止全球自動化掃描器對 1935 與 8890 端口的常態探測，最有效的手段是在邊界路由器與防火牆上完全關閉這些端口的公網對外映射。
%%{init: {"themeVariables": {}}}%%
flowchart LR
A["手機直播端"] -->|WireGuard UDP 隧道| B["VPN Gateway"]
B -->|虛擬內網網卡 10.0.0.1| C["MediaMTX:1935/8890"]
封包解裝流程解析：VPN Server 作為隧道終點，會解封裝 VPN 封包，因此能看到其中承載的是 RTMP/SRT 流量。對於 Internet 公網上的第三方探測器而言，僅能捕獲符合密碼學隨機分佈的 UDP 封包，從根本上抹除了直播服務的特徵指紋。
6. Hysteria2 vs WireGuard 選型
當 VPN 收斂架構應用於現場推流場景時，其選型邏輯與常規翻牆迥異：
🛡️ 台灣本地固定網絡環境 → 首選 WireGuard
- 核心優勢：協議極度輕量、封裝開銷極低、核心態運行。
- 手機端生態：官方客戶端極其成熟，支援 Split Tunnel 路由分流。
⚡ 飯店/會場 Wi-Fi 等高阻礙環境 → 備選 Hysteria2
- 核心優勢：基於 QUIC，Brutal 壅塞控制演算法對抗戶外弱網高丟包。
- 網絡伪裝：模擬標準 HTTP/3 流量，輕易穿透企業級防火牆對 UDP 的惡意限制。
7. 方案 B：動態 IP 白名單工具
若現場環境不便安裝 VPN 客戶端，則必須開啟公網端口，此時必須依賴動態白名單工具進行最小範圍的曝露控制。
該工具基於 Node.js 運行，透過精準文字標記（Marker）動態定位並更新 mediamtx.yml 內的 ips 授權池，觸發 MediaMTX 的 Hot Reload（熱加載） 機制。
# mediamtx.yml 內的動態標記範例
authInternalUsers:
- user: liveu_streamer
pass: $2b$10$BvR... (bcrypt雜湊)
ips: ["220.135.x.x"] # @dynamic-ip-pool: production-field
permissions:
- action: publish8. 五層縱深防禦與最終架構
健全的系統不依賴單一防線。本架構透過多層獨立關卡構建標準的縱深防禦（Defense in Depth）體系：
graph TD
L1["【第一層：VPN 網絡邊界】
公網 1935/8890 完全關閉，未授權封包在邊界直接丟棄。"]
L2["【第二層：動態 IP 白名單】
限制僅允許信任的現場出口公網 IP 建立連接。"]
L3["【第三層：發佈端強認證】
MediaMTX 驗證強密碼，拒絕 any 匿名 publish 行為。"]
L4["【第四層：連線速率限制】
限制單一 IP 握手頻率，阻斷憑證碰撞與資源消耗。"]
L5["【第五層：自動阻斷守護】
Fail2Ban 監控日誌，連續認證失敗直接執行核心級黑名單封鎖。"]
L1 --> L2 --> L3 --> L4 --> L5
整體整合架構圖
graph TD
subgraph TW_Field ["════════ 台灣現場戶外 ════════"]
Client["手機 / 攝像機推流端"] -->|僅允許打虛擬內網 IP 10.0.0.1| WG["[第一層: WireGuard 加密隧道]"]
end
subgraph Cloud_Boundary ["════════ 雲端防禦邊界 ════════"]
WG -->|解封裝 VPN 流量| IPTables["[第二層: iptables 網絡層動態白名單過濾池]"]
end
subgraph MMTX_Defense ["════════ MediaMTX 縱深防禦體系 (第三至五層) ════════"]
MMTX["MediaMTX 核心五層縱深"]
B1["- 監聽綁定: 10.0.0.1 (公網對外不可見)"]
B2["- 發佈控制: authInternalUsers 密碼校驗"]
B3["- 守護進程: Fail2Ban 實時日誌審查"]
MMTX --> B1 --> B2 --> B3
end
OBS["OBS Studio 控制台"]
IPTables --> MMTX
B3 -->|內網迴圈拉流| OBS
Platforms["Twitch / YouTube 平台"]
OBS -->|安全轉發| Platforms
9. 邊界安全檢查清單
- 確認邊界防火牆與寬頻路由器上已完全下架 1935、8890 的對公網映射規則。
- 檢查
mediamtx.yml，確認user: any佔位符已徹底移除。 - 確認 SRT 與 RTMP 發布密碼皆使用複雜的純英數字組合，避免特殊字符引發設備解析異常.
- 驗證 WireGuard 的
AllowedIPs已配置為 Split Tunnel 模式（僅放行伺服器虛擬網段）。 - 確認常駐守護進程已正確配置
Restart=always，防止極端網絡衝擊導致邊界服務崩潰。