我住三楼，其余楼层出租共 8 户。出租房那边只需要能上网，不是这次改造的重点，后面只作为一条边界出现。
需要设计的是我自己这一侧：一台 NAS、一批智能家居设备、全屋广告过滤、出门在外的远程访问，以及三楼对 YouTube、奈非等的访问需求。这些东西原来堆在一张扁平的网络里。改造的目标是把它们拆成两个互不可见的信任域，并在上游划出一条明确的不可信边界。
一、改造前的链路
原链路是：光猫桥接，主路由 PPPoE 拨号，出租房 8 户的设备、我的 NAS、智能家居和成员设备，全部直接接在主路由下，处在同一个二层网络里。
问题在于这是一张扁平网——没有分域，就没有分权：
- 出租房设备与自用设备同处一个二层广播域，租客设备做一次 ARP 探测就能发现我的 NAS 和其他自用设备，端口扫描也可以直接打过去；
- NAS 只有一块共享盘，没有账号隔离、没有配额、没有自动备份，家庭成员用起来门槛很高；
- 智能家居设备和私有存储挂在同一个网段，一台廉价设备被攻破即可横向触达全部数据。
改造要做的就是把这张扁平网拆开：自用资产收到软路由下游的两个域里，出租房设备留在主路由下，成为一条明确的不可信上游边界。
二、目标与验收口径
改造要落地的是三件事：隔离机制、统一身份、自动化闭环。对应的验收指标如下。
| 目标 | 验收指标 |
|---|---|
| 隔离有效 | 从上游租客网段扫描软路由 LAN 侧资产，越权可达端口数 = 0 |
| 广告过滤 | DNS 层拦截率 ≥ 15%，误杀率 < 1% |
| 网络质量 | 内网延迟抖动 < 2ms，DNS 平均解析 < 30ms |
| 备份闭环 | 增量备份成功率 ≥ 99%，接入 WiFi 后 5 分钟内完成 |
| 远程可用 | 外出访问可用性 ≥ 99% |
| 可维护 | 任一变更可在 15 分钟内回滚 |
三、改造后的链路
链路自上而下分成四段：
出口段。光猫只做光电转换，主路由负责 PPPoE 拨号。出租房设备直接接在主路由下，与软路由 WAN 同处一个二层广播域——这一段在设计上被当作不可信边界，而不是"上一级所以可信"。
网关段。软路由（OpenWrt）作三层网关，WAN 侧 input / forward 默认 REJECT，只有同时限定端口与来源的例外才能放行。
域段。软路由下划分两个互不可见的域：LAN-A 家庭域承载成员设备与 IoT 子域，LAN-B 私有云域承载 NAS、Home Assistant 与 AdGuard Home。域间默认 DROP，只白名单放行 DNS（53/853）、NTP、DHCP 与授权服务端口。
远程段。私有云域内的 NAS 不向公网暴露任何端口，外出访问全部走 Tailscale 加密隧道。
四、隔离怎么落地
- 家庭域与私有云域用 802.1Q VLAN + 独立网段划分，无线侧配独立 SSID，复用现有硬件；
- 域间默认策略 DROP，白名单只覆盖 DNS、NTP、DHCP 与授权服务端口；
- 私有云域关闭客户端之间的横向通信，避免拿到一个账号后可以在域内漫游；
- IoT 设备单独成域，只允许中枢单向访问，收敛横向渗透面；
- 上游边界：软路由 WAN 侧入站默认 REJECT，不放行任何没有来源限制的规则。
五、出口按楼层分开
两层的需求不一样，用一套出口策略凑合，两边都不舒服。
出租房那条链路不在软路由管辖内，只需要能出网，这里不展开。
三楼这一侧要满足两类需求：YouTube、奈非等站点，以及在外网访问家里的 NAS。前者按楼层分开处理；后者走加密隧道，NAS 的 SMB 与管理端口不开放到公网。
这里需要说明服务范围：本方案的全部服务只覆盖软路由下游。出租房设备位于软路由管辖之外，限速、DNS 强制和广告过滤都覆盖不到。这是拓扑决定的能力边界，不是实现疏漏。
六、硬件
软路由是一台联想 H3000（Intel Pentium J2900 四核 / 4GB 内存 / 120GB SSD）。原机带独立显卡，拆掉后把 PCIe 槽换成一张 Intel i226-V 双口 2.5GbE 网卡，WAN 与 LAN 各占一口；板载的 Realtek RTL8136 只有百兆，闲置不用。它是纯 headless 设备，不需要显示输出。
功耗：平台 TDP 10W，整机日常按同平台数据估算约 15W。该平台没有 RAPL 功耗计数器，这个数字是估算值，不是功率计实测。
七、广告过滤的能力边界
AdGuard Home 部署在软路由本地，接管下游全部终端的 DNS，终端零配置。但要先把能拦的和拦不到的分清楚：
| 层 | 手段 | 能拦 | 拦不到 |
|---|---|---|---|
| L1 DNS 域名层 | AdGuard Home + 公开规则 | 网页广告、跟踪器、多数 App 广告 SDK 的域名请求 | 与业务同域的首方广告、CDN 内嵌广告 |
| L2 抓包点名 | 对目标 App 抓包提取域名后回写黑名单 | 特定 App 的广告与推送域名 | 走 HTTPS Pinning 的 App |
| L3 不覆盖 | — | — | 视频前贴片、App 首方内嵌广告、需装证书的电视端 |
抓包在这里只作为一次性的分析手段，用来发现域名，不作为长期 MITM 代理挂在链路上——那涉及证书安装与隐私边界，需要单独取得同意。
八、远程访问
用 Tailscale（也可换 WireGuard）。不依赖公网 IP，设备级 ACL 可控。这里的红线是：NAS 的 SMB 与管理端口绝不直接暴露公网，远程一律走隧道、按内网地址访问。端口映射方案暴露面太大，家庭场景不采用。
九、当前状态
三楼的使用体验是：终端连上 WiFi 即被接管 DNS；照片和文档回到各自的私有目录，成员之间互不可见；在外用流量也能访问家里的媒体库。出租房设备照旧出网，对软路由下的任何资产不可达。
后面要补的是运维侧：资源与服务存活监控、异常告警、配置版本化，以及容量治理。目标是任一变更能在 15 分钟内回滚。