windy/my-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(network): refine gateway and switch ADRs

Browse Source
This commit is contained in:
windyboy
2026-08-07 17:29:19 +08:00
parent df3e3eb3ab
commit 1693eb46cf
4 changed files with 166 additions and 475 deletions
Download Patch File Download Diff File Expand all files Collapse all files
02_Areas/Network & VPN/Home Network Upgrade Plan.md
+49 -105
View File
@@ -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 / 端口转发时须重新评估。