智能家居分 VLAN：看見背景連線，也要接受功能取捨
把智能門鈴、插座、鏡頭等裝置放到獨立 VLAN，再以 DNS 記錄和防火牆規則觀察其對外連線，是了解家居 IoT 行為的一個實用途徑。XDA 作者分享，透過這種安排可找出較頻繁的 DNS 查詢、維持連線及遙測流量，並封鎖已識別的追蹤或分析端點。
不過，這是一篇個人經驗分享，沒有公開原始封包、完整域名清單或量化結果；裝置「致電回家」亦不等同存在漏洞或惡意行為。許多裝置依賴雲端來同步時間、維持連線、傳送狀態或檢查更新，使用者應先分辨流量用途，才決定是否封鎖。
分段的價值，在於縮小影響範圍
一般家居網絡常把電腦、NAS、訪客裝置及 IoT 硬件放在同一個子網。若其中一件 IoT 裝置遭入侵，平面網絡會令它較容易接觸同網的其他裝置。VLAN 可把它們拆到不同子網，例如把可信任裝置、IoT 和訪客網絡分開；廣播流量如 ARP 和 SSDP 探測亦不會直接跨越子網。
但 VLAN 本身並不是完整的安全邊界。真正關鍵是跨 VLAN 防火牆規則：預設拒絕 IoT 主動連到主要 LAN、管理網絡及路由器管理介面，只為所需控制路徑開例外。例如，若 Home Assistant 在可信任網絡，需要控制 IoT VLAN 的燈泡，才按實際本地 API 或連接埠放行。
這種設計把風險由「任何同網裝置都可能互相接觸」，收窄為「只容許預先定義的通訊」。對有 NAS、工作電腦或較多智能家居硬件的用戶，這個分隔比單純更改 Wi‑Fi 密碼更有針對性。
DNS 記錄可作起點，不能當全貌
把 IoT 裝置的 DNS 查詢導向 Pi-hole 或 AdGuard Home 一類本地 DNS sinkhole，可按裝置查看它們嘗試解析哪些外部網域。這能協助辨認持續出現的雲端、遙測或分析端點，再配合防火牆日誌和封包丟棄記錄，判斷封鎖後有沒有影響功能。
不過，DNS 觀察有明顯盲點：裝置可硬編 DNS server，例如 8.8.8.8，或使用 DNS over HTTPS，令本地查詢記錄未必看得到完整去向。因此，DNS 日誌適合作為初步線索，不能單靠它斷定某部裝置沒有對外通訊。
作者亦提到，部分裝置會略過 DHCP 提供的 NTP 設定，直接聯絡外部時間 server。準確時間對連網裝置往往有需要，這個現象本身未必有害；它反映的是廠商可能把網絡相依性寫進裝置，使用者未必在 app 內看得見。
先處理兼容性，再收緊規則
家居分段最常見的代價是本地發現和投放功能受影響。手機在可信任 VLAN、Chromecast 或其他 IoT 裝置在另一 VLAN 時，mDNS、SSDP 等多播發現協定通常不能自行跨網段；本地配對、控制或投放影片可能因而失效。可在 gateway 使用 Avahi、mDNS repeater 或獨立 SSDP relay，並只放行必要的單播流量，但這同時增加設定和排錯成本。
另一個取捨是更新。若完全封鎖 IoT VLAN 的 WAN 流量，裝置可能無法檢查或下載 firmware 更新。較穩妥的做法是先確認哪些裝置支援本地控制，再逐步封鎖特定裝置或端點；每次調整後檢查防火牆命中計數和丟棄日誌，並為仍需更新的裝置保留可管理的更新安排。
實行前也要確認路由器及交換器是否支援 802.1Q VLAN、分開的 DHCP 範圍，以及跨 VLAN 防火牆規則。沒有這些能力時，訪客 Wi‑Fi 可作較簡單的隔離起點，但其可控程度和本地裝置兼容性未必足夠。
下一步值得觀察的，是愈來愈多智能家居裝置能否在不依賴持續雲端連線下維持本地控制。對用戶而言，先建立流量可見度、再按功能需要逐步限制，會比一次過封鎖所有對外連線更容易管理。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- XDA Developers — I put every smart device on its own VLAN, and found out which ones were phoning home constantly — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
