解密之后：哪条策略最先看到你的 VPN 流量

一条 VPN 流量可以加密得毫无破绽、认证得毫无破绽，却仍然落到没人规划过的地方。你插上的那根网线并不决定内层数据包由哪条规则处理；决定它的是策略挂载点与路由。因此，两张机架图上看起来一样的设计，实际执行可能完全不同。要在这两者之间做选择，第一步是说出最先看到解密流量的那个控制点。

按策略挂载点决定，而不是按插哪个口

每个 VPN 平台都会在转发之前的某个位置评估已解密的流量，而这个位置在配置里有名字。在某个平台上是组策略过滤器，在另一个平台上是接口策略或区域对，在路由设备上可能只是 forward 链。真正执行规则的是挂载点，交换机端口只是网线插到的地方。找到挂载点是第一个决定，因为其余一切不过是相对它来摆放。

在翻硬件之前，先把流写下来：源是谁、去哪里、由哪个协议承载、允许哪个服务。然后找出分别落实这四件事的控制点。

两种形态，两套不同的执行故事

两种形态都很常见，各自可能适配不同的需求。

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

第一种形态可以在网关上落实所需的一切，前提是策略针对该目的地编写，且服务器没有绕开它的路径。第二种形态增加了一道边界，但只有当路由和策略真的让流量穿过它时才成立。与端点同网段的服务器也许永远不会走那个想象中的中间跳。图表达的是意图，路由表才说明实际发生什么。

用路由查询去验证，而不是用那张图。数据包从哪个接口出去、选了哪个下一跳，决定了第二种形态是否按设计运行。

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

把拓扑和隔离分开看

共用子网并不让一个位置变得不可信，专线中转也不让它变得受保护。起决定作用的是实际施加的限制、实际发生的转发，以及每一部分由谁管理。数交换机数量对这三件事都毫无说明。从策略和路由做决定，然后让拓扑去跟随这个决定。

也要把流量群体分开处理。远程接入池、站点到站点前缀和专线网络可以共用一台设备，却仍需要不同规则，因为它们的身份和风险不同。为某个群体写的规则，在共享地址规划时会悄悄覆盖其他群体。

为每种摆放检查故障与管理

每种摆放都有失效方式，而有用的问题是：某个部件停掉时，还有什么仍在工作。一台设备上挂多个逻辑接口，换不来独立恢复；下游防火墙若共用同一路供电或同一个管理员，就不算第二道边界。要问管理路径走在哪里，因为只能通过隧道访问的控制台根本不是恢复路径；ssh [email protected] true 从隧道外面执行，是证明控制台不依赖它最便宜的办法。某个平台的组策略文档把过滤器放在解密之后、加密之前的流量上，这正是在任何产品里都该寻找的那类具名挂载点。

把每个候选方案的故障故事写在执行故事旁边。在检查上占优、在恢复上吃亏的摆放是一种取舍，应当如实记录下来，而不是等事故当中才发现。

用允许的流和拒绝的流验收

拿着已批准的测试计划，从真实的 VPN 源检查三件事：应当能用的应用、不应当能用的资源，以及回程走的方向。拒绝是策略确实生效的证据，允许的流只能证明路径存在。

把选中的路径和策略结果一起保存，因为没有路径的结果无法复现，没有结果的路径无法辩护。这对组合在选择接入点时，比任何关于哪一层交换天生更安全的断言都有用得多。