Files
my-vault/02_Areas/Network & VPN/ADR - Home Network Layer 3 Boundary.md
T

270 lines
18 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "ADR - Home Network Layer 3 Boundary"
type: architecture-decision-record
status: accepted
date: 2026-08-07
tags: [network, adr, vlan, router, switch, security]
related:
- "[[Home Network]]"
- "[[Home Network Upgrade Plan]]"
---
# ADR:家庭网络的三层职责边界
## 状态
**已接受(Accepted**2026-08-07 确认采用方案 ARB5009 管理全部 VLAN 的三层接口、DHCP 与防火墙,核心交换机仅做二层 VLAN 转发。
## 背景
当前家庭网络有两个 IPv4 网段:
| 网络 | 现有网关 | 用途 |
| --- | --- | --- |
| `192.168.66.0/24`(拟 VLAN 66 | `192.168.66.254` | 电脑、可信设备、网络管理与基础设施 |
| `192.168.55.0/24`(拟 VLAN 55 | `192.168.55.254` | IoT 与 Home Assistant |
计划以 RB5009 替换 ER-X,并增加一台无风扇、支持 VLAN 的核心交换机。已确定的约束与目标:
- IoT 默认不能主动访问电脑网;电脑网可访问 IoT 网全部资源。
- IoT 可上网、使用 AdGuard Home DNS;未来可通过明确的服务例外规则访问电脑网服务。
- DHCP、DNS、IPv6 PD、PPPoE、NAT、端口转发与 WireGuard 迁移后应稳定、易排障。
- WireGuard 部署在 RB5009,采用分流;VPN 客户端可访问两个内网。
- 保留现有地址规划与基础设施 IP。
- 卧室部署,核心交换机要求无风扇或极低噪音;不要求 PoE。
- 核心交换机目标规格为 8–16 × 2.5GbE,具有 2–4 个 10G 上联;未来电脑网的纯万兆可独立扩展。
候选核心交换机为 **TP-Link Omada SG3210X-M2**8 × 2.5GbE、2 × 10G SFP+、无风扇,支持 VLAN、ACL 与静态路由。本文只将其作为二层 VLAN 交换机使用。 [官方规格](https://www.tp-link.com/us/business-networking/omada-switch-l3-l2-managed/sg3210x-m2/v1/)
## 待决策问题
两个 VLAN 的默认网关、DHCP 与跨 VLAN 安全策略应部署在:
1. **方案 ARB5009**(交换机仅做二层 VLAN 转发);或
2. **方案 B:核心交换机**(交换机做三层网关,RB5009 仅做 WAN/VPN)。
## 已确认的目标设计
| 范畴 | 已确认决策 |
| --- | --- |
| 网关与交换 | RB5009 是 VLAN55/VLAN66 的唯一网关、DHCP、防火墙、PPPoE、IPv6 PD、NAT 与 WireGuard 终点;SG3210X-M2 仅做无风扇二层 VLAN 交换。 |
| VLAN 与地址 | VLAN66`192.168.66.0/24` / 网关 `.254`VLAN55`192.168.55.0/24` / 网关 `.254`;保留既有地址池 `.38``.243`。 |
| 交换机上联 | RB5009 与交换机使用 10G SFP+ DACtrunk 仅允许 tagged VLAN55、VLAN66,不承载 native/untagged VLAN。 |
| 管理面 | 交换机通过 RB5009 DHCP 静态租约获得 `192.168.66.2`,仅 VLAN66 本地 HTTPS 管理;保留 Console 救援。RB5009 仅允许 VLAN66 与 WireGuard 的 HTTPS/SSH/WinBox 管理。 |
| 二层安全 | 未使用交换机端口禁用;启用 RSTP、环路/风暴保护与 DHCP Snooping;只有 RB5009 trunk 是 trusted DHCP 端口。 |
| Wi-Fi | U6 LiteVLAN66、电脑 SSID、仅 5GHz、WPA2/WPA3UAP-AC-LiteVLAN55、IoT SSID、仅 2.4GHz、WPA2-PSK/AESSSID 密码不同,初始不启用 IoT 无线客户端隔离。 |
| PVE 与 gfw | PVE 管理面仅 VLAN66 `192.168.66.26`;保留两条物理 access 网线,分别接 VLAN66/VLAN55。IoT VM 仅接 VLAN55。gfw VM 双网:`.66.1``.55.1`,保持按规则选用的旁路由,而非默认网关。 |
| Home Assistant | 独立物理服务器,VLAN55 access 端口,静态租约 `192.168.55.11`;不公开 `8123`。 |
| DNS 与服务隔离 | DHCP 只下发 AdGuard Home `.66.36`,无公共备用 DNS。IoT → 电脑网默认拒绝,但 RB5009 维护按“目标 IP + 协议 + 端口”的服务例外清单。 |
| 设备发现 | 启用 VLAN66 ↔ VLAN55 双向 IPv4 mDNS repeaterSSDP/IGMP relay 仅在具体设备需要时另行配置。 |
| IPv6 | 首次迁移即保留 PD `/60`,各 VLAN 一个 `/64`,应用等价的 IoT 隔离;公网 IPv6 默认拒绝入站。 |
| 远程访问 | WireGuard 运行于 RB5009UDP `51820`,分流,客户端可访问两个 VLAN,并使用 `.66.36` DNSDDNS 供应商待定。 |
| 公网暴露 | 保留 Transmission IPv4 与 IPv6 TCP/UDP `51413`;不迁移 OpenVPN、公网 SSH 或 Home Assistant `8123`;关闭 UPnP/NAT-PMP 与 Hairpin NAT。PS 位于 VLAN66、使用 DHCP 静态租约,端口按游戏需要手动添加。 |
| 运维 | RouterOS 使用稳定版、手动维护窗口更新。ER-X、RB5009、gfw/PVE 配置均加密备份;知识库仅记录脱敏摘要。切换采用先离线验证、后维护窗口割接,可回插 ER-X 回滚。 |
### 迁移前待办(非待决策)
- 导出并加密保存 gfw/OpenClash 与 PVE 网络配置,盘点当前“特殊流量走 gfw”的实际选流规则;首期不改变该行为。
- 确认 WireGuard 使用的 DDNS 域名及客户端配置。
- 记录 PS 的 MAC、静态地址及具体游戏端口;未确认时不创建端口映射。
- 为每一项未来 IoT → VLAN66 访问补充服务例外清单,而不是放宽整网规则。
## 方案对比与判定
图例:🟢 直接满足/风险低;🟡 可以实现,但有额外配置或限制;🔴 不适合或显著增加风险;⚪ 两方案无实质差异。此表涵盖**对当前决策有影响的特征**;不比较 OSPF、BGP、堆叠等本家庭网络没有需求的企业功能。
### 安全、服务与运维
| 可比较特征 | 方案 A:RB5009 负责三层 | 方案 B:交换机负责三层 | 胜方 |
| --- | --- | --- | --- |
| VLAN 55/66 的二层隔离 | 🟢 标准 802.1Q,由交换机实施 | 🟢 相同 | ⚪ 平手 |
| VLAN 默认网关 | 🟢 `.254` 在 RB5009,保留现有架构 | 🟡 `.254` 改为交换机 SVI;RB5009 要加静态路由 | **A** |
| IoT → 电脑网默认拒绝 | 🟢 一组 RB5009 firewall 规则,所有流量必经 | 🟡 必须改在交换机 ACL 实现;RB5009 firewall 看不到本地三层流量 | **A** |
| 将来新增 IoT 服务例外 | 🟢 在 RB5009 地址/端口清单追加规则 | 🟡 在交换机 ACL 维护例外,并验证硬件转发没有绕过规则 | **A** |
| 网络设备管理面保护 | 🟢 RB5009 firewall 可限制 IoT/WAN;交换机仅有 VLAN66 管理 IP | 🟡 要同时限制交换机管理面和 RB5009 管理面 | **A** |
| DHCP 与静态租约 | 🟢 两个 DHCP Server 与网关同机,沿用现有租约 | 🟡 交换机供 DHCP 会分散配置;RB5009 供 DHCP 则需 relay | **A** |
| DHCP 下发 DNS `.36` | 🟢 两个 DHCP network 统一下发 AdGuard Home | 🟡 可做,但 DHCP 所在设备/relay 需额外维护 | **A** |
| DNS / OpenClash 现有链路 | 🟢 不改变;仅允许 VLAN55 到 `.36:53` | 🟡 不改变服务本身,但跨设备路由/ACL增多 | **A** |
| IPv6 PD、RA 与 WAN IPv6 防火墙 | 🟢 PD 获取、两个 `/64` 的 RA 与防火墙在同一设备 | 🔴 前缀仍在 RB5009,需跨设备处理路由、RA 和回程规则 | **A** |
| WireGuard 分流至两个 VLAN | 🟢 VPN 终点与两个 VLAN 路由/规则同机 | 🟡 要维护 VPN → 交换机 SVI 的路由和 ACL | **A** |
| WAN 端口转发 | 🟢 NAT 后直接路由到 VLAN 主机 | 🟡 NAT 后再经过交换机路由;必须确认回程路径 | **A** |
| mDNS / 发现类协议 | 🟡 默认不跨 VLAN;将来按需在 RB5009 加 reflector/代理 | 🟡 同样需要 mDNS reflector 或专门网关 | ⚪ 平手 |
| 配置备份与恢复 | 🟢 关键 L3 配置主要一份(RB5009) | 🟡 两份关键 L3 配置必须一致地备份/恢复 | **A** |
| 排障路径 | 🟢 先看 RB5009 一个位置即可定位 DHCP、路由、NAT、VPN、规则 | 🟡 需同时查看交换机 SVI/ACL 与 RB5009 路由/NAT | **A** |
| 迁移与回滚 | 🟢 可保留 IP、DHCP 与服务地址,回插 ER-X 更直接 | 🔴 多项服务迁至交换机;回滚时须恢复 SVI、ACL、DHCP/relay、IPv6 | **A** |
### 性能、成本与扩展
| 可比较特征 | 方案 A:RB5009 负责三层 | 方案 B:交换机负责三层 | 胜方 |
| --- | --- | --- | --- |
| 同 VLAN 的 2.5G 交换 | 🟢 交换机 ASIC 线速转发 | 🟢 相同 | ⚪ 平手 |
| VLAN55 ↔ VLAN66 吞吐 | 🟡 经 RB5009;家用 IoT、DNS、控制流量足够 | 🟢 交换 ASIC 本地转发,适合长期多千兆跨 VLAN 流量 | **B** |
| 互联网吞吐 | 🟢 均经 RB5009 PPPoE/NAT | 🟢 相同;WAN 仍经 RB5009 | ⚪ 平手 |
| 上联链路使用 | 🟡 跨 VLAN 流量使用 RB5009 ↔ 交换机 10G trunk | 🟢 本地跨 VLAN 不占上联;仅 WAN/VPN 使用 | **B** |
| 延迟 | 🟢 家庭业务差异通常不可感知 | 🟢 ASIC 路由理论更低 | ⚪ 对当前场景无实质差异 |
| 设备与许可成本 | 🟢 不需要为三层功能额外购买/配置 | 🟢 已购 L2+ 交换机也能做静态路由 | ⚪ 硬件成本相同 |
| 卧室噪音与功耗 | 🟢 SG3210X-M2 无风扇,约 15W 上限 | 🟢 同一硬件,差异很小 | ⚪ 平手 |
| 未来多 VLAN / 高速 NAS | 🟡 可在出现实测瓶颈后迁移可信高流量 VLAN | 🟢 初始具备更高本地三层性能 | **B** |
| 未来改变安全策略 | 🟢 防火墙规则集中,扩展访客/IoT 例外容易 | 🟡 每次都要评估交换机 ACL 与路由行为 | **A** |
### 加权结论
权重 `5` 表示已确认的硬约束,`2` 表示未来假设;评分 `5` 表示完全满足。总分只让取舍可见,不是性能基准测试。
| 决策维度 | 权重 | 方案 A | 方案 B | 结果 |
| --- | ---: | ---: | ---: | --- |
| IoT 隔离与管理面保护 | 5 | 🟢 5 | 🟡 2 | **A** |
| 简化、排障与回滚 | 5 | 🟢 5 | 🟡 2 | **A** |
| DHCP / DNS / IPv6 一致性 | 4 | 🟢 5 | 🟡 2 | **A** |
| WireGuard 与 WAN 服务 | 4 | 🟢 5 | 🟡 3 | **A** |
| 当前跨 VLAN 性能 | 2 | 🟢 4 | 🟢 5 | **B(轻微)** |
| 未来多千兆扩展 | 2 | 🟡 3 | 🟢 5 | **B** |
| **总分(满分 135** | — | **🟢 121** | **🟡 72** | **提议采用 A** |
**结论:当前只有两种情况会推翻方案 A:**
1. 已实测出现持续的多千兆跨 VLAN 流量,且 RB5009 成为明确瓶颈;或
2. 决定接受更高复杂度,并愿意长期维护交换机 ACL、IPv6 路由/RA 与双设备排障。
在这两项均不成立时,方案 B 的性能潜力不能抵消其更高的安全与维护成本。
## 专业网络中的适用场景
两种架构都是专业网络中的标准做法;区别不在“哪个更高级”,而在**安全边界、东西向流量与运维能力**。
### 方案 A:防火墙/网关作为三层核心(Firewall-on-a-stick
适合以下场景:
| 场景特征 | 为什么适合方案 A |
| --- | --- |
| 家庭、工作室、小型办公室 | VLAN 数量少,跨 VLAN 流量通常以 DNS、管理、IoT 控制为主,性能需求低于安全与易维护需求。 |
| IoT、访客、办公终端需要隔离 | 所有跨区访问都经过状态防火墙,适合“默认拒绝、按服务放行”的最小权限策略。 |
| 单人或小团队运维 | DHCP、DNS 选项、VPN、NAT、IPv6 与审计日志集中在网关,变更与回滚成本低。 |
| WAN 服务复杂 | PPPoE、双栈 IPv6、端口转发、动态 DNS、WireGuard 等在同一个网络边界设备上,回程路径清晰。 |
| 设备性能仍有余量 | 跨 VLAN 峰值远低于网关可承受能力,没有持续的大规模东西向流量。 |
专业部署中,这常见于“下一代防火墙 + 接入交换机”结构:交换机负责接入与 VLAN,防火墙负责默认网关和安全策略。它牺牲部分东西向线速能力,换取策略可见性与审计完整性。
### 方案 B:三层核心交换机作为 VLAN 网关(Routed Access / Collapsed Core
适合以下场景:
| 场景特征 | 为什么适合方案 B |
| --- | --- |
| 大量高速东西向流量 | 服务器、存储、虚拟化、备份、渲染或多台工作站在不同 VLAN 间持续跑 2.5/10/25G;防火墙成为明确瓶颈。 |
| VLAN 数量与端口规模较大 | 多楼层、多个接入交换机、多个业务网段需要在核心层线速汇聚。 |
| 隔离需求可由交换机 ACL 表达 | 网络团队有能力在核心交换机维护 ACL、VLAN 接口、路由、IPv6 RA/ND 与变更验证。 |
| 独立安全边界清晰 | WAN、远程接入、深度检测仍由防火墙承担;核心交换机只承担可信区域或已定义 ACL 的内部路由。 |
| 具备专业运维条件 | 有配置版本管理、监控、告警、备份、变更窗口与回滚流程,能处理双设备路由故障。 |
专业网络中,方案 B 不等于“没有防火墙”。典型实践是:核心交换机负责高带宽、低延迟的可信业务 VLAN 路由;需要严格隔离的访客、IoT、DMZ 或不可信 VLAN,仍将默认网关放在防火墙,或通过交换机 ACL 强制送往防火墙。
### 对本网络的专业判断
本网络的 IoT VLAN 是**不可信区域**,且已决定采用“默认拒绝、按需放行”。即使未来电脑网出现万兆需求,也不应为了电脑网内部速度而让 IoT VLAN 绕过 RB5009 的安全策略。
更稳妥的演进路径是:
1. 现在采用方案 A,两个 VLAN 均由 RB5009 路由;
2. 将来电脑网内部需要万兆时,在 VLAN66 内增加独立纯万兆二层交换机;同 VLAN 流量不经过 RB5009
3. 只有当**可信、高流量 VLAN 之间**确实出现瓶颈时,才评估让三层核心交换机路由这些可信 VLAN;IoT VLAN55 继续保留在 RB5009 防火墙后。
因此,方案 A 是当前的专业且保守的安全设计;方案 B 是容量与运维能力达到一定规模后的演进设计,而不是家庭网络的默认升级项。
### 方案 A 的目标拓扑
```text
Internet / ONTbridge
└─ RB5009
├─ ether1PPPoE / IPv4 NAT / IPv6 PD / WAN firewall
├─ VLAN 66192.168.66.254/24、DHCP、跨 VLAN firewall
├─ VLAN 55192.168.55.254/24、DHCP、跨 VLAN firewall
├─ WireGuard:分流访问 VLAN 66 与 VLAN 55
└─ SFP+VLAN 55 + VLAN 66 tagged trunk
└─ SG3210X-M2L2 only;管理 IP 192.168.66.2
├─ access VLAN 66PC、gfw、dns、ubnt、电脑网 AP
└─ access VLAN 55IoT、Home Assistant、IoT AP
```
## 提议决策
**采用方案 ARB5009 管理全部 VLAN 的三层接口、DHCP 和防火墙;SG3210X-M2 仅作二层 VLAN 核心交换机。**
具体职责如下:
| 组件 | 职责 | 不承担的职责 |
| --- | --- | --- |
| RB5009 | PPPoE、IPv4 NAT、IPv6 PD/RA、防火墙、VLAN 55/66 网关、DHCP、WireGuard、Transmission 端口转发 | 不为客户端提供 DNS 解析服务 |
| AdGuard Home `192.168.66.36` | 两个 VLAN 的 DHCP 下发 DNSDNS 过滤与上游 DoH | DHCP、网关、VLAN 路由 |
| SG3210X-M2 | VLAN access/trunk、二层转发、RSTP、交换机管理 | DHCP、IPv4/IPv6 网关、跨 VLAN 路由、DNS、NAT、防火墙 |
| UniFi Controller `192.168.66.46` | AP 管理 | VLAN 路由或 DHCP |
### 最小安全策略
RB5009 的跨 VLAN 规则按以下优先级表达:
1. 允许 `established,related`;丢弃 `invalid`
2. 允许 VLAN66、VLAN55、WireGuard 分别访问 WAN。
3. 允许 VLAN66 → VLAN55 的全部访问。
4. 允许 WireGuard → VLAN66、VLAN55 的全部访问。
5. 允许 VLAN55 → `192.168.66.36` 的 TCP/UDP `53`
6. 通过独立的“IoT 例外服务”地址/端口清单,按需允许 VLAN55 → VLAN66 的后续访问。
7. 丢弃其余 VLAN55 → VLAN66 的新建连接。
8. 仅允许 VLAN66 和 WireGuard 管理 RB5009、交换机与其他网络管理服务;拒绝 VLAN55 与 WAN 的管理访问。
Home Assistant 位于 VLAN55`192.168.55.11:8123`),IoT 与其通信不跨 VLAN;外部用户通过 WireGuard 访问,不保留 `8123` 的公网端口转发。
### DHCP 与 DNS
| VLAN | DHCP 服务端 | 地址池 | DHCP 下发网关 | DHCP 下发 DNS |
| --- | --- | --- | --- | --- |
| VLAN66 | RB5009 | `192.168.66.38``.243` | `192.168.66.254` | `192.168.66.36` |
| VLAN55 | RB5009 | `192.168.55.38``.243` | `192.168.55.254` | `192.168.66.36` |
交换机只有一个管理地址 `192.168.66.2`,不在 VLAN55 配 IP,也不运行 DHCP 或 DNS。VLAN55 的 DHCP 广播经二层 trunk 到 RB5009 的 VLAN55 接口,RB5009 再响应对应网段的地址、网关和 DNS 选项。
## 后果
### 正面后果
- 两网隔离规则集中、可读,符合“电脑可管理 IoT,IoT 默认不能攻击电脑网”的目标。
- 保持当前地址与服务位置,减少迁移时的 DNS、AP、Controller 和端口转发改动。
- 交换机可独立更换,不影响路由/DHCP/防火墙架构。
- IPv6 与 WireGuard 都只有一个主要控制点。
### 负面后果与接受的代价
- 跨 VLAN 大流量不会在交换机 ASIC 内路由;会通过 RB5009。
- RB5009 是 VLAN 网关与 DHCP 的单点。家庭网络中这与 PPPoE/NAT 本就同为单点,可接受。
- 需要维护一条高质量的 RB5009 ↔ 交换机 trunk;建议使用 10G SFP+ DAC,预留第二个 SFP+ 口给未来扩展。
## 何时重新决策
出现以下任一情况后,重新评估方案 B 或新增第三层核心:
- 长期存在跨 VLAN 的多千兆/万兆 NAS、备份或虚拟化流量,且 RB5009 成为瓶颈。
- VLAN 数量明显增加,且每个 VLAN 都需要大规模本地三层转发。
- 愿意在核心交换机维护 ACL、IPv6 RA/路由和双端故障排查流程。
硬件三层转发的优势是性能,但它并不等同于安全防火墙;使用硬件转发时,流量可能绕过普通 router firewall,必须以交换机 ACL 单独实现访问控制。 [RouterOS L3 Hardware Offloading](https://help.mikrotik.com/docs/spaces/ROS/pages/62390319/L3%2BHardware%2BOffloading)
## 迁移时不随决策迁移的旧暴露面
| 服务 | 迁移后处理 |
| --- | --- |
| Transmission | 保留 `TCP/UDP 51413 → 192.168.66.51` 端口转发 |
| Home Assistant | 不公开 `8123`;通过 WireGuard 访问 |
| SSH`192.168.66.36:22`) | 不做公网端口转发;只允许 LAN66 / WireGuard |
| OpenVPN`192.168.66.32:1194` | 不迁移;由 WireGuard 替代 |
## 确认记录
- [x] 接受方案 A2026-08-07
- [ ] 拒绝方案 A,选择方案 B
- [ ] 修改后再决策
决策理由:当前网络以 IoT 隔离、简单运维与低迁移风险为首要目标;没有已实测的跨 VLAN 多千兆瓶颈。