VPN 解密后，哪条 ASA 规则看到流量

首先要丢掉的前提是：加密 ACL 是一种访问策略。它不是。在 Cisco ASA 上，那份列表只回答一个很窄的问题——哪些报文值得保护；它完全不涉及解密后的报文能否到达防火墙后面的服务器。访问权限是之后由接口策略、组策略过滤器，或两者共同决定的，取决于隧道是如何建立的。

加密 ACL 回答的是另一个问题

加密 ACL 是一张匹配列表。它告诉隧道两台对等体之间哪些流量需要加密；不匹配的报文根本不会受到保护。把它放宽，改变的只是保护范围，别的什么都不会变。

这就是为什么在那里加一个子网能让隧道起来，而实际应用依然失败。隧道能起来，是因为现在有了匹配；应用仍然失败，是因为那份列表里没有任何条目允许任何东西。两个不同的问题，由两张不同的列表回答。

绕过设置究竟跳过了什么

sysopt connection permit-vpn 让受保护的流量跳过入方向本应适用的接口 ACL 检查。它是为 VPN 部署提供的便利，而且是全局性的。它不触及组策略，也不触及按用户的授权过滤器。

要读实际值，而不是凭假设：即使从未显式配置，show running-config all sysopt 也会打印出该设置，很多混乱正是从这里开始的。

由于该设置是全局的，在某个出故障的子网上拿它做快速试验是很不划算的交易。那台防火墙上其他所有隧道都会共享这个结果。把它留给有回滚计划的、刻意的变更。

在解密方向上读过滤器

LAN-to-LAN 的 vpn-filter 是从隧道的视角写的，而不是从接口的视角。远端网络放在源位置，本地网络放在目的位置，因为解密后的报文就是这个样子。随后在加密前，同一个过滤器会在相反方向上再评估一次，地址角色对调。

正因如此，端口条件比照抄一份接口 ACL 更需谨慎。一条允许某个目的端口的规则，在反方向上可能产生意料之外的后果——新连接会把该端口当作源端口。在动手建列表之前，先写清楚哪一侧可以发起、实际是什么服务，以及哪一侧必须保持关闭。

确认实际挂上的是哪个过滤器：show running-config group-policy 和 show vpn-sessiondb detail l2l 合起来会告诉你会话继承了什么。编辑一份没有任何策略引用的 ACL 不会有任何改变。

不要把一个 ACL 对象用于两件事

接口上的 access-group 和 vpn-filter 看起来是同一种对象，却在不同的点、以不同的地址方向被评估。把同一份列表同时用于两者，会招来那种修好了隧道、却悄悄放松了物理接口的改动。

把它们分开，按各自的用途命名，并让方向的差异体现在名字里。

用新连接、在两个方向上验证

计划性变更之后，开一条应当被允许的新连接和一条应当被拒绝的新连接，然后把地址、方向和策略匹配情况连同结果一起记下来。已建立的会话证明不了任何关于新连接过滤的事情，因为它早已在旧规则下被放行了。

也要把深度检测算进去。厂商文档指出，VPN 过滤器检查的是初始连接，而不是检测引擎打开的每一条辅助连接，因此控制通道及其相关媒体流可能受到不同对待。如果应用能识别协议，就测实际流量，而不是单个端口探测。

一次大范围绕过之后变得可用的隧道，说明限制被移除了，而不是被满足了。值得保留的成果，是一个在下次评审时能指出来的、有名字的执行点。