DS-Lite 挡住的是入站 IPv4 托管，不是出站 VPN

DS-Lite 是一种在只承载 IPv6 的接入网上为客户提供 IPv4 连通性的方式。家用路由器没有自己专属的公网 IPv4 地址，仅凭这一事实，人们就认定这条连接上跑不了 IPv4 VPN。出方向通常没有问题。运营商对连接做转换，对端看到的只是一个普通的 IPv4 客户端。出问题的是反方向：托管某种期待未经请求的入站 IPv4 的东西。区别就在于由哪一端发起会话。

由哪一端发起连接

发起连接的客户端会在过程中创建转换状态。运营商的转换设备看到第一个数据包，分配一条映射并转发。回程流量能匹配这条映射，因为映射已经存在。

被动等待连接的服务器没有这样的状态可建。外部必须有人能够到达运营商并未同意映射的地址和端口，那是完全不同的请求。

追踪一次出站请求

架构在 RFC 6333 中给出了两端的名称。客户侧元素是 B4，它把 IPv4 封装进 IPv6。运营商侧元素是 AFTR，它完成地址转换并把数据包作为 IPv4 转发。

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN 服务器收到的是来自运营商转换后地址的普通 IPv4 连接。它不需要 DS-Lite 模式、特殊端口，也不需要知道客户的接入网只有 IPv6。这正是人们忽略的地方：对端根本分辨不出来。

客户端自身的配置同样普通。它需要一条经过 B4 和 AFTR 提供的、能通到服务器的 IPv4 路径，还需要服务器的主机名能解析成 IPv4 地址。

为什么入站托管才是失败的那一类

在家运行 IPv4 VPN 服务器，正是与运营商共享地址方案相冲突的设计。运营商的转换设备掌握公网地址和映射表，没有理由为单个用户建立常驻的入站映射。

家用路由器上的端口转发规则无法配置 AFTR。这条规则在本地设备上真实且正确，却改变不了上游任何东西，所以症状看起来像是永远好不了的防火墙问题。

运营商级转换与单一公网地址的差别也在这里：即使本地转发正确，也可能落到许多用户共享的地址上。

先诊断，再改接入方案

先确认实际开通的模式。原生双栈、DS-Lite，以及使用其他转换机制的纯 IPv6 网络，是三种不同的安排，运营商的营销名称未必与技术要求一致。

然后针对出站故障确立四项观察。客户端是否把 VPN 主机名解析成 IPv4 目的地？纯 IPv4 连通性是否可用，而不是可能悄悄走了 IPv6 的浏览器请求？客户端尝试的是哪种传输和端口，端点日志里到底有没有这次尝试？故障发生在初始交换阶段、空闲一段时间之后，还是只在大流量传输时出现？

这四个答案分别指向过滤、转换状态超时、端点写错或包大小处理。仅仅在账户页面上看到 DS-Lite，一条也证明不了。

仔细阅读运营商侧的变更

账户变更可能与一次正常连接同时发生，却一次性改动多项属性。要记下究竟哪项属性变了，因为新的套餐名称不是技术解释。

“启用双栈”的指示在有人确认运营商实际开通了什么之前都是含糊的。把它当作 IPv4 VPN 客户端的普遍要求，就把猜测变成了政策。

如果真实需求是入站 IPv4 托管，就和运营商讨论受支持的入站方案、原生地址或其他接入设计。如果需求只是笔记本访问远程服务器，那就改问那条具体的出站流量。工作顺序是：说清方向，确认已开通的模式，测试纯 IPv4 和一种传输，只有方向确实需要时才改接入方案。