智能灯泡、无线插座、网络摄像头、扫地机器人，这些消费级物联网设备大多需要持续联网，才能连上厂商的云服务。问题在于，它们会例行公事地产生未经请求的遥测数据、多余的DNS查询，甚至以未加密的方式回传数据流。
如果家里是一张扁平网络，风险就摆在那里。普通消费级网络会把个人工作站、敏感的NAS共享、访客设备和廉价物联网节点放在同一个本地子网里，任何一台设备被攻破，内部资产都可能暴露。把不可信的硬件隔离进受限沙箱，再实时监控和审计出站流量，是更稳妥的做法。
先审计，找出谁最吵
并非所有物联网设备都话多。要审计噪声、找出持续回传的行为，可以用DNS查询日志配合DNS黑洞。把物联网设备的DNS请求导到本地缓存解析器或黑洞工具（如Pi-hole、AdGuard Home），就能实时看到每台设备发起了哪些外部域名查询，从而判断哪些设备在持续请求。需要注意，这类方法会漏掉把DNS服务器写死成8.8.8.8的设备，也会漏掉走DNS over HTTPS的设备。
有些智能设备不理会DHCP下发的NTP服务器，直接去连外部时间服务器。这本身未必有害，很多联网设备确实需要准确对时，但它说明厂商会把用户不易察觉的网络依赖写死在设备里。
还有大量设备会持续发送保活心跳和遥测数据包，智能插座、自动开关、各类连云环境传感器都在其中。它们维持长连接TCP，或周期性向全球云基础设施（如亚马逊云服务、微软Azure，以及各区域厂商的遥测接收桶）发起HTTPS POST请求，上传设备状态、运行时长指标和本地环境诊断信息，制造出大量不必要的连接尝试。
网络分段，以及别忽视防火墙
网络分段依赖可管理交换机和路由器，通过802.1Q VLAN干道把物理端口和SSID逻辑划分到不同子网。比如VLAN 10给可信客户端，VLAN 20给物联网设备，VLAN 30给访客。每个VLAN跑在独立IP子网上，有各自的DHCP作用域，ARP请求、SSDP发现包这类广播流量就无法跨子网泄漏。但VLAN本身不是安全边界。
分段之外还要落实VLAN间防火墙规则。默认应显式拒绝VLAN之间的流量，禁止物联网子网主动向可信管理网络、主LAN和路由器管理接口发起TCP或UDP会话。只对已建立或相关的有状态数据包放行，允许特定的本地控制路径，比如可信VLAN上的Home Assistant服务器去访问某只物联网灯泡的本地API端口。
广播和组播也要处理。手机在VLAN 10，Chromecast在VLAN 20，投屏可能变得困难，而不少消费级智能设备依赖组播协议做本地配对和控制，这些协议原生不跨子网。物联网协议常用多播DNS和SSDP做本地发现，可以在网关上跑Avahi或mDNS中继，让授权的投屏设备和控制器发现本地电器；SSDP需要单独的中继，投屏可能还需要放行VLAN间的单播流量，防火墙规则得相应开口。
另一个问题是，封掉全部广域网访问的同时也封掉了固件检查，安全更新可能因此中断。物联网设备的固件更新需要手动检查并按需安装。
这套折腾下来，我干脆把设备转向本地化。借助防火墙状态表和DNS查询日志，我缓解了物联网设备制造的大部分异常流量：先定位出哪些设备在大量发起不必要的连接尝试，再找出具体的遥测收集服务器，然后建立显式阻断规则，丢弃发往这些已知追踪或分析端点的出站数据包。
对所有兼容设备，我还强制了仅本地运行模式。有些设备断网就会出问题，因为它们需要对时或配对，或者有依赖云端的功能。我把适用的物联网设备接入本地自动化平台，可选方案包括Matter-over-Thread、Zigbee和Z-wave，然后通过阻断特定IP的全部出站广域网流量彻底收回联网权限，同时保留本地子网通信。
改完之后，我复查了防火墙规则匹配计数和丢包日志，持续验证网络隔离是否生效，确保未授权的端口扫描尝试、外部固件检查查询和未经请求的遥测载荷都在网关层被拦截和化解。
普通消费级网络实践会让你对后台遥测、持续的云端握手和日常智能家居设备产生的多余DNS流量一无所知。把物联网硬件隔离到专用VLAN，审计DNS查询解析路径，用严格的防火墙边界验证设备行为，主本地网络才能被保护起来。
热门跟贴