智慧電臺機房網路架構：網閘、專線、區域網怎麼排
智慧電臺機房網路架構：網閘、專線、區域網怎麼排
廣播機房的網路架構，是一個被討論得少、被誤解得多的話題。
外行看機房，覺得就是幾臺伺服器、一堆網線、一個路由器。行內人知道，播出級機房的網路，是要按照等保標準分割槽隔離的，生產網、辦公網、網際網路三層的物理和邏輯隔離，稍微搞錯一個節點，輕則系統合規檢查不透過，重則播出事故。
這兩年，隨著 AI 系統進機房，這個問題變得更復雜了。AI 服務需要訪問網際網路（雲端 API、模型更新），也需要接觸生產內網（播出排程、素材儲存），這兩個需求之間存在天然的安全張力。
這篇文章，我把我們在實際部署中見過的架構模式整理出來，重點講清楚三層網路怎麼分、AI 系統落在哪一層、隔離裝置怎麼選。
等保對廣播機房網路分割槽的基本要求
先說合規背景。
國家對廣播電視播出機構的網路安全要求，主要來自兩個體系：等級保護（等保） 和 廣電行業專項安全規範。對於地市級以上廣播臺，播出系統通常被定為等保三級，這意味著必須有完整的安全分割槽和訪問控制。
對網路分割槽，等保三級的要求核心是：不同安全域之間不能直接互通，必須經過受控的邊界裝置做訪問控制。
在廣播機房的語境下，通常劃分為三個安全域：
播出生產網（最高安全域）：包含播出伺服器、播控系統、音訊矩陣、採編工作站（用於直接處理播出素材的部分）。這個網路對外完全隔離，不允許任何未經授權的出入口。
辦公內網（中等安全域）：行政、採編（非播出側）、新媒體運營等。可以訪問網際網路，但與生產網之間有明確隔離。
網際網路接入區（最低安全域）：雲 API 呼叫、外部資料接入、遠端維護通道都在這一層。
三層之間的邊界，不能只靠 VLAN 或軟體防火牆——這是最常見的誤區，我們後面專門講。
KAVANA 系統部署在哪一層
這個問題我們被很多臺的工程師問過，因為 KAVANA 系統有本地部署部分，也有云端 API 呼叫部分，兩者分屬不同安全域，必須明確。
本地部署部分（落在生產網）：
KAVANA MGR 播出管理系統、DOG 自動播出執行引擎、播出排程和佇列管理，這些元件直接參與播出流程，必須部署在生產網內。這些元件不主動訪問網際網路，只在生產網內與播出硬體互動。
具體來說，KAVANA MGR 作為播出管理核心，駐留生產網，所有播出指令的發起和確認都在生產網內完成，不經過網際網路邊界。DOG 播出引擎 同樣只在生產網內執行，接收 MGR 的指令，驅動音訊矩陣和播出裝置。
AI 處理部分（落在隔離區或辦公網）：
TTS 合成、ASR 轉寫、LLM 文案輔助，這些 AI 處理任務在時效上有一定彈性——不需要和播出硬體實時互動，只需要在播出前一段時間完成素材準備。因此可以部署在辦公網或隔離區，透過受控介面向生產網推送已完成的音訊檔案。
KAVANA AI 合成系統 的設計裡，AI 處理節點和播出節點之間只有單向資料流：AI 側生成音訊檔案，經稽覈後推入生產網素材庫；播出側從素材庫調取，不反向訪問 AI 節點。這個單向性很重要，是維持安全域隔離的關鍵設計。
三層之間的隔離裝置：硬體網閘、軟體網閘、防火牆各用在哪
分割槽劃清楚之後，邊界裝置的選擇是最容易被將就的一步。
播出生產網與辦公網之間：硬體網閘（必選）
等保三級要求，生產網和辦公網之間必須使用物理隔離裝置。硬體網閘（也叫單向匯入裝置、物理隔離閘）的原理是把資料拆包、檢查、重新封裝，兩側網路之間不存在任何直接的 TCP/IP 連線。
我們見過有臺在這個位置裝了 VLAN 分割加軟體防火牆，說"效果一樣"。這在技術上說不通——VLAN 是邏輯隔離，同一臺核心交換機上的兩個 VLAN 之間，在交換機被攻陷或配置出錯的情況下可以互通；軟體防火牆跑在通用作業系統上，作業系統本身就是攻擊面。等保檢查時，這種方案大機率不透過。
硬體網閘的價格，中端產品在 8-15 萬區間，對於地市級以上的臺不是大數目，不要在這裡省。
辦公網與網際網路接入區之間：軟體防火牆（主流選擇）
辦公網和網際網路之間，一般用商用防火牆（華為、奇安信、天融信等主流品牌都可以）。這一層的隔離沒有強制要求物理隔離，但要有完整的訪問控制策略：預設拒絕、按需開放、出入口流量審計。
雲 API 呼叫（TTS、ASR、LLM）從辦公網或隔離區發出，經防火牆出口到網際網路，回包經同一防火牆入站。這條鏈路在防火牆側要有明確的白名單——只允許特定 IP 和埠，不能開"全放行"。
生產網內部：wav9 格式防火牆（廣播專項）
這是一個廣播行業的特殊需求，外行容易忽視。
廣播生產網內部，音訊資料在系統間流轉，主要格式是 WAV 和 PCM。內部防火牆要能識別和檢查這些格式，而不是隻看 TCP/IP 層的包頭。"wav9 防火牆"是行業俗稱，指的是在生產網內部對音訊資料流做深度包檢查（DPI）的安全元件。
KAVANA 的播出系統在生產網內設計了內容完整性校驗機制，每個音訊檔案在進入播出佇列前都有格式驗證和後設資料核對，防止被篡改的音訊檔案進入播出鏈路。這不完全是防火牆功能，但起到類似的保護作用。
一個省級廣播臺的真實案例
這個案例來自我們實際參與的一個部署專案，電臺名稱做了模糊化處理。
這家臺有四個頻率，原有機房網路是"一張平面大網"——播出伺服器、採編工作站、行政辦公機，同一個 IP 段，靠各自的作業系統賬號做訪問控制。這在 2015 年之前很普遍，當時合規要求沒這麼嚴格。
2023 年等保評估，被整改通知，要求重新做網路分割槽。整改預算批下來，找到我們一起做技術方案。
整改方案分三步：
第一步，重新規劃 IP 地址段，把播出、採編、行政分進三個獨立段，網路交換機做 VLAN 分割。這一步主要是打基礎，工作量在於梳理現有裝置的 IP 分佈，有些老裝置 IP 地址是硬編碼在軟體裡的，改起來很麻煩。
第二步，在播出網和採編網之間安裝硬體網閘。選了一家國產品牌，中端型號，單向匯入，只允許採編側向播出側推素材，不允許反向連線。這一步的難點是在原有播出流程中加入檔案交換節點，不能影響現有播出的連續性。
第三步，AI 系統的網路接入。AI 處理節點部署在採編網，雲 API 呼叫透過採編網出口到網際網路。生成的音訊素材，經硬體網閘單向推入播出網素材庫。KAVANA 的播出系統從素材庫調取，不需要直接訪問 AI 節點。
整個改造完成用了三個月，最後等保評估透過，沒有重大整改項。
常見誤區整理
結合我們在各臺的經驗，整理幾個高頻誤區：
誤區一：用 VLAN 替代硬體網閘。前面說過，VLAN 是邏輯隔離，等保三級不認。生產網和辦公網之間必須有物理隔離裝置。
誤區二：AI 伺服器直接連生產網。有臺嫌麻煩，把 AI 伺服器直接接進生產網，圖的是素材傳輸方便。但 AI 伺服器本身需要訪問網際網路（更新模型、呼叫雲 API），一旦接進生產網，就在生產網裡引入了網際網路出口，直接破壞了分割槽的意義。
誤區三：雲 API 呼叫不做白名單。辦公網出口防火牆的 AI 呼叫規則，有臺設定成"允許 443 埠出站全放行"，這等於沒有防火牆。正確做法是隻放行 AI 服務商的特定 IP 段，定期核對，有變化及時更新。
誤區四：忽略內網橫向移動風險。大多數臺只關注"外面的攻擊怎麼進來"，忽略了"內網裡一臺機器被攻陷之後橫向擴散"的問題。生產網內部也需要最小許可權原則，播出伺服器只開放必要的埠，工作站之間不允許自由互訪。
給縣級臺的簡化版建議
上面講的很多內容針對地市級以上的臺，有專職 IT 人員，能做完整的三層架構。
對於人手有限的縣級臺，如果暫時沒條件做完整的三層網路分割槽，至少要做到這幾點：
播出伺服器和上網機器，物理上不連同一臺交換機。AI 系統需要聯網就單獨配一臺機器，不要裝在播出伺服器上。所有 AI 生成的內容，透過移動儲存或專用傳輸通道進播出網，不要直連。
這不是完美方案，但比"一張平面大網"要安全得多，也能應付基礎的合規檢查。
等到臺裡有條件升級架構，再按完整三層方案來做。
KAVANA 工程團隊在廣播機房網路安全領域有二十年實踐經驗，如需方案諮詢，可透過官網聯絡我們。