WireGuard IPv6 DNS 快速配置与故障排查全指南

• 为什么你的 WireGuard 在 IPv6 下 DNS 会“失灵”
• 先看常见症状与本质差异
• 核心原理：WireGuard 与 IPv6 DNS 如何协同
• 排查思路：从用户层到内核层逐步缩小范围
• 1. 验证接口与路由
• 2. 检查 DNS 配置来源
• 3. 测试 DNS 解析路径
• 4. 确认 IPv6 连通性与路由返回路径
• 5. MTU 与分片问题
• 6. 防火墙与邻居发现
• 典型案例：DNS 看似正常但连接超时
• 常用工具与它们的角色
• 实务建议（无需改动配置文件就能做的检查）
• 遇到特殊环境时的注意点
• 小结性提示（便于快速回顾）

为什么你的 WireGuard 在 IPv6 下 DNS 会“失灵”

部署 WireGuard 后，IPv6 环境下的 DNS 问题常比 IPv4 更难排查。原因在于 IPv6 的地址分配、路由与邻居发现机制与 DNS 的交互更复杂：有本地链路地址、全球单播地址、ULA（唯一本地地址）、以及可能的前缀委派（PD）。同时，常见的系统组件（systemd-resolved、NetworkManager、resolv.conf）对 IPv6 的处理各异，导致 DNS 请求可能并未走代理或被错误路由。

先看常见症状与本质差异

常见故障表现包括：

• 可以访问 IPv4 网站，但 IPv6 AAAA 解析失败或解析到错误地址；
• DNS 查询走了本地 ISP，而非 WireGuard 隧道；
• 某些域名能解析但无法通过 IPv6 连接（解析后连接超时）；
• IPv6-only 环境下应用访问完全中断或非常不稳定。

这些现象背后往往是两类问题：一是DNS 路由/策略问题（查询并未发往期望的 DNS 服务器），二是IPv6 地址与路由/MTU/防火墙问题（解析正确但连接不可达）。

核心原理：WireGuard 与 IPv6 DNS 如何协同

理解以下几点可以帮助快速定位问题：

• DNS 是基于 IP 路由的：DNS 请求会走系统路由表决定的出接口。WireGuard 通过创建虚拟接口并添加路由来将流量导入隧道，但这需要正确的表项（尤其是默认路由或特定目标路由）。
• 系统 DNS 管理器影响解析来源：systemd-resolved、NetworkManager、resolvconf 等可能在用户空间拦截并转发 DNS，或使用本地解析器/缓存。如果这些组件的行为与 WireGuard 的路由不配合，查询会走错误的出口。
• IPv6 无 NAT 的习惯：IPv6 通常依赖端到端路由而非 NAT，若服务器端未提供正确的路由/前缀，客户端即使解析出公网地址也无法从隧道到达目标。

排查思路：从用户层到内核层逐步缩小范围

下面给出一套有层次的排查流程，便于快速定位问题来源。

1. 验证接口与路由

确认 WireGuard 接口已建立，且隧道对等端的 IPv6 地址在本机可见。检查路由表中是否存在将目标 DNS 服务器或 2000::/3（全球 IPv6）导向 WireGuard 接口的路由。若没有默认路由被隧道覆盖，则 DNS 请求会走物理接口。

2. 检查 DNS 配置来源

判断系统使用哪个 DNS：resolv.conf 指向哪里，systemd-resolved 是否启用了本地 stub（通常是 127.0.0.53），NetworkManager 是否在管理 DNS。确保 WireGuard 提供的 DNS（若在配置中声明）被相应组件接受并优先使用。

3. 测试 DNS 解析路径

通过工具观察 DNS 查询实际走向：使用能够显示输出接口或捕获封包的工具（例如 tcpdump）观察 DNS 请求是否从 WireGuard 接口发出，是否到达远端 DNS 服务端并有回应。

4. 确认 IPv6 连通性与路由返回路径

解析成功并不等于可达。检查解析到的 AAAA 地址是否通过隧道可达，且服务器端是否知道如何将响应路由回你的隧道地址（尤其在 PD 或自定义前缀环境下）。如果服务器端没有对你的客户端前缀路由，通信会失败。

5. MTU 与分片问题

WireGuard 的 UDP 封装会减少有效 MTU，DNS（TCP 形式的较少）或较大的响应可能导致分片或被丢弃。观察是否在抓包中出现 ICMPv6 分片通告（Packet Too Big）。

6. 防火墙与邻居发现

IPv6 下的 ICMPv6 是必要的（用于路径 MTU、邻居发现等）。若防火墙阻断关键 ICMPv6 类型，邻居解析失败或 PMTU 机制失效会造成看似随机的连接问题。

典型案例：DNS 看似正常但连接超时

一位读者在 fq.dog 社区反馈：WireGuard 隧道建立后，使用指定的 IPv6 DNS 能成功解析 AAAA 记录，但访问这些地址时连接超时。排查步骤回顾：

• 抓包发现 DNS 请求经隧道发出，响应也返回；
• 进一步对解析出的目标地址进行 ICMPv6 测试，发现没有任何回应；
• 检查服务器端路由发现，服务端没有为客户端的 /64 前缀添加回路由；
• 在服务端补充静态路由或启用前缀委派后，连接恢复正常。

结论：DNS 能工作并不代表后续数据流也能通过隧道回程，必须确保双向路由链路完整。

常用工具与它们的角色

• tcpdump/wireshark：观察 DNS（53/udp）、ICMPv6，以及 WireGuard 接口流量，判断查询是否发出、回应是否到达、是否有 PMTU 通告。
• ping6/traceroute6：检测 IPv6 路径和跳数，验证响应链路。
• systemd-resolve / resolvectl：查看 systemd-resolved 状态与 DNS 条目，判断是否存在 split-DNS 或优先级问题。
• ip -6 route / ip -6 neigh：查看路由、邻居表，确认地址分配与可达性。

实务建议（无需改动配置文件就能做的检查）

• 重启网络守护进程（NetworkManager/systemd-resolved）观察 DNS 是否被正确刷新；
• 临时禁用防火墙规则以排除误阻；
• 在客户端运行抓包，确认 DNS 请求的出接口；
• 确认服务端是否为客户端前缀设置了回程路由，或是否在服务端启用了 IPv6 前缀委派；
• 检查并允许必要的 ICMPv6 类型：尽量不要在 IPv6 环境阻断 ICMPv6；
• 留意 MTU：如有“包太大”错误，适当减小 WireGuard 接口 MTU。

遇到特殊环境时的注意点

在 IPv6-only 或 IPv6 优先的网络中，DNS64 + NAT64 可能被用来实现与 IPv4-only 服务的互通。若你的隧道提供方使用 DNS64，客户端应确保查询通过隧道的 DNS，以便生成合成的 IPv6 地址。相反，若 DNS 在本地而非隧道内解析，会导致合成地址缺失或错误。

小结性提示（便于快速回顾）

排除 WireGuard IPv6 DNS 问题时，先确认：接口与路由是否正确、DNS 查询是否实际发往隧道、解析后的地址是否有回程路由、ICMPv6 是否被允许、以及 MTU 是否合适。按层次从 DNS 层到链路层逐项排查，往往能在较短时间内定位问题并修复。

在构建和维护翻墙服务时，关注这些细节不仅能提升稳定性，也能减少因 DNS 泄漏或路由不完整造成的隐私与可达性问题。对于 fq.dog 的读者，理解 IPv6 的端到端特性比依赖 NAT 的 IPv4 环境更关键。