From 1693eb46cf89fd3ac9701251051f9a31dad538fa Mon Sep 17 00:00:00 2001 From: windyboy Date: Fri, 7 Aug 2026 17:29:19 +0800 Subject: [PATCH] docs(network): refine gateway and switch ADRs --- ... - Gateway Selection RB5009 vs UXG-Lite.md | 187 ++++-------- .../ADR - Home Network Layer 3 Boundary.md | 287 ++++-------------- .../Home Network Upgrade Plan.md | 154 +++------- 02_Areas/Network & VPN/Home Network.md | 13 +- 4 files changed, 166 insertions(+), 475 deletions(-) diff --git a/02_Areas/Network & VPN/ADR - Gateway Selection RB5009 vs UXG-Lite.md b/02_Areas/Network & VPN/ADR - Gateway Selection RB5009 vs UXG-Lite.md index b2cb41e..7286dde 100644 --- a/02_Areas/Network & VPN/ADR - Gateway Selection RB5009 vs UXG-Lite.md +++ b/02_Areas/Network & VPN/ADR - Gateway Selection RB5009 vs UXG-Lite.md @@ -1,165 +1,88 @@ --- -title: "ADR - Gateway Selection RB5009 vs UXG-Lite" +title: "ADR - Gateway Selection: RB5009 vs UCG-Ultra" type: architecture-decision-record -status: accepted +status: conditional date: 2026-08-07 -tags: [network, adr, gateway, mikrotik, unifi] +tags: [network, adr, gateway, mikrotik, unifi, tp-link] related: - "[[ADR - Home Network Layer 3 Boundary]]" - "[[Home Network]]" - "[[Home Network Upgrade Plan]]" --- -# ADR：RB5009 与 UXG-Lite 的网关选型 +# ADR：网关选型——RB5009 与 UCG-Ultra ## 状态 -**已接受（Accepted）**：2026-08-07 确认选择 **MikroTik RB5009UG+S+IN** 作为家庭网络网关。UXG-Lite 不作为本次升级的网关。 +**条件性决策（Conditional）**：只采购一台网关。当前首选 **UniFi Cloud Gateway Ultra（UCG-Ultra）**；只有未通过验收，或出现明确的多千兆/RouterOS 硬约束时，才改选 **MikroTik RB5009UG+S+IN**。 -## 背景 +核心交换机仍以 TL-SE5420 为优先候选：它负责二层 VLAN，不承担 DHCP、VLAN 网关、NAT 或跨 VLAN 路由。交换机与网关的详细边界见 [[ADR - Home Network Layer 3 Boundary]]。 -已接受的 [[ADR - Home Network Layer 3 Boundary|三层职责边界]] 确定：网关是 VLAN55 与 VLAN66 的唯一三层边界，承担 DHCP、防火墙、PPPoE、IPv6 PD/RA、NAT、端口转发与 WireGuard；核心交换机仅做二层 VLAN 转发。 +## 决策背景 -当前网络计划以无风扇 **TP-Link Omada SG3210X-M2** 作为核心交换机。该交换机提供 8 × 2.5GbE 与 2 × 10G SFP+；网关与核心交换机之间需要承载两个 VLAN 的 trunk。现有 gfw 是 PVE 上的双网 ImmortalWrt VM，其“特殊流量走 gfw”的选流策略在迁移前仍需盘点，但首期不改变该行为。 +- 宽带为 1Gbps，光猫桥接，网关负责 PPPoE、NAT、IPv6、DHCP、防火墙、WireGuard 与必要端口转发。 +- VLAN66 `192.168.66.0/24` 与 VLAN55 `192.168.55.0/24` 的网关均为 `.254`；VLAN55 默认不能主动访问 VLAN66。 +- gfw 是 PVE 上的双网 ImmortalWrt VM（`.66.1` / `.55.1`）。需要代理的客户端直接选用 `.1` 为默认网关，其他客户端选用 `.254`；gfw 再经对应 `.254` 出 WAN。这不是主网关透明策略路由。 +- 已有 UniFi AP；当前 UniFi Network Controller 运行在 `.66.46` 的 PVE/Docker 上。 +- 网关到核心交换机只需承载 tagged VLAN55、VLAN66；业务 VLAN 不使用 native/untagged VLAN。 -候选网关为： +## 已核实的硬件事实 -1. **方案 A：MikroTik RB5009UG+S+IN**；或 -2. **方案 B：Ubiquiti UXG-Lite**。 - -## 已确认的目标设计 - -| 范畴 | 已确认决策 | -| --- | --- | -| 网关 | RB5009 是 VLAN55/VLAN66 的唯一网关、DHCP、防火墙、PPPoE、IPv6 PD/RA、NAT 与 WireGuard 终点。 | -| 核心交换 | SG3210X-M2 仅做无风扇二层 VLAN 交换；不承担 DHCP、VLAN 网关或跨 VLAN 路由。 | -| 网关上联 | RB5009 的 10G SFP+ 与核心交换机使用短距离 10G SFP+ DAC；trunk 仅允许 tagged VLAN55、VLAN66，不承载 native/untagged VLAN。 | -| VLAN 与地址 | VLAN66：`192.168.66.0/24`、网关 `.254`；VLAN55：`192.168.55.0/24`、网关 `.254`。 | -| 安全边界 | IoT（VLAN55）默认不能主动访问电脑网（VLAN66）；电脑网可访问 IoT 网；后续例外按目标 IP、协议与端口在网关防火墙中维护。 | -| 旁路由 | gfw VM 保持双网 `.66.1` / `.55.1` 与按规则选流的旁路由角色，不成为客户端默认网关。 | -| 远程访问 | WireGuard 运行在网关，采用分流，客户端可访问两个 VLAN 并使用 AdGuard Home `.66.36` DNS。 | - -## 经官方资料核实的硬件事实 - -| 项目 | RB5009UG+S+IN | UXG-Lite | -| --- | --- | --- | -| WAN/LAN 物理端口 | 7 × 1GbE、1 × 2.5GbE、1 × 10G SFP+ | 1 × 1GbE WAN、1 × 1GbE LAN | -| CPU | 四核 ARM 64-bit，1.4GHz | 双核 ARM Cortex-A53，1GHz | -| 内存 | 1GB DDR4 | 1GB | -| 系统 | RouterOS v7 | 由 UniFi Network Application 管理 | -| 最大功耗 | 25W | 3.83W | -| IPv6 ISP 支持 | RouterOS v7 支持 DHCPv6-PD / RA 配置 | 官方规格列出 IPv6 ISP Support | -| WireGuard 服务端 | RouterOS v7 支持 | 官方规格列出 WireGuard VPN Server | - -来源：[RB5009 官方手册](https://cdn.mikrotik.com/web-assets/product_files/RB5009UGSIN_250413.pdf)、[UXG-Lite 官方规格](https://techspecs.ui.com/unifi/advanced-hosting/uxg-lite?subcategory=all-advanced-hosting)。 - -## 方案对比与判定 - -图例：🟢 直接满足／风险低；🟡 可以实现，但有额外配置或限制；🔴 不满足已确认约束；⚪ 两方案无实质差异。 - -### 上联、性能与扩展 - -| 可比较特征 | 方案 A：RB5009 | 方案 B：UXG-Lite | 胜方 | +| 项目 | RB5009UG+S+IN | UCG-Ultra | 对本设计的意义 | | --- | --- | --- | --- | -| 与核心交换机的 trunk | 🟢 10G SFP+ DAC，可直接承载 VLAN55/66 | 🟡 仅 1GbE Ethernet trunk | **A** | -| 已接受架构下的 WAN / VLAN 间流量 | 🟢 不受 1GbE LAN 上联限制 | 🔴 全部经唯一 1GbE LAN 链路 | **A** | -| WireGuard / 端口转发回内网 | 🟢 使用高速上联，不与 1GbE LAN 上联竞争 | 🟡 与全部网关相关流量共享 1GbE LAN 链路 | **A** | -| 同 VLAN 的 2.5G 交换 | 🟢 由核心交换机 ASIC 转发，不经过网关 | 🟢 相同 | ⚪ 平手 | -| 未来超过 1Gbps 宽带或跨 VLAN 流量 | 🟢 不需要先更换网关接口 | 🔴 需要更换网关或改变已接受架构 | **A** | -| 低功耗与发热 | 🟡 最大功耗较高 | 🟢 最大功耗 3.83W | **B** | +| 端口 | 7 × 1GbE、1 × 2.5GbE、1 × 10G SFP+ | 1 × 2.5GbE、4 × 1GbE RJ45；默认 WAN 为 2.5GbE | RB5009 可用 10G SFP+ DAC 上联 TL-SE5420；UCG-Ultra 到核心交换机应按 1GbE LAN trunk 设计。 | +| 系统与管理面 | RouterOS v7；UniFi AP 继续由独立 Controller 管理 | UniFi Cloud Gateway，内置 UniFi Network | UCG-Ultra 可替代 `.66.46` 的 Controller；RB5009 保留两套管理面。 | +| CPU / 内存 | 四核 ARM 1.4GHz、1GB DDR4 | 四核 ARM Cortex-A53 1.5GHz、3GB RAM、16GB 存储 | 厂商未提供两者完全同条件的防火墙/PPPoE对照测试，不以 CPU 参数直接断言实际吞吐胜负。 | +| 最大功耗 | 25W；无外接设备时 14W | 6.2W | UCG-Ultra 的公开最大功耗低 7.8W（按 RB5009 无外接设备值比较）；实际耗电仍取决于模块和负载。 | +| 散热 | 被动散热 | 官方规格未列出风扇/噪音指标 | RB5009 的被动散热是已确认事实；UCG-Ultra 的噪音不以推测代替，购买前应确认。 | +| 安全能力 | RouterOS v7 可配置状态防火墙、IPv4/IPv6、路由、WireGuard | 官方列出状态/L7/区域防火墙、DPI、IPS/IDS、内容过滤、WireGuard、IPv6 ISP Support | UCG-Ultra **不缺少防火墙**；两者均需用实际规则和 IPv6 验收。 | +| IDS/IPS 厂商标称 | 本 ADR 的官方产品页未提供可对照值 | 1Gbps | 对 1Gbps 宽带，UCG-Ultra 的标称与目标相符，但 PPPoE、规则和真实流量仍须实测。 | +| UniFi 设备容量 | 不适用 | 30+ UniFi 设备、300+ 并发客户端 | 对当前两台 AP 有充足公开容量余量。 | -### 功能、迁移与运维 +来源：[RB5009 官方产品页](https://mikrotik.com/product/rb5009ug_s_in)、[UCG-Ultra 官方规格](https://techspecs.ui.com/unifi/cloud-gateways/ucg-ultra?s=us)。 -| 可比较特征 | 方案 A：RB5009 | 方案 B：UXG-Lite | 胜方 | +## 专业比较 + +| 决策维度 | RB5009 | UCG-Ultra | 专业判断 | | --- | --- | --- | --- | -| 两 VLAN、DHCP、IPv4 NAT 与防火墙 | 🟢 可集中于 RouterOS | 🟢 可实现 | ⚪ 平手 | -| IPv6 PD 分发至多个 VLAN | 🟢 可显式配置 PD、RA 与防火墙 | 🟡 文档支持，仍须对电信 PPPoE/PD 验收 | **A** | -| WireGuard UDP `51820` | 🟢 可实现 | 🟢 可实现 | ⚪ 平手 | -| VLAN 间 mDNS | 🟢 RouterOS 支持 IPv4 mDNS repeater | 🟡 官方规格列出 mDNS，需验证实际跨 VLAN 行为 | **A** | -| 现有 UniFi AP 管理 | 🟢 AP 继续由现有 Controller 管理 | 🟢 与网关统一在 UniFi Network Application 管理 | **B** | -| gfw 旁路由选流策略迁移 | 🟢 RouterOS 可按盘点结果配置路由/防火墙 | 🟡 是否可等价实现取决于尚未盘点的规则 | **A** | -| 配置与故障排查 | 🟢 网关、路由、DHCP、IPv6 与策略在一套 RouterOS 配置中 | 🟡 UniFi 管理更统一，但 1GbE 限制和 gfw 等价性需额外验收 | **A** | +| 当前 1Gbps 宽带出网 | 🟢 | 🟢 | 两者都不因物理 WAN 端口成为瓶颈。UCG-Ultra 的 1GbE LAN trunk 是全双工，单独 WAN ↔ LAN 流量不是额外劣势。 | +| 经网关的高流量 | 🟢 10G SFP+ 上联 | 🟡 单个 1GbE LAN trunk | VLAN 间流量会在该 trunk 的两个方向各经过一次；持续大流量跨 VLAN、VPN 或端口转发回内网时，UCG-Ultra 更早受限。 | +| gfw 旁路由模式 | 🟢 | 🟢 | 客户端直接选择 `.1` 时，两者都不需要主网关 PBR，也不会天然产生回路。 | +| IPv6、DHCP、NAT、端口转发、WireGuard | 🟢 可精细配置 | 🟢 功能公开列出，需实机验收 | 不把“可配置得更细”误写成“当前必需”。UCG-Ultra 必须验证电信 PD/RA、规则和端口转发。 | +| VLAN55 默认拒绝与服务例外 | 🟢 RouterOS 规则 | 🟢 Zone-Based Firewall / 策略规则 | 两者都能实施最小权限；UCG-Ultra 应从 VLAN55 实测规则顺序和例外。 | +| UniFi 管理与运维 | 🟡 两套管理面 | 🟢 网关、AP、Network 合一 | UCG-Ultra 可移除 PVE 上 Controller 的升级、备份和可用性责任；TP-Link 交换机仍独立管理。 | +| 救援口、带外排障、可编程性 | 🟢 多余端口、RouterOS CLI/诊断 | 🟡 4 个 1GbE LAN，但策略表达和低层诊断更受 UniFi 范围约束 | RB5009 的真实优势；只有确实需要时才值得为复杂度与功耗付费。 | +| 功耗与设备数量 | 🟡 | 🟢 | UCG-Ultra 本身更低功耗且可能替代自托管 Controller；但 PVE 是否仍运行取决于其他工作负载，不能把整机节电全部归因于它。 | +| 未来多千兆 LAN / 10G SFP+ | 🟢 | 🔴 无 SFP+，LAN 为 1GbE | 这是 RB5009 的硬性胜场；不是当前 1Gbps 宽带的硬性要求。 | -UniFi 的 IPv6 PD 与 WireGuard 功能参考：[IPv6 in UniFi](https://help.ui.com/hc/en-us/articles/36378535649687-Configuring-IPv6-in-UniFi)、[WireGuard VPN Server](https://help.ui.com/hc/en-us/articles/115005445768-UniFi-Gateway-WireGuard-VPN-Server)。RouterOS 的 mDNS repeater 仅支持 IPv4：[RouterOS DNS/mDNS](https://help.mikrotik.com/docs/spaces/ROS/pages/37748767/DNS?src=contextnavpagetreemode)。 +## 结论与采购规则 -### 加权结论 +### 当前专业意见：选 UCG-Ultra -权重 `5` 表示已确认的硬约束，`2` 表示偏好；评分 `5` 表示完全满足。总分仅用于使取舍可见，不代表性能基准测试。 +在现有事实下，**选择 UCG-Ultra**：你的 1Gbps 宽带并不要求 10G 网关上联；gfw 的“客户端自行使用 `.1`”模式也不要求 RouterOS 策略路由。UCG-Ultra 同时承担网关与 UniFi Network 控制平面，可消除一套长期维护的 Controller 服务，且公开最大功耗显著低于 RB5009。 -| 决策维度 | 权重 | 方案 A：RB5009 | 方案 B：UXG-Lite | 结果 | -| --- | ---: | ---: | ---: | --- | -| 10G DAC 核心上联 | 5 | 🟢 5 | 🔴 1 | **A** | -| 网关相关流量的带宽与扩展 | 5 | 🟢 5 | 🔴 1 | **A** | -| gfw 现有行为的低风险迁移 | 4 | 🟢 5 | 🟡 2 | **A** | -| IPv6、WireGuard 与跨 VLAN 功能可控性 | 4 | 🟢 5 | 🟡 3 | **A** | -| UniFi 单一管理界面 | 2 | 🟡 2 | 🟢 5 | **B** | -| 低功耗与发热 | 2 | 🟡 2 | 🟢 5 | **B** | -| **总分（满分 110）** | — | **🟢 98** | **🟡 50** | **采用 A** | +这不是说 UCG-Ultra 的 1GbE LAN 没有代价：它是所有经网关流量的共享路径。只是对“**1Gbps 宽带 + 两个 VLAN + 以 IoT/DNS/控制为主的跨 VLAN 流量**”而言，该代价尚不是已证实的瓶颈。 -UXG-Lite 的低功耗与统一管理界面是明确优点，但不足以抵消其唯一 1GbE LAN 上联与 gfw 策略等价性未知带来的限制。已接受的三层职责边界依赖网关承载所有跨 VLAN、WAN、WireGuard 与端口转发流量，因此 10G 上联是当前架构的必要能力，而非未来假设。 +### 直接选择 RB5009 的条件 -## 已接受的决策 +出现任一条，就不应为了统一 UniFi 管理而选择 UCG-Ultra： -**采用方案 A：RB5009UG+S+IN 作为网关，并通过 10G SFP+ DAC 连接 SG3210X-M2。** +1. 网关到 TL-SE5420 必须使用 10G SFP+ DAC，或已有持续的多千兆跨 VLAN / VPN / 回内网流量； +2. 宽带升级到超过 1Gbps，且需要相应的多千兆 LAN 上联； +3. 必须在主网关上做任意下一跳的透明选流、复杂路由标记/策略路由，或需要 RouterOS 的低层可观测性； +4. UCG-Ultra 未通过本 ISP 的 PPPoE、IPv6 PD/RA、WireGuard、端口转发、VLAN 隔离或 gfw 实测。 -RB5009 的职责与 [[ADR - Home Network Layer 3 Boundary|三层职责边界 ADR]] 保持一致： +## UCG-Ultra 迁移与验收 -| 组件 | 职责 | 不承担的职责 | -| --- | --- | --- | -| RB5009 | PPPoE、IPv4 NAT、IPv6 PD/RA、防火墙、VLAN55/66 网关、DHCP、WireGuard、Transmission 端口转发 | 不为客户端提供 DNS 解析服务 | -| SG3210X-M2 | VLAN access/trunk、二层转发、RSTP、交换机管理 | DHCP、IPv4/IPv6 网关、跨 VLAN 路由、DNS、NAT、防火墙 | -| AdGuard Home `.66.36` | 两个 VLAN 的 DNS 过滤与上游 DoH；由 RB5009 DHCP 下发为唯一 DNS | DHCP、网关、VLAN 路由 | -| UniFi Controller `.66.46` | AP 管理 | 网关、VLAN 路由或 DHCP | - -### 目标上联拓扑 - -```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 - │ - └─ 10G SFP+ DAC ── SG3210X-M2（L2 only；管理 IP 192.168.66.2） -``` +1. 从 `.66.46` 的自托管 UniFi Network 导出 `.unf` 网络备份；在 UCG-Ultra 内置 Network 恢复。迁移完成前保留旧控制器和回滚路径，完成后不让两个控制器同时管理同一设备。[官方迁移说明](https://help.ui.com/hc/en-us/articles/360008976393-Backups-and-Migration-in-UniFi) +2. 建立 VLAN55、VLAN66、`.254` 网关、DHCP 和唯一 DNS `.66.36`；核心 trunk 仅允许 tagged VLAN55/66。 +3. 验证 PPPoE IPv4、IPv6 PD、每个 VLAN 的 RA、IPv6 WAN 入站默认拒绝、IPv4/IPv6 NAT/端口转发和 WireGuard。 +4. 从 VLAN55 验证默认拒绝、DNS 和已批准服务例外；从 VLAN66 验证对 VLAN55 的管理访问。 +5. 分别验证 `.1` 客户端和 `.254` 客户端：前者经 gfw → `.254` 出网，后者直接经 `.254` 出网；确认 gfw 不可直通 VLAN55 ↔ VLAN66，且 IPv6 不绕过 gfw。 +6. 确认 TL-SE5420 的实机散热/噪音以及 RSTP、DHCP Snooping、trusted DHCP trunk；这些是独立于网关的采购前提。 ## 后果 -### 正面后果 - -- 网关到核心交换机的 trunk 不再成为 1GbE 瓶颈，符合已接受的网关三层架构。 -- gfw 旁路由、IPv6 PD/RA、WireGuard、端口转发与跨 VLAN 安全策略可在 RouterOS 中明确配置和验证。 -- 无需为了未来超过 1Gbps 的宽带或跨 VLAN 流量而先更换网关。 -- 现有 UniFi AP 仍可由自建 Controller 管理，不依赖 UniFi 网关。 - -### 负面后果与接受的代价 - -- RB5009 的功耗和发热高于 UXG-Lite。 -- 网关与 AP/Controller 不使用同一管理界面；需要维护 RouterOS 与 UniFi Controller 两套管理面。 -- gfw 的现有选流规则仍需在迁移前盘点、备份并在维护窗口验证；这不是重新选择 UXG-Lite 的前提，而是 RB5009 割接前的必做项。 - -## 迁移前待办（非待决策） - -- 导出并加密保存 ER-X、gfw/OpenClash 与 PVE 网络配置，盘点“特殊流量走 gfw”的实际选流规则。 -- 离线配置并验证 RB5009 的 PPPoE、VLAN55/66、DHCP、IPv6 PD/RA、防火墙、WireGuard 与 Transmission 映射。 -- 使用 10G SFP+ DAC 验证 RB5009 与 SG3210X-M2 的 tagged VLAN55/VLAN66 trunk；不配置 native/untagged VLAN。 -- 在维护窗口验证 IoT 隔离、AdGuard Home DNS、gfw 行为、WireGuard 和 IPv4/IPv6 连通性；保留可回插的 ER-X 作为回滚方案。 - -## 何时重新决策 - -只有在以下任一前提发生变化时，才重新评估 UXG-Lite 或其他网关： - -- 已接受的网关承担全部 VLAN 三层职责的架构被替换；或 -- 明确接受网关相关流量受 1GbE LAN 上联限制，且不再需要 10G DAC 上联；或 -- 选择的替代网关提供不低于当前需求的多千兆 LAN/SFP+ 上联，并通过 gfw、IPv6 与 WireGuard 验收。 - -## 确认记录 - -- [x] 接受 RB5009UG+S+IN（2026-08-07） -- [x] 拒绝 UXG-Lite 作为本次升级网关（2026-08-07） -- [ ] 完成 gfw 规则盘点与 RB5009 割接验收 - -决策理由：RB5009 同时满足已接受的网关三层职责边界、10G DAC 核心上联与低风险迁移要求；UXG-Lite 的 1GbE LAN 上联不符合该目标设计。 +- 只购买 **UCG-Ultra 一台网关**；RB5009 是替代决策，不与其串联或并行作为第二网关。 +- UniFi AP 和网关迁入 UCG-Ultra 管理面；TP-Link 交换机仍由其 Web/CLI/SNMP 或商云独立管理。 +- 若验证后 UCG-Ultra 不满足约束，回插 ER-X 并保留验收记录，再采购 RB5009；不在生产网络中试图叠加两种网关方案。 diff --git a/02_Areas/Network & VPN/ADR - Home Network Layer 3 Boundary.md b/02_Areas/Network & VPN/ADR - Home Network Layer 3 Boundary.md index 95a5e29..0903ae9 100644 --- a/02_Areas/Network & VPN/ADR - Home Network Layer 3 Boundary.md +++ b/02_Areas/Network & VPN/ADR - Home Network Layer 3 Boundary.md @@ -3,267 +3,82 @@ title: "ADR - Home Network Layer 3 Boundary" type: architecture-decision-record status: accepted date: 2026-08-07 -tags: [network, adr, vlan, router, switch, security] +tags: [network, adr, vlan, firewall, unifi] related: - - "[[Home Network]]" + - "[[ADR - Gateway Selection RB5009 vs UXG-Lite]]" - "[[Home Network Upgrade Plan]]" --- -# ADR：家庭网络的三层职责边界 +# ADR：家庭网络三层边界 ## 状态 -**已接受（Accepted）**：2026-08-07 确认采用方案 A；RB5009 管理全部 VLAN 的三层接口、DHCP 与防火墙，核心交换机仅做二层 VLAN 转发。 +**已接受（Accepted）**：VLAN55 与 VLAN66 的三层网关、安全策略、DHCP、IPv6、WAN 和 VPN 都由**唯一硬件网关**承担；核心交换机仅作二层 VLAN 交换。本 ADR 只规定职责边界；当前硬件首选、规格和验收条件记录在 [[ADR - Gateway Selection RB5009 vs UXG-Lite]]。 -## 背景 +## 背景与约束 -当前家庭网络有两个 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：交换机负责三层 | 胜方 | +| 网络 | IPv4 网段 | 硬件网关 | 用途 | | --- | --- | --- | --- | -| 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** | +| VLAN66 | `192.168.66.0/24` | `192.168.66.254` | 电脑、可信设备、网络管理与基础设施 | +| VLAN55 | `192.168.55.0/24` | `192.168.55.254` | IoT 与 Home Assistant | -### 性能、成本与扩展 +- IoT 不应主动访问 VLAN66；VLAN66 可按需管理 VLAN55。 +- 家庭宽带为 1Gbps；PPPoE、IPv6 PD/RA、NAT、端口转发与 WireGuard 必须在同一个边界设备内清晰可排障。 +- `gfw` 是 PVE 上双网 ImmortalWrt VM（`.66.1` / `.55.1`）。部分客户端直接将它作为替代默认网关；gfw 再将默认路由指向同 VLAN 的 `.254`。 +- 交换机部署在卧室，散热和噪音须在采购前确认。 -| 可比较特征 | 方案 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 | +| 最终硬件网关（当前首选 UCG-Ultra） | PPPoE、IPv4 NAT、IPv6 PD/RA、防火墙、VLAN55/66 网关、DHCP、WireGuard、必要端口转发 | DNS 递归解析、交换机二层接入 | +| 核心交换机（当前优先 TL-SE5420） | VLAN access/trunk、二层转发、RSTP、环路/风暴保护、DHCP Snooping、管理面 | DHCP、VLAN 网关、跨 VLAN 路由、NAT、防火墙 | +| AdGuard Home `.66.36` | DHCP 下发的唯一 DNS、过滤和上游 DoH | DHCP、网关、VLAN 路由 | +| gfw `.66.1` / `.55.1` | 被明确选择的客户端的代理出口 | VLAN55 ↔ VLAN66 直通路由、WAN NAT、公网防火墙 | +| UCG-Ultra 内置 UniFi Network | 管理 UCG-Ultra 和 UniFi AP | TP-Link 交换机管理、客户端转发以外的 PVE 工作负载 | -### 最小安全策略 +### 二层与地址设计 -RB5009 的跨 VLAN 规则按以下优先级表达： +- 网关与核心交换机间仅使用一条 tagged trunk，允许 VLAN55、VLAN66；业务 VLAN 不作 native/untagged VLAN。 +- 若交换机要求 trunk PVID，PVID 必须是没有任何客户端或管理业务、且网关没有三层接口的专用 VLAN。 +- 终端使用对应 VLAN 的 access 口；AP 端口按实际 SSID 需要配置 access 或 tagged trunk。 +- 交换机管理地址位于 VLAN66；仅 VLAN66 与 WireGuard 可管理网关、交换机和 PVE。 +- 只有网关 trunk 是 trusted DHCP 端口；其余接入口不可信。 -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` 的公网端口转发。 +1. WAN 入站默认拒绝，只显式开放所需端口转发；IPv6 入站应用同等原则。 +2. 允许已建立/相关流量，丢弃无效流量。 +3. VLAN66 可主动访问 VLAN55；VLAN55 → VLAN66 默认拒绝，仅以“目标 IP + 协议 + 端口”添加服务例外。 +4. 两个 VLAN 都可经网关访问 WAN；DHCP 只下发 `.66.36` 为 DNS。 +5. 使用 gfw 的设备配置 `.1` 为默认网关；其他设备配置 `.254`。这不是主网关 PBR，也不形成必然回路。 +6. 禁止 gfw 在两个 VLAN 之间直接转发；验证代理模式的回程/NAT 行为。 +7. IPv6 必须逐项验证：使用 gfw 的客户端不能因接收 `.254` 的 RA 而绕过 gfw。 -### 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` | +当前首选 **UCG-Ultra**，因为它将网关和 UniFi Network 管理面合并，官方标称 1×2.5GbE WAN、4×1GbE LAN、1Gbps IDS/IPS 和 6.2W 最大功耗。它没有 SFP+；其到核心交换机的 trunk 是 1GbE。若该单一 LAN 上联、IPv6、gfw 或业务迁移不满足验收，再改选 RB5009，而不是让两台网关叠加工作。[UCG-Ultra 官方规格](https://techspecs.ui.com/unifi/cloud-gateways/ucg-ultra?s=us) -交换机只有一个管理地址 `192.168.66.2`，不在 VLAN55 配 IP，也不运行 DHCP 或 DNS。VLAN55 的 DHCP 广播经二层 trunk 到 RB5009 的 VLAN55 接口，RB5009 再响应对应网段的地址、网关和 DNS 选项。 +TL-SE5420 作为二层核心交换机时，公开规格支持 RSTP、DHCP Snooping 与对应二层保护能力；TL-SE2420 的公开规格没有同等证明。两者的散热方式均须在购买前确认。[TL-SE5420 规格](https://www.tp-link.com.cn/product_2899.html?v=specification)、[TL-SE2420 规格](https://www.tp-link.com.cn/product_2935.html?v=specification) -## 后果 +## 拒绝的方案 -### 正面后果 - -- 两网隔离规则集中、可读，符合“电脑可管理 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 替代 | +| 交换机承担两个 VLAN 的三层网关 | IoT 的跨 VLAN 安全策略会分散到交换机 ACL 与网关，IPv6、DHCP、VPN、NAT 的排障和回滚复杂度增加。 | +| gfw 成为所有客户端的默认网关 | 不需要代理的流量被迫经过 VM，扩大故障域；也会模糊硬件网关的安全和 NAT 边界。 | +| UCG-Ultra 与 RB5009 串联运行 | 没有当前功能需求，会增加双 NAT、策略归属和故障排查风险。 | -## 确认记录 +## 后果与重新决策条件 -- [x] 接受方案 A（2026-08-07） -- [ ] 拒绝方案 A，选择方案 B -- [ ] 修改后再决策 +**正面后果：**跨 VLAN 访问始终经过同一状态防火墙；DHCP、IPv6、VPN、NAT 与端口转发集中，安全策略和回滚路径明确。 -决策理由：当前网络以 IoT 隔离、简单运维与低迁移风险为首要目标；没有已实测的跨 VLAN 多千兆瓶颈。 +**接受的代价：**UCG-Ultra 的核心上联是 1GbE；高流量跨 VLAN、VPN 或端口转发回内网会共享该链路。核心交换机仍是单点，网关也是单点。 + +在以下情况重新评估硬件，但不改变“网关负责三层、交换机负责二层”的边界： + +- UCG-Ultra 无法通过 PPPoE、IPv6 PD/RA、gfw、WireGuard、隔离或服务迁移验收； +- 需要持续的多千兆网关 LAN 上联、10G SFP+ 或更复杂的主网关选流； +- TL-SE5420 的噪音不适合卧室，且不愿放宽 RSTP/DHCP Snooping 要求。 diff --git a/02_Areas/Network & VPN/Home Network Upgrade Plan.md b/02_Areas/Network & VPN/Home Network Upgrade Plan.md index cc8f535..06a3ee0 100644 --- a/02_Areas/Network & VPN/Home Network Upgrade Plan.md +++ b/02_Areas/Network & VPN/Home Network Upgrade Plan.md @@ -1,133 +1,77 @@ --- title: Home Network Upgrade Plan type: proposal -tags: [network, lan, mikrotik, vlan, migration] +tags: [network, lan, unifi, vlan, migration] created: 2026-08-07 updated: 2026-08-07 -related: "[[Home Network]]" +related: + - "[[Home Network]]" + - "[[ADR - Home Network Layer 3 Boundary]]" + - "[[ADR - Gateway Selection RB5009 vs UXG-Lite]]" --- # Home Network Upgrade Plan -> 架构决策已在 [[ADR - Home Network Layer 3 Boundary]] 接受。本文保留为迁移计划；涉及 VLAN 职责、安全策略、设备选型与已确认参数时，以 ADR 为准。 +> 本文是迁移执行计划。三层职责以 [[ADR - Home Network Layer 3 Boundary]] 为准；硬件选型、厂商规格和采购前提以 [[ADR - Gateway Selection RB5009 vs UXG-Lite]] 为准。 -## 最简方案（采用） +## 当前拟采用方案 -采用 **RB5009UG+S+IN + 支持 VLAN 的二层网管交换机**：RB5009 是唯一的互联网网关、安全边界和三层设备；交换机只负责二层 VLAN 转发。即使购买的 CRS 带三层功能，第一阶段也不启用其三层路由。 +在下列验收项通过后，采用 **UniFi Cloud Gateway Ultra（UCG-Ultra）+ TL-SE5420**： -只保留两个 VLAN，沿用现有网段与 IP： +- UCG-Ultra 是两个 VLAN 的唯一三层网关，负责 PPPoE、IPv4 NAT、IPv6、DHCP、状态防火墙、WireGuard 与端口转发； +- TL-SE5420 只承担二层 VLAN access/trunk、RSTP、环路/风暴保护和 DHCP Snooping，不建立 SVI、不运行 DHCP 或跨 VLAN 路由； +- UCG-Ultra 内置 UniFi Network，迁移成功后停止 PVE 上的自托管 UniFi Network Controller； +- 若 UCG-Ultra 无法通过 IPv6、gfw 或服务迁移验收，则回到网关 ADR 重新评估，不购买第二台网关作为“备用方案”。 -| 用途 | VLAN / 网段 | 默认网关 | 设备 | +UCG-Ultra 的固定端口布局为 **1 × 2.5GbE RJ45 + 4 × 1GbE RJ45**；官方称其默认 WAN 为 2.5GbE、IDS/IPS 吞吐为 1Gbps、最大功耗为 6.2W。网关至 TL-SE5420 使用一个 **1GbE tagged trunk**，仅允许 VLAN55 和 VLAN66；不能把它误写成 10G 或 2.5G LAN 上联。[UCG-Ultra 官方规格](https://techspecs.ui.com/unifi/cloud-gateways/ucg-ultra?s=us) + +| 用途 | VLAN / 网段 | 硬件网关 | 主要设备 | | --- | --- | --- | --- | -| 可信设备与管理 | VLAN 66 / `192.168.66.0/24` | `192.168.66.254` | PC、手机、NAS、`gfw`、`dns`、UniFi Controller、AP 管理地址 | -| IoT | VLAN 55 / `192.168.55.0/24` | `192.168.55.254` | 灯、插座、电视、摄像头及 Home Assistant | - -这比“先把所有端口桥到 LAN66、以后再处理 LAN55/IPv6”的方案更安全：后者会直接破坏现有 LAN55 地址规划和 DHCP 边界，且会让已在使用的 IPv6 消失。 - -### 设备与连线 +| 可信设备与管理 | VLAN 66 / `192.168.66.0/24` | `192.168.66.254` | PC、NAS、`gfw`、`dns`、网络设备管理面、AP 管理地址 | +| IoT | VLAN 55 / `192.168.55.0/24` | `192.168.55.254` | 灯、插座、电视、摄像头、Home Assistant | ```text 光猫（桥接） - └─ RB5009 ether1：PPPoE / WAN - └─ 一个 tagged trunk（VLAN 55、66） - └─ 二层网管交换机 - ├─ access VLAN 66：PC、dns、gfw、ubnt 等可信设备 + └─ UCG-Ultra：PPPoE / NAT / IPv6 / DHCP / 防火墙 / WireGuard + └─ 1GbE tagged trunk（仅 VLAN 55、66） + └─ TL-SE5420（仅二层交换） + ├─ access VLAN 66：PC、dns、gfw、AP 管理 ├─ access VLAN 55：有线 IoT、Home Assistant - └─ AP 端口：native/untagged VLAN 66（AP 管理）+ tagged VLAN 55（IoT SSID） + └─ AP trunk：管理 VLAN + 需要承载的 SSID VLAN ``` -最少只需一条 RB5009 ↔ 交换机的 trunk；不需要为每个网段各拉一条上联线。若 AP 不需要同时提供两个 SSID，也可以将其端口设为单一 access VLAN，配置更简单。 +## gfw 的边界 -### 最小防火墙策略 +`gfw` 是 PVE 上的双网 ImmortalWrt VM（`.66.1`、`.55.1`），并非 UCG-Ultra 透明策略路由的下一跳： -按以下顺序在 **RB5009** 配置 forward 规则： +- 需要代理的客户端自行以对应 VLAN 的 `.1` 为默认网关； +- 其余客户端以硬件网关 `.254` 为默认网关； +- gfw 的默认路由指向相应 VLAN 的 `.254`，由 UCG-Ultra 统一 NAT 和连接 WAN； +- 禁止 gfw 在 VLAN55 与 VLAN66 之间直接转发，避免绕过网关的 VLAN 隔离策略； +- IPv6 不能让使用 gfw 的客户端直接以 `.254` 的 RA 出口绕过 gfw，必须在割接时逐台验证或明确禁用该客户端的 IPv6。 -1. 允许 `established,related`，丢弃 `invalid`。 -2. 允许 VLAN 66 与 VLAN 55 分别访问 WAN。 -3. 允许 VLAN 66 主动访问 VLAN 55（管理 IoT）。 -4. 允许 VLAN 55 仅访问必要的 LAN66 服务：`192.168.66.36` 的 TCP/UDP `53`；如 IoT 实际使用透明代理，再保留其到 `192.168.66.1` 所需的流量路径。 -5. 按需允许 IoT → Home Assistant：`192.168.55.11:8123`（两者都在 VLAN 55 时无需跨 VLAN 规则）。 -6. 丢弃 VLAN 55 → VLAN 66 的其余新建连接。 -7. 路由器自身的 WinBox/Web/SSH 仅允许 VLAN 66 管理，不向 VLAN 55 开放。 +## 最小安全策略 -该策略允许电脑管理设备、IoT 正常使用 DNS/上网，同时阻止 IoT 扫描电脑、NAS、DNS 管理页和 UniFi Controller。先不要细分更多 VLAN、ACL、访客网或将网关迁到交换机。 +1. 允许已建立/相关连接，丢弃无效连接；WAN 入站默认拒绝，仅保留明确端口转发。 +2. VLAN66、VLAN55 可各自访问 WAN。 +3. 允许 VLAN66 主动访问 VLAN55；VLAN55 → VLAN66 默认拒绝。 +4. 对 VLAN55 仅放行所需例外，如 `192.168.66.36` 的 TCP/UDP `53`；每个新增服务例外记录目标 IP、协议与端口。 +5. 仅从 VLAN66 和 WireGuard 管理 UCG-Ultra、交换机和 PVE；不从 VLAN55 开放管理面。 +6. DHCP 只下发 AdGuard Home `192.168.66.36`，不下发公共备用 DNS。 -## 对原建议的核实 +## 迁移与验收 -| 项目 | 结论 | 实际处理方式 | -| --- | --- | --- | -| RB5009 替代 ER-X | 正确 | RB5009 有 7 × 1GbE、1 × 2.5GbE、1 × 10G SFP+，适合做 PPPoE 网关；但它不是三层交换机。 | -| PPPoE MTU | 基本正确 | PPPoE 接口的 `max-mtu` / `max-mru` 不应大于 `1492`；物理以太网口通常保留 `1500`，不要为了 PPPoE 将其也改成 `1492`。 | -| MSS Clamping | 方向正确，命令位置不对 | RouterOS 使用 `/ip firewall mangle` 的 `change-mss`，不是 filter 表中的“tcp-mss 动作”。仅在实际遇到 PMTU 问题时添加并测试。 | -| IPv6 PD | 正确且应首批迁移 | 在 PPPoE 上以 DHCPv6 client 获取 PD，拆分现有 `/60` 中的两个 `/64` 给 LAN66/LAN55，并通过 RA/SLAAC 广播。不能把 IPv6 简单丢回光猫，否则会改变网关与防火墙边界。 | -| Bridge VLAN Filtering | 正确 | 可把 VLAN 55 及 LAN66 的 VLAN 化二层转发硬件卸载；RB5009 的交换芯片支持 VLAN filtering + L2 硬件卸载。 | -| “RB5009 的 VLAN 间路由硬件卸载” | 不正确 | RB5009 的 `88E6393` 不在 RouterOS L3HW 支持设备列表中；跨 VLAN 路由应由其 CPU + 防火墙处理。 | -| DHCP DNS 设为空 | 不正确 | DNS 设为空不是“关闭自动分配”，而是不会向客户端下发 AdGuard DNS。两个 DHCP network 都应明确下发 `192.168.66.36`。RB5009 自身 DNS 服务可不对 LAN 开放。 | -| DHCP Option 43 | 非必需 | 已被采纳的 AP 保留已有 inform URL 即可。只有重置/新接入的跨 VLAN AP 无法发现控制器时才配置；先确认 Docker 映射后的实际 inform 端口。 | -| 直接沿用默认防火墙 | 部分正确 | 可从 RouterOS 默认 IPv4/IPv6 防火墙开始，但必须在切换前加入 VLAN 间允许规则、端口转发和管理访问限制。 | -| 先把 LAN55 并入 LAN66 | 不建议 | 会改变 `192.168.55.0/24`，造成 DHCP、静态地址与 AP 管理中断；也无法在真实生产路径中验证双 VLAN。 | +1. **备份和盘点**：导出 ER-X 配置、DHCP 静态租约、端口转发和 WAN 参数；从现有自托管 UniFi Network 下载 `.unf` 网络备份。凭据不写入知识库。 +2. **离线准备**：升级 UCG-Ultra 至稳定版本；创建 VLAN55/VLAN66、网关 `.254`、DHCP、DNS、IPv4/IPv6 防火墙、WireGuard 和必要端口转发。配置 TL-SE5420 为二层 VLAN 交换，启用 RSTP 与 DHCP Snooping；网关 trunk 为唯一 trusted DHCP 端口。 +3. **迁移 UniFi 管理面**：按官方“Network-only backup”流程，在 UCG-Ultra 内置 Network 恢复 `.unf`；迁移期间只保留一个有效控制器。若设备显示由其他控制器管理，按官方流程迁移或重新采纳，不盲目重置所有 AP。[官方迁移说明](https://help.ui.com/hc/en-us/articles/360008976393-Backups-and-Migration-in-UniFi) +4. **维护窗口割接**：替换 ER-X，先验收 PPPoE、IPv4 出网、DHCP、DNS、VLAN 隔离，再接回 AP、PVE、Home Assistant 与 IoT。 +5. **IPv6 与 gfw 验收**：确认 ISP PD、两个 VLAN 的 RA、IPv6 入站默认拒绝；分别验证使用 `.1` 与 `.254` 的客户端不会形成回路或 IPv6 绕过。 +6. **业务验收**：测试 WireGuard、必要端口转发、AdGuard、OpenClash/Mihomo、两台 AP 和 VLAN55 的最小例外规则。 +7. **回滚**：验收未通过时回插 ER-X，保留 UCG-Ultra 与交换机配置和日志供排障；不在未验证前停掉旧控制器的备份。 -RouterOS 官方资料说明 PPPoE 的 IP 层 MTU 上限为 1492；MSS 修改属于 mangle 规则。 [PPPoE](https://help.mikrotik.com/docs/spaces/ROS/pages/2031625/PPPoE?src=breadcrumbs-parent)、[Mangle](https://help.mikrotik.com/docs/spaces/ROS/pages/48660587/Mangle?src=contextnavpagetreemode) +## 不在本阶段做的事 -RB5009 的接口规格与交换芯片为 7 × 1GbE、1 × 2.5GbE、1 × 10G SFP+、`88E6393`；RouterOS 的 L3HW 设备列表只列 CRS/CCR 等型号，未包含 RB5009。 [RB5009 产品手册](https://cdn.mikrotik.com/web-assets/product_files/RB5009UGSIN_250413.pdf)、[L3 Hardware Offloading](https://help.mikrotik.com/docs/spaces/ROS/pages/62390319/L3%2BHardware%2BOffloading) - -## 推荐采购方案 - -### 路由器：RB5009UG+S+IN - -**推荐购买。** 它能胜任当前 PPPoE、NAT、DHCP、IPv6 PD、端口转发和两个 VLAN 的防火墙路由，也为上联核心交换机提供 10G SFP+。 - -### 三层交换机：按实际端口与速率选择 - -| 使用场景 | 推荐 | 原因 | -| --- | --- | --- | -| 当前所有有线终端均为 1G，需要大量端口 | `CRS326-24G-2S+RM`（机架）或 `CRS326-24G-2S+IN`（桌面） | 24 × 1GbE + 2 × 10G SFP+；适合作为汇聚交换机。 | -| 准备为 NAS/PC/未来 AP 提供 2.5G，8 个电口足够 | `CRS310-8G+2S+IN` | 8 × 2.5GbE + 2 × 10G SFP+，支持硬件三层转发。 | -| AP 需要由交换机供电 | 以上型号均需另配 PoE 方案 | 保留现有 PoE 注入器，或另选有足够 802.3af/at 预算的 PoE 交换机；不要假设上述非 PoE 型号可供电。 | - -CRS326 提供 24 × 1GbE 与 2 × 10G SFP+；CRS310 提供 8 × 2.5GbE 与 2 × 10G SFP+，并支持硬件三层转发。 [CRS326 规格](https://manual.mikrotik.com/hardware/crs326-24g-2s-plus-rm/)、[CRS310 产品页](https://mikrotik.com/product/crs310_8g_2s_in) - -> 如果宽带不超过 1Gbps、内网也没有 NAS/PC 的大流量需求，新增三层交换机不会显著改善上网体验。它的价值是端口扩容、VLAN 管理和未来 2.5/10G 演进；不是本次替换 ER-X 的必要条件。 - -## 目标架构（第一阶段） - -```text -光猫（桥接） - └─ RB5009 ether1 / WAN - ├─ PPPoE + IPv4 NAT + IPv6 PD /60 + WAN 防火墙 - └─ SFP+ 10G trunk - └─ CRS（VLAN-aware 交换） - ├─ VLAN 66 / LAN66：192.168.66.0/24，GW 192.168.66.254 - │ ├─ gfw 192.168.66.1 - │ ├─ dns 192.168.66.36 - │ ├─ ubnt 192.168.66.46 - │ └─ U6 Lite 192.168.66.6 - └─ VLAN 55 / LAN55：192.168.55.0/24，GW 192.168.55.254 - └─ UAP-AC-Lite 192.168.55.5 -``` - -建议使用 VLAN ID `66` 和 `55`（与现有网段尾号一致）。两台设备之间的 10G 链路为 tagged trunk；终端/AP 端口为对应 VLAN 的 untagged access 端口。现有 AP 若只承载一个管理网络，先作为 access 端口；只有在未来通过 UniFi 下发多个 SSID VLAN 时才改为 trunk。 - -RB5009 与 CRS 都应仅建立一个 VLAN-aware bridge。RouterOS 明确说明多个 bridge 会失去硬件卸载，并建议用 bridge VLAN filtering 隔离二层网络。 [Bridging and Switching](https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging%20and%20Switching) - -## 三层交换的边界 - -第一阶段，CRS 运行二层交换，两个 VLAN 的网关/SVI 均在 RB5009。因此所有 LAN55 ↔ LAN66 流量都会被 RB5009 防火墙看到，最符合当前“默认双向可达、以后可能收紧”的需求。 - -后续若内网跨 VLAN 大流量确实成为瓶颈，才考虑在 **CRS310/CRS326** 上启用 L3HW，并把部分 VLAN 的网关迁到 CRS。注意：硬件路由会绕过普通 RouterOS firewall；官方文档明确要求在“硬件路由或防火墙”之间作取舍。届时必须用交换机 ACL 重新实现隔离策略，且保留 WAN 口到 RB5009 的 CPU/防火墙路径。 [L3HW 防火墙限制](https://help.mikrotik.com/docs/spaces/ROS/pages/62390319/L3%2BHardware%2BOffloading#L3HardwareOffloading-L3HWFeatureSupport) - -## 迁移顺序与验收 - -1. **备份与盘点**：导出 ER-X 配置（脱敏保存），记录 PPPoE 凭据、DHCP 静态租约的 MAC、端口转发协议、UPnP 需求及每条网线的去向；不要将现有配置中的密码写进笔记库。 -2. **离线配置 RB5009**：升级到稳定 RouterOS v7；建立 WAN/LAN interface list、VLAN 55/66、两个 IPv4 地址与 DHCP server、静态租约、DNS `192.168.66.36`、WAN NAT 和 IPv4/IPv6 基线防火墙。管理入口只允许来自 LAN66 的管理主机。 -3. **离线配置 CRS**：启用管理 VLAN、RSTP 与 VLAN filtering；建立 trunk/access 端口表。先保持其为 L2 交换机，不配置 SVI 或 DHCP。 -4. **迁移 IPv6**：在 PPPoE 上获取 IPv6 PD，将 `/60` 划出两个 `/64`，对两个 VLAN 发 RA/SLAAC；保留必要 ICMPv6、DHCPv6-PD 和 established/related 规则。IPv6 客户端有公网地址，因此 forward 链必须默认拒绝 WAN 发起的新连接。 [RouterOS IPv6 防火墙](https://help.mikrotik.com/docs/spaces/ROS/pages/48660574/Filter?src=breadcrumbs-parent) -5. **维护窗口切换**：替换 ER-X；先验证 PPPoE、IPv4/IPv6 出网、DNS、DHCP、到 `gfw` 的透明代理路径，再逐一接回 VLAN 66 与 VLAN 55 端口。 -6. **服务验收**：确认 AdGuard DNS、OpenClash、Mihomo、UniFi 控制器、两台 AP、四条端口转发（HASS/Transmission/SSH/OpenVPN）和 hairpin NAT（若仍需要）均正常。 -7. **观察与收紧**：观察至少一周 DHCP 日志、IPv6 RA、UPnP 和 NAT；再决定 LAN55 是否需要限制访问 LAN66 的管理服务。 - -## UniFi 注意事项 - -- 已采用的 AP 不需要为迁移重新配置 Option 43；保持可访问现有 inform 地址即可。 -- 对跨 VLAN 的新 AP/重置 AP，先确保 AP 到 Controller 的实际 inform 端口（当前记录为宿主机 `:9080`）可达。UniFi 官方默认示例使用 TCP `8080`，而 Docker 常会将宿主机 `9080` 映射到容器内 `8080`，因此应以控制器实际端口映射为准。 -- 如确有自动发现需求，Option 43 的 IPv4 地址格式为 `0104` 加控制器 IPv4 的十六进制；对于 `192.168.66.46` 即 `0104c0a8422e`。这只解决发现问题，不能替代 VLAN 间路由与防火墙放行。 [UniFi Layer-3 Adoption](https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3) +- 不启用核心交换机三层路由，不让 VLAN55 的安全边界绕过 UCG-Ultra。 +- 不建立 native/untagged 业务 VLAN 的网关 trunk。 +- 不购买 RB5009、UXG-Lite 或 UXG-Max 与 UCG-Ultra 同时运行；它们是替代选项，不是本拓扑的叠加设备。 +- 不把 UCG-Ultra 的 2.5GbE **WAN** 误当作可供核心交换机使用的 2.5GbE **LAN**。对本设计，网关到核心的上联是 1GbE，持续高流量跨 VLAN / VPN / 端口转发时须重新评估。 diff --git a/02_Areas/Network & VPN/Home Network.md b/02_Areas/Network & VPN/Home Network.md index 48ba007..07b966c 100644 --- a/02_Areas/Network & VPN/Home Network.md +++ b/02_Areas/Network & VPN/Home Network.md @@ -7,7 +7,7 @@ updated: 2026-08-07 # Home Network -> 当前网络结构与服务清单。WAN IP 为动态地址，仅作为记录时的状态参考。 +> 当前网络结构与服务清单。WAN IP 为动态地址，仅作为记录时的状态参考。拟迁移目标另见 [[Home Network Upgrade Plan]]；本页不将计划设备误记为已上线状态。 ## 拓扑概览 @@ -34,13 +34,22 @@ Internet | LAN55 | `192.168.55.0/24`，接口 `switch0` / `eth1`–`eth3`，网关 `192.168.55.254` | | 跨网段连通性 | 默认双向可达；`LAN_IN` 规则虽已定义，但未绑定到接口 | +## 已批准的迁移目标（尚未上线） + +- 以 **UCG-Ultra** 替换 EdgeRouter X，继续使用两个 `.254` 网关地址；它负责 PPPoE、DHCP、IPv4/IPv6 防火墙、NAT、WireGuard 和端口转发。 +- 以 TL-SE5420 作为纯二层核心交换机；网关到交换机采用 1GbE tagged trunk，仅承载 VLAN55 和 VLAN66。 +- UCG-Ultra 内置 UniFi Network。迁移完成并确认 AP 已采纳后，停用 `ubnt` 上自托管的 UniFi Controller；切换前保留其 `.unf` 备份和原控制器，不能提前关停。 +- `gfw` 保持 `.66.1` / `.55.1` 双网旁路由。需要代理的客户端自行使用 `.1`，其余客户端使用 `.254`；不是所有设备都经 gfw。 + +详细验收和回滚步骤见 [[Home Network Upgrade Plan]]。 + ## 核心主机 | 主机 | IP | 服务与职责 | | --- | --- | --- | | `gfw.windy.lan` | `192.168.66.1`、`192.168.55.1` | PVE 上的双网 ImmortalWrt VM；OpenClash 旁路由，使用 fake-ip + TPROXY；`dnsmasq → clash :7874` | | `dns.windy.lan` | `192.168.66.36` | AdGuard Home DNS（TCP/UDP `53`）；上游 DoH：阿里、腾讯；DNSSEC 关闭。Mihomo 显式代理（systemd 服务） | -| `ubnt` | `192.168.66.46` | UniFi Network Controller（Docker `v9.5.21`；inform `:9080`、UI `:8443`）及 Dockge | +| `ubnt` | `192.168.66.46` | 当前：UniFi Network Controller（Docker `v9.5.21`；inform `:9080`、UI `:8443`）及 Dockge；迁移到 UCG-Ultra 后停止其控制器职责 | ## DHCP 与名称解析