← 返回博客
📝 软路由

2026年软路由网段隔离与内网安全完全指南：VLAN划分、访客网络、IoT设备隔离与防火墙规则实战

✍️ 阿航 📅 最后更新：2026年09月27日 📂 软路由 📖 30 分钟阅读
网段隔离VLAN访客网络IoT隔离防火墙规则OpenWrt
📌 一分钟总结

把设备按信任等级分成几段：访客网、IoT 网、账号网各走各的出口。DSA 与 swconfig 两种设备的 VLAN 写法、访客网最小可用配置、防火墙 zone 规则、按网段分流代理，外加十个常见坑与决策表。

大部分家庭网络只有一段 192.168.1.0/24：手机、电脑、NAS、摄像头、扫地机器人、访客的手机、工作室备用机，全都挂在一起。省事，但代价是把信任等级完全不同的设备塞进了同一个广播域——任何一台被入侵的设备，都能直接扫到你的 NAS、路由器管理页面，甚至内网里的数据库。

更现实的问题是出口。同一个网段里，有人需要稳定的境外专线跑业务，有人只是看看网页，IoT 设备还在不停往厂商云发心跳。全部走同一条路径，主力出口就会被下载和无关流量拖垮。

网段隔离不是企业网络的专利。把设备按「信任等级」分成几段，各自给不同的防火墙策略和不同的出口，是软路由上性价比最高的一次改造：一次配好，长期受益。把网段分开之后，每个网段还要各自决定出口——主网段可以直连，办公与账号网段得走稳定的境外线路。出口这一层建议固定一两家作为基线，IEPL 专线机场如自由猫延迟和抖动都比普通中转低，拿来做「基准出口」最省心，出问题时也更容易判断是自己网络的问题还是线路的问题。

一、先想清楚：隔离到底解决什么问题

网段隔离的价值有三层，按重要性排序：

第一层，限制爆炸半径。一台设备中毒、被植入、被远程控制，它能横向扫描的范围就限于自己所在的那一段。这就是安全圈里说的「横向移动」——攻破一台门禁摄像头远比攻破主力电脑容易，而它们如果同网段，摄像头就是通往你内网的跳板。

第二层，按网段分配出口。主网段可以走直连或轻量代理；工作/账号网段走固定专线出口；访客网段走一条便宜的大流量线路；IoT 网段只允许出网、不准进内网。同一条宽带，四种完全不同的策略。

第三层，可控的广播域。几十台设备同网段时，ARP 表混乱、DHCP 冲突、某台设备的广播风暴都会放大。分段之后每段的设备数量可控，排障时"哪一段出问题"这个信息本身就能省掉一半时间。

这三层里，第一层是刚需。第二层是这次改造真正的收益点——很多人做隔离的初衷不是为了安全，而是为了让主力出口不被无关流量污染。

顺便说一句：网段规划是后续所有配置的地基。如果你连 LAN 网段和 DHCP 池都还没理顺，建议先回到软路由首次配置清单把拨号方式、LAN 网段避开光猫冲突、DHCP 地址池与静态租约、DNS 下发这几项过一遍，再来划分网段会顺很多。

二、四种隔离做法怎么选

先破除一个误区：不是所有人都有必要划 VLAN。VLAN 是二层隔离，最适合「有线设备多、要接交换机和多个 AP」的场景。如果你家设备基本都是无线接入，用「独立 SSID + 独立子网 + 独立防火墙 zone」就能拿到九成收益，而且不会因为交换机不支持 VLAN 而卡住。

做法隔离层级需要什么适合代价
桥内多 VLAN（DSA bridge-vlan）二层支持 DSA 的设备；需要带 VLAN 的交换机或 AP有线设备多、多 AP、要跨设备延伸同一网段配置复杂度最高，配错会失联
多个桥设备（br-home / br-office）二层只要网口够多x86 软路由，按物理口分网段网口占满，不方便延伸
独立 SSID + 独立子网 + 独立 zone三层任何 OpenWrt 设备无线为主的家庭，访客网、IoT 网二层仍相通，需靠防火墙拒绝转发
仅用代理网关的访问控制不隔离代理插件（OpenClash 等）只想按设备/网段决定走不走代理只是分流，不是安全边界

最后一行需要特别强调：代理插件的「访问控制」是分流工具，不是隔离工具。它们解决的是「哪些设备走代理」，完全没有阻止设备之间互相访问。很多人以为在 OpenClash 里把 IoT 加进黑名单就"隔离"了，实际上摄像头照样能访问你 NAS 的 5000 端口。

如果你已经有一台旁路由在做透明网关，隔离和代理可以分开处理：旁路由负责出口，主路由负责网段。旁路由的搭建与常见坑可以参考旁路由完全指南，本文重点放在主路由这一侧的分段与防火墙规则。

分段的第二层收益在出口。设备一旦分开，你就有条件按段分配出口：主网段直连或轻量代理，办公网段绑一条固定专线，访客网段走便宜的线路。这里最省心的选择是纯 IEPL 线路的机场——不需要自己判断节点走的是中转还是专线，配置里几乎没有可调项，比如SS-ID这类纯 IEPL 方案，用「不动脑」换稳定性，适合直接当一个网段的固定出口，主线路抖动时切换成本也最低。

三、OpenWrt 上划 VLAN：先确认是 DSA 还是 swconfig

这一步不能凭记忆，因为两种驱动的写法完全不通。OpenWrt 从 21.02 起逐步用 DSA（Distributed Switch Architecture）替代 swconfig，新设备基本都是 DSA，但老设备、特别是从 19.07 一路升级上来的，可能还是 swconfig。

一条命令判断：

if grep -sq DEVTYPE=dsa /sys/class/net/*/uevent; then
  echo "You have DSA"
else
  echo "swconfig device"
fi

官方特别提醒过：从 21.02 之前的版本升级、或者设备从 swconfig 换成 DSA 驱动之后，最好不要沿用旧配置，重新配一遍比迁移更稳。

DSA 写法：桥 + bridge-vlan

DSA 里 VLAN 是「桥的 VLAN」，不是交换芯片 VLAN 的直接等价物。配置分两部分：config device 定义桥和它的成员口，config bridge-vlan 定义每个 VLAN 有哪些口、是 tagged 还是 untagged。端口写法里 u 是 untagged，t 是 tagged，* 表示这个口是该 VLAN 的 PVID（收到未打标签的帧就归到这个 VLAN）。

# /etc/config/network 片段
config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

# VLAN 10：主网段，lan1/lan2 接内网，lan4 是通往 AP 的 trunk
config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1:u*'
	list ports 'lan2:u*'
	list ports 'lan4:t'

# VLAN 20：IoT 网段
config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan3:u*'
	list ports 'lan4:t'

# VLAN 30：访客网段
config bridge-vlan
	option device 'br-lan'
	option vlan '30'
	list ports 'lan4:t'

# VLAN 90：垃圾桶 VLAN，放未使用的网口
config bridge-vlan
	option device 'br-lan'
	option vlan '90'
	list ports 'lan4:u*'
	option local '0'

config interface 'lan'
	option device 'br-lan.10'
	option proto 'static'
	option ipaddr '192.168.10.1'
	option netmask '255.255.255.0'

config interface 'iot'
	option device 'br-lan.20'
	option proto 'static'
	option ipaddr '192.168.20.1'
	option netmask '255.255.255.0'

config interface 'guest'
	option device 'br-lan.30'
	option proto 'static'
	option ipaddr '192.168.30.1'
	option netmask '255.255.255.0'

接口名用 br-lan.10 这种「桥名 + VLAN ID」的写法，防火墙里再把 interface 绑到不同的 zone。

swconfig 老设备

swconfig 设备用 config switch_vlan，绑在 switch0 之类的交换芯片上，端口用数字编号加 t／u 后缀（例如 option ports '1t 2t 3'）。如果你在 /etc/config/network 里看到 config switch 段，那就是 swconfig 路线，不要照抄上面的 DSA 写法。

三条安全纪律

官方文档在 VLAN 安全一节里给了几条容易被忽略的建议，值得照抄：

不要用 VLAN 1 承载数据网。VLAN 1 在大量网络设备上是硬编码默认值，也因此是攻击和误配置最常见的落点。

把 trunk 口的 native VLAN 改成未使用的 ID，显式要求 trunk 上只通行带标签的流量。注意部分硬件不支持在一个口上混用 tagged 与 untagged，这种设备用不了这招。

空闲网口挂到不用的 VLAN。把没人用的网口（lan3:u* 这种写法）划进一个「垃圾桶 VLAN」，并设 option local '0'——这样 OpenWrt 不会给它建接口，物理插上网线也进不了任何一段网络。

四、访客网络：独立 SSID + 独立子网 + 只出不进

访客网是最容易做、收益最明显的一段。目标很简单：访客能上网，能拿 IP，能解析 DNS，但碰不到你的 NAS、路由器管理页和任何内网设备。

在动手配之前先说出口这件事：访客网段的出口可以单独配一个订阅。这类「低优先级、但确实要出去看境外站点」的流量不值得占用主力出口，用一份便宜的大流量套餐把它接住就好——像瑶瑶领先这种入门档（9.9 元 384GB 级别）的定位就是小流量、多设备、低预算场景，给访客网段或备用设备当出口，成本压力小，也不会和办公网段抢线路。

官方给的标准配方分四步——网络、无线、DHCP、防火墙。下面这段可直接改地址照用：

# 1) 网络：独立子网
uci -q delete network.guest
uci set network.guest="interface"
uci set network.guest.proto="static"
uci set network.guest.device="br-guest"
uci set network.guest.ipaddr="192.168.30.1/24"
uci commit network

# 2) 无线：独立 SSID 绑到 guest 网段
uci -q delete wireless.guest
uci set wireless.guest="wifi-iface"
uci set wireless.guest.device="$(uci get wireless.@wifi-iface[0].device)"
uci set wireless.guest.mode="ap"
uci set wireless.guest.network="guest"
uci set wireless.guest.ssid="Guest"
uci set wireless.guest.encryption="psk2"
uci set wireless.guest.key="换成你自己的密码"
uci commit wireless

# 3) DHCP：独立地址池，租期放短
uci -q delete dhcp.guest
uci set dhcp.guest="dhcp"
uci set dhcp.guest.interface="guest"
uci set dhcp.guest.start="100"
uci set dhcp.guest.limit="150"
uci set dhcp.guest.leasetime="1h"
uci set dhcp.guest.force="1"
uci commit dhcp

force 是官方在「Resolving race conditions」里给的做法：把 dhcp.guest.force 设为 1，避免 netifd 启动顺序导致的 DHCP 服务不绑定接口。表现为「WiFi 连上了但拿不到 IP」，遇到这个症状先查它。

防火墙这一步是重点，也是唯一必须逐条理解的一步：

# 4) 防火墙：独立 zone，只出不进
uci -q delete firewall.guest
uci set firewall.guest="zone"
uci set firewall.guest.name="guest"
uci set firewall.guest.network="guest"
uci set firewall.guest.input="REJECT"
uci set firewall.guest.output="ACCEPT"
uci set firewall.guest.forward="REJECT"

# 只允许访客转发到 wan
uci -q delete firewall.guest_wan
uci set firewall.guest_wan="forwarding"
uci set firewall.guest_wan.src="guest"
uci set firewall.guest_wan.dest="wan"

# 放行 DNS 与 DHCP，否则访客连域名都解析不了
uci -q delete firewall.guest_dns
uci set firewall.guest_dns="rule"
uci set firewall.guest_dns.name="Allow-DNS-Guest"
uci set firewall.guest_dns.src="guest"
uci set firewall.guest_dns.dest_port="53"
uci set firewall.guest_dns.proto="tcp udp"
uci set firewall.guest_dns.target="ACCEPT"

这里有两个关键理解：input REJECT 意味着访客连路由器的管理界面都访问不到；forward REJECT 意味着访客之间的转发也被拒绝，再加上一条 guest→wan 的 forwarding，访客就只能出网。DHCP 请求（UDP 67）如果是 IPv4 网段，还需要一条放行规则，否则设备拿不到地址——这一点和 DNS 一起构成「访客能用」的最小集合。

如果想让访客只能看网页、连 SSH、游戏的端口都不通，可以把那条 forwarding 换成一条只放 80/443 的 rule：

uci set firewall.guest_fwd="rule"
uci set firewall.guest_fwd.name="Allow-HTTP/HTTPS-Guest-Forward"
uci set firewall.guest_fwd.src="guest"
uci set firewall.guest_fwd.dest="wan"
uci add_list firewall.guest_fwd.dest_port="80"
uci add_list firewall.guest_fwd.dest_port="443"
uci set firewall.guest_fwd.proto="tcp"
uci set firewall.guest_fwd.target="ACCEPT"

如果访客自己的设备也要互不可见（比如你在开小型活动，不想让来客互相扫端口），打开无线层的客户端隔离：

uci set wireless.guest.isolate="1"
uci set wireless.guest.bridge_isolate="1"
uci commit wireless
wifi reload

isolate 隔离同一个无线接口下的客户端，bridge_isolate 进一步隔离不同无线接口之间的客户端（双频各一个 SSID 的情况就需要它）。官方明确提示「部分硬件或驱动不支持这个选项」——设完一定要实测。

最后是治理，不是安全：访客网段值得单独限速，否则一个人下电影全屋遭殃。官方给了 qos-scripts 的做法（opkg install qos-scripts，然后在 uci 里给 guest 接口设 upload/download 的 kb/s），更新也更推荐图形界面的 luci-app-sqm。

五、IoT 网段：智能家居其实最该被关起来

智能家居设备的共同点是：固件常年不更新、必须连厂商云、为了能被 APP 发现而开放本地端口、出厂密码经常没人改、通信行为对用户完全不可见。它们是家里「最不可信」的一批设备，但通常又是最不值钱、最容易换的一批——所以隔离它们几乎没有代价。

IoT 网段的策略可以更激进，只有一条原则：只能出网，谁都不许主动访问它，它也不许主动访问别人。

uci -q delete firewall.iot
uci set firewall.iot="zone"
uci set firewall.iot.name="iot"
uci set firewall.iot.network="iot"
uci set firewall.iot.input="REJECT"
uci set firewall.iot.output="ACCEPT"
uci set firewall.iot.forward="REJECT"

# IoT 只能转发到 wan，不能到 lan
uci -q delete firewall.iot_wan
uci set firewall.iot_wan="forwarding"
uci set firewall.iot_wan.src="iot"
uci set firewall.iot_wan.dest="wan"

注意这里没有给 lan → iot 任何 forwarding。原因是防火墙的 forwarding 是单向的，一条规则只管一个方向；要双向通必须写两条。IoT 网段通常不需要任何一条——你不需要从电脑主动连摄像头，需要的时候用厂商 APP（走云端）就够了。

例外情况有两种，都靠 config rule 精确开口，而不是整段放开：

一是 NAS 接收摄像头录像。这种要让摄像头主动推流到 NAS，规则要写源是 iot、目标是 lan、目标是 NAS 的特定端口（例如 554 或厂商私有端口）。

二是家里有需要被内网访问的设备，比如本地 Home Assistant 要读某台设备的状态。同样按端口开，不要按网段开。

给 IoT 设备配静态租约是个值得做的额外动作。DHCP 池里的地址随租期漂移，写死规则时会很难受：

# 给设备固定 IP，方便后续写规则
uci add dhcp host
uci set dhcp.@host[-1].name="camera-1"
uci set dhcp.@host[-1].mac="AA:BB:CC:DD:EE:FF"
uci set dhcp.@host[-1].ip="192.168.20.11"
uci commit dhcp

顺带一个经验值：IoT 网段的 DHCP 池建议留足，但也别和主网段撞号。家庭 IoT 设备实际活跃数量经常比你记的多（网关、插座、传感器、摄像头、扫地机、音箱都可能各占一个 IP），池子给 50 个以上的余量比较稳。

六、跨境多账号：为什么必须给「账号设备」单独开一个网段

前面的隔离都是「防内网横向移动」，这一段是另一个维度的需求：隔离身份。

做跨境电商多店铺、社媒矩阵、海外广告投放的人，最怕的不是网络慢，而是多个账号被平台判定为同一主体。平台侧的关联判断通常看三件事：账号环境（浏览器 / 指纹）、网络出口（IP），以及行为轨迹的时间相关性。网段隔离解决的是第二件事——如果两个店铺共用同一个出口 IP，光靠浏览器隔离是拦不住关联的。

正确做法是「一个账号组 = 一个网段 = 一个固定出口」：

  • 把每个账号组的设备塞进独立网段（例如 192.168.40.0/24 / 192.168.41.0/24）
  • 这一段的出口绑定固定节点或固定 IP，不要用会漂移的负载均衡/自动选择策略组——今天走 A 节点、明天走 B 节点，等于每天换一次身份
  • 出口 IP 的类型要在意：机房 IP 与住宅/原生 IP 在平台风控里的表现差距明显（这不是平台公开文档，而是长期运营出来的经验判断），账号类业务优先用住宅/原生 IP 出口
  • 给账号网段单独限速并禁止 P2P/下载，避免把出口 IP 拉进黑名单，这块的判断标准可以参考机场避坑与防跑路指南里关于线路稳定性的部分

这里必须要一个定位匹配的出口。要做住宅 IP、原生 IP 这类出口，机场里可选的并不多，仙路湾的定位就是住宅 IP / 原生 IP，主要面向跨境多账号、流媒体解锁这类需要 IP 纯净度的场景。给「账号设备」整租一个网段绑到这条出口上，比在每台设备上单独装客户端、单独维护配置要省太多事——尤其账号设备数量一多，集中管理是唯一可行的方式。

最后一条纪律：账号网段的设备不要用来做任何「拉满带宽」的事情。同一条出口上的 IP 一旦因为异常流量被标记，你的账号组是一起受影响的。

七、隔离的边界：哪些设备不该搬走

隔离做到一半最容易翻车的地方不是技术，是「哪些设备不能分开」。因为很多家庭设备互相发现靠的不是路由器，而是 mDNS 和 SSDP 这类链路本地多播——它们压根不跨三层。把设备分到不同网段，等于把它们的发现机制掐断。

典型受害者：

  • AirPrint / AirPlay 打印机与投屏：靠 mDNS 发现，跨网段会「找不到设备」
  • Chromecast、部分智能电视：靠 mDNS + SSDP 发现
  • HomeKit / 米家 / 涂鸦等家庭中枢：本地控制依赖同一网段（云端控制不受影响）
  • NAS 与家庭影音库：DLNA 发现同样是多播

所以正确的分法不是「按房间分」，而是「按信任等级分」：需要互相发现的设备放在同一段（手机、电脑、NAS、打印机、投屏、家庭中枢），把不需要被信任的设备赶出去（IoT、访客、工作室外部设备）。

如果确实要把发现机制跨网段带过去，只有两条路：在路由器上跑一个 mDNS 反射/中继，或者放弃本地发现改用云端/直连 IP。反射方案后面在排错一节里会讲，它的前提是你清楚自己在扩大什么范围。

一个具体的折中例子：家里有 NAS、Apple TV、几台 HomePod 和一堆智能灯，怎么分？NAS、Apple TV、手机、电脑留在主网段——投屏、AirPlay、局域网直连全部照常；智能灯、摄像头、扫地机、智能音箱这些只需要连云端的设备丢进 IoT 网段，它们的日常控制走厂商云，换网段完全不影响使用；访客单独一段。这样三段各司其职，主网段里不留任何「不该联网的设备」，而需要互相发现的设备一台都没被分开。

八、代理网关与网段联动：哪些网段走代理，哪些直连

网段划好之后，最容易产生的新需求是「按网段决定谁走代理」。这件事有三个层次，按精细度递增：

层次一：防火墙层直接拒绝。把某个网段完全不纳入代理链。优点是干净，缺点是这条网段的流量无论目标是什么都不走代理。

层次二：代理插件的访问控制黑白名单。以 OpenClash 为例，它提供 lan_ac_mode（0 黑名单 / 1 白名单，默认 0），配套的列表项是 lan_ac_black_ips、lan_ac_black_macs、lan_ac_white_ips、lan_ac_white_macs，IP 项支持 IP 或 CIDR 网段，MAC 项支持 MAC 地址。底层实现是在防火墙层用 nftables 的 ip saddr（IP）与 ether saddr（MAC）匹配，命中就 return 走直连。

这里有两个必须知道的依赖，很多人配了不生效就是踩在这：一是 Fake-IP 模式下必须把 DNS 模式设为「防火墙重定向」（enable_redirect_dns=2），因为 Fake-IP 返回的是虚拟 IP，客户端并不知道真实目标，必须靠防火墙重定向 DNS 才能做出基于真实目标的访问控制；二是 白名单模式（lan_ac_mode=1）只在 redir-host 系列模式下生效，MAC 白名单是唯一不受这条限制的。换句话说，你想按 IP 段做白名单，就得先确认代理模式是 redir-host 系列。

实操上最常用的两条规则是：想让某个网段整体直连，就往黑名单里写 CIDR（例如 192.168.20.0/24，顺带把 IoT 网段丢进去）；想只让主网段走代理，就用白名单模式加主网段 CIDR。用网段做分流的前提是网段地址固定，所以前面说的静态租约、固定 DHCP 池在这里会再收一次回报。

层次三：来源流量访问控制。如果维度不止「网段」，OpenClash 在插件设置页底部还提供了一个 lan_ac_traffic 规则表，可以按七个维度组合匹配：内部地址（src_ip，支持 IP、CIDR 和 localnetwork）、内部端口、协议、地址族、接口（如 eth1、wg0、docker0）、用户 UID、以及 DSCP 标记；匹配后的动作可选 RETURN（跳过代理走直连）、ACCEPT（放行）、DROP（静默丢弃）。它的规则被插在代理链的 position 0，优先级高于其他所有代理规则。

这个功能解决的是网段解决不了的问题：Docker 容器流量、WireGuard 隧道流量、某个进程（按 UID）的流量要不要绕过代理。做容器和虚拟化的时候特别有用。

还有一个很容易踩的坑：如果你用 MAC 名单做访问控制，而手机或电脑开着「私有 Wi-Fi 地址」（iOS、Android、Windows 默认都会开），这个设备每次连 WiFi 都可能换一个随机 MAC，名单自然就失效了——表现是「昨天还好好的，今天这个设备突然走了代理/突然不通了」。规避办法是两条路选一条：要么把这个设备的随机 MAC 关掉并固定，要么放弃 MAC 名单、改用 IP 段匹配，前提是给它固定了 DHCP 租约。相比之下按网段和静态租约组合做规则，长期维护成本最低。

需要提醒的是，DNS 也会影响分流的实际效果。代理分流是「连接层」，DNS 分流是「解析层」，两者不一致会出现「规则明明写了直连，实际还是走了代理」。这类问题的排查思路在软路由 DNS 分流与防污染指南里讲得很细；代理侧的策略组和规则设计则参考OpenClash 进阶配置。

九、十个常见的坑与排错

症状最可能的原因怎么查
访客 WiFi 连上了但拿不到 IPDHCP 未绑定接口，或 netifd 启动竞争查 /tmp/dhcp.leases；确认该 dhcp 段的 interface 与 force 设定
访客仍能访问 NAS只加了 SSID，没建独立 zone，仍在 lan 区uci show firewall 看访客接口挂在哪个 zone
以为隔离了，但电脑还能 ping 通摄像头同 zone 内 forward 是 ACCEPT两条网络如果属于同一个 zone，必须拆成两个 zone 才会被拒绝
跨网段投屏/HomeKit 找不到设备mDNS 是链路本地多播，不跨三层见下方第 4 条详解
IPTV / 组播花屏桥的 IGMP snooping 未开netifd 的桥设备支持 igmp_snooping 选项（开启时默认同时打开 multicast_querier）
改完 VLAN 后连不上路由器管理接口没有 zone，或被划进了 local '0' 的 VLAN留一个能带 IP 的接口并绑到 input ACCEPT 的 zone
网段隔离了，代理还是全局生效访问控制没按网段写，或写成 /32看黑白名单列表里是不是 CIDR；确认 DNS 重定向依赖是否满足
智能家居 APP 本地控制失效中枢与设备不在同一网段把中枢留在主网段，或改用云端模式
IPv6 泄漏，设备绕过代理只隔离/代理了 IPv4每个网段单独看 IPv6 是否分配了地址与路由
改网络配置后彻底失联没有回滚路径先 uci export network > /tmp/net.bak，再动手

关于第 4 条，展开说一下。mDNS 工作在链路本地多播地址（IPv4 下是 224.0.0.251，IPv6 下是 ff02::fb），路由器默认不跨网段转发。要让它跨过去，需要在路由器上跑一个反射/中继，让它在多个接口之间转发 mDNS 报文。avahi 的配置文件里就有专门的段落——配置文件模板中 [reflector] 段的 enable-reflector 默认是 no，打开它才会跨接口反射。开启前想清楚边界：反射意味着你主动把某个网段的设备暴露给了另一个网段的发现机制，这正好和隔离的初衷相反。

另一个高频坑是「网段改了但 DHCP 池没改」。旧网段的池子还留在配置里，设备从旧池拿到地址，网关却是新网段的地址——表现是「能连 WiFi 但不能上网」。这类问题的判断方法和软路由科学上网故障排查指南里「先判断是网络层还是代理层」的思路一致：先看能不能 ping 通网关，再看 DNS，最后才怀疑代理。

还有两条命令级别的经验：在 DSA 设备上查当前 VLAN 用 bridge vlan show，比翻配置文件可靠；查防火墙最终生效的规则用 nft list ruleset（fw4）或 iptables-save（fw3），因为 uci 里写的内容要经过服务生成才生效，两者不一致说明服务没重启或规则被别的脚本覆盖。

十、按需求选方案：四种典型配置

场景最少要做的事出口安排
租房 / 单间，设备 10 台以内① 一个访客 SSID + 独立子网；② 访客 zone input/forward REJECT；③ 访客限速全网共用一条轻量机场
家庭，有 NAS + 一堆 IoT① 主/IoT/访客三段；② IoT 只出网；③ NAS 按端口对摄像头开口主网段直连或轻代理；IoT 直连（如需访问境外服务再单开）
家庭 + 有线设备多 / 多 AP① 桥内划 VLAN；② trunk 到 AP，禁用 VLAN 1 承载数据；③ 空闲口进垃圾桶 VLAN按 VLAN 分出口，办公 VLAN 绑固定节点
工作室 / 多账号运营① 一个账号组一个网段；② 固定 IP 出口，不用漂移策略组；③ 账号段禁下载账号段绑住宅/原生 IP 出口；访客段单开便宜套餐

如果目标只是「别让访客碰到我的东西」，第一行的三件事就够了，十分钟能配完。真正需要划 VLAN 的是第三行——有线设备多、要跨交换机与 AP 延伸同一网段的时候，VLAN 才是唯一干净的解法，多设备之间的延伸方式可以顺带参考软路由异地组网指南里关于接口与隧道边界的部分。

十一、一页速查卡

# 判断 DSA 还是 swconfig
grep -sq DEVTYPE=dsa /sys/class/net/*/uevent && echo DSA || echo swconfig

# 动手前备份（失联时用第一条回滚）
uci export network > /tmp/net.bak
# 回滚：uci import network < /tmp/net.bak && uci commit network

# 查看当前 VLAN、桥成员与地址
bridge vlan show
ip -d link show
ip -4 addr

# 查看最终生效的防火墙规则（与 uci 配置可能不同）
nft list ruleset | head -50

# 看 DHCP 租约，判断设备到底落在哪个网段
cat /tmp/dhcp.leases

# 某个网段是否被代理命中（OpenClash 场景）
uci show openclash | grep -i "lan_ac"

# 桥的组播开关（IPTV / 投屏相关问题）
uci show network | grep -i "igmp\|multicast"

十二、常见问题（FAQ）

Q1：运营商光猫 + 软路由当二级路由，还需要划网段吗？
需要，但可以简化。二级路由后面就是一个独立子网，访客和 IoT 网段直接建在软路由上即可，不用动光猫。唯一注意点是别让软路由的 LAN 网段与光猫网段撞号，这属于首次配置就要确认的项。

Q2：交换机不支持 VLAN，VLAN 方案是不是就废了？
不是。有线侧受限，但无线侧照样能分段——用「独立 SSID + 独立子网 + 独立 zone」做三层隔离，成本为零。等换交换机时再升到 VLAN。

Q3：一个 SSID 能同时给访客和 IoT 用吗？
技术上可以，但别这么干。访客是「人」，IoT 是「设备」，两者的防火墙策略完全不同（访客要允许大量出站，IoT 需要更严的出站白名单与固定 IP），混在一段会让规则变得难以维护。

Q4：隔离后打印机、投屏会不会找不到？
如果打印机和电脑分到了不同网段，会。把需要互相发现的设备留在同一段，是比开 mDNS 反射更省事的做法。

Q5：访客网段限多少合适？
看你的上行。经验做法是按总上行的三到五成给访客，留出余量给主网段。家用宽带的上行通常远小于下行，访客上传更容易把线路吃满。

Q6：访客网段要不要也走代理？
看访客需要什么。只是上国内网站不需要。如果访客要看境外站点，建议单独给它一份订阅而不是共用主力出口——这也是低优先级网段最合理的成本安排。

Q7：VLAN ID 怎么选，为什么不能用 VLAN 1？
1 是很多网络设备硬编码的默认 VLAN，最容易成为攻击和误配置的落点；数据网从 10、20、30 这种开始编号即可，再留一个高位 ID（如 90）当垃圾桶 VLAN。

Q8：无线 Mesh / AP 模式下怎么把网段带到远端？
有线回程的 AP 用 trunk 口带 tagged 流量过去，在 AP 上再拆成不同 SSID 绑不同 VLAN。无线回程的 Mesh 通常不支持 VLAN 透传，这种场景只能退回到「一台设备一个 SSID 网段」的方式。

Q9：网段隔离能防住设备中毒吗？
不能防中毒，但能把影响限制在一段之内。隔离的价值是「爆炸半径」，不是「免疫」。

Q10：IoT 网段要不要做时间控制？
不必按网段做。如果需要控制访问时段，用单设备的规则或设备自带的功能更合适，避免把网络策略和业务规则混在一起。

Q11：要不要给每个网段单独配 DNS？
多数场景不需要，共用一个 DNS 就够。当某个网段需要不同的解析策略（例如访客段做去广告、办公段走 DoH）时才有必要分开，此时注意 DHCP 下发的 DNS 要跟着改，否则设备还是用旧的解析器。

Q12：只有一台路由器，隔离会不会让网变慢？
三段网段之间的转发都在同一台设备内部完成，硬件转发路径几乎不变。真正的性能开销来自代理（加解密与转发模式）和 QoS，与网段数量无关。如果你的瓶颈是代理吞吐，先看软路由性能优化里的转发模式与 MTU 部分。

Q13：改了网段之后，之前按 IP 写的规则都要重写吗？
要。任何按 IP 或 MAC 写的规则都绑定在具体地址上，网段一变全部失效。这也是为什么建议一次性把网段规划到位——每改一次地址规划，都要回头核对一遍防火墙规则、DHCP 静态租约和代理插件的访问控制列表。

Q14：怎么确认隔离真的生效了，而不是「看起来生效」？
用真实设备做双向测试，不要只在路由器上 ping。断开一台设备、连到目标网段的 SSID，然后从它去 ping 主网段的 NAS、访问路由器管理页、扫一下常见端口；再从主网段的电脑反向访问它。两边都通不了，才算隔离生效。只测一个方向是最常见的误判来源。

推荐阅读

网段分好之后，下一步通常是让代理插件也按段工作，OpenClash 规则集运维指南讲的是规则更新与命中率验证；如果你还在犹豫用哪个代理插件，软路由代理插件对比里对各插件的访问控制与性能差异有逐项对比。

升级硬件时的取舍（多口网卡、ARM 与 x86 的转发能力差异、不同预算该买什么）可以参考软路由硬件选购指南。

📖 推荐阅读

📝 软路由

软路由入门指南：OpenWrt安装配置到全屋科学上网

📝 软路由

OpenClash进阶配置指南：分流策略、规则优化与性能调优

📝 软路由

2026年主流软路由固件横评：OpenWrt、iStoreOS、爱快、ROS到底哪个最适合你？

← 上一篇：2026年自建节点CDN中转完全指南：用 C…下一篇：2026年独立开发者出海网络完全指南：开发资…
📑 目录