VPN 客户端流量与防火墙状态：外层与内层流量

VPN 握手完成，客户端拿到地址，可网关后面的服务仍然拒绝连接。防火墙往往只是忠实地执行了指令。它放行的是外层隧道流量，而解封装后的应用连接是另一种数据包。由此引出了两个决定：你放行的是哪一层流量，以及边界到底跟不跟踪状态。

在把这两件事分开之前，任何规则调整都只是猜测。

防火墙看到的是两种不同的数据包

解封装之前，防火墙看到的是发往 VPN 端点的流量：一条通往监听端口的外层 UDP 流。解封装之后，被转发的数据包携带的是客户端的内层地址和服务的目的地址。

针对外层流的放行，并不等于授权了被转发的 TCP 连接。两者可能在不同的链、不同的接口上被评估，经过地址转换后地址也不同。

对比两侧等效位置上的抓包。隧道边缘的抓包和服务器上的抓包，对同一次会话显示的是不同的元组。

第一个决定：放行隧道还是放行服务

如果客户端只需要 VPN 端点本身，外层放行可能就够了。如果它需要网关之外的服务，就需要针对该目的地址和端口的转发放行。让隧道规则顺带放行服务，是一个应当被明确命名的设计选择，而不是意外。

把客户端范围和服务范围都收窄。从隧道子网放行到整个局域网，等于决定信任每一台主机，而不是为某个应用开一条捷径。

把两条规则分别写下来。隧道规则和服务规则的失败方式不同，排查时用的证据也不同。哪一条先失败，你就知道该先查哪一层。

第二个决定：每处边界是有状态还是无状态

已建立连接的规则可以为已放行的会话放行回包，但具体行为取决于产品。云安全组通常是有状态的；子网 ACL 往往无状态，两个方向都需要显式处理。不要假设路径上每一处边界对待状态的方式都一样。设计规则之前，先把每处边界列出来，标明它是有状态还是无状态。

规则变更之后，已有的被跟踪连接可能继续工作，而新连接失败，反过来也可能。这个差异是有用的线索，而不是在生产网关上清空全部连接状态的理由。

用一次全新的受控请求去测试，并查看相应的计数器。干净的测试胜过破坏性的重置。把计数器名称记进变更记录，下一次测试才能用同一份证据。

在同一策略下验证回程路径

从客户端向服务发一条新请求，然后检查每处边界上的正向和回程计数器。确认回包走的是你预期的路径，尤其是在涉及地址转换时。

把预期的客户端范围和服务范围收窄，并在放行该请求的同一套规则下验证回程路径。只在旧连接还开着时才生效的规则，不是真正可用的规则。