AWS Client VPN 拆分隧道：该发布哪些路由

控制台提供拆分隧道开关，于是这个决定看起来像一个复选框。其实不是。真正送到客户端的是终端节点发布的那个路由集合，而这份清单决定了哪些私有网段走隧道、一般公网流量留在本地还是从 AWS 出去，以及客户端还能与哪个解析器通信。三个问题决定了设计，而每一个都可以在连接仍然成功的情况下被答错。

拆分隧道开关不是目标清单

AWS 把拆分隧道描述为：建立连接时把终端节点路由加入客户端的路由表。指向私有 VPC 的一条路由把隧道限定在该目标上；其余一切走客户端的常规路径。默认路由是另一条指令、另一种效果，所以 拆分隧道文档 警告不要在这类终端节点上发布 0.0.0.0/0：这往往不是扩展连通性，而是把它弄断。终端节点的路由表是策略，客户端的路由表是你可以检查的结果。

把终端节点路由表和客户端已安装的路由放在一起读。标签描述意图；路由描述实际发生了什么。

第一个决定：一般公网流量要不要留在本地？

如果浏览应当使用用户自己的连接，就只发布工作所需的私有目标，到此为止。不要因为某个全隧道教程里有一条就添加公网路由，也不要以为多出的路由提高了安全性。它改变的是路径，不增加策略，而且通常要付出你没有预算的延迟。

如果公网流量应当从 AWS 出去，就按文档搭建互联网访问架构：终端节点路由、授权规则、关联子网的路径、安全策略，以及可用的上游出口。单靠一条默认路由什么也提供不了。

第二个决定：发布哪些私有网段，由谁授权？

发布能为实际工作负载服务的最小目标集合，并且 检查每个关联子网都能路由到它们。终端节点的路由目标与子网的 VPC 路由属于不同层次，一个层次里存在的路由并不能证明另一个层次。授权又是另一件事：一个目标可以可达，却因为客户端所属组没有允许它的规则而被拒绝。

测试一次成功的会话只能证明一条路径。要检查每一个关联子网，因为后来添加的子网关联恰恰是缺失路由通常所在的地方。

当某个目标必须按名称可达时，注意接下来要问的是名称解析，而不是路由。

第三个决定：哪个解析器跟随隧道？

客户端可能收到一个只能通过 VPN 到达的 DNS 服务器，而这个解析器只有在它自己的地址处于已授权路由之内时才有效。两半都要验证：解析器地址跟随已发布的路由，服务器回答应用所查询的名称。按地址成功而按主机名失败，说明问题在命名而不是路由；这种情况下调试隧道会白费一下午。

公网名称应当像连接前那样解析，这也是为什么必须对你发布的内容保持精确。

改动路由集合，然后验证两个世界

AWS 文档说明，修改拆分隧道终端节点上的路由会重置客户端连接。修改时要考虑到这一点：应用改动、通过受支持的客户端重新连接，并重新读取已安装的路由，而不是相信编辑前应用的状态。过期的已应用状态，是正确改动看起来坏掉的最常见原因。

只有当一项私有资源与一个公网目标都按预期工作——按名称、按地址，并且在你真正支持的地址族上——才接受这个设计。能完成认证的隧道，和能正确分流量的隧道不是一回事。

把路由清单连同理由写进 runbook，让下一个人能分得清哪些是有意排除、哪些是忘了。