vps/docs/se5420-review-claim-verification-2026-08.md

SE5420 实施评审主张核实（2026-08-10）

核对基准（历史快照）： 本文于 2026-08-10 针对 lan-se5420-deployment-guide.md 的评审前版本（35577d0）撰写。该指南自 ffb37a9（"finalize SE5420 deployment guide per review"）起已按本评审修订，当前 origin/main 章节已重组：旧 §3.3 → §4.3、旧 §6（gfw）→ §11、旧 §7（SSID）→ §12、旧 §9（验收/IPv6）→ §13 + §11.4。文末「当前指南处理情况」列出各主张的现行状态；实施以部署指南现行为准。

范围。 本文核对对 lan-se5420-deployment-guide.md 的评审意见。结论分为 “已证实”（规范/一手资料直接支持）、“基本证实”（架构推论成立但仍须读取现场配置）和 “需现场核实”（不能仅由文档或产品手册断言）。这不是实施变更，也不替代维护窗前的 uci show firewall、交换机当前 VLAN 表和 PVE bridge 配置检查。

核实结论

评审主张	结论	依据与限定
firewall.ubunt_upg.masq=1 是错误方向，应在实际出站的 wan zone 做 IPv4 NAT	已证实	OpenWrt 明确规定 masquerade 是按出站 zone/interface控制；masq 通常在 wan。因此，对 ubunt_upg → wan 流量把 masq 放在源 zone 不是该需求的正确 zone 语义。若 wan 已 masq，不应重复开启；也可用 masq_src 只限 192.168.10.0/24。见 OpenWrt firewall configuration 和 fw4 masq 测试。
ubunt_upg → wan 允许所有经 gfw wan 可路由的目的地，不等于只上互联网	已证实	forwarding 的 src/dest 是 zone-to-zone 单向许可，未按“Internet”语义区分目标 IP；规则可用 dest_ip 限制。故若 gfw 的 wan 接在 LAN66 且 ER-X 可路由 LAN55，评审所列 LAN66/LAN55 风险成立。最终可达网段仍须以 gfw 路由表、ER-X 路由/防火墙现场检查为准。见 OpenWrt forwarding/rule 参考。
不应把 ubunt_upg.forward 改为 ACCEPT；forward_policy 不是必要的标准 zone 选项；匿名 uci add 不可重复执行	基本证实	OpenWrt zone 的标准项是 forward，forwarding 是独立 section，参考页未定义 forward_policy。单独的具名 forwarding 足以允许跨 zone 路径，因此保持 zone 内 forward=REJECT 是较小权限配置。匿名 section 每执行一次都会新增一节，这是 UCI 的操作语义；实施应先读现场配置并使用具名 section。
VLAN10 必须有显式 IPv6 策略，否则可能绕过仅 IPv4 的 NAT/隔离	已证实	fw4 将 masq（IPv4）和 masq6（IPv6）分开；forwarding 默认 family 是 any。仅写 IPv4 DHCP/NAT/地址规则不能表达 VLAN10 的 IPv6 RA、DHCPv6、路由和过滤策略。是否已经存在可用 IPv6 前缀、以及 OpenClash 是否接管 IPv6，必须现场验证。见 OpenWrt firewall configuration。
管理 SVI + 默认路由与“不开 SVI/静态路由/一切 L3”矛盾	已证实	指南（历史版）§3.3 同时要求 VLAN66 192.168.66.253/24 与默认路由，又要求不开 SVI/静态路由。TL-SE5420 官方称其为三层交换机，支持静态路由、RIP、DHCP server/relay。准确目标应是：仅保留 VLAN66 管理 L3 interface/默认网关，不给 VLAN55/10 建 L3 interface，且禁用不需要的 L3 服务和跨 VLAN routing。见 TL-SE5420 官方页 与 官方安装手册。
必须明确移除 VLAN1 成员，PVID 变更本身不等于 access-port VLAN membership	已证实	PVID/native VLAN 只处理进入端口的未标记帧；access/trunk 的允许 VLAN 列表是独立概念。指南（历史版）§3.3 只列 VLAN66/55 member 和 PVID，未写移除 VLAN1 或 ingress filtering。验收应检查 VLAN1 member、VLAN1 管理 IP、端口允许 VLAN 和 tagged-frame ingress policy。见 Ubiquiti 对 native/tagged/access/trunk 的定义（术语与 802.1Q 语义）以及 Linux bridge VLAN 配置示例（显式 bridge vlan del ... vid 1）。TL-SE5420 具体 GUI/CLI 行为仍以其固件手册核验。
NAS 不应在未先完成双端 LACP 时同时接两口；LACP 不使单 TCP 流自动达到 5G	基本证实	这是标准二层环路/聚合变更控制结论：没有已协商的 LAG 时，两条同 VLAN 并行链路会构成潜在环路；STP 只能作为保护而非实施方法。官方产品页列出 LACP 相关资料，但本次未取得 TL-SE5420/TrueNAS 对端的精确配置与当前 NAS 连接状态，故“必然环路/双 IP”不能在桌面审阅中断言。单连接吞吐受链路散列限制是 802.3ad 的常见实现特性，应以 NAS 与交换机的 hash policy 和 iperf3 实测验收。
非 VLAN-aware 的 PVE vmbr0 不提供 VLAN10 的端口级隔离	已证实	PVE 将 bridge 描述为虚拟交换机；VLAN-aware mode 才能给 guest NIC 赋 VLAN tag，或显式 trunk。Linux 内核说明：vlan_filtering=0 时 bridge 不考虑 VLAN tag，且默认关闭；开启后才按 MAC 和 VLAN tag转发及进行严格 VID 检查。因此“共享非 VLAN-aware bridge 可让可控 guest 主动消费 VLAN10，不能作为严格隔离边界”成立。不能仅凭该结论断言每个 guest 必定收到每个单播帧：未知单播/广播会泛洪，已学习的单播会按 FDB 转发。见 PVE 网络配置 和 Linux bridge 文档。
AP VLAN10 tagged frame 在一个普通 untagged LAN66 access path 上会“自动去 tag 并泄漏到 LAN66”	不成立／需改写	802.1Q 的 native VLAN 是对未标记流量的 VLAN；tagged VLAN 需被显式允许于 trunk。因此通常的正确表述是：若上游不允许 VLAN10 tag，AP 到 VLAN10 网关/DHCP 的路径不存在，SSID 会成为不可用入口。实际设备的端口模式（包括是否错误地配置为 all/trunk、是否接受 tagged ingress）须现场查看，不能泛称必然去标签。见 Ubiquiti VLAN 端口定义 和 Ubiquiti VLAN troubleshooting。
仅保留 SSH 会话不是移动 PVE/ER-X 物理上联时的真正带外回滚路径；应全程保持 SE5420 Console	已证实	这是直接的操作依赖判断：TCP SSH 的承载链路被拔除时会断，不能证明回滚可达。TL-SE5420 官方安装手册确认该机有 Type-C Console，且本仓库指南本身也把恢复出厂流程建立在 Console 上。故应在迁移前接通 Console、标注旧/新端口、逐根迁移并用 MAC 表与链路/错误计数验证。见 官方安装手册。
“所有设备均不得直连 ER-X”不是避免环路的必要条件	已证实	环路取决于同一 L2 广播域存在多条并行二层路径，不取决于是否还有一个独立终端直接接 ER-X。应禁止的是一个下级交换机/桥接主机同时形成平行路径。此项仍需以 ER-X switch0 VLAN/bridge 现场配置和实际接线图确认。
性能不应承诺全面 2.5G；同 VLAN 才可能在 SE5420 本地交换超 1G，跨 55/66 与 Internet 受 ER-X/宽带限制	已证实	TL-SE5420 的 2.5G 端口仅提高经其本地二层转发的链路上限；跨子网必须由网关路由，Internet 另受 WAN/PPPoE 约束。产品页确认 16×2.5G + 4×10G SFP+，但 ER-X、NAS、PC、AP 的实际协商速率和 NIC/布线能力必须由 ethtool/端口状态及 iperf3 验证。见 TL-SE5420 官方规格。

已核对的文档内事实

现行指南的历史版本（35577d0）确实包含评审指出的关键文字：旧 §3.3 的管理 IP/默认路由与“不开 SVI/静态路由”；旧 §6 的 ubunt_upg.masq、forward=ACCEPT、forward_policy、匿名 forwarding；旧 §7 只验“不可达 LAN66”；旧 §9 对新增 VLAN10 写“IPv6 行为与升级前一致”。因此上述评审不是对未出现内容的假设。

但这些内容在 ffb37a9 起的修订中已被修正或重组：ubunt_upg.masq 与 forward_policy 已删除，gfw 防火墙改为 §11（§11.3 第 2 步明确“不要给 ubunt_upg zone 加 masq”）；VLAN10 IPv6 在 §11.4 显式写为“本阶段不提供”；SVI/L3 边界在 §4.3 第 16 步单列“L3 明确边界检查”。本文按历史快照保留评审结论，读者应以现行部署指南为准。

本仓库的 hosts/gfw.windy.lan.md 还记录 gfw 的 eth0 在 LAN66、eth1 在 LAN55，故 ubunt_upg → wan 的隔离结论应在执行前以当前 ip route、uci show firewall、nft list ruleset 复核，而不能从方案文字直接把规则写死。

gfw 现场只读复核（2026-08-10）

已通过 ssh -4 root@192.168.66.1 仅读取配置和运行规则，未修改设备。该结果会改变 评审中两项“当前状态”的表述：

现场事实	对评审的影响
wan zone 已有 masq='1'；现有配置另有具名 ubunt_upg_nat，运行时渲染为 oifname "eth0" 且只匹配 ip saddr 192.168.10.0/24 masquerade。	“必须在 wan 开 masq”的方向原则正确，但“当前无 masq”不正确。现有显式 SNAT 已在实际出 eth0 时执行；计划中再将 masq 加到 ubunt_upg 仍是多余且方向错误。
当前放行是具名 ubunt_upg_to_lan，不是 ubunt_upg→wan；其运行链先拒绝 192.168.66.0/24，再允许到 lan。gfw 的 IPv4 default route 是 192.168.66.254。	计划新增 ubunt_upg→wan 会是与当前设计不同、过宽的改动。现有 LAN66 阻断规则在该链中先匹配；但对经 ER-X 可达的 LAN55/其他内网仍没有显式拒绝，故隔离评审的剩余风险成立。应以明确内网前缀 deny + 所需外网 allow 重写，而不是加 WAN forwarding。
ubunt_upg DHCPv6 和 RA 都是 disabled；运行路由表仅有各接口的 IPv6 link-local route，没有 IPv6 default route；全局 IPv6 forwarding 是 1。	评审“VLAN10 未明确 IPv6 策略”的表述对计划文本仍成立，但“IPv6 可能立即绕过”的事实判断在当前状态未获证实：现有 RA/DHCPv6 已关闭且无 IPv6 默认路由。实施文档仍应把这项显式写为“IPv6 不提供”，并在启用前复查。
系统是 ImmortalWrt 25.12.0，/usr/bin/apk 存在（apk-tools 3.0.5）。	评审中“ImmortalWrt 21.02.5 应使用 opkg”的版本判断错误/过时；在本机上 apk add tcpdump 是可用包管理器。仍应先检查软件包可用性，避免在维护文档中把两种命令并列为未经验证的替代方案。

这些命令输出未含凭据、令牌或私钥，故仅记录了安全相关的摘要；不将完整防火墙快照提交至仓库。

当前指南处理情况（2026-08-13 核对）

对 origin/main（2fd354c）逐项核对评审主张：

评审主张	现行状态	现行位置
ubunt_upg.masq=1 方向错误	✅ 已修复	§11.3 第 2 步「不要给 ubunt_upg zone 加 masq」
ubunt_upg→wan 不等于只上互联网	⚠️ 原则成立，指南已禁止新增宽泛 forwarding；LAN55/RFC1918 显式 deny 仍为待办	§11.1b「待补缺口」、§11.3
勿改 forward=ACCEPT；无 forward_policy；匿名 uci 不可重复	✅ 已修复	§11.3 第 1 步保持 REJECT；指南已无 forward_policy
VLAN10 须显式 IPv6 策略	✅ 已修复	§11.4「本阶段不提供 VLAN10 IPv6」
管理 SVI + 默认路由 vs「不开一切 L3」矛盾	✅ 已消解	§4.3 第 16 步「L3 明确边界检查」
须移除 VLAN1 成员；PVID≠membership	✅ 指南已加强；现网仍偏离（W1N-54）	§4.3 第 9–12 步；VLAN1 不可删说明
NAS 双口未 LACP 前勿并行	✅ 已体现	§7 第 7 步「仅口 8，口 12 断开」
非 VLAN-aware PVE bridge 不能作隔离边界	✅ 已体现	§9.2 要求 VLAN-aware + bridge-vids
AP tagged 帧在 access 口自动去 tag	✅ 本文已纠正（不成立）	—
SSH 非真正带外；须 Console	✅ 已体现	开头第 2 条、§4.1、§16
「所有设备不得直连 ER-X」非必要	✅ 已体现	全程三条第 1 条、§7
不应承诺全面 2.5G	✅ 已体现	§8 第 7 条、§14

实施前的最低限度现场证据

1. gfw：保存并审阅 uci show firewall、ip route、ip -6 route、nft list ruleset；确认 wan 的 masq 与所有 WAN→内网、VLAN10→内网匹配次序。
2. SE5420 Console：导出/截图 VLAN1、55、66 member 和 PVID/ingress-filter 状态；确认唯一管理 L3 interface 和路由/relay/DHCP 状态。
3. PVE：记录 /etc/network/interfaces、VM NIC VLAN tags 和 bridge vlan show，再决定是否把 VLAN-aware 改造另开窗口。
4. AP：从实际设备 info 或控制器记录确认 Inform URL（本仓库目前记录 http://192.168.66.46:9080/inform），并验证 VLAN10 tag 只经 U6/PVE trunk。
5. NAS：单网口稳定后，另窗配置并验证两端 LACP，第二根线最后插入；用多流及单流 iperf3 分开验收。