折腾一上午才发现：原来是 mwan3 把我的 IPv6 悄悄丢进了黑洞——一次 OpenWrt IPv6 假连通排障实录
摘要
WAN6、DHCPv6、Prefix Delegation 全部正常，OpenWrt 却始终无法访问公网 IPv6。本文记录一次真实的 OpenWrt IPv6 假连通故障排查过程，并解释为何 mwan3 残留策略路由会让 IPv6 流量掉进 blackhole。
折腾一上午才发现：原来是 mwan3 把我的 IPv6 悄悄丢进了黑洞
很多人判断 IPv6 是否正常，往往只看 WAN6 有没有拿到公网地址、Prefix Delegation（PD）是否成功下发，或者 AAAA 记录能否正常解析。但一次真实的排障经历说明：这些指标全部正常，并不代表 IPv6 真正可用。
这次故障发生在一台运行 eSir OpenWrt 的家庭网关上。运营商为中国电信，光猫桥接，OpenWrt 负责 PPPoE 拨号，下游连接华硕 AP 和多台终端设备。表面上看，整个 IPv6 配置没有任何异常，但公网 IPv6 访问始终失败。最终发现，真正的问题并不在运营商，也不在 DHCPv6，而是一个早已被遗忘的 mwan3 组件。
故障现象：所有指标正常，唯独无法访问 IPv6
最初发现问题的方式非常简单：
ping6 ipv6.google.com结果持续超时。
按常规思路检查后发现：
- WAN6 已成功获取公网 IPv6 地址
- DHCPv6 工作正常
- Prefix Delegation 成功下发前缀
- DNS 可以正常解析 AAAA 记录
- traceroute6 已经能够进入运营商骨干网络
如果只看这些指标，大多数人都会认为 IPv6 已经完全恢复正常。
然而现实情况却是：IPv6 实际不可用。
为什么这类问题特别容易误判
很多用户对 IPv6 连通性的理解仍停留在“拿到地址就算成功”的阶段。
实际上，一个完整的 IPv6 通信过程至少涉及多个环节：
- 获取公网 IPv6 地址
- 获取 Prefix Delegation 前缀
- LAN 正确广播 IPv6 信息
- DNS 返回 AAAA 记录
- 路由表存在正确出口
- 策略路由不拦截流量
- 防火墙允许相关数据包通过
只要其中任意一个环节出现问题，都可能导致最终访问失败。
而本次故障最大的迷惑性在于：前面几个环节全部正常。
排查思路：从运营商一路怀疑到自己
在发现 ping6 完全不通后，首先怀疑的是运营商侧问题。
随后检查光猫桥接配置、PPPoE 拨号状态、IPv6 前缀获取情况，均未发现异常。
继续检查 OpenWrt 网络配置、DHCPv6 参数以及 DNS 设置，同样没有发现明显错误。
由于 traceroute6 已经能够看到运营商骨干网节点，因此网络似乎又不像完全中断。
这种“看起来正常、实际上不通”的状态，让排查过程变得异常困难。
真正的问题：mwan3 遗留策略路由
转折点来自对系统路由策略的进一步检查。
执行：
ip -6 rule发现系统中存在与 fwmark、blackhole、unreachable 相关的 IPv6 策略路由规则。
继续检查：
ip6tables-save发现大量 mwan3 自动生成的规则链。
最终确认系统中仍安装着：
mwan3
luci-app-mwan3虽然当前网络环境已经不存在多 WAN 或负载均衡需求，但这些遗留规则仍然参与 IPv6 流量决策。
mwan3 到底是什么
mwan3 是 OpenWrt 中常见的多线路管理组件（Multi WAN Manager）。
它主要用于：
- 双 WAN 接入
- 多运营商出口
- 负载均衡
- 故障自动切换
- 基于策略的流量分流
其核心机制是利用防火墙标记（fwmark）与策略路由（Policy Routing）控制不同流量走向不同出口。
当配置完整且维护得当时，mwan3 十分强大。
但如果曾经启用过多 WAN、测试过负载均衡，随后又修改网络结构，却没有同步清理相关配置，就可能留下失效规则。
对于 IPv6 而言，这些规则有时会把数据包导向 blackhole（黑洞路由）或 unreachable（不可达路由），导致流量在本机就被直接丢弃。
为什么 traceroute6 正常而 ping6 失败
这是本次故障最容易让人困惑的地方。
策略路由问题并不一定会影响所有类型的数据包。
不同协议、不同目的地址、不同标记状态下，流量可能匹配不同规则。
因此可能出现：
- DNS 正常
- traceroute6 正常
- 部分 IPv6 网站可访问
- ping6 全部失败
这种状态通常被称为“假连通”。
从用户视角来看，网络似乎已经恢复；但从实际业务角度看，IPv6 仍然处于异常状态。
最终解决方案
确认问题来源后，处理方式非常直接：
停止服务：
/etc/init.d/mwan3 stop关闭开机启动：
/etc/init.d/mwan3 disable重启网络：
service network restart随后再次验证：
ping6 ipv6.google.com
ping6 240e:42:c000::1
curl -6 ip.sbIPv6 连通性恢复正常。
排查 OpenWrt IPv6 时值得优先检查什么
如果遇到类似情况，可以按照以下顺序检查：
- `ip -6 addr` 查看地址是否正常获取
- `ip -6 route` 查看默认路由是否存在
- `ip -6 rule` 查看是否存在异常策略路由
- 检查 mwan3 是否仍在运行
- 检查防火墙自定义规则
- 使用 `curl -6 ip.sb` 验证实际出口
- 使用多个目标地址交叉验证
相比单纯查看 WAN6 状态，这些检查更容易发现隐藏问题。
写在最后
这次故障最大的启示是：IPv6 是否正常，不能只看地址是否获取成功。
WAN6 有地址，不代表 IPv6 正常；PD 下发成功，不代表 IPv6 正常；DNS 能解析 AAAA 记录，也不代表 IPv6 真正可用。
真正的 IPv6 连通性依赖地址获取、路由表、防火墙、策略路由以及出口路径共同工作。
对于长期折腾 OpenWrt 的用户来说，最危险的往往不是当前配置，而是那些早已忘记、却仍然在后台发挥作用的历史配置。mwan3 本身并不是问题，但当网络结构已经发生变化时，残留的策略路由规则很可能成为排查过程中最容易被忽略的“隐形故障源”。