270 lines
18 KiB
Markdown
270 lines
18 KiB
Markdown
---
|
||||
|
|
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 确认采用方案 A;RB5009 管理全部 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. **方案 A:RB5009**(交换机仅做二层 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+ DAC;trunk 仅允许 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 Lite:VLAN66、电脑 SSID、仅 5GHz、WPA2/WPA3;UAP-AC-Lite:VLAN55、IoT SSID、仅 2.4GHz、WPA2-PSK/AES;SSID 密码不同,初始不启用 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 repeater;SSDP/IGMP relay 仅在具体设备需要时另行配置。 |
|
|||
|
|
| IPv6 | 首次迁移即保留 PD `/60`,各 VLAN 一个 `/64`,应用等价的 IoT 隔离;公网 IPv6 默认拒绝入站。 |
|
|||
|
|
| 远程访问 | WireGuard 运行于 RB5009,UDP `51820`,分流,客户端可访问两个 VLAN,并使用 `.66.36` DNS;DDNS 供应商待定。 |
|
|||
|
|
| 公网暴露 | 保留 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 / ONT(bridge)
|
|||
|
|
│
|
|||
|
|
└─ RB5009
|
|||
|
|
├─ ether1:PPPoE / IPv4 NAT / IPv6 PD / WAN firewall
|
|||
|
|
├─ VLAN 66:192.168.66.254/24、DHCP、跨 VLAN firewall
|
|||
|
|
├─ VLAN 55:192.168.55.254/24、DHCP、跨 VLAN firewall
|
|||
|
|
├─ WireGuard:分流访问 VLAN 66 与 VLAN 55
|
|||
|
|
└─ SFP+:VLAN 55 + VLAN 66 tagged trunk
|
|||
|
|
│
|
|||
|
|
└─ SG3210X-M2(L2 only;管理 IP 192.168.66.2)
|
|||
|
|
├─ access VLAN 66:PC、gfw、dns、ubnt、电脑网 AP
|
|||
|
|
└─ access VLAN 55:IoT、Home Assistant、IoT AP
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 提议决策
|
|||
|
|
|
|||
|
|
**采用方案 A:RB5009 管理全部 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 下发 DNS;DNS 过滤与上游 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] 接受方案 A(2026-08-07)
|
|||
|
|
- [ ] 拒绝方案 A,选择方案 B
|
|||
|
|
- [ ] 修改后再决策
|
|||
|
|
|
|||
|
|
决策理由:当前网络以 IoT 隔离、简单运维与低迁移风险为首要目标;没有已实测的跨 VLAN 多千兆瓶颈。
|