diff --git a/docs/lan-core-switch-upgrade-plan.md b/docs/lan-core-switch-upgrade-plan.md new file mode 100644 index 0000000..3a6cc2c --- /dev/null +++ b/docs/lan-core-switch-upgrade-plan.md @@ -0,0 +1,156 @@ +# LAN 核心交换机升级计划（保留 ER-X） + +**状态：** SE5420 **已采购**（2026-08-09）。**实施与验证以 [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) 为准**； +本文保留为设计/阶段划分参考。 +**锁定硬件：** TP-Link **`TL-SE5420`**（16 × 2.5GbE RJ45 + 4 × 10GbE SFP+）。 +**目标：** SE5420 承接全部 LAN 物理接入与二层转发；ER-X 继续承担公网、NAT、防火墙、 +LAN66/LAN55 网关与 DHCP。 + +**拓扑与流量的详细说明**（职责、逻辑网、流量路径、Wi-Fi 分工、验收边界）见： +[lan-erx-se5420-network.md](lan-erx-se5420-network.md)。 + +SE5420 官方资料：静态功耗 8 W、最大功耗 32 W；VLAN、LACP、STP/RSTP/MSTP、ACL、 +CLI/SNMP、配置导入导出与固件下载。无 PoE——AP 使用本地取电 + 普通网线。 + +## 已确认边界（摘要） + +| 项 | 结论 | +|---|---| +| 硬目标 | 同 VLAN 2.5G；SFP+ 先空槽 | +| 核心角色 | 纯 L2；不开 L3 / DHCP Server/Relay / NAT | +| 网关 | 默认一律 ER-X `.254`；升级专用 SSID（后续）才走 `gfw` `.1` | +| 本次 Done | 阶段 0–3；VLAN10 / 客人 SSID / 升级 SSID 另立项目 | +| 切换 | 30–60 分钟维护窗；旧交换迁完后闲置 | +| 首批 2.5G | NAS + 主力 PC（或 PVE） | +| 管理 | 先本地 HTTPS/SSH；云以后再说 | + +### 保留的 ER-X 职责 + +| 项目 | 迁移后职责 | +|---|---| +| PPPoE / WAN、NAT、端口转发、WAN 防火墙 | ER-X，不变 | +| LAN66 (`192.168.66.0/24`) 默认网关与 DHCP | ER-X `eth0`，不变 | +| LAN55 (`192.168.55.0/24`) 默认网关与 DHCP | ER-X `switch0`，不变 | +| LAN66 ↔ LAN55 三层转发 | ER-X，不变 | +| 升级专用 Wi-Fi 网关（后续） | `gfw` VM，不是 ER-X 或核心交换机 | + +ER-X 与核心之间使用两条**独立无标签 access**（LAN66 + LAN55），不向 ER-X 送 +VLAN tag。 + +### 核心交换机职责 + +- 所有有线设备、AP 与 PVE 的物理接入； +- VLAN66、VLAN55 的二层转发； +- 为日后 U6 Lite 与 PVE 预留 VLAN10 trunk（本次不启用业务）； +- 同 VLAN 的 1G/2.5G 转发； +- SFP+ 预留未来 10G（DAC/AOC/光；不用 10GBASE-T 作默认）。 + +## 目标拓扑（简图） + +```text + Internet + | + ER-X / PPPoE + +-------+--------+ + | | + eth0, LAN66 switch0 port, LAN55 + access access + | | + +-------+--------+ + | + TL-SE5420 核心（纯 L2） + | | | + PVE / gfw U6 Lite LAN66/LAN55 access + （日后 trunk） （日后 trunk） NAS, PC, dns, ubnt, AC-Lite … +``` + +完整端口表、流量路径与 Wi-Fi 分工见 +[lan-erx-se5420-network.md](lan-erx-se5420-network.md)。 + +## VLAN 与端口设计 + +| VLAN / 逻辑网络 | 核心配置 | 网关 / DHCP | 用途 | +|---|---|---|---| +| 66 | access；PVE/U6 日后 trunk 的 native | ER-X `eth0` / `.254` | 主 LAN、管理 | +| 55 | access | ER-X `switch0` / `.254` | LAN55、AC-Lite | +| 10（后续） | 仅 PVE 与 U6 trunk 上 tagged | `gfw` | 升级专用 SSID | +| 管理 | LAN66 管理地址；不新建 VLAN | reservation / 静态 | SE5420 管理面 | + +管理地址分配前先查 ER-X DHCP/reservation；禁用不需要的 HTTP/Telnet；云管延后； +保留 HTTPS/SSH 与离线配置备份（备份不进本仓库）。 + +### 初始端口分配 + +| 预留 | 对端 | 模式 | +|---|---|---| +| 铜口 1 | ER-X `eth0` | access VLAN66 | +| 铜口 2 | ER-X `switch0` 成员口 | access VLAN55 | +| 铜口 3 | PVE（`gfw`） | 现 access 66；日后 trunk native66+tag10 | +| 铜口 4 | U6 Lite | 同上；本地取电 | +| 铜口 5 | UAP-AC-Lite | access VLAN55；本地取电 | +| 其余铜口 | NAS、PC、`dns`、`ubnt`… | 默认 access VLAN66 | +| SFP+ 1–4 | 未来 | 空槽 | + +## 分阶段实施与验收 + +### 阶段 0：采购前核验 + +1. 确认 SE5420 revision、保修、手册、固件页。 +2. 确认 VLAN trunk、RSTP/MSTP、LACP、镜像、配置导出、错误计数。 +3. SFP+ 模块本次不买；有对端后再选 DAC/AOC/光。 +4. 盘点线缆与对端（LAN66/55、PVE、两台 AP）；确认关键 2.5G 链路可协商。 + +### 阶段 1：离线初始化核心 + +1. 仅电源 + 隔离管理本：管理 IP、强密码、时区、NTP、HTTPS/SSH；**关闭 L3/DHCP**。 +2. 导出初始配置（离线保存，不进仓库）。 +3. 建立 VLAN66/55/10 与端口模板；VLAN10 不接生产。 +4. 开启 RSTP/MSTP；不制造物理环路。 + +### 阶段 2：维护窗迁移 LAN66 + +1. 使用约定维护窗（约 30–60 分钟）；保留原接线作回滚。 +2. 先接铜口 1 ↔ ER-X `eth0`；验证管理地址、`.254`、DNS `.36`、互联网。 +3. 逐台迁到 VLAN66 access；每台确认地址/DNS/路由/业务。 +4. 最后迁 `ubnt`、`dns`、NAS/PC；禁止无意双上行。 + +### 阶段 3：迁移 LAN55 + +1. 接铜口 2 ↔ ER-X `switch0` 成员口。 +2. 测试设备获 `192.168.55.x`、网关 `.254`、可达 DNS。 +3. AC-Lite → 铜口 5；确认 `.55.5` 与 Inform Connected。 +4. 旧交换下电闲置。 + +### 阶段 4：VLAN10 升级专用 Wi-Fi（独立项目） + +不与本次 Done 捆绑。仅 U6；网关 `gfw`；详见 +[lan-erx-se5420-network.md](lan-erx-se5420-network.md) 第 6.5 / 8 节与 +[unifi-network.md](unifi-network.md)。 + +## 性能预期与不变瓶颈 + +- 同 VLAN、两端在核心上的 2.5G：可测 2.5G 级二层。 +- 上网与 LAN66↔LAN55：仍经 ER-X 1G 路径。 +- 空 SFP+ 不使网络「变成 10G」。 + +## 验收清单 + +- 管理面、口令、离线备份； +- 端口速率与错误计数； +- LAN66/55 的 DHCP、网关、DNS、互联网与关键本地服务； +- 两台 AP Connected；Inform 仍为 `http://192.168.66.46:9080/inform`； +- 无无意环路；旧交换已闲置； +- （建议）两台 2.5G 终端同 VLAN `iperf3`。 + +## 回滚 + +验证失败则停迁、恢复原接线；不改 ER-X WAN/DHCP/SSH。VLAN10 失败只撤新 SSID。 + +## 参考 + +- [ER-X + SE5420 网络与拓扑说明](lan-erx-se5420-network.md) +- [LAN 概览](lan-overview.md) +- [ER-X 配置记录](edgerouter-x-configuration.md) +- [UniFi 网络](unifi-network.md) +- [`gfw`](../hosts/gfw.windy.lan.md) +- [TL-SE5420 官方规格](https://www.tp-link.com.cn/product_2899.html?v=specification) diff --git a/docs/lan-erx-se5420-network.md b/docs/lan-erx-se5420-network.md new file mode 100644 index 0000000..1e98852 --- /dev/null +++ b/docs/lan-erx-se5420-network.md @@ -0,0 +1,321 @@ +# ER-X + TL-SE5420 网络与拓扑说明 + +**状态：** SE5420 **已采购**（2026-08-09）。**实施与验证以 [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) 为准**； +本文保留为拓扑/流量路径/职责边界的设计说明。 +**锁定硬件：** EdgeRouter X（保留）+ TP-Link `TL-SE5420`（新建核心）。 +**本文目的：** 说明升级后物理拓扑、逻辑网络、流量路径与职责边界；实施步骤见 +[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md)。 + +--- + +## 1. 一句话架构 + +```text +公网 ← ER-X（网关 / NAT / DHCP / 防火墙） + ↑ 两条独立 access 上联（LAN66 + LAN55，无 VLAN tag） + TL-SE5420（纯 L2 核心：所有接入、同 VLAN 转发、未来 trunk） + ↑ + 有线终端 / PVE(gfw) / 两台 UniFi AP +``` + +- **ER-X** 继续当唯一主网关：PPPoE、NAT、端口转发、LAN66/LAN55 的 `.254` 与 DHCP。 +- **SE5420** 只做二层：接线、VLAN 隔离转发、端口统计；**不开** L3、静态路由、DHCP + Server/Relay、NAT。 +- **`gfw`（PVE 上的 OpenWrt）** 仍是旁路由；默认客户端网关仍是 `.254`。以后若启用 + 「设备升级」专用 SSID，该 SSID 的客户端才把网关指向 `.1`。 + +--- + +## 2. 已确认的设计决策 + +| 决策 | 结论 | +|---|---| +| 硬目标 | 同 VLAN **2.5G** 二层转发；10G 仅 SFP+ 预留 | +| 核心型号 | **`TL-SE5420`**（16×2.5G RJ45 + 4×10G SFP+） | +| 终局形态 | ER-X 边缘网关 + 核心纯 L2；可分阶段实施 | +| 本次升级 Done | 迁完 LAN66/LAN55 接入与验收（计划阶段 0–3）；不含 VLAN10 | +| 默认网关 | **`192.168.66.254` / `192.168.55.254`（ER-X）** | +| 专用升级 SSID | 仅 **U6 Lite**；客户端网关 **`gfw` `.1`**（后续项目） | +| 客人网 | 仅 **UAP-AC-Lite**；UniFi Guest 隔离，仍在 **LAN55**（后续） | +| 切换方式 | **30–60 分钟维护窗** 集中切；旧交换迁完后闲置 | +| 首批 2.5G | NAS + 主力 PC（或 PVE）；其余可先 1G | +| SFP+ | 先空槽；有明确 10G 对端再买 DAC/光模块 | +| AP 供电 | **本地取电 + 普通网线**（SE5420 **无 PoE**） | +| 管理面 | 先本地 HTTPS/SSH；云以后再说；L3/DHCP 严格关闭 | + +--- + +## 3. 设备职责 + +### 3.1 EdgeRouter X（`gw`，`192.168.66.254`） + +| 职责 | 说明 | +|---|---| +| WAN | `eth4` → PPPoE（`pppoe0`），NAT、WAN 防火墙、端口转发 | +| LAN66 网关/DHCP | `eth0` = `192.168.66.254/24`；DHCP 池与静态映射不变 | +| LAN55 网关/DHCP | `switch0`（`eth1`–`eth3`）= `192.168.55.254/24` | +| 跨网段路由 | LAN66 ↔ LAN55 仍由 ER-X 三层转发 | +| 与核心的连接 | **两条无标签 access**，不是 802.1Q trunk | + +ER-X 当前不是 trunk 设计：不要向它发送 VLAN66/55 的 tag。核心上 VLAN66 的 +untagged 帧进 `eth0`；VLAN55 的 untagged 帧进 `switch0` 的某个成员口。 + +### 3.2 TL-SE5420（新建核心） + +| 职责 | 说明 | +|---|---| +| 物理接入汇聚 | 有线设备、PVE、两台 AP 都接到 SE5420 | +| VLAN66 / VLAN55 | 二层转发（access 或 trunk 的 native/allowed） | +| 同 VLAN 高速交换 | 两端都是 2.5G 时可跑满协商速率（受 NIC/线材限制） | +| 未来 trunk | PVE、U6：native 66 + tagged 10（仅后续阶段启用） | +| 不做 | 不当默认网关；不开 DHCP；不做 NAT；第一阶段不开 SVI/路由 | + +管理地址：落在 **LAN66** 的一个未占用地址（先查 ER-X DHCP reservation，再分配）； +不新建管理 VLAN。 + +### 3.3 旁路由 `gfw`（`192.168.66.1`） + +| 现状 | 升级后（阶段 0–3） | 更后续 | +|---|---|---| +| PVE 上的 ImmortalWrt VM | 仍挂在 **untagged LAN66** | 可增 VLAN10 接口 | +| OpenClash 旁路/透明代理 | 路径不变：客户端默认仍走 `.254` | 升级专用 SSID → 网关 `.1` | +| 不能单独「做出」VLAN10 | 需 PVE vSwitch + 核心 trunk + U6 trunk | 见第 7 节 | + +### 3.4 其它现网角色（地址与角色不变） + +| 主机 | 地址 | 角色 | +|---|---|---| +| `dns.windy.lan` | `192.168.66.36` | AdGuard Home + Mihomo | +| `ubnt` | `192.168.66.46` | UniFi Controller；Inform `http://192.168.66.46:9080/inform` | +| U6 Lite | `192.168.66.6` | LAN66 AP；后续承载升级专用 SSID | +| UAP-AC-Lite | `192.168.55.5` | LAN55 AP；后续承载客人 SSID | +| PVE | `192.168.66.26`（DHCP 静态） | 宿主机；上挂 `gfw` | +| NAS / 主力 PC 等 | 既有 reservation | 首批 2.5G 候选 | + +--- + +## 4. 物理拓扑 + +### 4.1 目标连线（阶段 3 完成后） + +```text + Internet + │ + PPPoE / WAN + │ + ┌──────────┴──────────┐ + │ EdgeRouter X │ + │ (gw / 网关) │ + │ │ + │ eth0 switch0 成员口 + │ LAN66 LAN55 + │ untagged untagged + └───┬───────────────┬─┘ + │ │ + 铜口1│ │铜口2 + │ │ + ┌─────────┴───────────────┴─────────┐ + │ TL-SE5420 核心 │ + │ 16×2.5G RJ45 + 4×SFP+（先空） │ + │ 纯 L2 · VLAN66 / VLAN55 │ + └───┬─────┬─────┬─────┬─────┬───────┘ + │ │ │ │ │ + 铜口3 铜口4 铜口5 其余铜口 SFP+ + │ │ │ │ （预留） + │ │ │ │ + PVE U6 AC-Lite NAS/PC/ + (gfw) Lite (LAN55) dns/ubnt… + LAN66 LAN66 默认 LAN66 + （日后可 （日后可 + trunk) trunk) +``` + +要点： + +1. **星型**：终端与 AP 只上联到 SE5420；旧交换机迁完后**闲置**，避免双上行环路。 +2. **ER-X 双上联**：LAN66、LAN55 各一条独立铜缆；两条都是 access，**不打 tag**。 +3. **AP 供电**：SE5420 无 PoE；U6 / AC-Lite 在安装点**本地取电**，网线只传数据。 +4. **SFP+**：四个槽位先空着；有 10G NIC/对端与兼容模块后再上 DAC/AOC/光纤。 + +### 4.2 与「现在」的差异（概念上） + +```text +现在（简化） 目标 +───────────── ──── +终端/AP ──► ER-X 内置交换/旧交换 终端/AP ──► SE5420 ──► ER-X（仅网关） +同网段 1G 交换受 ER-X/旧设备限制 同 VLAN 2.5G 在 SE5420 上本地交换 +跨网段 / 上网 仍经 ER-X 跨网段 / 上网 仍经 ER-X（不变） +``` + +ER-X **不会被换成**「只接一条 trunk 的路由」；WAN 与双 LAN 接口模型保持不变。 + +--- + +## 5. 逻辑网络（VLAN / 子网） + +### 5.1 本次升级范围内（阶段 0–3） + +| 名称 | 子网 | 核心上的形态 | 网关 | DHCP | 典型成员 | +|---|---|---|---|---|---| +| **LAN66** | `192.168.66.0/24` | VLAN 66：access，或 trunk 的 native | ER-X `eth0` `.254` | ER-X | PVE、gfw、dns、ubnt、U6、NAS、PC… | +| **LAN55** | `192.168.55.0/24` | VLAN 55：access | ER-X `switch0` `.254` | ER-X | UAP-AC-Lite、原 LAN55 设备 | + +客户端 DNS 仍按现网：DHCP 下发 `192.168.66.36`（AdGuard）。 +LAN55 ↔ LAN66 互通仍走 ER-X（现网 `LAN_IN`/`LAN_OUT` 未挂到接口时，两边默认可达；不要把未生效的防火墙当隔离边界）。 + +### 5.2 后续能力（不进本次 Done） + +| 名称 | 打算 | 网关 | 落点 | 依赖 | +|---|---|---|---|---| +| **升级专用 Wi-Fi** | 独立 SSID → 独立 VLAN（如 VLAN10） | **`gfw` `.1`**（该 VLAN 内） | **仅 U6 Lite** | 核心 trunk + PVE vSwitch + `gfw` DHCP/NAT | +| **客人网** | 客人 SSID + UniFi Guest 隔离 | 仍 **ER-X `.254`（LAN55）** | **仅 UAP-AC-Lite** | UniFi 策略；**不**新建 VLAN | + +客人网与升级 SSID **分工到两台 AP**，避免一上来就做「两台 AP 同一客人 VLAN + ER-X trunk」的改造。 + +### 5.3 核心上为何仍预配 VLAN10 + +阶段 1 可在 SE5420 上建好 VLAN10 与 trunk 模板，但： + +- **不接生产终端**； +- **不改 UniFi SSID**； +- **不在 `gfw` 上启用与 ER-X 冲突的 DHCP**。 + +这样迁线项目与「专用升级 Wi-Fi」解耦：核心一次配好端口角色，业务另开窗口。 + +--- + +## 6. 流量怎么走 + +### 6.1 同 VLAN、两端都在核心上（例如 NAS ↔ PC，皆 LAN66） + +```text +NAS ──(2.5G)── SE5420 ──(2.5G)── PC + （二层交换，不经过 ER-X） +``` + +这是本次升级的**主要收益**。吞吐受 NIC、线材、磁盘限制；与 ER-X 的 1G 无关。 + +### 6.2 访问互联网（任意 LAN66/LAN55 客户端） + +```text +客户端 → SE5420 →（对应 access 上联）→ ER-X → PPPoE → Internet +默认网关 = .254 +``` + +上网路径仍受 **ER-X 上联 1G** 与 PPPoE 限制；换核心**不会**把公网变成 2.5G。 + +### 6.3 LAN66 ↔ LAN55 + +```text +LAN66 设备 → SE5420(VLAN66) → ER-X eth0 + ↕ 三层转发 +LAN55 设备 → SE5420(VLAN55) → ER-X switch0 +``` + +跨网段必须过 ER-X；两条上联各 1G，且 ER-X 是否硬件加速需实测，**不要**按 2.5G 承诺跨 VLAN 吞吐。 + +### 6.4 旁路由 `gfw`（默认主网行为） + +默认：DHCP 仍发网关 `.254`。客户端若把代理/策略指到 `gfw`，或由上游策略引流，则 +`gfw` 以旁路由身份处理；**主网关身份仍是 ER-X**。 + +### 6.5 未来：升级专用 SSID（仅说明，非本次范围） + +```text +手机 --SSID(升级)--> U6 Lite --tag VLAN10--> SE5420 --tag VLAN10--> PVE --> gfw + 网关 .1 +gfw 上游仍回 LAN66 → SE5420 → ER-X → Internet +``` + +主 SSID（如现有 `ubnt-windy`）继续 untagged/LAN66，网关仍是 `.254`，互不影响。 + +--- + +## 7. 端口预留（SE5420） + +端口号以面板为准；下表是角色预留。 + +| 预留 | 对端 | 模式 | 备注 | +|---|---|---|---| +| 铜口 1 | ER-X `eth0` | access VLAN66 | 主网上联 | +| 铜口 2 | ER-X `switch0` 成员口 | access VLAN55 | LAN55 上联 | +| 铜口 3 | PVE（`gfw` 所在宿主机） | 阶段 0–3：access VLAN66；日后 trunk native66+tag10 | 只允许需要的 VLAN | +| 铜口 4 | U6 Lite | 同上 | 本地取电；日后升级 SSID | +| 铜口 5 | UAP-AC-Lite | access VLAN55 | 本地取电；日后客人 SSID | +| 其余铜口 | NAS、PC、`dns`、`ubnt`… | 默认 access VLAN66 | 首批 2.5G：NAS + 主力 PC/PVE | +| SFP+ 1–4 | 未来 10G | 空槽 | 优先 DAC/AOC/光；不用 10GBASE-T 模块作默认 | + +禁止：同一设备同时接旧路径与新核心形成**无意双上行**（环路/环回保护误杀/不稳定）。 + +--- + +## 8. Wi-Fi 与 UniFi（目标语义） + +| SSID 类型 | AP | 二层落点 | 客户端网关 | 本次升级是否必须完成 | +|---|---|---|---|---| +| 现有主 SSID（如 `ubnt-windy`） | 按现网 | LAN66 等 | `.254` | 迁线后保持 Connected 即可 | +| 客人 SSID | **仅 AC-Lite** | LAN55 + UniFi Guest 隔离 | `.254` | **否**（后续） | +| 升级专用 SSID | **仅 U6** | 未来 VLAN10 | **`.1`（gfw）** | **否**（后续） | + +Inform 仍为：`http://192.168.66.46:9080/inform`。 +AC-Lite 在 LAN55、Controller 在 LAN66：跨网段由 ER-X 转发（现网已验证可达）。 + +--- + +## 9. 管理与安全面 + +| 项 | 做法 | +|---|---| +| SE5420 管理 IP | LAN66 未占用地址；DHCP reservation 或静态；先查 ER-X 再写 | +| 管理协议 | 本地 HTTPS / SSH；禁用不需要的 HTTP/Telnet | +| 云管 | 先本地管稳；商云/App **以后再说** | +| L3 功能 | **全部关闭**（无 SVI、无静态路由、无 DHCP Server/Relay） | +| STP | 开启 RSTP/MSTP；合理根桥优先级；迁完后不留生产环路 | +| 配置备份 | 离线导出；**不得**把含口令/SNMP 的备份放进本仓库 | +| AP | 本地电源 + 数据网线；核心不供电 | + +--- + +## 10. 性能预期（诚实边界） + +| 场景 | 预期 | +|---|---| +| 同 VLAN、两端 2.5G 接在 SE5420 | 可达约 2.5G 级二层（测 `iperf3` 验收） | +| 上网 / PPPoE | 仍受 ER-X WAN 与 1G 上联限制 | +| LAN66 ↔ LAN55 | 必过 ER-X；按 1G 级规划，实测为准 | +| SFP+ 空槽 | **不等于**网络已是 10G | +| 未来 VLAN10 + `gfw` | 受 PVE NIC/vSwitch 与 `gfw` 处理能力限制，勿预先承诺 2.5G 路由 | + +--- + +## 11. 验收时「网络算正常」的样子 + +阶段 3 完成后，应同时满足： + +1. 有线设备从 SE5420 获取正确网段地址；默认路由为对应 `.254`；DNS `.36` 可用。 +2. 互联网、端口转发、现有本地服务行为与迁线前一致（除同 VLAN 内网吞吐变快）。 +3. U6（`.6`）与 AC-Lite（`.55.5`）在 UniFi 为 Connected；Inform 未改。 +4. SE5420 管理面仅可信 LAN66 可达；默认口令已改；配置已离线备份。 +5. 端口协商速率、CRC/错误计数正常；旧交换已下电闲置。 +6. （可选强化）两台 2.5G 终端同 VLAN `iperf3` 结果入库/记笔记。 + +VLAN10 / 升级 SSID / 客人 SSID **失败或未做，不否决**本次核心升级。 + +--- + +## 12. 回滚语义 + +任一阶段失败：停止继续搬家；把刚迁的设备插回原 ER-X/旧交换端口。 +**不要**在故障中改 ER-X 的 WAN、DHCP 池、网关地址或 SSH 策略。 +后续 VLAN10 失败：只撤 SSID/VLAN 绑定，主 SSID 与 `.254` 路径保持不动。 + +--- + +## 13. 参考 + +- 实施阶段与清单：[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md) +- 现网地图：[lan-overview.md](lan-overview.md) +- ER-X：[edgerouter-x-configuration.md](edgerouter-x-configuration.md)、[hosts/gw.md](../hosts/gw.md) +- UniFi / VLAN10 前置：[unifi-network.md](unifi-network.md) +- `gfw`：[hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) +- SE5420 规格： diff --git a/docs/lan-overview.md b/docs/lan-overview.md index 8054fd3..4bb965f 100644 --- a/docs/lan-overview.md +++ b/docs/lan-overview.md @@ -35,6 +35,11 @@ from each section below. │ ubnt — UniFi Network Controller (192.168.66.46) ``` +> **SE5420 purchased (2026-08-09):** TP-Link `TL-SE5420` acquired; deployment plan is +> [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md). Design/planning refs: +> [lan-erx-se5420-network.md](lan-erx-se5420-network.md), +> [lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md). + --- ## Hosts @@ -42,12 +47,20 @@ from each section below. | Host | Role | SSH | IPv4 | Facts | |------|------|-----|------|-------| | **gw** | EdgeRouter X primary LAN gateway | `ssh -4 zhiqiang@192.168.66.254` | `192.168.66.254` | [hosts/gw.md](../hosts/gw.md) | -| **gfw.windy.lan** | OpenWrt LAN gateway / OpenClash | `ssh -4 root@192.168.66.1` | `192.168.66.1` | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) | -| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) | -| **ubnt** | UniFi Network Controller | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | [hosts/ubnt.md](../hosts/ubnt.md) | +| **PVE** | Proxmox host (`.66.26`/vmbr0 · `.55.26`/vmbr1) — hosts gfw/dns/ubnt/haos VMs | `ssh -4 root@192.168.66.26` | `192.168.66.26` | — | +| **gfw.windy.lan** | OpenWrt LAN gateway / OpenClash — **PVE VM 140** | `ssh -4 root@192.168.66.1` | `192.168.66.1` | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) | +| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy — **PVE VM 120** (`pihole`) | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) | +| **ubnt** | UniFi Network Controller — **PVE VM 160** | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | [hosts/ubnt.md](../hosts/ubnt.md) | +| **haos** | Home Assistant (HAOS) — **PVE VM 180** (LAN55) | — | `192.168.55.11` | — | +| **NAS/FreeNAS** | NAS; `transmission` jail runs here (`.51`) | — | — | — | | **U6 Lite** | UniFi AP (LAN66) | `ssh -4 zhiqiangf@192.168.66.6` | `192.168.66.6` | [docs/unifi-network.md](../docs/unifi-network.md) | | **UAP-AC-Lite** | UniFi AP (LAN55) | `ssh -4 zhiqiangf@192.168.55.5` | `192.168.55.5` | [docs/unifi-network.md](../docs/unifi-network.md) | +> **Positioning facts (verified 2026-08-09):** `dns`/`ubnt`/`gfw`/`haos` are all VMs on PVE +> (no separate physical hosts); `transmission` is a FreeNAS/NAS jail. Only gw, PVE, +> NAS, U6, UAP-AC-Lite, and wired PCs/NAS are physical SE5420 ports. See +> [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) §1. + --- ## gw — EdgeRouter X (LAN gateway) @@ -163,6 +176,8 @@ AP SSH account is `zhiqiangf` (key-only, verified). See [docs/unifi-network.md]( - [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) — AdGuard Home + Mihomo detail - [hosts/ubnt.md](../hosts/ubnt.md) — UniFi controller + proxy contract - [docs/unifi-network.md](../docs/unifi-network.md) — APs, inform endpoint, recovery +- [docs/unifi-third-party-vlan10-dhcp.md](unifi-third-party-vlan10-dhcp.md) — VLAN Wi-Fi feasibility and DHCP boundary +- [docs/unifi-openwrt-vlan10-implementation-examples.md](unifi-openwrt-vlan10-implementation-examples.md) — supported topology and examples - [docs/edgerouter-x-configuration.md](../docs/edgerouter-x-configuration.md) — effective gw config - [docs/unifi-openclash-localhost.md](../docs/unifi-openclash-localhost.md) — proxy bypass -- [runbooks/adguard-home-health.md](../runbooks/adguard-home-health.md) — AGH health \ No newline at end of file +- [runbooks/adguard-home-health.md](../runbooks/adguard-home-health.md) — AGH health diff --git a/docs/lan-rb5009-upgrade.md b/docs/lan-rb5009-upgrade.md new file mode 100644 index 0000000..0e146a0 --- /dev/null +++ b/docs/lan-rb5009-upgrade.md @@ -0,0 +1,397 @@ +# ER-X → RB5009 网关升级：网络形态与实施计划 + +**状态：** 规划文档（未采购、未接线、未改生产配置）。 +**重要变更（2026-08-09）：** **SE5420 已采购**，网络升级改为「保留 ER-X + SE5420 核心」路径—— +实施与验证以 [lan-se5420-deployment-guide.md](lan-se5420-deployment-guide.md) 为准。 +本文保留为「ER-X 网关未来替换为 RB5009」的备选方案；其中 PVE 透传调研与 VLAN10 实现方法仍适用。 + +--- + +## 1. 一句话架构 + +```text +公网 ← RB5009（主网关：PPPoE / NAT / 防火墙 / DHCP / IPv6 / VLAN 66+55 三层） + ↑ 全部终端 / AP / PVE 直连其 8×1G 端口 + （SFP+ 空槽，为未来 10G 核心预留） +``` + +- **RB5009** 兼任路由与 LAN 二层交换：所有接入设备直插 RB5009 端口。 +- 客户端默认网关仍是 **`.254`**（RB5009 沿用 ER-X 地址，客户端零感知）。 +- **`gfw`** 仍为旁路由（默认网关 `.254`）；OpenClash 行为不变。 +- **ER-X 升级后下电闲置，作为已配置的备件保存**（回滚路径）。 +- 2.5G/10G 同 VLAN 交换目标**放弃**（无 SE5420）；LAN 二层为 1G。 + +--- + +## 2. 已确认的设计决策 + +| 决策 | 结论 | +|---|---| +| 角色 | RB5009 单机：路由 + LAN 交换 + 双 VLAN 三层 | +| WAN | **PPPoE**，走 **`ether1`（2.5G 铜口接 ONT/光猫）**，MTU 1492 | +| LAN 模型 | **单 bridge + VLAN 过滤**：VLAN 66（多数端口）+ VLAN 55；VLAN 10 预留 | +| 网关地址 | **沿用 `192.168.66.254` / `192.168.55.254`**；重编址另立项目 | +| IPv6 | **保留对等**：PPPoE 上 DHCPv6-PD `/60` + 双 LAN SLAAC `/64` + IPv6 防火墙 | +| 端口转发 | 4 条 **原样迁入**（hass / transmission / ssh / openvpn）+ hairpin NAT | +| LAN55 成员 | **保持现状**（AC-Lite、Aqara 及原 LAN55 设备）不迁到 VLAN66 | +| 管理面 | SSH **仅密钥**（`zhiqiang`）；禁用默认 `admin`；**禁 Winbox/API/WebFig** 或仅限 LAN | +| 迁移方式 | 台面预配置（临时 `.253`）→ 维护窗（30–60 分钟）→ 验证 → ER-X 留作备件 | +| 固件/备份 | 当前稳定 RouterOS 7.x；上线前 `.backup` + 文本导出存离线 | +| 时区/NTP | `Asia/Shanghai` + 现有 NTP 服务器 | +| 安全 | PPPoE 口令、SSH 私钥、`zhiqiang` 口令**只存设备上**，不落本仓库 | + +--- + +## 3. 升级后的网络形态（拓扑图） + +### 3.1 目标物理拓扑（升级完成后） + +```text + Internet + │ PPPoE (ether1 2.5G, MTU 1492, IPv6 PD /60) + ▼ + ┌──────────────────────────────────────────────┐ + │ RB5009 (gw) RouterOS 7.x │ + │ ether1 = WAN (PPPoE) │ + │ bridge + vlan-filtering=yes │ + │ vlan66 = 192.168.66.254/24 (pvid 66) │ + │ vlan55 = 192.168.55.254/24 (pvid 55) │ + │ SFP+ = 空槽（未来 10G） │ + │ SSH-only 管理（仅 LAN） │ + └─────┬─────────┬──────────┬──────────┬────────┘ + │ pvid66 │ pvid66 │ pvid66 │ pvid55 + │ │ │ │ + gfw (.1) dns (.36) ubnt (.46) UAP-AC-Lite (.55.5) + PVE (.26) NAS/PC… U6 Lite Aqara (.55.248) + (.66.6) +``` + +端口角色以面板为准；下表是建议预留： + +| RB5009 端口 | 对端 | 模式 | +|---|---|---| +| `ether1` | ONT/光猫 | WAN，PPPoE | +| `ether2`–`ether8` | PVE/gfw、dns、ubnt、U6 Lite、NAS、PC、杂项 | access，pvid 66 | +| `ether9` | 原 LAN55 成员（AC-Lite、Aqara…） | access，pvid 55 | +| SFP+ `sfp-sfpplus1` | 未来 10G 核心 | 空槽 | + +> **禁止双上行：** 任一设备不得同时接旧 ER-X 与 RB5009（环路 / 双默认网关）。 + +### 3.2 逻辑网络 + +| VLAN | 子网 | 网关 / DHCP | 形态 | 成员 | +|---|---|---|---|---| +| **66** | `192.168.66.0/24` | RB5009 `vlan66` `.254` | 多数端口 access | gfw、dns、ubnt、U6、PVE、NAS、PC… | +| **55** | `192.168.55.0/24` | RB5009 `vlan55` `.254` | `ether9` access | AC-Lite、Aqara…（原 LAN55 全量） | +| 10（预留） | `192.168.10.0/24` | 未来（`gfw`） | 暂不配业务 | 升级专用 SSID（后续项目） | + +- 客户端 DNS：DHCP 仍下发 **`192.168.66.36`**（AdGuard Home）。 +- UniFi Inform 仍为 `http://192.168.66.46:9080/inform`。 +- LAN66 ↔ LAN55 互通由 RB5009 三层转发（沿用现网默认可达语义，防火墙不设隔离边界）。 + +### 3.3 流量怎么走 + +```text +同 VLAN（NAS ↔ PC）： 客户端 → RB5009 端口 → bridge（二层交换，1G） +跨 VLAN（66 ↔ 55）： 客户端 → RB5009 路由（vlan66 ↔ vlan55，1G） +上网： 客户端 → RB5009 → PPPoE → Internet（限速 = 线路；RB5009 fasttrack 去掉 ER-X ~900M 天花板） +旁路由： 默认网关仍 `.254`；显式代理走 gfw（不变） +未来 VLAN10： U6 trunk → RB5009 →（转发 VLAN10）→ gfw（后续项目） +``` + +### 3.4 性能预期（诚实边界） + +| 场景 | 预期 | +|---|---| +| WAN / PPPoE | 线路速率以内；若线路 >1G，RB5009 fasttrack 可跑满（ER-X 受 900M 限制） | +| 同 VLAN 交换 | **1G**（无 SE5420；RB5009 8×1G） | +| 跨 VLAN | 1G 级三层 | +| SFP+ 空槽 | 不等于已是 10G | + +--- + +## 4. 分阶段实施计划 + +### 阶段 0：采购前核验 + +1. 确认 RB5009 revision、保修、零售渠道、RouterOS 当前稳定版本号（建议 7.x 最新 stable）。 +2. 确认硬件：1× 2.5G PoE-in（ether1）、8× 1G、1× SFP+、1GB RAM。SFP+ 模块本次不买。 +3. 盘点线缆与对端：ONT ↔ ether1；原 LAN55 设备清单（AC-Lite、Aqara…）及原 ER-X `switch0` 接线。 + +### 阶段 1：离线初始化（台面） + +1. 仅电源 + 隔离管理本。设置身份、时区 `Asia/Shanghai`、NTP。 +2. 建 `zhiqiang` 管理用户（**密钥登录，禁密码**）；**删除/禁用默认 `admin`**。 +3. 建 bridge + VLAN 66/55 + 端口模板（`ether2–8` pvid66，`ether9` pvid55）；**临时地址 `.253`**（不与 ER-X `.254` 冲突）。 +4. 配 WAN PPPoE（ether1）、默认路由、NAT masquerade、4 条端口转发 + hairpin、防火墙（input/forward）、MSS clamp、IPv6 PD + SLAAC + IPv6 防火墙。 +5. 配 DHCP 池 `.38–.243`、24h 租约、DNS `.36`、UniFi Inform 选项、**静态映射全量照搬**。 +6. 管理面收口：**禁 Winbox（8291）/ API（8728）/ WebFig（80/443）**；SSH 仅限 LAN66/55。 +7. `system backup save` + `/export`，导出到离线存储（**不落仓库**）。 + +**参考 RouterOS 配置骨架**（口令/密钥用占位符；落地前逐一核对）： + +```text +# 身份 / 时区 / NTP +/system identity set name=gw +/system clock set time-zone-name=Asia/Shanghai + +# WAN +/interface ethernet set ether1 name=wan +/interface pppoe-client add name=pppoe0 interface=wan user= \ + password= add-default-route=yes use-peer-dns=no \ + mtu=1492 mru=1492 + +# bridge + VLAN +/interface bridge add name=bridge66 vlan-filtering=yes +/interface bridge port add bridge=bridge66 interface=ether2 pvid=66 +... # ether3..ether8 同 pvid 66 +/interface bridge port add bridge=bridge66 interface=ether9 pvid=55 +/interface bridge vlan add bridge=bridge66 vlan-ids=66 tagged=bridge66 +/interface bridge vlan add bridge=bridge66 vlan-ids=55 tagged=bridge66 +/interface vlan add name=vlan66 interface=bridge66 vlan-id=66 +/interface vlan add name=vlan55 interface=bridge66 vlan-id=55 + +# 地址（台面先用 .253，维护窗切 .254） +/ip address add address=192.168.66.254/24 interface=vlan66 +/ip address add address=192.168.55.254/24 interface=vlan55 + +# NAT masquerade + 端口转发 + hairpin +/ip firewall nat add chain=srcnat out-interface=pppoe0 action=masquerade +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=8123 \ + action=dst-nat to-addresses=192.168.55.11 to-ports=8123 +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=51413 \ + action=dst-nat to-addresses=192.168.66.51 to-ports=51413 +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=udp dst-port=51413 \ + action=dst-nat to-addresses=192.168.66.51 to-ports=51413 +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=5822 \ + action=dst-nat to-addresses=192.168.66.36 to-ports=22 +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=udp dst-port=5822 \ + action=dst-nat to-addresses=192.168.66.36 to-ports=22 +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=tcp dst-port=1194 \ + action=dst-nat to-addresses=192.168.66.32 to-ports=1194 +/ip firewall nat add chain=dstnat in-interface=pppoe0 protocol=udp dst-port=1194 \ + action=dst-nat to-addresses=192.168.66.32 to-ports=1194 +/ip firewall nat add chain=srcnat connection-nat-state=dstnat action=masquerade # hairpin + +# 防火墙（input / forward），顺序很重要：SSH 放行必须早于默认 drop +/ip firewall filter add chain=input connection-state=established,related action=accept +/ip firewall filter add chain=input connection-state=invalid action=drop +/ip firewall filter add chain=input protocol=icmp action=accept +/ip firewall filter add chain=input in-interface=pppoe0 action=drop comment="drop WAN in" +/ip firewall filter add chain=input protocol=tcp dst-port=22 \ + src-address=192.168.66.0/24,192.168.55.0/24 action=accept comment="mgmt SSH" +/ip firewall filter add chain=input action=drop comment="drop other input" +/ip firewall filter add chain=forward connection-state=established,related action=fasttrack-connection \ + hw-offload=yes +/ip firewall filter add chain=forward connection-state=established,related action=accept +/ip firewall filter add chain=forward connection-state=invalid action=drop +/ip firewall filter add chain=forward in-interface=pppoe0 action=drop comment="drop WAN fwd" +/ip firewall filter add chain=forward action=accept comment="accept LAN fwd" + +# MSS clamp（PPPoE MTU 1492 → 1452；ER-X 旧值 1412 偏小，验证后按标准值收敛） +/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \ + tcp-mss=1400-65535 action=change-mss new-mss=1452 passthrough=yes + +# IPv6（PD /60 + SLAAC /64） +/ipv6 dhcp-client add interface=pppoe0 request=prefix pool-name=pd6 \ + pool-prefix-length=60 add-default-route=yes +/ipv6 address add from-pool=pd6 interface=vlan66 address=::1 adverts=yes +/ipv6 address add from-pool=pd6 interface=vlan55 address=::1 adverts=yes +# /ipv6 firewall filter 参照 IPv4：established/related accept、invalid drop、 +# icmpv6 accept、pppoe0 in drop、默认 drop，forward 同构 + +# DHCP（池 / DNS / Inform / 静态映射全量照搬 ER-X） +/ip pool add name=pool66 ranges=192.168.66.38-192.168.66.243 +/ip pool add name=pool55 ranges=192.168.55.38-192.168.55.243 +/ip dhcp-server add name=dhcp66 interface=vlan66 address-pool=pool66 lease-time=1d +/ip dhcp-server add name=dhcp55 interface=vlan55 address-pool=pool55 lease-time=1d +/ip dhcp-server network add address=192.168.66.0/24 gateway=192.168.66.254 \ + dns-server=192.168.66.36 +/ip dhcp-server network add address=192.168.55.0/24 gateway=192.168.55.254 \ + dns-server=192.168.66.36 +# 静态映射：从 ER-X 导出后逐条 /ip dhcp-server lease add ... +# UniFi Inform：DHCP option 43（hex 编码为 http://192.168.66.46:9080/inform）， +# 或依赖已 adopt AP 的 set-inform；与现网 ER-X 行为保持一致。 +``` + +### 阶段 2：上台预验证（ER-X 仍在线） + +1. 将 RB5009 `ether2` 接入现有 LAN66 网段（管理本同网段），SSH 登录 `.253`。 +2. 全配置复查：VLAN 表、防火墙规则顺序（SSH 在 drop 前）、NAT、路由、IPv6。 +3. **暂不启用 RA/DHCP**（避免与 ER-X 冲突）。预验证 `.253` 可达、SSH 密钥生效、`zhiqiang` 无密码。 +4. 确认 ER-X 当前配置**已备份并保存**（作为回滚依据；`show configuration commands` 过滤敏感行）。 + +### 阶段 3：维护窗切换（约 30–60 分钟） + +1. 变更 RB5009 `vlan66`/`vlan55` 地址 `.253 → .254`。 +2. **下电 ER-X**（保留原接线与配置，不作任何改动）。 +3. ONT 线从 ER-X `eth4` 移到 RB5009 `ether1`。 +4. 观察 PPPoE 拨号：`/interface pppoe-client monitor pppoe0` 直至 `status=established`；确认 WAN IP 与默认路由。 +5. 验证清单（见第 5 节），全绿才算完成。 + +### 阶段 4：上线收口 + +1. 再确认管理面：禁 Winbox/API/WebFig、SSH 仅密钥、默认 `admin` 已除。 +2. 更新固件/补丁至已核定的稳定版；重新导出备份（`.backup` + 文本）存离线。 +3. ER-X 下电收纳为**已配置备件**，把其接线与角色记录到 `hosts/gw.md` 备份节。 + +### 阶段 5（后续，另立项目） + +**时序确认：** VLAN10 升级专用 Wi-Fi 是 RB5009 上线**稳定之后**的独立项目，不并入本次维护窗。 + +- 4 条端口转发是否仍需的审计。 +- 网关重编址（`.254 → 其它`）决策。 +- **VLAN10 升级专用 SSID → `gfw`（可行性审查，2026-08-09）**。 +- 迁移后同步本仓库事实文档：`hosts/gw.md`、`docs/lan-overview.md`、`inventory/hosts.md`、`AGENTS.md` 快速地图。 + +### 阶段 5 附：VLAN10 可行性审查 + +**结论：** 换 RB5009 后**物理上可行**，但 RB5009 只解决「交换机侧」路径；PVE 宿主机到 `gfw` 虚拟机这一段（此前判定为不可行的关键缺口）仍必须单独打通。 + +**为什么今天在 AP 上做 VLAN10 会坏 66 网：** + +U6 接的是 ER-X `eth0`（untagged access，且 ER-X 交换机 `vlan-aware` 关闭）。给 SSID 打 VLAN10 后，U6 把客户端帧打成 **802.1Q tag 10** 发往 ER-X；ER-X 端口是普通 access、不处理 tag，VLAN10 帧被当作无标记帧**漏进 66 广播域**；全网只有一个 DHCP（ER-X），VLAN10 客户端拿到 `192.168.66.x`，泄漏的广播/发现干扰 66 网。这是「无 802.1Q 传输路径」的必然结果，不是 AP 配置问题。 + +**RB5009 下实现需要 3 个前提：** + +1. **RB5009 bridge 增加 VLAN10 转发：** + `/interface bridge vlan add bridge=bridge66 vlan-ids=10 tagged=,` + 只在这两个口 tagged。**不要**在 RB5009 上给 VLAN10 配 IP / DHCP（gfw 才是网关与唯一 DHCP）。 +2. **PVE 宿主机路径（必须做，RB5009 解决不了这一段）：** + PVE 物理上联口透传 tagged VLAN10；`gfw` 虚拟机有一块 VLAN10 可达的网卡 + （如 vmbr0 开 `vlan_filtering` + 给 gfw 加第二块 pvid 10 的 NIC，或 VM 内 `eth0.10`）。 + 这是此前「无法实现」的同一处缺口，需在 PVE/vSwitch 层单独验证。 +3. **`gfw` 侧：** VLAN10 网卡 `192.168.10.1/24` + DHCP（`192.168.10.0/24`）+ 出 66 口 + masquerade。RB5009 无需到 `192.168.10.0/24` 的路由（gfw SNAT 后源地址即 66 网段）。 + +**两个注意点：** + +- **单 DHCP 原则：** VLAN10 上唯一 DHCP 是 gfw；RB5009 不得在 VLAN10 提供 DHCP。 +- **设计确认：** 升级 SSID 客户端走 gfw 网关后，DNS 为 gfw 的 dnsmasq→clash（7874）， + **不是** AdGuard `.36`——这是「被代理网络」的预期行为，需接受。 + +### 阶段 5 附：PVE 上 VLAN10 透传实现（调研 2026-08-09） + +官方 wiki + 多个社区案例支持两种模型，核心原则是 **「一层只拥有一个 tag」**——要么 PVE 拥有 +access VLAN，要么 OpenWrt 拥有 trunk，**不能在同一张 NIC 上两层都做**。 + +**方案 A（推荐）：PVE 拥有 access VLAN，gfw 加第二块 virtio 网卡** + +1. `vmbr0` 开 vlan-aware（`/etc/network/interfaces`）： + + ```text + auto vmbr0 + iface vmbr0 inet static + address 192.168.66.26/24 + gateway 192.168.66.254 + bridge-ports eno1 + bridge-stp off + bridge-fd 0 + bridge-vlan-aware yes + bridge-vids 10 # 至少含 10；常见默认 2-4094 + ``` + +2. gfw VM 添加 `net1: virtio,bridge=vmbr0,tag=10`。VM 内该网卡是**无标记**接口 + （已落在 VLAN10 广播域），**不要再建同名 8021q 子接口**。 +3. 现有 `eth0`（native/untagged = VLAN66）不动，gfw 原有角色不变。 +4. PVE 物理上联口（PVE→RB5009）改为 **trunk：native 66 + tagged 10**。 +5. OpenWrt 内：新网卡 `192.168.10.1/24` + DHCP（`192.168.10.0/24`）+ 独立 firewall zone→wan masq。 + +**方案 B：OpenWrt 拥有 trunk（单 NIC 多 VLAN）** + +- `vmbr0` vlan-aware；VM NIC **不加 tag**；trunk 原样进 VM；OpenWrt 内建 `8021q` 设备 + （`eth0.10`，x86/virtio 用 `option type '8021q'`，不要套用 DSA 教程）。物理上联 trunk。 +- 更灵活（一块网卡多 VLAN），是 router VM 的常见做法，但需要 OpenWrt 8021q 配置， + 且方案 A 对现有单网卡 gfw 改动更小。 + +**RB5009 侧配套（U6 口 + PVE 口都做成 trunk）：** + +```text +/interface bridge port add bridge=bridge66 interface= pvid=66 +/interface bridge port add bridge=bridge66 interface= pvid=66 +/interface bridge vlan add bridge=bridge66 vlan-ids=66 tagged=bridge66 untagged=,,<其余66口> +/interface bridge vlan add bridge=bridge66 vlan-ids=55 tagged=bridge66 untagged= +/interface bridge vlan add bridge=bridge66 vlan-ids=10 tagged=, +``` + +VLAN10 在 RB5009 上**纯二层桥接**（U6 ↔ PVE），三层由 gfw 承担；RB5009 无 VLAN10 IP/DHCP。 + +**常见坑（社区高复发）：** + +- **双标签：** PVE 设了 `tag=10` 又在 OpenWrt 里建 `eth1.10` → 一帧被两层改两次。 +- **native VLAN 不一致：** trunk 上无标记帧被两端当成不同 VLAN → DHCP 消失 / 拿到错网段 + （正是你之前在 AP 上打 VLAN10 坏 66 网的同类故障）。 +- **bridge 未 vlan-aware：** tagged 帧进 host 后在 bridge 过滤层消失。 + +**诊断命令：** + +```bash +# PVE host +bridge vlan show +ip -br link +tcpdump -eni <上联口> # 帧是否到物理口 +tcpdump -eni vmtapXXXXXX # 帧是否到 VM tap +# OpenWrt guest +ip -d link show +logread -e netifd +``` + +**参考案例：** + +- PVE 官方 wiki — Network Configuration / VLAN 802.1Q（三种模式 + vlan-aware bridge）： + +- 「OpenWrt VM on Proxmox」设计（trunk vs access 谁拥有 tag、双标签坑）： + +- PVE 论坛「Tagged and Untagged VLAN」（`bridge-vlan-aware yes` + `bridge-vids` 解法）： + +- OpenWrt 论坛 guest WiFi tagged VLAN 案例（`vmbr0.3`→VM 第三网卡；guest 拿到错误网段的 + 同型故障，最终归因在 PVE/host 侧）： + +> **PVE host 改动风险：** 给 `vmbr0` 开 vlan-aware 是对宿主机网络栈的修改，有管理面断连风险； +> 需在维护窗内用控制台/独立带外通道进行，先 `ifreload -a`（PVE7+ 的 ifupdown2 支持热应用）， +> 保留原配置作回滚。 + +--- + +## 5. 验收清单（「网络算正常」的样子） + +1. 管理面：`zhiqiang` 密钥 SSH 可从 LAN66/55 登录；默认 `admin` 禁用；Winbox/API 不可达；`.254` 管理可达。 +2. VLAN：客户端取得正确网段（`.66.x` / `.55.x`），默认网关 `.254`，DNS `.36` 可用。 +3. 互联网：PPPoE 已建立；IPv4 外网通；端口转发逐条从公网验证（hass 8123、transmission 51413、ssh 5822→.36:22、openvpn 1194）。 +4. IPv6：两 VLAN 拿到 SLAAC `/64`，默认路由存在，外部 IPv6 可达；IPv6 防火墙未阻断必要 ICMPv6/DHCPv6。 +5. 本地服务：跨 VLAN（`.55.x` ↔ `.66.x`）互通；AdGuard Home、UniFi 控制器、`gfw` 旁路由行为与升级前一致。 +6. UniFi：U6 Lite（`.66.6`）与 UAP-AC-Lite（`.55.5`）在控制器显示 **Connected**；Inform 未变 `:9080`。 +7. 无环路、无双默认网关；端口协商与错误计数正常。 +8. 备份（`.backup` + 文本导出）已离线保存；ER-X 已下电收纳。 + +--- + +## 6. 回滚语义 + +任一阶段失败：**停手**。 + +- **维护窗内失败（PPPoE 未起 / 客户端不通 / 防火墙锁死）：** + 1. 下电 RB5009。 + 2. ONT 线插回 ER-X `eth4`。 + 3. 给 ER-X 上电 → 服务在数分钟内恢复。 + 4. 不要在故障中改 ER-X 的 WAN、DHCP、网关地址或 SSH 策略。 +- **维护窗成功后** ER-X 只是备件；后续 VLAN10 失败只撤 SSID/VLAN 绑定，主 SSID 与 `.254` 路径不动。 + +--- + +## 7. 安全与记录 + +- **本仓库永不记录**：PPPoE 口令、`zhiqiang` 口令、SSH 私钥、RouterOS 备份（含口令/密钥）。 +- 每次实质性变更（切换、回滚、加固）完成后，在 Linear **`vps` 项目**记录 scope / action / verification / 遗留 follow-up（本次先不建 issue，待执行时补）。 +- SSH 与访问策略变更遵循仓库「SSH access safety」流程：ER-X 会话保持为回滚路径，新密钥登录验证成功前不关闭旧通道。 + +--- + +## 8. 参考 + +- 现网地图：[lan-overview.md](lan-overview.md) +- ER-X 现状：[edgerouter-x-configuration.md](edgerouter-x-configuration.md)、[hosts/gw.md](../hosts/gw.md) +- UniFi：[unifi-network.md](unifi-network.md)、[hosts/ubnt.md](../hosts/ubnt.md) +- `gfw`：[hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) +- 作废方案（**不再实施**）：[lan-erx-se5420-network.md](lan-erx-se5420-network.md)、[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md) +- MikroTik RB5009 官方：、RouterOS v7 手册 diff --git a/docs/lan-se5420-deployment-guide.md b/docs/lan-se5420-deployment-guide.md new file mode 100644 index 0000000..67018fe --- /dev/null +++ b/docs/lan-se5420-deployment-guide.md @@ -0,0 +1,401 @@ +# SE5420 核心交换机升级实践指南（两步实施） + +**状态：** SE5420 **已采购**，待实施。本文是真实可操作、可验证的升级实践文档； +取代早期「规划说明」性质文档中的实施细节（[lan-erx-se5420-network.md](lan-erx-se5420-network.md)、 +[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md) 保留作拓扑/设计参考）。 + +**硬件：** TP-Link **TL-SE5420**（16× 2.5G RJ45 + 4× 10G SFP+，无 PoE），440×180×44 mm（1U）。 +**架构：** ER-X **保留**为唯一网关（PPPoE/NAT/防火墙/DHCP/双网段三层）；SE5420 纯 L2 核心； +`gfw` 旁路由（OpenClash）；VLAN10 升级专用 SSID 走 gfw 网关。 + +--- + +## ⚠️ 两步实施总览（2026-08-09 确认） + +**第一步（本次）：只做 55/66 主网。** SE5420 初始化、ER-X 上联、PVE/AP/设备迁移、 +验收稳定。**全程不建 VLAN10、不给口 2/3 加 tagged 10、不改 gfw、不改 UniFi `ubnt-upg`。** + +**第二步（第一步稳定 ≥1 天后，独立窗口）：整体做 VLAN10。** +SE5420 加 VLAN10 + 口 2/3 tagged 10 → gfw 补齐 → UniFi 改 Third-party Gateway → 启用 SSID → 验证。 + +> 分离原则：**第一步与第二步不共享任何配置动作**，第一步完成后网络与升级前 +> 语义一致（仅同 VLAN 交换变 2.5G）；VLAN10 全部动作集中在第二步，回滚互不牵连。 + +| 步骤 | 范围 | Done 判定 | +|---|---|---| +| **第一步** | SE5420 台面配置(66/55) → ER-X 上联 → 迁移 → 稳定 | 第 7 节验收前 7 条全绿 | +| **第二步** | VLAN10（SE5420 + gfw + UniFi + SSID） | 第 7 节第 8 条 + 验证链全通 | + +--- + +## 0. 已验证的现状事实（2026-08-09 只读核实） + +> 以下事实已通过 SSH/UniFi API 实测确认，直接决定下文步骤： + +| 项 | 实测结果 | +|---|---| +| PVE 物理网卡 | **双网卡**：`enp1s0`→vmbr0(LAN66 .26)，`enp2s0`→vmbr1(LAN55 .26) | +| PVE bridge | `vmbr0` **非 vlan-aware（flat bridge）** → **天然透传 tagged 帧**给所有 VM（含 gfw eth0） | +| PVE VM 清单 | 120 `pihole`=**dns/.36**（AdGuard+Mihomo，vmbr0）、140 `gfw`(vmbr0+vmbr1)、160 `ubnt`(vmbr0)、180 `haos`(vmbr1/LAN55)、100 `gateway`(停) | +| **dns 位置** | **dns（`.36`）是 PVE 上 VM 120，非独立物理机** → 不占 SE5420 口 | +| **transmission 位置** | **transmission 是 NAS(FreeNAS) 内 jail（`.51`）** → 不占 SE5420 口 | +| gfw 虚拟网卡 | `net0`→vmbr0(66)、`net1`→vmbr1(55) | +| gfw 内部 | `eth0.10`=192.168.10.1/24 已配；DHCP(100-250)已配；fw4 `ubunt_upg` 链全建；OpenClash 全局 TPROXY 在 | +| gfw 缺口 | **无 `ubunt_upg→wan` 转发、无 masq**；zone `forward=REJECT` → VLAN10 现在上不了网（**第二步才补**） | +| UniFi | `ubnt-upg` 网络(VLAN10, dhcp 关) + `ubnt-upg` SSID 已存在，**且 SSID 当前 enabled（泄漏风险！）**；网络 purpose=corporate，需改 Third-party Gateway（**第二步才改**） | +| U6 Lite | `.66.6`，有线上联，接 ER-X eth0（untagged access） | +| UAP-AC-Lite | `.55.5`，有线上联 | +| PVE 防火墙 | 无任何自定义规则，未拦 tagged 帧 | + +--- + +# 第一步：SE5420 + 55/66 主网 + +## 1. 目标拓扑与端口规划（第一步范围） + +```text + Internet + │ PPPoE (pppoe0) + ▼ + ┌───────────────────────────────────────────┐ + │ ER-X (gw) eth0=LAN66 .254 switch0=LAN55 .254 │ + └──────┬──────────────────┬─────────────────┘ + │ access VLAN66 │ access VLAN55 + │ │ + ▼ ▼ + ┌──────────────────────────────────────────────────┐ + │ TL-SE5420 核心（纯 L2，VLAN-aware） │ + │ SFP+ 空槽（未来 10G） │ + └─┬──────┬───────┬──────┬──────┬──────┬───────────┘ + │ │ │ │ │ │ + PVE PVE U6 AC-Lite dns/NAS/PC + enp1s0 enp2s0 Lite (55) (access 66) + access access access + 66 55 66 +``` + +### 端口角色表（第一步：全部为 66/55 access；**不含 VLAN10**） + +SE5420 前面板为 **8 口一排、共两排**（每排 8×RJ45，右侧 4×SFP+）。采用**按 VLAN 分排**： +**上排（口 1–8）= LAN66**，**下排（口 9–16）= LAN55**。每排首位是该 VLAN 的 ER-X 上联。 + +> 端口编号假定 TP-Link 常规布局（上排 1–8、下排 9–16）；**接线前先对照实物面板标注编号**。 + +| SE5420 口 | 对端 | 第一步模式 | PVID | 成员 VLAN | +|---|---|---|---|---| +| **上排 1** | ER-X `eth0`（66 上联） | access | 66 | untagged 66 | +| 2 | PVE `enp1s0`（承载 gfw/dns/ubnt VM） | access | 66 | untagged 66 | +| 3 | U6 Lite | access | 66 | untagged 66 | +| 4 | NAS/FreeNAS（第 1 口，含 transmission jail） | access | 66 | untagged 66 | +| 5 | NAS/FreeNAS（第 2 口，LACP 预留） | access | 66 | untagged 66 | +| 6 | windy-pc (.99) / hp-nas (.32) | access | 66 | untagged 66 | +| 7–8 | LAN66 预留 | access | 66 | untagged 66 | +| **下排 9** | ER-X `switch0` 成员口（55 上联） | access | 55 | untagged 55 | +| 10 | PVE `enp2s0`（承载 haos VM） | access | 55 | untagged 55 | +| 11 | UAP-AC-Lite | access | 55 | untagged 55 | +| 12 | 隔壁房间上联（IoT 设备） | access | 55 | untagged 55 | +| 13 | 打印机（未来） | access | 55 | untagged 55 | +| 14–16 | LAN55 预留 | access | 55 | untagged 55 | +| SFP+ 1–4 | 未来 10G | 空槽 | — | — | + +> **第二步才变更（本步不动）**：口 2、口 3 从 access 66 改为 **trunk（untagged 66 + tagged 10）**， +> 并新建 VLAN10。第一步**不要**建 VLAN10、**不要**在任何口上 tagged 10。 + +> **哪些设备不占 SE5420 口（都是 PVE 上的 VM，走 PVE 物理网卡）：** +> - **dns / AdGuard Home / Mihomo（`.36`）** = PVE VM 120 `pihole`（vmbr0） +> - **ubnt 控制器（`.46`）** = PVE VM 160（vmbr0） +> - **gfw（`.1`）** = PVE VM 140（vmbr0 + vmbr1） +> - **haos / Home Assistant（`.55.11`）** = PVE VM 180（vmbr1/LAN55） +> - **transmission（`.51`）** = NAS(FreeNAS) 内 jail，走 NAS 网口 + +> **第一步关键约束：** +> - 全部口为 66/55 access；**不建 VLAN10**。 +> - **不要**向 ER-X 送任何 VLAN10 tag（本步根本没有 VLAN10）。 +> - NAS 若启用 **LACP 聚合**：口 4/5 建端口聚合组（802.3ad），PVID 66；SE5420 需 `L2 → LAG` 配置。 +> - 禁止同一设备同时接旧路径与新核心（环路）。 + +--- + +## 2. 第一步·阶段 0：开工前检查（一次性） + +1. SE5420 开箱：核对型号、前面板（模式切换按键 / 指示灯 / **Type-C Console 口** / 16×2.5G RJ45 / 4×SFP+ / 1×USB）。 +2. **固件**：下载最新官方固件并升级（V1.0 平台）。操作： + - 下载页：TP-LINK 官网 → TL-SE5420 产品页 → **资源下载** tab → **升级软件** 分类。 + - 直达：`https://www.tp-link.com.cn/product_2899.html?v=download`（升级软件区）。 + - 已知版本：**TL-SE5420 V1.0 升级软件 20230908_1.0.0**（2023-09-08 发布，以页面当前列出的为准）。 + - 升级入口：登录 WEB 后 **系统 → 软件升级 → 选择文件 → 升级**（升级期间勿断电）。 + - 注意核对设备底部标签的 **硬件版本 V1.0** 与固件配套；V1.x 别刷 V2 版（若后续出现）。 + - 升级完确认版本号，再进入后续配置。 +3. 准备一条 Type-C 串口线（Console 本地登录）或普通网线（WEB 登录）；一台**隔离管理本**（不用接现有 66 网）。 +4. **禁用 `ubnt-upg` SSID**（UniFi 控制台 → WiFi → `ubnt-upg` → 关 enable）。它在无路径状态下已经泄漏 tag10 到 66 网，先止血。记录 SSID 原设置以便第二步回滚。 + > 这是**唯一**在第一步就涉及 VLAN10 的动作——目的只是止血，与第二步的实施无关。 +5. 备份当前 ER-X 配置（过滤敏感行），并给 `hosts/gw.md`、`docs/lan-overview.md` 留改前快照。 + +--- + +## 3. 第一步·阶段 1：离线初始化 SE5420（台面，不接生产） + +> 本阶段细节来自官方《TL-SE5420 安装手册》V1.0（2023）与 Omada 官方 VLAN 配置指南。 + +### 3.1 首次登录 + +**WEB 登录（推荐，无需串口驱动）：** +1. 管理本网线接 SE5420 **任意 RJ45 业务口**；管理本静态 IP 设为 `10.18.18.10/24`，网关暂留空。 + > **默认业务口 IP 是 `10.18.18.251`**（非 192.168.0.1，勿凭家用路由经验）。 +2. 浏览器访问 `http://10.18.18.251`。 +3. 首次登录行为： + - **WEB**：要求**设置用户名和密码**（出厂无默认口令，直接创建），创建后进入管理界面。 + - **Console/Telnet/SSH**：官方《Accessing the Switch》指出默认账号为 **`admin/admin`**（首次登录后立即改密）。 + > 渠道默认值可能不同，以实物为准：若 WEB 已设口令，CLI 用它登录；若尚未设置，尝试 `admin/admin`。 + +**Console 本地登录（可选，WEB 不可用时兜底）：** +1. 电脑装「TP-LINK USB 串口驱动程序」（官网下载或随机光盘）。 +2. 终端仿真程序参数：**波特率 38400**、数据位 8、校验无、停止位 1、流控无。 +3. 回车出现 `TL-SE5420>` 提示符即登录成功；输入 `enable` 进特权模式。 + +### 3.2 基础安全设置 +1. 改强口令（不落仓库）；设时区 `Asia/Shanghai`、NTP。 +2. **关 Telnet/HTTP**；保留 HTTPS + SSH： + - 关 Telnet：GUI `Security → Access Security → Telnet Config`，关闭 Telnet；或 CLI `telnet disable`。 + - 关 HTTP：`Security → Access Security → HTTP Config`，关闭 HTTP server。 + - 开 SSH：`Security → Access Security → SSH Config`，Enable SSH（默认端口 22）。 +3. **关云管理**（商云 `smbcloud.tp-link.com.cn` 全局开关不开启；云管后续单独评估）。 +4. **保存配置**——安装手册强调「配置实时生效，但断电前必须点保存配置」，每次改完都点保存。 + +### 3.2b SSH 登录 SE5420（覆盖确认） + +> 参考官方《Accessing the Switch》与《OpenSSH 7.0+ 登录》指南。SSH 默认端口 **22**， +> 两种认证：口令模式（默认 `admin/admin`，改后为自定义口令）、密钥模式（PuTTY Key Generator 生成）。 + +**在 WSL/管理本上 SSH 登录：** +```bash +ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 \ + -o HostKeyAlgorithms=+ssh-rsa,ssh-dss \ + admin@192.168.66.253 +# 输入口令后进 User EXEC 模式，再输入 enable 进特权模式 +``` + +> ⚠️ **OpenSSH 7.0+ 兼容性（官方指南）**：TP-Link 交换机旧算法默认被新版 OpenSSH 禁用， +> 需在客户端 `~/.ssh/config` 为 `192.168.66.253` 显式启用： +> ```text +> Host 192.168.66.253 +> KexAlgorithms +diffie-hellman-group1-sha1 +> HostKeyAlgorithms +ssh-rsa +> PubkeyAcceptedAlgorithms +ssh-rsa +> ``` +> 若 `ssh` 仍报算法协商失败，用 `-o` 逐项追加；具体以本机 OpenSSH 版本提示为准。 + +**关 SSH（如不需 CLI 远程管理）**：GUI `SSH Config` 关闭，或 CLI `no ip ssh server`。 + +**保存（CLI）**：`copy running-config startup-config`。 + +### 3.3 管理地址与 VLAN（第一步：只建 66/55） + +> 菜单路径来自 TP-Link 官方《Omada 802.1Q VLAN 配置指南》与《管理 VLAN 指南》（SE5420 同平台）。 +> 具体菜单名以设备 WEB 界面为准。**本步不建 VLAN10。** + +**1. 管理地址**（官方：`L3 FEATURES → Interface`，编辑 VLAN 接口的 IPv4；不是 System）： + - 改为静态 **`192.168.66.253/24`**，网关 **`192.168.66.254`**（池外地址，无冲突）。 + - 默认网关（官方：`L3 FEATURES → Static Routing → IPv4 Static Routing Config`）： + 目的 `0.0.0.0`、掩码 `0.0.0.0`、下一跳 `192.168.66.254`、距离 `1`。 + - **管理 VLAN 限制**（官方指南）：`Security → Access Security → Access Control` 建 IP 规则， + 接口 HTTP/HTTPS，源 `192.168.66.0/24`——仅管理 VLAN 内主机可访问 GUI。 + - ⚠️ 改完管理地址后，管理本网卡要改回 `192.168.66.x` 同网段（或 DHCP）才能继续登录。 + +**2. 建立 VLAN**（`L2 Features → VLAN → 802.1Q VLAN → VLAN Config`，**只建 66 / 55**）： + - 每个 VLAN 页内把端口按「tagged / untagged」勾选进成员： + - **66**：untagged 口 1、2、3、4、5、6、7、8（本步全为 access） + - **55**：untagged 口 9、10、11、12、13、14、15、16 + +**3. 端口 PVID**（`L2 Features → VLAN → 802.1Q VLAN → Port Config`，逐口设 PVID）： + - 口 1–8：PVID **66**（access） + - 口 9–16：PVID **55**（access） + - 逐口核对 tagged/untagged 归属，避免漏配。 + +**4. 关闭一切 L3 能力**：不开三层接口/SVI、不配静态路由、不开 DHCP Server/Relay；SE5420 只做二层。 + +**5. 生成树**（`L2 Features → Spanning Tree`）：启用 RSTP（或 MSTP），STP 优先级设低（如 4096）——即便拓扑无环也兜底。 + +**6. 保存配置**：改完立即保存（`System → Save Config` 或右上角保存按钮），否则断电丢失。 + +**7. 导出配置备份**（离线保存，**不进本仓库**）。 + +### 3.4 台面验证（未接生产） +1. 管理本接上排任意口（access 66）：应能访问 `192.168.66.253`，且仅限 66 网段。 +2. 查看端口状态全 up；确认口 1–8 PVID=66、口 9–16 PVID=55（`show vlan` / 对应 CLI）。 +3. 确认**没有** VLAN10（本步应无 VLAN10 表项）。 + +--- + +## 4. 第一步·阶段 2：维护窗迁移（30–60 分钟） + +> 原则：**先断旧、后接新**；每次移动一根线后立即验证；全程保留 ER-X 管理会话与 PVE 会话。 +> **本步所有口都是 66/55 access，不涉及 VLAN10。** + +### 4.0 准备 +- 打印第 1 节端口表；给所有现网线缆贴标签。 +- 保留现有 ER-X 原接线不动（作为回滚路径）**直到最后一步**。 +- 通知中断窗口；确认 ER-X 管理 SSH 与 PVE 管理 SSH 两个会话均可用（`BatchMode=yes` 测试）。 + +### 4.1 建立 ER-X ↔ SE5420 两条上联 +1. 接 SE5420 **上排口 1 ↔ ER-X `eth0`**（LAN66 上联）。 + - 此刻 ER-X eth0 可能还连着旧设备 → **先拔旧设备**，再接口 1（避免 eth0 同时连 SE5420 与旧路径形成环路）。 + - 验证：管理本（或从 66 网）ping `192.168.66.253`（SE5420）、`192.168.66.254`（ER-X）、外网。 +2. 接 SE5420 **下排口 9 ↔ ER-X `switch0` 某个成员口**（LAN55 上联）。 + - 同样先拔该口旧接线。 + - 验证：从 55 网 ping `192.168.55.254`、`192.168.66.46`（控制器）。 + +### 4.2 迁移 PVE（双网卡） +1. PVE `enp1s0` → SE5420 **口 2（access 66）**。 +2. PVE `enp2s0` → SE5420 **口 10（access 55）**。 +3. 验证（SSH PVE）：`ip -br addr` 显示 `.66.26`、`.55.26`；`ping 192.168.66.254`；`ping 192.168.55.254`。 +4. 确认 gfw VM 两块网卡都活着：SSH gfw → `ip -br addr` → eth0(.66.1)、eth1(55)。 + +> PVE 是宿主，**只要 PVE 活着，gfw/dns/ubnt 虚拟机就不会断**；这是迁移 PVE 放在最先的原因。 + +### 4.3 迁移 AP 与接入设备 +1. U6 Lite → SE5420 **口 3（access 66）**。本地取电，网线只走数据。 + - 验证：U6 拿到 `.66.6`，UniFi 控制器显示 Connected；Inform 仍 `:9080`。 +2. UAP-AC-Lite → SE5420 **口 11（access 55）**。 + - 验证：`.55.5` Connected。 +3. **隔壁房间上联 → SE5420 口 12（access 55）**。 + - 对端是 **IoT 设备**（未来会有打印机）。迁移前确认那端是单台设备还是小交换机；若对端已是一台设备，直接拔 ER-X switch0 旧口、接口 12 即可。 + - 验证：隔壁房间 IoT 设备恢复地址（LAN55 网段）、网关 `.254`、可达 DNS `.36`。 +4. NAS/FreeNAS（含 transmission jail）→ **口 4/5**；windy-pc/hp-nas/杂项 → **口 6**（均为 access 66），逐个验证地址/DNS/业务。 + - dns/.36、ubnt/.46、gfw/.1、haos 均随 PVE 网卡迁移，**不单独插口**——只验证 PVE 后这些 VM 的 IP 与业务即可。 +5. **旧交换/旧接线全部下电**；确认无任何设备仍走 ER-X 直连旧口（双上行=环路）。 + +### 4.4 全局验证（第一步 Done 判定） +见第 7 节验收清单前 7 条全绿。**VLAN10 完全不在本步范围。** + +--- + +# 第二步：VLAN10 升级专用 SSID（第一步稳定 ≥1 天后，独立窗口） + +> **时机确认（2026-08-09）：** 第一步验收前 7 条全绿、网络稳定运行 ≥1 天后，再进入本步。 +> 本步所有动作（SE5420 VLAN10、gfw、UniFi）互相独立但按序执行，任一步失败可单独回滚。 + +## 5. 第二步·阶段 1：SE5420 增加 VLAN10 + +1. **建 VLAN10**（`L2 Features → VLAN → 802.1Q VLAN → VLAN Config`）： + - **10**：**tagged 口 2、口 3**（只这两个，其余口不放）。 +2. **口 2、口 3 改为 trunk**（`VLAN → Port Config`）： + - 口 2（PVE enp1s0）：PVID **66**，untagged 66 + **tagged 10**。 + - 口 3（U6）：PVID **66**，untagged 66 + **tagged 10**。 + - 其余口不动（保持第一步的 66/55 access）。 +3. **保存配置**（`System → Save Config`）。 +4. **验证**：`show vlan` 确认 VLAN10 仅 tagged 口 2/3；口 2/3 的 66 流量不受影响（66 上联仍通）。 + > 此时 VLAN10 无任何客户端流量（SSID 未启用），配置就位但无害。 + +## 6. 第二步·阶段 2：gfw 补齐 VLAN10 上网能力（SSH `root@192.168.66.1`） + +```sh +# 1) ubunt_upg zone 加 masq + 允许 forward +uci set firewall.ubunt_upg.masq='1' +uci set firewall.ubunt_upg.forward='ACCEPT' +uci set firewall.ubunt_upg.forward_policy='ACCEPT' # 若 fw4 版本支持 +# 2) 增加 ubunt_upg -> wan 转发 +uci add firewall forwarding +uci set firewall.@forwarding[-1].src='ubunt_upg' +uci set firewall.@forwarding[-1].dest='wan' +uci commit firewall +/etc/init.d/firewall reload +# 3) 确认 DHCP 已绑定（应已存在，无则补） +uci show dhcp.ubunt_upg # interface='ubunt_upg', start=100, limit=150 +``` + +> **为什么必须 masq**：VLAN10 客户端源地址 `192.168.10.x` 经 gfw 出 eth0 到 ER-X 后， +> 若无 masq，ER-X 无法把公网回包路由回 `192.168.10.0/24`。masq 后源地址变成 66 网段。 + +**验证（gfw 自测，纯本地无副作用）：** +```sh +nft list chain inet fw4 forward_ubunt_upg # 应有 jump accept_to_wan / wan 处理 +uci show firewall | grep -A2 ubunt_upg_to_wan +# 确认 eth0.10 能 ping 通自身（接口 up） +ping -c1 192.168.10.1 +``` + +## 7. 第二步·阶段 3：UniFi 改网络 + 启用 SSID + +1. **UniFi → Networks → `ubnt-upg`**： + - 网络类型/路由器设为 **Third-party Gateway**（或 equivalent，视 9.5.21 UI），**DHCP 保持关闭**； + - VLAN ID `10`、子网 `192.168.10.0/24`、网关 `192.168.10.1`； + - **广播范围只选 U6 Lite**（勿让 UAP-AC-Lite 广播，它在 LAN55 无 VLAN10 通道）。 +2. **UniFi → WiFi → `ubnt-upg` enable**（广播范围仅 U6 Lite）。 +3. **验证链（必须逐级）：** + - a. gfw：`tcpdump -eni eth0.10` 观察——应看到来自新 SSID 客户端的 DHCP/数据帧 + （`tcpdump` 若缺用 `apk add tcpdump` / `opkg update && opkg install tcpdump`）。 + - b. 客户端连 `ubnt-upg` → 应获 `192.168.10.100~250`，网关 `192.168.10.1`，DNS 为 gfw(clash)。 + - c. gfw：`cat /tmp/dhcp.leases | grep 192.168.10` 出现客户端租约。 + - d. gfw：`nft list chain inet fw4 dstnat | grep -A1 "7892"` 计数增长 → 证明被 OpenClash 接管。 + - e. 客户端能访问外网，且**不能**访问 LAN66（`Block-ubunt-upg-to-LAN66` 规则预期生效）。 +4. 失败处理：只撤 SSID（enable off），不动主 SSID 与 `.254` 路径。 + +--- + +## 8. 回滚语义 + +| 步骤/阶段 | 失败动作 | +|---|---| +| 第一步·阶段 1 | 无生产影响；还原 SE5420 台面配置或出厂即可 | +| 第一步·阶段 2（维护窗内） | **停手**；把刚迁的线插回 ER-X 原口；不动 ER-X WAN/DHCP/SSH | +| 第二步·阶段 1（SE5420 VLAN10） | 删 VLAN10、口 2/3 恢复 access 66 | +| 第二步·阶段 2（gfw） | 撤 `ubunt_upg` 的 masq/forwarding，恢复原 zone | +| 第二步·阶段 3（SSID） | 只关 `ubnt-upg` SSID；主 SSID、`.254`、gfw 66 路径不受影响 | + +### SE5420 恢复出厂（忘记口令 / 需要重配） + +> 官方《安装手册》附录 A「问题1」方法（**需 Console 串口**）： + +1. 管理本连 SE5420 **Type-C Console 口**（波特率 38400，8N1，无流控）。 +2. 交换机断电重启；终端出现 **`Press CTRL-B to enter the bootUtil`** 时同时按 `Ctrl+B` 进 bootUtil 菜单。 +3. 输入 `2`（软件复位），复位后恢复出厂默认；此后首次 WEB 登录为创建新用户名/密码（初始管理 IP 恢复 `10.18.18.251`）。 +4. 恢复后按第一步·阶段 1 重配，并**重新保存配置**。 + +--- + +## 9. 验收清单（「网络算正常」的样子） + +**第一步 Done（前 7 条全绿）：** +1. SE5420 管理面：`192.168.66.253` 仅 LAN66 可达；默认口令已改；配置已离线备份。 +2. LAN66：客户端 DHCP 拿 `.66.x`、网关 `.254`、DNS `.36`；外网通。 +3. LAN55：客户端拿 `.55.x`、网关 `.254`、DNS `.36`；跨网段互通（`.55.x ↔ .66.x`）。 +4. 端口转发逐条从公网验证（hass 8123 / transmission 51413 / ssh 5822→.36:22 / openvpn 1194）。 +5. UniFi：U6(`.66.6`) 与 AC-Lite(`.55.5`) Connected；Inform `:9080` 未变。 +6. 无环路、无双默认网关；端口协商与错误计数正常；旧交换已下电。 +7. `gfw` 旁路由行为与升级前一致（主网默认网关仍 `.254`）。 + +**第二步额外（第 8 条）：** +8. `ubnt-upg` 客户端 `192.168.10.x`、网关 `.10.1`、可上网、不可达 LAN66；gfw 侧 DHCP 租约与 OpenClash 计数可查。 + +**贯穿：** +9. IPv6 行为与升级前一致（SE5420 纯二层不碰 IPv6）。 + +--- + +## 10. 安全与记录 + +- **本仓库永不记录**：SE5420 口令、ER-X 配置快照（含 PPPoE/口令）、gfw 凭据。 +- 每次实质变更后，在 Linear `vps` 项目记录 scope / action / verification / 遗留 follow-up。 +- SE5420 配置备份离线保存；不做云管。 +- SSH/访问策略变更遵循仓库「SSH access safety」流程。 + +--- + +## 11. 参考 + +- 设计说明：[lan-erx-se5420-network.md](lan-erx-se5420-network.md) +- 早期阶段计划（已细化于本文）：[lan-core-switch-upgrade-plan.md](lan-core-switch-upgrade-plan.md) +- 现网地图：[lan-overview.md](lan-overview.md) +- ER-X：[edgerouter-x-configuration.md](edgerouter-x-configuration.md)、[hosts/gw.md](../hosts/gw.md) +- UniFi / VLAN10 前置：[unifi-network.md](unifi-network.md)、[unifi-third-party-vlan10-dhcp.md](unifi-third-party-vlan10-dhcp.md) +- `gfw`：[hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) +- PVE：[PVE 透传方法调研](lan-rb5009-upgrade.md#阶段-5-附pve-上-vlan10-透传实现调研-2026-08-09) +- SE5420 官方安装手册（默认 IP `10.18.18.251`、Console 38400、恢复出厂）： +- **SE5420 安装手册（Markdown 整理版）**：[se5420-official-manuals/tl-se5420-install-manual.md](se5420-official-manuals/tl-se5420-install-manual.md) +- SE5420 规格： +- SE5420 固件下载： +- Omada 802.1Q VLAN 配置指南（`L2 Features → VLAN → 802.1Q VLAN → VLAN Config / Port Config`）： +- Omada 管理 VLAN 配置指南： +- TP-Link「Accessing the Switch」（WEB/Console/Telnet/SSH 登录、管理 IP 与网关、保存配置）： +- TP-Link「OpenSSH 7.0+ 登录交换机」（KexAlgorithms/HostKeyAlgorithms 兼容）： diff --git a/docs/se5420-official-manuals/tl-se5420-install-manual.md b/docs/se5420-official-manuals/tl-se5420-install-manual.md new file mode 100644 index 0000000..e04e463 --- /dev/null +++ b/docs/se5420-official-manuals/tl-se5420-install-manual.md @@ -0,0 +1,262 @@ +# TL-SE5420 官方安装手册（整理版） + +> **来源：** TP-LINK《TL-SE5420 V1.0 安装手册 1.0.2》（PDF），已整理为 Markdown。 +> 官方 PDF： +> 配套实施文档：[../lan-se5420-deployment-guide.md](../lan-se5420-deployment-guide.md) +> 说明：PDF 中示意图已省略（仅保留文字）；正文以官方 PDF 为准。 + +--- + +## 声明 + +- Copyright © 2023 普联技术有限公司，版权所有，保留所有权利。 +- 产品规格和资讯仅供参考，如有内容更新，恕不另行通知。本手册仅作为使用指导，所作陈述均不构成任何形式的担保。 + +## 相关文档 + +| 文档名称 | 用途 | +|---|---| +| 《安装手册》 | 交换机的安装过程、启动以及常见故障处理 | +| 《用户手册》 | 交换机的各个功能应用以及常见功能使用问题处理 | +| 《命令行手册》 | 交换机 CLI（Command Line Interface，命令行界面）参考信息 | +| 《防雷安装手册》 | 安装中如何做好防雷措施以避免设备雷击损坏 | + +技术支持：服务热线 `400-8863-400` · 邮箱 `fae@tp-link.com.cn` · 微信公众号「TP-LINK商用网络」/「TP-LINK商云APP」 + +## 阅读对象与约定 + +- 适合阅读对象：网络工程师、网络管理员。 +- 本手册如无特别说明，均以 **TL-SE5420** 机型为例介绍，所指交换机为 2.5G 三层网管交换机。 +- 产品规格标贴位于设备底部，扫描二维码可查看安规符号释义。 + +--- + +## 第 1 章 产品介绍 + +### 1.1 产品简介 + +2.5G 三层网管交换机，支持静态路由和动态路由 RIP 协议，提供完备的安全防护机制、完善的 QoS 策略和丰富实用的 VLAN 功能。适用于中小型企业网、校园网络、酒店、网吧等使用场景。 + +### 1.2 产品外观 + +**前面板组成：** 1 模式切换按键 · 2 指示灯 · 3 1 个 Type-C Console 端口 · 4 16 个 2.5Gbps RJ45 端口 · 5 4 个 SFP+ 端口 · 6 1 个 USB 端口 + +**模式切换按键：** 用于切换指示灯的指示状态，支持「端口模式」和「堆叠模式」切换。任意模式下超过 45s 不按动按钮，自动恢复为端口模式。（模式切换功能软件后续升级支持，以实际软件功能为准。） + +**指示灯状态：** + +| 指示灯 | 名称 | 工作状态 | 工作说明 | +|---|---|---|---| +| PWR | 电源指示灯 | 常亮 / 熄灭 / 闪烁 | 供电正常 / 未通电或供电异常 / 供电异常 | +| SYS | 系统指示灯 | 绿色闪烁 / 红色闪烁 | 系统正常 / 系统异常 | +| Master | 堆叠指示灯 | 绿色常亮 / 黄色常亮 / 熄灭 | 堆叠主设备 / 堆叠错误 / 非主设备 | +| Stack | 模式指示灯 | 绿色常亮 / 熄灭 | 端口指示灯工作在堆叠模式 / 其它模式 | +| 1-16（端口模式） | 端口指示灯 | 绿色常亮 / 黄色常亮 / 闪烁 / 熄灭 | 2.5Gbps / 10/100/1000Mbps / 传输中 / 未连接 | +| 17-20（端口模式） | 端口指示灯 | 绿色常亮 / 黄色常亮 / 闪烁 / 熄灭 | 10Gbps / 2.5Gbps 或 1000Mbps / 传输中 / 未连接 | +| USB | 端口指示灯 | 绿色常亮 / 熄灭 | USB 连接正常 / 未连接或异常 | + +**Console 端口：** 用于和计算机或其他终端的串口相连以管理或配置交换机。TL-SE5420 提供 **1 个 Type-C Console 端口**。 + +**2.5Gbps RJ45 端口：** 16 个，支持 10M/100M/1000M/2.5Gbps 速率，每个端口对应一个端口指示灯。 + +**10Gbps SFP+ 端口：** 支持接入 1Gbps/2.5Gbps SFP 光/电模块或 10Gbps SFP+ 光/电模块，每个端口对应 1 个 Link/Act 指示灯。 + +**USB 端口：** 标准 USB2.0，480Mbps。可和交换机 Flash 文件系统交互（上传/下载应用程序、配置文件）。支持**交换机 U 盘开局**（详见《用户手册》）。 + +> 注意：不同厂商 USB 设备的兼容性和驱动存在差异，TP-LINK 不保证所有 USB 设备都能正常使用；如不能使用不属于交换机故障。 + +**后面板组成：** 1 防雷接线柱 · 2 电源插座（三相，220V~50Hz 交流电源）。 + +> 注意：请使用原装电源线；请通过电源线插头连接到有接地连接的输出插座；请远离水、火、潮湿或炎热环境；不要自行拆卸、修理、修改设备或更换电池（有爆炸危险）。 + +--- + +## 第 2 章 产品安装 + +### 2.1 物品清单 + +- 交换机 ×1 · 电源线 ×1 · 机架 L 型支架 ×2 · 安装手册 ×1 · 接地线 ×1 · 其他配件 + +### 2.2 安装注意事项 + +**安装安全：** +- 安装过程中电源保持关闭，佩戴防静电手环并保证接地良好； +- 确认供电电压与交换机标示电压相符； +- 通电前确认不会引起电源电路超负荷； +- 工作时不要打开外壳； +- 清洁前先拔电源插头，勿用湿润面料擦拭或液体清洗； +- 保持交换机底部朝下水平放置。 + +**环境要求：** + +| 环境描述 | 温度 | 相对湿度 | +|---|---|---| +| 工作环境 | 0℃ ~ 40℃ | 10% ~ 90%RH 无凝结 | +| 存储环境 | -40℃ ~ 70℃ | 5% ~ 90%RH 无凝结 | + +- 海拔：仅适用于 2000m 以下地区。 +- 室内防尘、防电磁干扰、防雷：确认设备与大地接地良好；远离高频大功率设备；室外布线建议使用信号防雷器。 +- 安装台：机架或工作台需承重至少 **5.5Kg**；供电插座与交换机距离不超过 1.5 米。 + +### 2.3 安装工具准备 + +十字螺丝刀 · 防静电手环 · 网线、光纤 + +### 2.4 产品安装 + +**桌面安装：** 底部朝上放置于稳定桌面 → 粘贴 4 个脚垫到机壳底部四角凹槽 → 翻转放平。机壳周围预留 5~10cm 空隙确保散热。 + +**19 英寸机架安装：** 检查机架接地与稳定性 → 两侧安装 L 型角铁并固定 → 安放到机架内由托架支撑 → 螺钉固定 L 型角铁到机架导槽。机架内一般由下至上安装。 + +--- + +## 第 3 章 硬件连接 + +### 3.1 连接 RJ45 端口 +通过 RJ45 端口连接交换机和对端设备。 + +### 3.2 连接 SFP+ 端口 +连接 SFP/SFP+ 光/电模块或 SFP+ 电缆。**SFP+ 端口默认支持 10Gbps；若使用千兆 SFP 光模块，需先将 SFP+ 端口速率设置为 1000Mbps。** 使用 SFP+ 电缆时确保最小弯曲半径符合要求。 + +### 3.3 连接 Console 端口 +Type-C Console 端口，连接后可通过命令行管理交换机（登录方法见 4.2）。 + +### 3.4 连接电源线 +接入 220V~50Hz 交流电源；确认供电电源与大地良好接触，确认电源开关位置以便及时断电。 + +### 3.5 设备初始化 +接通电源后自动初始化： +- PWR 指示灯亮 = 电源连接正确，灭 = 供电异常； +- SYS 指示灯闪烁 = 系统初始化成功，灭或常亮 = 初始化失败； +- Link/Act 指示灯会闪烁一下后熄灭，指示系统已复位。 + +### 3.6 安装后检查 +- 周围散热空间与空气流通； +- 电源插座供电符合规格； +- 电源、交换机、机架正确接地； +- 与其它网络设备连接正常。 + +--- + +## 第 4 章 配置指南 + +### 4.1 WEB 登录 + +> **TL-SE5420 业务口固定 IP 为 `10.18.18.251`**；电脑连接业务口时需设 IP `10.18.18.x`（x 为 2-250 任意值），子网掩码 `255.255.255.0`。 + +1. 普通 PC 用网线连接交换机任意一个 RJ45 业务端口； +2. 浏览器输入 `http://10.18.18.251` 回车； +3. **设置用户名和密码**，点击<确认>登录 WEB 管理界面； +4. 首页左上角商标可访问 TP-LINK 官网；左侧主菜单进行功能配置。 + +### 4.2 本地登录（Console） + +1. 连接 Type-C Console 口到计算机； +2. 安装「**TP-LINK USB 串口驱动程序**」（官网下载或随机光盘）； +3. 终端仿真程序参数： + - 波特率 **38400bps** · 数据位 **8** · 奇偶校验 **无** · 停止位 **1** · 数据流控制 **无** +4. 输入回车，出现 **`TL-SE5420>`** 提示符即登录成功。 + +### 4.3 远程登录（Telnet） + +1. cmd 输入 `telnet 10.18.18.251`； +2. 输入登录用户名和密码； +3. 输入 `enable` 回车进入特权模式。 + +### 4.4 云管理 + +1. Web 界面 →<云管理> → 开启<全局开关>； +2. 访问 `https://smbcloud.tp-link.com.cn/login.html`，登录 TP-LINK ID； +3. 项目集中管理 → 设备列表 → 添加设备（输入 MAC、名称、用户名、密码、分组；MAC 可扫设备底部二维码获取）； +4. 设备信息页找到对应条目 →<远程配置> → 云平台远程管理。 + +--- + +## 附录 A 常见故障处理 + +**问题1：忘记用户名和密码（恢复出厂设置）** +1. 串口连 Console 口，打开终端； +2. 交换机断电重启，终端出现 **`Press CTRL-B to enter the bootUtil`** 时按 `Ctrl+B` 进入 bootUtil 菜单； +3. 输入 **`2`** 进行软件复位，恢复到出厂默认设置，登录用户名和密码均为 **admin**。 + +**问题2：电源指示灯显示不正常** +- 电源线连接是否正确；供电电源是否匹配（100-240V~ 50/60Hz）。 + +**问题3：无法登录 WEB 管理界面** +- 是否达到 HTTP 管理人数上限； +- 端口线缆连接与端口状态； +- 电脑 IP 与交换机 IP 是否同网段； +- `ping 127.0.0.1`（本机 TCP/IP）与 `ping 10.18.18.251`（交换机）。 + +**问题4：断电后配置消失** +- 配置实时生效，但**断电前必须点保存配置**。 + +--- + +## 附录 B 技术参数规格 + +| 项 | 值 | +|---|---| +| 产品型号 | TL-SE5420 | +| 技术标准 | IEEE 802.3 / 802.3i / 802.3u / 802.3ab / 802.3z / 802.3bz(2.5G/5G) / 802.3ae(10G) / 802.3ad(链路聚合) / 802.3x(流控) / 802.1p(QoS) / 802.1q(VLAN) / 802.1x / 802.1d(STP) / 802.1s(MSTP) / 802.1w(RSTP) / 802.1ab(LLDP) | +| 端口 | 16× 10/100/1000/2.5G RJ45 + 4× 10G SFP+ | +| 传输方式 | 存储转发 | +| 数据传输速率 | 10M半双工/20M全双工 · 100M半/200M全 · 千兆2000M全 · 2.5G 5000M全 · 10G 20000M全 | +| 包转发速率 | 10BASE-T:14881pps · 100BASE-TX:148810pps · 1000BASE:1488095pps · 2.5GBASE-T:3720238pps · 10GBASE:14880952pps（每端口） | +| 电源输入 | 220V~50Hz | +| 工作温度 | 0℃~40℃ | +| 存储温度 | -40℃~70℃ | +| 工作湿度 | 10%~90%RH 无凝结 | +| 存储湿度 | 5%~90%RH 无凝结 | + +网络介质（部分）：10BASE-T 3类线≤100m · 100BASE-TX 5类线≤100m · 1000BASE-T 超5类≤100m · 2.5GBASE-T 超5类≤100m · 10GBASE-SR OM1/OM2/OM3 MMF 2m~300m · 10GBASE-LR SMF 2m~10000m。 + +--- + +## 附录 C 连接 SFP+ 端口补充说明 + +- **光纤**：单模（芯径 9/10μm，模间色散小，适合远程）；多模（芯径 50/62.5μm，传输距离较近，一般几公里）。 +- **光模块**：按性质分单模/多模；按速率分百兆/千兆/万兆。SFP/SFP+ 端口兼容单模、多模光模块，推荐使用 TP-LINK 光模块。 + +**TP-LINK 光模块参考表：** + +| 模块类型 | 产品型号 | 速率 | 距离 | 传输介质 | +|---|---|---|---|---| +| 光模块 | TL-SM512LS-10KM | 10Gbps | 10km | SMF 双纤 LC | +| 光模块 | TL-SM512LM-300m | 10Gbps | 300m | OM3 MMF 双纤 LC | +| 光模块 | TL-SM411LSA/B-5KM | 2.5Gbps | 5km | SMF 单纤 LC | +| 光模块 | TL-SM411LSA/B-500m | 2.5Gbps | 500m | SMF 单纤 LC | +| 光模块 | TL-SM411SSA/B-500m | 2.5Gbps | 500m | SMF 单纤 SC | +| 光模块 | TL-SM412LS-5KM | 2.5Gbps | 5km | SMF 双纤 LC | +| 光模块 | TL-SM311LSA/B-20KM | 1Gbps | 20km | SMF 单纤 LC | +| 光模块 | TL-SM311LSA/B-2KM | 1Gbps | 2km | SMF 单纤 LC | +| 光模块 | TL-SM311SSA/B-2KM | 1Gbps | 2km | SMF 单纤 SC | +| 光模块 | TL-SM312LS-40KM | 1Gbps | 40km | SMF 双纤 LC | +| 光模块 | TL-SM312LS-20KM | 1Gbps | 20km | SMF 双纤 LC | +| 光模块 | TL-SM312LS-20KM工业级 | 1Gbps | 20km | SMF 双纤 LC | +| 光模块 | TL-SM312LM-550m | 1Gbps | 550m | OM2 MMF 双纤 LC | +| 电口模块 | TL-SM510U | 10Gbps | 30m | 超六类网线 | +| 电口模块 | TL-SM410U | 2.5Gbps | 100m | 超五类网线 | +| 电口模块 | TL-SM310U | 1Gbps | 100m | 超五类网线 | + +--- + +## 附录 D 产品保修卡（要点） + +- 免费保修范围外的情况：超出保换/保修期限、未按要求安装使用、擅自改动设置或拆机、意外或人为损坏、运输损坏、不可抗力等。 +- 技术支持热线：`400-8863-400` · 邮箱 `fae@tp-link.com.cn` · 官网 `www.tp-link.com.cn`。 +- **售后服务承诺：三年保修。** +- 外置电源保换 1 年，电池 6 个月，鼠标 3 个月；无线外置天线及光纤头 3 个月。 +- 购机 15 天内出现性能问题且外观无划伤可换新。 + +--- + +## 附录 E 有毒有害物质含量声明 + +（详见官方 PDF 附表。） + +--- + +公司地址：深圳市南山区深南路科技园工业厂房 24 栋南段 1 层、3-5 层、28 栋北段 1-4 层 +公司网址： · 技术支持 E-mail：`smb@tp-link.com.cn` · 技术支持热线：`400-8863-400` +文档版本：REV1.0.2 diff --git a/docs/sirivision-sr-s25g3218f-research-2026-08.md b/docs/sirivision-sr-s25g3218f-research-2026-08.md new file mode 100644 index 0000000..7714b21 --- /dev/null +++ b/docs/sirivision-sr-s25g3218f-research-2026-08.md @@ -0,0 +1,158 @@ +# 希力威视 SR-S25G3218F 调查（2026-08-08） + +**结论：** 若需求是大量 2.5G 终端、少量 10G 光上联，`SR-S25G3218F` 的端口密度 +更合适；厂商已公开该型号的固件页，但仍缺少完整规格书、管理手册与兼容矩阵。若需求是 8 条全部可协商 +1/2.5/5/10G 的铜缆链路，且希望有可查的 L3 能力和固件入口，兮克 +`SKS8300-8T` 是资料更完整、风险更低的选择；它的代价是主动风扇、外置 12 V 电源、 +无 SFP+ 光口，且仍不应把消费级/SMB 设备当作安全边界或唯一核心。两者都应在 +到货可退换期内完成实机验收。 + +本页为采购前资料调查，不代表已接入本地网络；检索日期为 2026-08-08。 + +## 已能核实的事项 + +| 项目 | 结论与证据强度 | +|---|---| +| 型号/端口 | 京东的希力威视商品标题称该 SKU 为 `SR-S25G3218F`，有 16 个 2.5G 电口和 2 个万兆光口，并宣传 VLAN、端口隔离与 LACP。该店铺被厂商官网列为可购买的「京东旗舰店」，因此可作为销售规格，非技术手册。[京东商品页](https://item.jd.com/100165071727.html)；[厂商购买渠道说明](https://en.sirivision.com/contactus/) | +| 厂商身份 | 厂商官网为 Shenzhen/Guangdong Sirivision Communication；英文官网说明其自 2016 年起提供接入、汇聚和核心交换机方案。[厂商首页](https://en.sirivision.com/) | +| 公开的二手厂家资料 | 同一制造商名义的 Alibaba 出口页将精确型号写成 `16*2.5G+2*10G`、`120Gbps`，并列出 QoS、VLAN、SNMP、L3 与 stackable。这是制造商发布在平台上的销售资料，**不是**官网数据表；其中后五项不能据此视为已验收的功能承诺。[制造商平台页](https://www.alibaba.com/pla/SR-S25G3218F-QoS-Managed-SFP-Switch-1625G210G_1601494946214.html) | +| 固件入口 | 厂商已发布此精确型号的[固件页](https://www.sirivision.com/sr-s25g3218f%E5%9B%BA%E4%BB%B6/)。公开变更记录提到“光口自适应”和“增加 DAC 配置”；这证明厂商维护过该路径，**不**代表任意 SFP+/DAC/铜模块均兼容。 | +| 本机可计算的带宽 | 端口线速相加为单向 60 Gb/s（16 × 2.5 + 2 × 10）；若厂商所谓 `120Gbps` 是全双工交换容量，则数学上吻合。它**不**证明缓冲、PPS、表项规模或实际无阻塞性能。 | + +## 网管/L2/L3 能力边界 + +京东标题足以支持把 VLAN、端口隔离、LACP 作为「卖家声称提供」的功能；不得由此推导出 +ACL、IPv4/IPv6 静态路由、SVI 数量、DHCP relay、OSPF/RIP、VRRP、IGMP、ERPS、 +802.1X、RADIUS/TACACS+、SSH/HTTPS 管理、SNMP 版本、日志/审计、配置备份或固件 +安全维护一定存在。 + +尤其要注意：厂商官网把真正列出的 2.5G L3 产品标为 +`SR-S25G3412F (8 × 2.5G + 4 × 10G SFP+)`；其 2.5G 类目只显示 7 个型号， +不含 `SR-S25G3218F`。官网也把 L2+、Web Smart、L3 分成不同产品类别。这个目录 +差异**不是**证明 3218F 没有 L3，而是说明「三层」无法通过官网的精确型号文档确认。 +[2.5G 产品目录](https://en.sirivision.com/product-category/products/2-5g-switches/)； +[官网的 10G L3 目录](https://en.sirivision.com/product-category/products/10g-switches/10g-layer3-managed-switches/)； +[官网的 L2+ 分类示例](https://en.sirivision.com/product-category/products/gigabit-switches/gigabit-layer2-managed-switches/)。 + +采购前请向京东/厂商索取**与机身 SKU、硬件 revision 和固件版本对应**的 PDF +数据表、管理手册和 release notes，并要求书面回答至少以下问题： + +1. L3 是只有 VLAN Interface/IPv4 静态路由，还是另有 IPv6、ACL、动态路由、DHCP relay + 等；每项的最大 VLAN、MAC、ARP、路由、ACL、LAG 数量分别是多少？ +2. LACP 是否符合 802.3ad、一个 LAG 最多多少成员、能否跨两台设备（若销售页的 + `stackable` 属实，堆叠的线缆/模块、最大成员、控制面和软件版本为何）？ +3. 管理面是否支持 HTTPS/SSH、禁用 HTTP/Telnet、独立管理 VLAN、SNMPv3、syslog、NTP、 + 配置导出/回滚和已签名或可校验的固件；默认凭据首次登录是否强制修改？ + +## 供电、散热和光口：当前不能确认 + +针对该精确 SKU，厂商官网目录与公开搜索未找到说明书/数据表，所以以下均为**待确认， +不能猜测**： + +- 是否为内置 AC 电源、额定输入范围/最大功耗、是否带电源开关和接地端子；是否完全 + 不提供 PoE（本型号名和京东标题均未写 PoE，但这不足以替代规格书）。 +- 风扇数量、常态/满载噪声、风向、环境温湿度、机架深度与安装耳；不要将「金属壳」 + 或产品照片等同于无风扇/静音。 +- 两个槽是否均为 **10G SFP+**，是否可协商 1G SFP；支持的 SR/LR/BiDi 波长距离、 + DAC/AOC 长度、第三方模块/EERPOM 兼容策略、10GBASE-T SFP+ 模块的功耗/温度限制， + 以及是否支持 GPON/XPON ONU「猫棒」。 + +厂商确实单列「SFP Optical Modules」产品分类，但这不构成 3218F 的兼容清单。 +[厂商产品导航](https://en.sirivision.com/)。购买光模块/直连线时，应要求厂商按这台 +设备的硬件/固件 revision 出具兼容型号清单；没有书面清单时，先在可退换期实测两端的 +链路、重启恢复、热插拔与长时间满载错误计数。 + +## 风险与建议验收 + +- **文档/生命周期风险（中到高）：** 精确型号不在厂商当前官网 2.5G 目录，虽有固件下载页， + 但未公开完整型号手册、明确 release notes 或兼容矩阵。官网的售后条款也要求按具体产品查询保修期，配件（含光纤头） + 的保修条款与主机不同；不要把平台页的「3 年」当作中国零售 SKU 的已确认保修。 + [厂商售后条款](https://en.sirivision.com/after-sale-protection/) +- **功能表述风险（高）：** 页面将 L2 特性和「三层网管」并列；在命令/网页菜单、 + 手册和测试证明之前，将其当作 L2 VLAN/LACP 设备部署，跨 VLAN 路由仍由现有网关承担。 +- **双 10G 上联约束（中）：** 两个 SFP+ 可作双上联或一个二成员 LAG，但 LAG 增加的是 + 多流量总吞吐，单一 TCP/UDP 流通常仍受一条 10G 链路限制；上级设备也必须匹配 LACP + 配置。 +- **管理面风险（中到高）：** 家用/低价网管设备常见明文管理、弱默认口令或不透明的固件 + 更新周期；采购后先置于受限管理 VLAN，改口令、升级已验证固件，且不将管理界面暴露 + 到 WAN/访客网。 + +最低验收应包括：逐口协商 100M/1G/2.5G、两只不同厂家 SFP+/DAC（仅在卖家承诺支持的 +范围内）、VLAN trunk/access/PVID、STP/环路保护、LACP 故障切换、端口隔离、满载 +双向 iperf3 与错误计数、冷启动后的配置保留，以及管理面的 HTTPS/SSH/SNMPv3/配置备份。 +如无法提供与型号匹配的正式资料或其中任一关键项失败，应在退换期内退货，并选择公开 +数据表、固件与兼容矩阵更完整的型号。 + +## 备选：兮克 SKS8300-8T 对比 + +### 已核实的厂商规格 + +兮克官网的精确型号页明确将 `SKS8300-8T` 定位为三层管理型 10G 全电口交换机，并列出： + +- 8 × 1/2.5/5/10GBASE-T RJ45；160 Gb/s 交换容量、119.05 Mpps、12 Mbit 缓存、 + 16K MAC、12 KB 巨帧、512 MB DRAM、32 MB Flash，尺寸 207 × 136 × 35 mm； +- QoS、ACL、IP+MAC+端口绑定、流分类/优先级标记、多端口镜像、静态/灵活 QinQ、 + sFlow，以及「基于策略的 IPv4/IPv6 单播路由」。 + +这些是厂商能力声明，并非对每一种路由协议或表项上限的承诺；但相对 3218F 的仅有 +销售标题，它给出了精确型号、转发性能和 L3 范围。[兮克 SKS8300-8T +产品页](https://seekswan.com/user/custom-pages/SKS8300-8T.html) + +独立的 OpenWrt 设备资料将其识别为 Realtek RTL9303、512 MB RAM，记录了原厂固件 +下载入口和串口/TFTP 恢复路径；其硬件数据页列为 12 V / 4 A。这支持「可恢复、可替换 +系统」的可操作性，但**不是**兮克对原厂功能的支持承诺。 +[OpenWrt 设备页](https://openwrt.org/toh/xikestor/sks8300-8t)； +[OpenWrt 硬件数据](https://openwrt.org/toh/hwdata/xikestor/xikestor_sks8300-8t)。 + +### 能力、物理与运维比较 + +| 维度 | 希力威视 SR-S25G3218F | 兮克 SKS8300-8T | +|---|---|---| +| 接口/典型用途 | 16 × 2.5G 电口 + 2 × 10G SFP+（销售规格）；适合很多 2.5G 终端/NAS，以 10G 光或 DAC 上联。 | 8 × 1/2.5/5/10GBASE-T；适合 10G 铜缆设备、2.5/5G 多速率 NAS/主机。没有 SFP+，光纤上联必须经媒体转换或选另一型号。 | +| 可确认的三层范围 | 仅销售/平台资料称 L3；没有精确型号官方手册，不能确认静态路由以外的功能。 | 官网明确写策略型 IPv4/IPv6 单播路由、ACL/QoS/sFlow/QinQ；动态路由、VRRP、IPv6 ACL/SNMP/认证等仍须按当前固件手册确认。 | +| 冗余/二层 | 卖家声称 VLAN、端口隔离、LACP；STP/环网的实现与规格未知。 | 官网声明 L3 和多项转发特性，但未在产品页给出 STP/LACP/ERPS 的精确限制；购买前仍索取手册。 | +| 散热/噪声 | 无可核实的精确型号风扇、噪声、功耗或风向数据。 | 独立手册镜像和产品图均称智能温控风扇，但厂商产品页未给 dBA；应按「有风扇、可能听得见」规划，不能承诺静音。 | +| 供电 | 未找到精确型号官方输入/功耗资料。 | OpenWrt 硬件数据记录 12 V / 4 A；确认随附电源适配器的插头、余量和地区认证。官方产品页未给满载功耗。 | +| 固件/恢复 | 有精确型号官方固件页；公开记录包含光口自适应与 DAC 配置改动，但未找到完整 release notes、恢复步骤或兼容矩阵。 | 厂商产品页提供「相关下载」区，OpenWrt 还记录原厂固件入口、RJ45 串口和 U-Boot/TFTP 恢复；原厂镜像是否签名、漏洞修复 SLA、配置回退仍未知。 | + +关于 8T 的风扇、满载功耗（常见转述为 ≤36 W）、温度范围、芯片型号等，本次未找到 +相应的**厂商原始数据表**；不将第三方手册转录当作已核实规格。若噪声、UPS 容量或 +机柜散热是购买约束，请先让卖家提供产品铭牌照片、适配器铭牌照片、额定/实测功耗和 +dBA 测试条件。 + +### 选择与验收建议 + +- 选 **3218F**：必须有 ≥12 个 2.5G 接入端、10G 光/DAC 上联、且 L3 留给现有路由器。 + 下单前先取得精确型号手册和 SFP+/DAC 兼容承诺；否则端口数量优势不足以抵消资料风险。 +- 选 **8T**：最多 8 个设备但需要多速率 10G RJ45、明确的 IPv4/IPv6 静态/策略路由和 + 以后自行维护/恢复的余地。不要把其 160 Gb/s 标称交换容量误解为 8 端口同时 10G + 全双工的性能保证——该标称与端口总线速数学相等，但仍须以实测和厂商 PPS/缓冲说明为准。 +- 两台都不应单独承担防火墙、访客/IoT 安全隔离或 WAN 暴露；VLAN 的跨网段策略和公网 + 边界留在受支持的网关/防火墙上。先为管理面创建专用 VLAN，仅从管理主机访问，禁用 + 未使用的远程管理协议，备份配置和原厂固件后再接入生产网络。 + +## 低功耗核心备选（8 × 2.5G + 2 × SFP+） + +如果核心只需接最多 8 台铜缆终端、上联/连接 NAS 使用 DAC 或光纤 10G，优先考虑没有 +PoE 的以下两款。它们都满足 VLAN trunk、LACP 和至少两个 10G SFP+ 的需求；不要为 +AP 选 PoE 版来承担核心，因为 PoE 预算、风扇和待机损耗都会明显增加。 + +| 型号 | 端口与管理能力（厂商声明） | 厂商功耗 / 噪声资料 | 对当前 LAN 的判断 | +|---|---|---|---| +| **TP-Link Omada SG3210X-M2** | 8 × 100M/1G/2.5G RJ45、2 × 10G SFP+，并有 RJ45 和 Micro-USB console。厂商规格列出 802.1Q VLAN、STP/RSTP/MSTP、静态 LAG 和 802.3ad LACP（最多 8 个聚合组、每组最多 8 端口）；L3 是 32 个 IPv4/IPv6 接口、48 条静态路由。 | **无风扇**；100–240 V AC 内置电源。`UN 1.20` 数据表：待机最高 **6.0 W**（220 V/50 Hz、25 °C），最高 **15.3 W**（220 V）或 **15.0 W**（110 V）。 | **首选低功耗方案。** 足以做 LAN66 核心、给 PVE/gfw 与 U6 Lite 做 VLAN 10 trunk，并以 SFP+ DAC/光口连接 10G NAS/主机；它不提供 5G/10G RJ45，10G 铜缆需外置转换或 SFP+ 10GBASE-T 模块。 | +| **MikroTik CRS310-8G+2S+IN** | 8 × 2.5G RJ45、2 × 10G SFP+；SFP+ 笼支持 1G/2.5G/10G。RouterOS v7（也可选 SwOS）支持 VLAN、链路聚合与 ACL。 | 18–57 V DC 外置供电；官方给出“无附件”最高 **21 W**、总体最高 **34 W**，且机内 **1 个风扇**。厂商没有在该页给出 dBA。 | 可用且软件/文档/恢复路径成熟，但不是本题的静音低功耗优先项：官方最大功耗显著高于 TP-Link，且有风扇。适合明确偏好 RouterOS/SwOS 与其可维护性时选。 | + +功耗数字是各厂商的**上限/待机测试条件**，不是你实际墙插读数；SFP+ 光模块、DAC/AOC，尤其 +10GBASE-T SFP+ 模块，会另增功耗和热量。对于本网络，用被动 DAC 或短距光模块连接 10G +设备，通常比全 RJ45 10G 核心更容易保持低温、低噪。 + +`SG3210X-M2` 的上表数据对应 TP-Link 的 `UN 1.20` 数据表；不同地区/硬件版本的包装、 +认证和功耗标注可能不同，购买中国零售版本前应让卖家确认**准确硬件版本、保修渠道和固件地区**。 +本次未找到 TP-Link 中国官网的该精确型号页，因此不能把海外官方页面当作大陆现货/售后承诺。 +MikroTik 同样应通过其官方零售商查询渠道确认本地库存和保修。两台购买前还应确认所选 +SFP+/DAC 的兼容清单。 + +来源：[TP-Link 产品规格](https://www.tp-link.com/uk/business-networking/omada-switch-access-pro/sg3210x-m2/)； +[TP-Link `UN 1.20` 数据表](https://static.tp-link.com/upload/product-overview/2025/202512/20251224/SG3210X-M2%28UN%29%201.20_datasheet.pdf)； +[MikroTik 产品页](https://mikrotik.com/product/crs310_8g_2s_in)； +[MikroTik 用户手册](https://help.mikrotik.com/docs/spaces/UM/pages/214630429/CRS310-8G%2B2S%2BIN)。 diff --git a/docs/unifi-network.md b/docs/unifi-network.md index 788ca09..a82bb1b 100644 --- a/docs/unifi-network.md +++ b/docs/unifi-network.md @@ -68,6 +68,62 @@ db.device.find( ).pretty() ``` +## Dedicated Wi-Fi through a third-party gateway + +### Architecture boundary discovered on 2026-08-08 + +`gfw` is a virtual machine connected only to the native LAN 66 network; the +physical Wi-Fi uplink is also an ER-X LAN 66 path. The ER-X provides DHCP for +that LAN. There is no verified 802.1Q-capable path from the U6 Lite to `gfw`. + +Consequently, the proposed `ubnt-upg` design is **not implementable on the +current topology without an additional VLAN-capable L2 path**. Giving the VM +an `eth0.10` interface alone does not create VLAN 10 on the physical switch or +deliver tagged frames to it. + +UniFi APs associate clients and bridge an SSID into a selected 802.1Q VLAN; +they do not allocate DHCP addresses. The controller configures that AP +behavior, but it is not a DHCP service for a third-party-gateway VLAN. The +gateway on the corresponding VLAN provides DHCP. In the existing topology, the +ER-X DHCP service legitimately answers untagged LAN 66 requests. + +The observed `192.168.66.91` lease on `ubnt-upg` is therefore expected when +traffic reaches the existing untagged LAN 66. It is not a failure that can be +fixed by changing the controller or by adding another DHCP server to the same +broadcast domain. + +### Conditions for a future implementation + +The design becomes viable only after adding and proving one of these: + +1. A VLAN-capable switch/trunk from the U6 Lite to a VLAN-10 interface on the + actual gateway, with native LAN 66 retained for AP management; or +2. A hypervisor/vSwitch and physical uplink configured to pass VLAN 10 end to + end to the `gfw` VM, plus the corresponding tagged port towards the U6. + +Then configure one UniFi virtual network with **Router: Third-party Gateway** +and VLAN ID `10`, map only `ubnt-upg` to it, and have the VLAN 10 gateway be +the sole DHCP server for `192.168.10.0/24`. A test client must obtain +`192.168.10.x`, with traffic and its lease visible on that gateway, before the +SSID is considered working. + +### Protecting existing Wi-Fi + +`ubnt-windy` is the existing 5 GHz SSID and has been restored on the U6 Lite. +Keep its network and broadcast/device assignment unchanged. If the dedicated +SSID is ever retried, use the controller's normal **Specific -> U6 Lite** +broadcast selection for `ubnt-upg` only; do not reuse, move, or manually edit +an existing SSID's AP group. An AP configuration push can still briefly +reassociate clients, so zero-impact work on the same AP cannot be guaranteed. + +### References + +- [Feasibility and DHCP responsibility](unifi-third-party-vlan10-dhcp.md) +- [Supported topology and implementation examples](unifi-openwrt-vlan10-implementation-examples.md) +- Ubiquiti: [Creating Virtual Networks (VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs), + [Creating WiFi SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs), and + [Switch Port VLAN Assignment](https://help.ui.com/hc/en-us/articles/26136855808919-Switch-Port-VLAN-Assignment-Trunk-Access-Ports). + ## Managed access points | Name | Model | Management IP | Firmware | Management network | Inform port | diff --git a/docs/unifi-openwrt-vlan10-implementation-examples.md b/docs/unifi-openwrt-vlan10-implementation-examples.md new file mode 100644 index 0000000..309a3b6 --- /dev/null +++ b/docs/unifi-openwrt-vlan10-implementation-examples.md @@ -0,0 +1,120 @@ +# UniFi AP + OpenWrt VLAN-backed Wi-Fi: implementation evidence + +**Research date:** 2026-08-08 +**Scope:** research only. This file does not assert that the local physical +path currently carries VLAN 10, and no controller, AP, ERX, or OpenWrt setting +was changed while preparing it. + +## Conclusion + +Yes. This is a normal, supported deployment pattern: UniFi APs and Network +Application manage the SSID-to-VLAN mapping, while a non-UniFi gateway such as +OpenWrt owns the tagged VLAN interface, its subnet, DHCP, routing, and +firewall/policy routing. The existing untagged LAN DHCP server remains in +place; it serves only the native LAN, while OpenWrt serves the tagged VLAN. + +Ubiquiti's current third-party-gateway recipe specifically says to configure +the subnet, VLAN ID, and DHCP **on the third-party gateway first**, then create +a UniFi virtual network with **Router = Third-party Gateway** and the same VLAN +ID. [Ubiquiti: Creating Virtual Networks (VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs) + +That supported pattern requires an end-to-end tagged path. It is not feasible +on the current local topology: `gfw` is a VM connected only to untagged LAN 66 +and there is no verified physical or virtual switch trunk carrying VLAN 10 from +the U6 Lite to that VM. Creating `eth0.10` inside the VM cannot supply the +missing L2 transport. + +## The reusable topology + +```text +main SSID ── untagged/native LAN66 ── ERX DHCP ── 192.168.66.0/24 + │ +U6 Lite ── AP uplink trunk (native LAN66 + tagged VLAN 10) ── gfw/OpenWrt + └── ubnt-upg SSID ── VLAN 10 ── gfw.10: 192.168.10.1/24 + DHCP + OpenClash +``` + +This is not two DHCP servers answering one broadcast domain. They serve two +separate L2 broadcast domains. An AP bridges a station's DHCP request into the +VLAN selected for its SSID; it does not allocate the address itself. Ubiquiti +states that SSID clients become members of the selected VLAN and that every +port between AP and gateway must allow that VLAN. [Ubiquiti: Creating UniFi +WiFi SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs) + +OpenWrt's own VLAN documentation shows the same mixed-link model: an untagged +LAN plus tagged VLAN interfaces on a common link, and explicitly notes that a +separate DHCP server can serve each segment. [OpenWrt: VLAN / switch +configuration](https://openwrt.org/docs/guide-user/network/vlan/switch_configuration) + +## Evidence of existing deployments + +### Protocol and product documentation (authoritative) + +* Ubiquiti's third-party-gateway workflow is an exact product-supported recipe + for the UniFi half: gateway first, then matching VLAN in UniFi. It does not + require a UniFi gateway or switch. [Creating Virtual Networks + (VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs) +* Ubiquiti specifies the exact Wi-Fi half: choose the network in the SSID's + **Network** dropdown, select the APs that should broadcast it, and permit the + VLAN on all intervening ports. [Creating UniFi WiFi + SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs) +* Ubiquiti's troubleshooting topology specifically calls an SSID VLAN made + native on the AP port, or absent as a tagged VLAN upstream, a broken setup; + it directs operators to trace every AP-to-gateway port. [Virtual Network + (VLAN) Troubleshooting](https://help.ui.com/hc/en-us/articles/9592924981911-Virtual-Network-VLAN-Troubleshooting) +* OpenWrt documents Linux 802.1Q interfaces and bridge VLAN membership. Its + example calls out a trunk carrying untagged traffic and tagged VLANs, which + is the link gfw needs. [OpenWrt: VLAN / switch + configuration](https://openwrt.org/docs/guide-user/network/vlan/switch_configuration) + +### User-reported working deployments (official Ubiquiti Community; anecdotal) + +These are not Ubiquiti support guarantees, but they demonstrate that the exact +vendor split is in real use: + +* A user reports a UniFi site whose upstream router/DHCP server is **OpenWrt**; + they create a Third-Party Gateway network, assign its VLAN tag, then bind it + to the Wi-Fi SSID. The report says it works without a UniFi gateway or switch. + [UniFi Network Application 7.4.156 discussion](https://community.ui.com/releases/UniFi-Network-Application-7-4-156/15ac6260-9cd1-4ac3-a91c-4880c1c87882?page=36) +* A second user reports two SSID VLANs over an **OpenWrt Linksys WRT32X 802.1Q + trunk**, with no USG or UniFi switch; the controller network is selected in + the SSID's Network dropdown. [Assigning VLANs to SSIDs on Controller + 6](https://community.ui.com/questions/Assigning-VLANs-to-SSIDs-on-Controller-6/3e656047-685f-470e-954c-703077e89aaa) +* A Ubiquiti Community post describes an existing multi-VLAN UniFi deployment + with an OpenWrt NanoPi R6S gateway and all UniFi networks configured as + Third-party Gateway. [OpenWrt third-party-gateway + deployment](https://community.ui.com/questions/Replacing-an-existing-third-party-router-firewall-with-a-UXG-Lite-on-an-existing-UniFi-network/5de2504a-fac2-437a-b893-495a6be2f3c0) + +## Exact mapping for this network + +| Layer | Required configuration | +|---|---| +| `gfw` / OpenWrt | Only after a tagged path reaches the VM: create/retain VLAN-10 interface, address `192.168.10.1/24`, run the **only** DHCP server for that segment, and apply the intended OpenClash/policy routing. | +| U6-to-gfw path | Native/untagged LAN66 for U6 management; tagged VLAN 10 allowed at every switch/link. Do not replace the native LAN with VLAN 10. | +| UniFi network | One VLAN 10 virtual network with **Router: Third-party Gateway**. This is controller metadata that makes the AP tag the selected SSID; it is not a DHCP service. | +| `ubnt-upg` Wi-Fi | Select that VLAN 10 network. Do not enable UniFi Hotspot/guest portal unless deliberately required. | +| Existing Wi-Fi | Leave `ubnt-windy`, `ubnt-windy-2`, and `ubnt-haas` network/VLAN choices untouched; they remain on their existing LANs and DHCP servers. | + +The acceptance test is therefore unambiguous: after reconnecting, a device on +`ubnt-upg` must receive `192.168.10.x` from the VLAN 10 gateway, while a device +on existing Wi-Fi continues to receive its established LAN address. A +`192.168.66.x` lease on the dedicated SSID means VLAN 10 was not selected or +did not pass the L2 path; it is not evidence that the U6 should run DHCP. + +## Protecting the existing Wi-Fi during a retry + +The current UniFi UI supports **All**, **Specific**, and **Groups** independently +for each SSID's Broadcasting APs selection. [UniFi WiFi SSID and AP Settings +Overview](https://help.ui.com/hc/en-us/articles/32065480092951-UniFi-WiFi-SSID-and-AP-Settings-Overview) + +Given the earlier incident where changing a virtual/AP group removed +`ubnt-windy` from the U6 Lite, the low-risk control is to leave every existing +SSID's Broadcasting APs selection unchanged and set **only `ubnt-upg`** to +**Specific → U6 Lite**. Do not reuse or move the default SSID into a temporary +group. This does not eliminate the short re-provision/reassociation caused by +an AP config push, but it prevents the configuration-level loss of the default +SSID that was observed. + +Before enabling the dedicated SSID, inspect the saved settings and AP's +effective configuration, then test with one client. Only the dedicated SSID +should be affected by a failure; LAN66 DHCP and the existing SSIDs require no +change. diff --git a/docs/unifi-third-party-vlan10-dhcp.md b/docs/unifi-third-party-vlan10-dhcp.md new file mode 100644 index 0000000..6ad408b --- /dev/null +++ b/docs/unifi-third-party-vlan10-dhcp.md @@ -0,0 +1,104 @@ +# UniFi Wi-Fi VLAN 10 with a third-party gateway + +**Research date:** 2026-08-08 +**Scope:** evidence-backed design only; no controller, AP, switch, EdgeRouter, +or OpenWrt settings were changed by this research. + +## Answer: who assigns client addresses? + +Neither a UniFi Network controller nor a UniFi AP is the DHCP server for a +normal third-party-gateway deployment. The controller configures the AP; the +AP maps a selected SSID to an 802.1Q VLAN and bridges the client's DHCP +broadcast into that VLAN. A UniFi **Gateway** can provide DHCP, but Ubiquiti's +DHCP documentation expressly describes the DHCP server as a service of UniFi +Gateways, not APs or the Network Application. [UniFi DHCP Server](https://help.ui.com/hc/en-us/articles/360012097513-UniFi-DHCP-Server) + +Accordingly, an existing DHCP server on the native/untagged LAN (here, the +EdgeRouter X for `192.168.66.0/24`) is expected to answer an SSID that is not +actually VLAN-tagged. It must **not** provide the lease for a genuinely +separate dedicated VLAN. That VLAN's gateway would provide its DHCP service. + +## Required architecture + +```text +client → SSID ubnt-upg → U6 Lite + │ VLAN 10 (802.1Q tagged) + ▼ + every intervening L2 link permits VLAN 10 + ▼ + gateway VLAN-10 interface: 192.168.10.1/24 + DHCP + routing/OpenClash +``` + +The AP's management traffic may remain untagged on LAN66. VLAN 10 is only +the client traffic emitted by `ubnt-upg`; it must be carried, tagged, from the +U6 Lite through every intervening switch/link to `gfw`. Ubiquiti explicitly +states that selecting a network for an SSID makes connected clients members of +that VLAN and that all ports between AP and gateway must permit its VLAN ID; +it recommends AP uplinks be trunked for the relevant VLANs. [Creating UniFi +WiFi SSIDs](https://help.ui.com/hc/en-us/articles/26136823938583-Creating-UniFi-WiFi-SSIDs) + +On a managed UniFi switch, this means the AP uplink and every upstream port in +the path have native LAN66 (for AP management) plus tagged VLAN 10. Ubiquiti +defines that as a trunk, and warns that an AP uplink must not restrict VLANs +needed downstream. [Switch Port VLAN Assignment](https://help.ui.com/hc/en-us/articles/26136855808919-Switch-Port-VLAN-Assignment-Trunk-Access-Ports) + +If a non-UniFi switch is in the path, its 802.1Q settings must be configured +equivalently (or it must be verified to transparently forward VLAN 10); UniFi +does not manage that switch. This is a physical/L2 requirement, so merely +creating a controller network cannot make a VLAN reach `gfw`. + +## Local feasibility result + +The local `gfw` instance is a VM attached only to untagged LAN 66, and the U6 +Lite's physical path is the same ER-X LAN 66 network. No VLAN-capable physical +trunk or verified hypervisor/vSwitch VLAN handoff exists between them. The +diagram above is therefore a valid design pattern but **not a description of +the current deployable topology**. An `eth0.10` interface inside the VM cannot +create that missing L2 path. + +To make this architecture feasible, add a VLAN-capable switch/trunk from AP to +gateway, or configure an end-to-end tagged VLAN handoff through the hypervisor +and its physical uplink. Until then, leave the ER-X LAN 66 DHCP design in place +and do not expect `gfw` to serve an SSID-only subnet. + +## Correct controller model (after the L2 prerequisite exists) + +Use one UniFi virtual network for VLAN 10 whose **Router** is **Third-party +Gateway** and whose VLAN ID is `10`; assign that network to Wi-Fi +`ubnt-upg`. Configure the subnet, VLAN and DHCP on the VLAN gateway first. +This follows Ubiquiti's documented third-party-gateway workflow: create the +VLAN on the gateway, then add a UniFi virtual network with Router = +Third-party Gateway and the matching VLAN ID. [Creating Virtual Networks +(VLANs)](https://help.ui.com/hc/en-us/articles/9761080275607-Creating-Virtual-Networks-VLANs) + +Do not enable a second DHCP service in UniFi for this VLAN. The controller +entry is the AP/switch VLAN definition; the gateway on VLAN 10 remains the +sole DHCP server and default gateway. The EdgeRouter X's LAN66 DHCP service +can remain unchanged because it is for untagged LAN66, not VLAN 10. + +## Safe verification sequence + +1. Read-only confirm on `gfw` that its VLAN-10 interface has + `192.168.10.1/24`, DHCP is enabled for `192.168.10.0/24`, and no other + DHCP daemon serves that VLAN. +2. In the controller, verify `ubnt-upg` selects the Third-party Gateway VLAN + 10 network, not `Default`/LAN66 and not an unassigned VLAN-only placeholder. +3. Trace the U6 Lite-to-`gfw` L2 path and permit tagged VLAN 10 on every link + while retaining LAN66 as the AP's native/management network. +4. Reconnect a test client (forget/rejoin or renew lease). The expected lease + is `192.168.10.x`, gateway/DNS `192.168.10.1` (or the DNS option configured + by `gfw`), never `192.168.66.x`. +5. Confirm a lease appears on `gfw` and that the VLAN-10 interface's RX/TX + counters advance. Ubiquiti's VLAN troubleshooting guide identifies + upstream ports not allowing the VLAN as the common cause when Wi-Fi clients + cannot receive a correct IP address. [Virtual Network (VLAN) + Troubleshooting](https://help.ui.com/hc/en-us/articles/9592924981911-Virtual-Network-VLAN-Troubleshooting) + +## What the observed `192.168.66.91` proves + +It is evidence that the client's DHCP discover reached the LAN66 broadcast +domain and was answered by the EdgeRouter X. It does not show a DHCP failure +on `gfw`; it shows that the client was bridged untagged (or VLAN 10 was not +carried end-to-end) at that attempt. The corrective work is therefore to make +the SSID-to-VLAN association and L2 trunk path real, then test the lease—not to +make the AP/controller compete with the LAN DHCP server. diff --git a/hosts/dns.windy.lan.md b/hosts/dns.windy.lan.md index f5b2fee..0b0e0ef 100644 --- a/hosts/dns.windy.lan.md +++ b/hosts/dns.windy.lan.md @@ -7,6 +7,7 @@ | IPv4 | `192.168.66.36` | | SSH | `ssh -4 windy@192.168.66.36` | | OS | Debian 12 | +| **Host** | **PVE VM 120 (`pihole`)** — not a separate physical host (verified 2026-08-09) | | Roles | AdGuard Home LAN DNS; Mihomo explicit-proxy service | Use `windy` for routine inspection. Do not store credentials, AdGuard Home diff --git a/hosts/gfw.windy.lan.md b/hosts/gfw.windy.lan.md index ca22639..729e9a1 100644 --- a/hosts/gfw.windy.lan.md +++ b/hosts/gfw.windy.lan.md @@ -8,6 +8,7 @@ | IPv4 | `192.168.66.1` | | SSH | `ssh -4 root@192.168.66.1` (key-only, verified 2026-08-06) | | OS | ImmortalWrt 25.12.0 (r37854), Linux `6.12.87`, x86/64 | +| **Host** | **PVE VM 140 (`gfw`)** — dual NIC: `net0`→vmbr0(LAN66), `net1`→vmbr1(LAN55) (verified 2026-08-09) | Do not store the root password in this repository. @@ -42,6 +43,21 @@ OpenClash runs `/etc/openclash/clash` (clash_meta core) with configuration `8443` is not an OpenClash listener and has no runtime nftables forwarding rule. It is included only in OpenClash's common TLS-sniffing port list. +## VLAN 10 Wi-Fi feasibility + +`gfw` is a VM attached to untagged LAN 66, rather than a physical VLAN-trunk +endpoint. The U6 Lite likewise reaches the ER-X over LAN 66, whose DHCP +service supplies client addresses. Therefore `gfw` cannot currently receive an +SSID's VLAN 10 traffic merely by creating an `eth0.10` interface inside the VM. + +Do not treat a local `eth0.10`/`192.168.10.1` configuration as a deployable +Wi-Fi gateway unless the hypervisor/vSwitch and the complete physical path to +the AP have first been configured and verified to carry tagged VLAN 10. The +`ubnt-upg` test receiving a `192.168.66.x` lease was the expected consequence +of the available untagged path, not evidence that this host should compete +with ER-X DHCP. See +[UniFi Network: Dedicated Wi-Fi through a third-party gateway](../docs/unifi-network.md#dedicated-wi-fi-through-a-third-party-gateway). + ## Operational note When OpenClash logs a LAN client request such as @@ -50,4 +66,3 @@ an explicit-proxy client sending its own loopback request to the gateway. Fix the originating host's `NO_PROXY` / `no_proxy` configuration; do not create a listener on this router to mask the problem. See [the UniFi localhost proxy note](../docs/unifi-openclash-localhost.md). - diff --git a/hosts/ubnt.md b/hosts/ubnt.md index 9ad4d49..d4c8527 100644 --- a/hosts/ubnt.md +++ b/hosts/ubnt.md @@ -8,6 +8,7 @@ | IPv4 | `192.168.66.46` | | SSH | `ssh -4 windy@192.168.66.46` | | Hostname | `ubnt` | +| **Host** | **PVE VM 160 (`ubnt`)** — not a separate physical host (verified 2026-08-09) | | Privilege | `windy` has passwordless sudo and is in the `docker` group | The current SSH ED25519 host-key fingerprint is diff --git a/inventory/hosts.md b/inventory/hosts.md index 09fac87..6b6a248 100644 --- a/inventory/hosts.md +++ b/inventory/hosts.md @@ -23,10 +23,10 @@ the software deployed there, see [the LAN overview](../docs/lan-overview.md). | pdns.wsvc.info | Poweradmin UI | — (HTTPS) | → hk2 | active | see hk2 | | pgweb.wsvc.info | PowerDNS Postgres UI | — (HTTPS) | → hk2 | active | see hk2 | | **synapse.chans.xyz** | Matrix homeserver (ESS: Synapse + MAS + Element) | `ssh -4 windy@synapse.chans.xyz` | `169.58.86.13` | **active** | [hosts/synapse.chans.xyz.md](../hosts/synapse.chans.xyz.md) | -| **gfw.windy.lan** | OpenWrt (ImmortalWrt) LAN gateway / OpenClash | `ssh -4 root@192.168.66.1` | `192.168.66.1` | **active** | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) | -| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | **active** | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) | +| **gfw.windy.lan** | OpenWrt (ImmortalWrt) LAN gateway / OpenClash (PVE VM 140) | `ssh -4 root@192.168.66.1` | `192.168.66.1` | **active** | [hosts/gfw.windy.lan.md](../hosts/gfw.windy.lan.md) | +| **dns.windy.lan** | AdGuard Home LAN DNS + Mihomo explicit proxy (PVE VM 120) | `ssh -4 windy@192.168.66.36` | `192.168.66.36` | **active** | [hosts/dns.windy.lan.md](../hosts/dns.windy.lan.md) | | **gw** | EdgeRouter X primary LAN gateway | `ssh -4 zhiqiang@192.168.66.254` | `192.168.66.254` | **active** | [hosts/gw.md](../hosts/gw.md) | -| **ubnt** | UniFi Network Controller | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | **active** | [hosts/ubnt.md](../hosts/ubnt.md) | +| **ubnt** | UniFi Network Controller (PVE VM 160) | `ssh -4 windy@192.168.66.46` | `192.168.66.46` | **active** | [hosts/ubnt.md](../hosts/ubnt.md) | `status: stub` = known to exist; fill `hosts/.md` when next touched. diff --git a/linear-workflow.config.yaml b/linear-workflow.config.yaml new file mode 100644 index 0000000..eaf364d --- /dev/null +++ b/linear-workflow.config.yaml @@ -0,0 +1,2 @@ +version: 1 +profile: minimal