VPN 中的 IPv6 ULA：私有寻址，而非隐私保护

看似私有的地址，并不是大多数人所说的那种私有，IPv6 的唯一本地地址就是最清楚的例子。ULA 前缀为 VPN 提供一份稳定的内部规划，用于其背后的资源。它不加密任何内容，不认证对端，也不决定客户端能访问哪些服务。把前缀当作安全控制，正是本文要消除的错误。

前缀究竟提供什么

RFC 4193 将 fc00::/7 保留给本地使用，L 位区分本地分配的地址空间与保留形式。在实践中，这意味着你生成的是 fd00::/8。规范还定义了 40 位全局 ID 应当如何派生，以免相互独立的站点误选同一前缀。该地址空间被设计为留在公共互联网之外，这属于路由属性，而不是保护。

在一个站点内部，通常的布局是一个 /48 全局 ID 划分为若干子网：一个给隧道客户端，一个给服务器侧，每个远程 LAN 各一个。这个结构就是全部好处，而且是寻址层面的好处。每个数据包仍然需要路由，也仍然需要允许它的策略。

把前缀与隧道混为一谈，正是设计最终记录下 fd00 地址、并假定二者之间的流量受保护的原因。除非另有东西提供保护，否则它并不受保护。

为什么照抄示例前缀会吃亏

每个教程都用一个人人记得住的前缀，而每个照抄的读者都继承同样的冲突风险。两个站点日后通过站点到站点隧道连接，而地址范围相同，就会产生与 IPv4 私有地址重叠时相同的歧义。双方单看都没错，而合并后的网络无法判断指的是哪个目的地。

按文档记录的流程生成全局 ID 只需一分钟，问题也就消失了。把前缀、生成输入和日期记在地址规划旁边。

对在收购后合并网络、或用 VPN 连接两个实验室的人来说，这个风险并不只是理论。对单个站点它也不紧迫，所以一直拖到合并已经排上日程。

范围与访问是两个问题

ULA 并非用于普通的全球路由互联网寻址。这并不会让使用它的每台主机都可信，也不会让这些主机无法从其他已连接的私有网络到达。防火墙和应用权限仍然决定对端能用什么，隧道仍然提供它被配置的那种认证。

互联网出口需要自己的 IPv6 出口设计。给客户端分配 ULA 地址并不会产生通往任意全球目的地的访问，收到这种地址的客户端也不应被指望借它浏览公共互联网。

前缀不同的两个站点仍然需要彼此地址范围的返回路由，两个防火墙也都需要匹配的规则。这一切都不来自地址族本身。真正随之而来的是文档工作：一份前缀表，以及允许在每个前缀上应答的系统清单。

在两端核对规划

确认前缀出现在你以为的位置，然后确认某个目的地确实能经它到达。

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

地址列表显示哪个接口持有哪个子网，收到错误子网的客户端通常会在这里显现。路由列表显示远程前缀是否有经过隧道的路径，而不是被丢弃。测试回答唯一重要的问题：数据包能否往返。

重新连接后要重复检查，因为保留地址却丢失路由的客户端会产生一种看似在线、实则不转发任何东西的连接。地址是容易的部分，消失的往往是路由。把两份输出存在连接配置名称旁边，让下一次比较从证据出发。