逆向工程 UniFi Inform 通訊協定

背景

這篇文章源於 Tamarack 創辦人分享其逆向工程 UniFi Inform 協定的經驗。作者過去在經營 UniFi 雲端託管服務時，受限於 UniFi 控制器不支援多租戶架構，導致每個客戶都必須佔用獨立的虛擬主機，利潤極其微薄。為了實現多租戶路由並降低成本，他深入研究了裝置與控制器通訊的封包結構，發現雖然酬載經過加密，但標頭中的 MAC 位址卻是明文，這成為了開發高效能代理轉發層的關鍵。

社群觀點

Hacker News 的討論首先聚焦於協定細節的技術糾錯。針對作者提到封包標頭出現「TNBU」是「UBNT」反轉的觀察，社群成員指出這並非單純的拼寫反轉，而是與網路位元組順序（大端序）有關。由於 Ubiquiti 早期設備多採用 MIPS 處理器，將其股票代碼 UBNT 以大端序存儲在協定中作為魔術數字是相當合理的設計。此外，有資深用戶回憶道，UBNT 早在 UniFi 品牌誕生前就是 Ubiquiti 網路設備的預設登入帳號，這反映了該公司長期的工程慣例。

在實務應用層面，討論轉向了自動化部署的挑戰。有用戶質疑，如果裝置尚未採用，代理伺服器如何得知特定 MAC 位址屬於哪個租戶。作者對此回應，除了手動預先註冊 MAC 位址外，系統也支援透過來源 IP 進行映射，這對於利用 DHCP Option 43 進行大規模自動部署的場景尤為重要。一旦裝置完成初步導向並設定了特定的 Inform URL，後續通訊就能透過標準的 HTTP Host 標頭進行路由，MAC 路由則退居為處理邊際情況或工廠重設裝置的備援機制。

社群中也出現了對 UniFi 生態系封閉性的不滿與期待。部分開發者希望能看到一個開源且跨廠商的存取點控制器，能夠同時管理 Ubiquiti、MikroTik 與 TP-Link 等不同品牌的設備，實現真正的多供應商統一管理。此外，關於 UniFi 攝影機（Protect 系列）的討論也相當熱烈。有用戶抱怨攝影機無法像無線基地台那樣輕易接入自建的 Docker 控制器，而是被強制綁定在官方的 NVR 硬體上。雖然有開發者嘗試透過 SSH 修改設定檔來提取串流，但其通訊協定採用了修改版的 FLV 格式而非標準 RTSP，增加了逆向工程與整合開源 NVR 系統的難度。

最後，討論也觸及了基礎設施的安全與維運。有用戶提到新註冊的網域常被 NextDNS 等安全工具預設攔截，引發了關於網管人員是否應過度依賴「新網域即惡意」過濾策略的辯論。同時，針對 UniFi 控制器後端的資料庫遷移，社群也分享了將 MongoDB 遷移至 FerretDB 的實驗經驗，指出雖然日常運作無礙，但在執行備份還原等涉及特定資料庫語義的操作時仍存在相容性風險。

延伸閱讀

• Tamarack 官方文件：詳細說明了如何透過 MAC 位址與來源 IP 進行多租戶遷移與設備映射。
• Home Assistant 社群討論：關於如何在不使用官方 NVR 的情況下，透過手動修改設定檔讓 UniFi 攝影機輸出串流的技術細節。
• Ubiquiti 技術規格頁面：包含早期 XR 系列長距離無線模組等硬體歷史資料。