5G CPE + iStoreOS/iKuai IPv6 穿透折腾实录：从失败到主旁路由重构
在 5G CPE 环境下，iStoreOS（OpenWrt）因 DHCPv6-PD 协议兼容性问题无法获取 IPv6 地址。本文记录了从排查失败、跨系统测试到最终重构为主旁路由架构，成功实现全网 IPv6 推送与 EasyTier P2P 穿透的完整过程。
阶段一：iStoreOS (OpenWrt) 直连获取 IPv6 失败与排查
现象记录： 将直通物理网卡分配给 iStoreOS 作为主路由连接 CPE。iStoreOS 的 WAN6 接口状态显示"未启用"，无法获取 IPv6 地址。
PC 直连交叉测试： 将物理网线从服务器拔下直连 Windows 电脑，电脑通过 SLAAC（无状态地址自动配置）成功获取公网 IPv6 地址。此测试确认了 CPE 的 IPv6 下发功能正常，但存在 MAC 地址绑定机制（CPE 的 /64 网段会锁定首次通信的设备 MAC）。
协议差异分析：
- 前缀委派 (PD) 限制：5G 移动基站通常不提供 IPv6 子网前缀（Prefix Delegation）。CPE 只能向下游设备分配单点 IP。
- OpenWrt 客户端逻辑：iStoreOS 默认的 odhcp6c 进程严格遵循 DHCPv6-PD 标准，默认参数为
reqprefix 'auto'。当向 CPE 请求前缀失败时，iStoreOS 拒绝配置单一的 IPv6 地址。 - 底层配置干预：尝试通过 SSH 修改
/etc/config/network，将 WAN6 的reqprefix设为no，并修复/etc/config/dhcp中遗留的大小写匹配错误（wan6与WAN6冲突）及多 master 冲突。重置网络后，由于 OpenWrt 底层客户端与该 CPE 的 SLAAC 广播逻辑不兼容，仍无法稳定获取 IP。
阶段二：引入 iKuai 进行跨系统变量测试
测试准备： 在 PVE 环境中关闭 iStoreOS，将同一块直通网卡分配给 iKuai 虚拟机。
重置 CPE 缓存： 断开 5G CPE 电源 30 秒，清空基带芯片中的 MAC-IPv6 绑定记录。
iKuai 获取状态： iKuai 启动后，WAN1 接口通过 DHCPv6 模式瞬间获取到 240e: 开头的 IPv6 地址，后缀掩码为 /128。
机制确认： 此结果证实了网络链路与直通网卡硬件无故障。iKuai 的 DHCPv6 客户端逻辑允许在无 PD 前缀的情况下接收并使用 /128 单点地址，从而兼容了该 5G CPE 的分配机制。
阶段三：网络拓扑重构（主旁路由架构）
基于上述协议兼容性差异，将网络拓扑调整为 iKuai 主路由 + iStoreOS 旁路由 架构。
1. iKuai 主路由配置
- 承接外部网络：负责拨号及 IPv6 地址的直接获取。
- 开启 IPv6 中继：在 iKuai 内网设置中开启 IPv6 中继模式，将 CPE 的路由通告（RA）广播包透传至局域网。
2. iStoreOS 旁路由克隆与配置
- 硬件调整：在 PVE 中对原 iStoreOS 进行"完整克隆"。在克隆机的硬件设置中移除物理直通网卡，仅保留桥接到
vmbr0（局域网交换机）的虚拟网络设备。 - 接口裁剪：登录旁路由后台，删除原有的 WAN 和 WAN6 接口，仅保留 LAN 接口。
- 网关与 DNS 指向：将 LAN 接口的 IPv4 网关和自定义 DNS 指向 iKuai 的局域网 IP（例如
192.168.10.1）。 - 停用 DHCP 服务：在 LAN 接口的 DHCP 服务器设置中勾选"忽略此接口"，并在 IPv6 设置中将路由通告、DHCPv6 服务、NDP 代理全部设为"禁用"，将 IP 分配权完全交还给 iKuai。
阶段四：SLAAC 终端分配与 P2P 验证
地址获取逻辑转变： 在旁路由架构下，iStoreOS 接入局域网的身份从"网关路由器"转变为"普通客户端设备"。它不再主动请求 DHCPv6-PD。
EUI-64 地址生成： 局域网内的安卓手机、Windows 电脑以及 iStoreOS 旁路由，接收到 iKuai 中继过来的 RA 广播后，均通过 SLAAC 协议结合自身的 MAC 地址（EUI-64 算法），自动计算并生成了 240e: 开头的公网 IPv6 地址。
穿透验证： iStoreOS（br-lan 接口）获得公网 IPv6 后，其内部部署的 EasyTier 节点识别到公网环境。外部设备通过原生 IPv6 网络接入时，无需通过远端 Relay 服务器转发，直接通过底层的 IPv6 路由建立 P2P（点对点）直连，延迟和带宽达到物理链路标准。
