VPN 子网会继承 ASA 接口的安全级别吗？

有人问分支 VPN 子网在 ASA 上是「安全级别 0 还是 100」，这个问题本身已经包含错误。安全级别是本地接口的属性，在接口配置中分配为 0 到 100。通过隧道到达的远程子网不会获得任何级别，无论 crypto map 怎么写。所以这个问题没有数字答案。

更实用的下一个问题是：哪条策略允许分支访问服务器，哪条策略把分支挡在防火墙自身之外。这是两个答案，下面的流程把它们分开。

安全级别属于接口

运行 show running-config interface，你会看到 security-level 出现在每个物理接口或 VLAN 接口下，而不是出现在隧道组或 crypto map 下。默认的从高到低放行在这些接口之间评估，所以这个数字会改变它所属路径上的检查与隐式 ACL 行为。

对于解密后的 VPN 流量，入口仍然是隧道终止处的 outside 接口，出口是通往服务器的 inside 接口。在动任何东西之前，把这两个都写下来。这一步就能消除大部分困惑，因为它把一个抽象的信任问题变成了接口对。

ACL 绕过有一条有名字的边界

sysopt connection permit-vpn 就是人们说「VPN 流量忽略 ACL」时半记得的那个设置。它确实会跳过符合 VPN 流量条件的接口 ACL，而 9.x 参数指南按接口和方向限定它，而不是宣布一个全局例外。

在凭记忆推理之前，先检查配置了什么：

• show running-config all sysopt 看实际生效的值，而不只是非默认行。
• show running-config access-group 看哪条 ACL 应用在哪个接口和方向。
• show vpn-sessiondb detail l2l 确认会话实际使用哪个隧道组和过滤器。

为了收紧 VPN 访问而关闭这个设置，是影响面很大的改动。它会把每条符合条件的 VPN 流量重新交给外部 ACL，这通常会以与你被问到的分支无关的方式破坏正在工作的隧道。

阅读挂在会话上的过滤器

真正的逐隧道控制是 VPN 过滤器：由组策略或用户名引用的 ACL，在解密之后、加密之前应用。用户级过滤器会覆盖组级值，所以同一个隧道组的两个人可能有不同的实际访问权限。

要确认优先级，而不是假设它。show running-config group-policy <name> 显示组值，show running-config username <name> 显示是否存在按用户的值。如果两者都存在，用户值优先。然后按过滤器评估的方向，把该 ACL 的条目与你关心的流量做比对。

允许应用服务器的过滤器，对管理访问什么也没说。那是另一条路径上的另一套规则。

验证一条允许和一条拒绝

不用等用户报告就能看到决策，最快的方法是 Packet-tracer。把解密侧的流量交给它，让它说出经过的 ACL、NAT 和检查阶段。

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. 读结果行：它会指出允许或丢弃该报文的 ACL。
3. 用 inside 接口上的管理目的地重复一次，确认被拒绝。
4. 任何改动之后再重复一次，让改动前后的状态都被记录下来。

然后用真实流量验证：从分支发一个成功的应用请求，再向 ASA 发一次失败的 SSH 尝试。Packet-tracer 模拟的是路径；真实流量才证明模型对上了。

回滚让它生效的那次改动

如果修复是关闭 ACL 绕过或放宽过滤器，要保留之前的配置。改动前保存的受影响对象 show run 截取，足够把它们恢复；ASA 配置是面向行的，所以回滚意味着重新输入旧行，而不是恢复文件。

记录接口对、生效的过滤器、packet-tracer 给出的 ACL 名称，以及你实际改过的命令。有了这份记录，下一次复查就是五分钟的核对，而不是又一场关于信任级别的争论。