为 VPN 客户端使用公网前缀：它到底会破坏什么

因为数字看起来整齐就随手选一个客户端地址池，等于装上去一条随时会发作的路由。VPN 要能用，前缀不一定非要是私有地址；使用一个属于别人的地址段，也不会因此就把你的用户暴露到互联网上。它真正做的是：只要隧道还在，这些地址就代表着另一重含义；而隧道一断开，含义又变一次。请按顺序走完下面五项检查，一旦答案落在「已被别处分配」就停下来。

分配不等于宣告

把地址放在隧道接口上，并不会把它宣告到互联网。公网可达需要一条路由、一条被授权的路径，以及愿意承载它的运营商，而这些都不会因为某个客户端从地址池里拿到了地址就自动出现。防火墙策略和主机授权同样是各自独立的决定。

所以真正的风险和大多数人的假设并不一样。借来的前缀不会让你的客户端变得可达；它做的是让属于别人的目标从你的客户端这边不可达，这是一种成因不同、责任人不同的故障。没有人遭到攻击，也没有任何宣告泄露出去。用户只是打不开昨天还正常的网站，而服务台没有任何理由怀疑 VPN 地址池。

选择地址池时，这个区别很关键。如果你唯一担心的是对外暴露，那么公网段看起来是安全的，因为没有任何东西宣告它。真正的隐患是客户端为这个前缀安装的那条本地路由，而无论别人是否看得见，这条路由都会照样装上。

客户端路由实际捕获了什么

隧道一建立，客户端就会收到一条指向地址池前缀的路由，而这条路由会压过默认路由，覆盖其内部的每一个目标。发往该网段内合法主机的请求，现在会走 VPN 而不是互联网。它是失败、挂起，还是连到了错误的服务器，取决于你这一侧如何处理它。

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

先在隧道开启时执行一次查询，再在隧道关闭时执行一次。同一个地址在前一种情况下是一回事，在后一种情况下完全是另一回事；任何在这段切换期间缓存了连接或域名解析的应用，行为都会前后不一致。这种不一致比干脆的失败更难支持，因为它取决于时机。在错误时刻重连的用户，体验会和没有重连的人不同。

这也是为什么一个眼熟的 IP 地址并不能证明身份。对真实目标仍然要保留证书和服务器名称校验，因为五分钟前你到达的那个数字地址，现在可能属于另一段会话。

把地址池和你认识的每一个网络对比一遍

RFC 1918 划出三个私有用途的地址段：192.168.0.0/16、172.16.0.0/12 和 10.0.0.0/8。数百万个彼此独立的组织在重复使用它们，所以「私有」只是关于分配的陈述，从来不是「没有别人选过同一组数字」的承诺。

把候选地址池与办公 LAN、云上 VPC、其他 VPN 地址池、合作伙伴链路，以及远程员工家里很可能存在的地址范围逐一比对。家里的情况不是你发明一个奇怪前缀的理由，而是把地址池做小、写成文档的理由。

和负责路由的人一起协调分配，并把回程路径记录在同一个地方。一个谁都无法回程路由的地址池，就是一次故障中会被重新「发现」的地址池。把地址池写进与站点网段相同的那份文档，而不是某个只有一个人改过的客户端配置。正是文档让下一次冲突变得可以避免。

什么时候公网地址才是正确答案

拥有正确分配的全球地址空间的机构，完全可以搭建使用公网地址的 VPN 地址池，有些机构还刻意这样做以避免地址转换。这种设计依然需要路由、源地址校验、访问规则和客户端认证；分配本身一样都给不了。

它真正提供的是唯一性，而这正是借来的前缀所缺少的属性。如果你确实持有这个地址段，客户端安装的路由就指向真正属于你的地址，隧道断开时含义也不会改变。

不要为了弥补地址池选择而自动加 NAT。带有显式回程路由的私有路由设计，比因为地址从未规划才被迫做的地址转换更干净；IPv6 需要自己的、有意的规划，而不是照抄 IPv4 的假设。

在不丢失访问能力的前提下退役一个糟糕的地址池

如果地址池已经部署，先做清点再动手：地址预留、已安装的路由、解析进该网段的 DNS 记录、防火墙作用域，以及依赖它们的应用。然后像对待任何一次路由切换那样谨慎地安排变更。要向会察觉的人公告，因为地址池一挪，他们的会话就会掉。客户端地址的静默变更，会产生看起来与这项工作毫无关系的支持工单。

保留一条不依赖你正在移除的地址池的恢复路径，因为你撤回它的那一刻，远程访问也可能随之消失。之后两个方向都要验证：预期的私有目标仍然可用，而被捕获过的互联网目标现在解析回真正的主人。

你想要的，是一个网络团队能够作为一个整体来分配、路由和退役的地址池。仅有一个地址格式，既建立不了安全，也建立不了连通性。