纯 IPv6 网络会在隧道启动前打断 VPN

笔记本接入只下发 IPv6 的会场 Wi-Fi，VPN 客户端不停转圈并失败，而同一个配置文件一小时前在酒店还能用。凭据没有任何变化。变化的是：客户端现在必须经由只承载 IPv6 的网络抵达 IPv4 目的端，而并非每个客户端都知道该怎么做。

沿着数据包走过的同样五步逐一检查。

第 1 步：观察名称解析

如果配置文件使用主机名，第一个问题就是解析器返回什么。dig AAAA vpn.example.com 在纯 IPv6 网络上会返回真实的 AAAA 记录、由 DNS64 合成的记录，或者什么都返回不了。合成应答把 IPv4 目的端编码在转换前缀里，只有这时没有 IPv6 目的端的客户端才够得着它。而写死 IPv4 地址的配置文件根本走不到这一步，因为没有任何名字可供合成。

就是这一处差异解释了大多数“那边能用、这边失败”的报告，而且一条命令就能看出来。

第 2 步：看客户端调用了哪个地址族

看套接字，而不是进度条。在纯 IPv6 链路上朝 IPv4 地址打开 IPv4 套接字的客户端，根本没有地方把它发出去，失败表现为超时而不是名称错误。客户端连接时用 ss -tanp 可以看到远端地址以及它尝试的地址族。再与 ip -6 route 对照，确认默认路由是真正的 IPv6 下一跳。

套接字表里的地址族才是事实。进度条是别人写的一段摘要。

第 3 步：把转换与隧道分开

NAT64 和 DNS64 是接入网抵达 IPv4 目的端的方式，隧道一旦建立，它们对隧道不做任何事。建在转换路径上的隧道仍然要协商自己的内部编址，而内部 IPv4 或 IPv6 的覆盖是另一个策略问题。如果客户端连上了却什么都到不了，你已经越过了转换，进入了路由，这是另一套证据、另一次排查。

转换失败看起来是从来没连上。内部覆盖失败看起来是连上了却什么都到不了。

第 4 步：在另一个网络上测试同一个配置文件

把同一个配置文件、客户端版本和凭据拿到双栈网络上重做一遍。如果那里能用、只在纯 IPv6 路径上失败，变量就是接入网而不是配置文件。把客户端版本和网络状态写进工单，因为最终的修复是升级客户端或者换一个目的端。

说“VPN 坏了”的报告没法处理。说“只在纯 IPv6 接入下失败”的报告才是缺陷报告。

第 5 步：修路径，而不是改安全设置

那些诱人的修法只会让事情更糟。关闭 IPv6 会拿掉网络提供的唯一路径。把客户端指向公共解析器会破坏 DNS64 合成，因为合成的结果必须来自转换器背后的解析器。关掉证书校验只能让你连上一个你无法确认的东西。这些都不是修复，其中两个还是会比事故活得更久的安全回退。

真正可选的是一个支持网络转换模型的客户端，或者一个具有可达 IPv6 地址的目的端。去要其中之一。