通过 VPN 使用 IPv6：委派前缀不是地址池

同一天来了两个请求：一台笔记本需要经隧道获得 IPv6，一个小站点则想为其路由器背后的设备获得 IPv6。两者都被用地址打发了，第二个随后花了一周持续失败。角色不同，机制、配置和证明其可用的检查也就不同。本手册把两者分开处理。

第一步：先确定你在服务哪种角色

单台主机需要隧道接口上的一个地址、一条通往远端的路由，下游没有需要编号的东西。隧道背后的路由器则需要一整段可以分发的网络，还要在远端有一条把那些地址指回它的路由。隧道背后是什么，决定了之后每一个决定。

在打开任何配置之前先回答这个问题。这一步之后的一切都取决于你给出的答案。

第二步：单台主机的地址分配

分配隧道地址，确认产品所期望的前缀长度，并检查客户端是为远端范围安装路由，而不是把它丢给本地默认网关。隧道接口上的 /128 对点对点链路是正常的，而那里的 /64 则是在宣称一段没人委派的网络。两份输出能定论：地址表与路由表，两端都要读。要把它们放在一起看，因为路由指向错误接口是这一步最常见的错误。

用两端的地址表和路由表核对，然后发一个请求。如果请求正常发出却没有任何回应，故障在远端的路由上，而不在客户端的地址上。

第三步：隧道背后路由器的委派

前缀委派是与地址分配不同的另一套机制，有自己的请求和自己的租约。委派方必须配置成能发出足够下游网络使用的前缀，请求方路由器则必须用该前缀给内侧接口编号。

不要以为服务移动客户端的地址池就能做委派。许多 VPN 产品只分配单个地址，根本没有委派角色；而到达你边缘的运营商前缀也不会自动传递给对端。记录每个地址池承担的角色，因为两者的配置位置不同。

第四步：把回程路由写明确

两端必须就哪个对端承载哪段前缀达成一致。在远端添加指向隧道的委派网络路由，并确认没有重叠范围已经占用了它。

只有合法前缀而没有回程路由，得到的是一份漂亮的地址规划，却完全没有连通性。没有访问规则的路由会把站点暴露得比预期更多，所以两项改动要在同一个窗口内配对完成，别让半应用状态落到用户身上。

第五步：从路由器背后验证

按顺序检查：客户端上的隧道接口地址、内侧接口上的委派前缀、远端指向该前缀的路由，最后是从路由器背后设备发出的请求。用一个你能控制的目的地，这样静默阻断才能和路由缺失区分开。哪一步让你意外，就该在继续之前先修那一步。

最后一项检查做两遍，一遍从路由器本身，一遍从它背后的设备。路由器能到而客户端不能到，是委派或转发的问题，不是上游的问题。

回滚

改动前保留旧的地址配置，并记下你改的是两套机制中的哪一套。只删委派前缀不删路由会留下黑洞，只删路由不删前缀会留下谁都到不了的地址。两项改动要分开记录，因为撤掉一个而留下另一个，只会让站点在一个方向上不可达。

如果发现某个产品并不支持你需要的角色，就停下来改设计，而不是硬把一个客户端字段拉长去容纳它从来不该容纳的范围。用错机制答复的支持工单，代价比改设计更高。