VPN 适配器显示 /32 并不表示只有一个目的地址

VPN 适配器上的 255.255.255.255 掩码是客户端自己的地址，不是可达主机的上限。要分别阅读路由、网关范围和返回路径。

适配器显示 255.255.255.255，人们常常据此断定 VPN 只能到达一个地址。这种理解把客户端自身的地址与经由隧道路由的目的地址集合混为一谈。在点对点或已路由的接口上，这是两个不同的对象，只有其中一个限制可达性。这个误解之所以流传，是因为该掩码看起来像人们在以太网上学到的子网掩码。

误解：主机掩码意味着只有一个可达主机

/32 分配告诉接口链路这一端属于哪个地址，在点对点链路上它的含义仅此而已。对端地址是另一个字段，而说明对端之外有什么的路由又是另一套东西。掩码中没有任何内容描述远端网络，因为远端网络并不是在掩码中描述的。把它读成可达性的上限，就像把自己家的门牌号读成一份允许拜访的全部地址清单。

这种混淆有真实的根源：在以太网上，主机掩码确实意味着该网段上只有一个地址。隧道不是以太网网段，决定什么流量经过它的是客户端的路由表，而不是掩码。正因如此，同一个 /32 可以出现在整个数据中心之前。

把地址和路由当作两个独立对象来读

把接口和路由表一起打印出来，然后把它们读成对两个问题的两个回答。地址回答这一端是谁，路由回答流量可以去哪里。第三个问题，网关允许哪些目的地址，在客户端上完全看不到。iproute2 的地址参考之所以分别描述本地地址、对端和前缀路由字段，正是这个原因。

ip addr show tun0
ip route show
ip route get 10.60.5.10

在 Windows 上，地址列表与路由表之间也存在同样的分离，而查询命令是查看哪个对特定目的地址胜出的最快方式。如果查询返回隧道接口，客户端就会把数据包发到那里。如果返回物理适配器，客户端根本不会询问 VPN，再多服务器端权限也改变不了。要检查你真正需要的那个目的地址，而不是随便一个公网地址。

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

如果查询指向错误的接口，就停下来。这是客户端的路由问题，要在客户端上修正。

为什么把掩码改宽通常会更糟

为了看起来像办公 LAN 而把分配改成 /24，可能在链路上产生一个前缀：内核现在认为整个 /24 都直接连在隧道接口上。本该经由网关路由的地址，其流量随后就被当作链路上有邻居一样发送出去。结果是看起来像服务器故障的黑洞。

它同时掩盖了真正的问题，即缺失的路由或网关上缺失的权限。这两者都不是更宽的掩码能产生的，而且改动之后两者依然存在。如果设计需要在接口上使用更大的前缀，那是针对所用接口模型的决定，要拿着文档来做。从别的产品截图里抄一个掩码，并不是这个决定。

如果缺少远端前缀路由，就修正它的配置。如果路由存在而连接仍被拒绝，掩码从来就不是诊断结论。

路由正确但流量仍然失败时

正确的路由只能证明客户端会把数据包发出去。网关仍须接受该目的地址，分配到的地址必须有返回路径，服务也必须允许这条流量。把这三件事分开测试：客户端上的查询、网关允许的范围，以及向一台必需服务器发出的请求。在三条都就位之前认证就成功是正常的，这也正是已连接的客户端仍然可能什么都到不了的原因。

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

在网络设备管理的服务上，把网络对象和组权限与其所有者放在一起。要求客户端到达什么，和允许它使用什么，是两种不同的设置，往往在不同的界面上。改一个再测另一个，就是工单在两个团队之间来回弹的原因。

应当退役的误解是：掩码是可达性的上限。把地址、路由和网关策略当作三个独立事实来读，/32 就不再像限制，而开始像一次普通的隧道分配。

相关文章