家庭网络 mDNS 与 SSDP 跨 VLAN 透传实战：让 AirPlay、HomeKit、Chromecast 在隔离子网间互通

摘要：划分 VLAN 把 IoT、监控、访客隔离开后，AirPlay、HomeKit、Chromecast 等依赖多播发现的设备往往互相"看不见"。本文讲清 mDNS/SSDP 为何被 VLAN 阻断，并用 OpenWrt 的 avahi 反射 + igmpproxy/udproxy 让发现跨段恢复，同时给出安全收敛建议。

一、为什么一划 VLAN，音箱和电视就"失联"了

很多人在读完 VLAN 隔离教程后，把智能音箱放 IoT 段、手机在办公段、Apple TV 在影音段，结果 AirPlay 投屏找不到了、HomeKit 配件掉线了、Chromecast 搜不到。根因只有一个：AirPlay、HomeKit、Chromecast、DLNA 都靠链路本地多播做服务发现，而 VLAN 的天然边界就是"不通播、不跨段"。多播包出不了自己的子网，发现协议就失效——不是设备坏了，是它们根本"喊"不到对方。

二、mDNS 与 SSDP 到底在喊什么

mDNS（Multicast DNS，组播地址 224.0.0.251:5353）：苹果生态的命根子。HomeKit 配件、AirPlay、Bonjour 打印机都靠它在 .local 域名下自报家门。
SSDP（Simple Service Discovery Protocol，239.255.255.250:1900）：DLNA、UPnP 设备（群晖/飞牛的媒体服务器、Chromecast、智能电视）靠它广播 NOTIFY 并响应 M-SEARCH。

两者都是 TTL=1 的链路本地多播，路由器默认不转发。所以只要设备和服务不在同一二层广播域，发现必然失败。

三、三种解决思路怎么选

把设备放回同一 VLAN：最简单但违背隔离初衷，不建议。
mDNS 反射（Reflector）：在网关上运行 avahi-daemon，监听各 VLAN 的 mDNS，再把查询/应答反射到其他 VLAN。零路由、最省心，适合家庭。
跨段路由 + 静态服务记录：企业做法，在 DNS 里手写 _airplay._tcp 等 SRV 记录，维护成本高。

家庭场景无脑选方案 2 反射。

四、OpenWrt 上用 avahi-daemon 做 mDNS 反射

OpenWrt 官方源就有 avahi-daemon 和 avahi-utils，装好后在 /etc/config/avahi 里启用反射：

config agent
    option reflectors '1'      # 关键：开启跨接口反射
    option interfaces 'lan iot iot_tv'

reflectors '1' 让 avahi 在列出的接口之间转发 mDNS 查询和应答。注意 interfaces 要写成你实际的 VLAN 接口名（如 br-lan、br-iot）。重启服务：

/etc/init.d/avahi-daemon restart

此时手机（lan）已经能发现 IoT 段的 HomePod/音箱，AirPlay 列表重新出现。

五、让 DLNA/SSDP 也跨段：igmpproxy 或 udproxy

mDNS 只解决苹果/AirPlay 系。DLNA/UPnP（飞牛媒体服务器、Chromecast）走 SSDP（239.255.255.250）和 IGMP，需要额外处理。轻量做法是用 udproxy 或 igmpproxy 把 1900 端口的 SSDP 在 VLAN 间转发：

# /etc/config/igmpproxy 示意
config igmpproxy
    option quickleave '1'
config phyint
    option network 'lan'
    option direction 'upstream'
config phyint
    option network 'iot'
    option direction 'downstream'

更干净的是在防火墙里放通对应多播地址的转发规则，避免把整个广播域打通。

六、HomeKit 与 Thread 的例外

用 HomePod/Apple TV 作 HomeKit 中枢时，Thread 边界路由器本身就在做跨网络 Mesh，HomeKit 配件通信走中枢而非纯 mDNS，所以即便不反射，已配对的配件通常也能用。但首次配对、AirPlay 投屏、远程访问仍依赖 mDNS，反射照开不误。Matter over Thread 同理：配网靠 Thread 网络，跨 VLAN 控制靠边界路由，反射是兜底。

七、安全收敛：别无脑全透传

反射会把这些多播"发现信息"暴露到原本隔离的段。建议：

只把真正需要互通的接口列入 interfaces，别把访客 VLAN 也加进去；
配合防火墙，仅放通 5353/1900 多播与对应的单播服务端口（如 AirPlay 的 7000/5000）；
访客段永远不参与反射，避免客人手机发现你家内网设备。

八、怎么验证反射真的生效了

在 OpenWrt 上抓包确认 mDNS 已在 IoT 段出现：

tcpdump -i br-iot udp port 5353 -n

能看到 *.local 的查询/应答即成功。手机端打开"家庭"App 应重新列出配件；视频 App 的 AirPlay 列表应出现客厅 Apple TV。若仍看不到，先查 avahi 的 interfaces 是否写错接口名，再查防火墙是否把 5353 多播转发挡了。

小结

VLAN 隔离不该以牺牲体验为代价。用 avahi 反射解决 mDNS、用 igmpproxy/udproxy 补上 SSDP，就能在"隔离"和"互通"之间拿到平衡。核心记住一句话：多播发现过不了 VLAN，就在网关上做反射，且只反射必要的段。