宽泛的 IPsec 选择器不等于放行所有服务

两端的对等体约定保护整个子网，于是有人把这份约定读成了可以访问其中每一项服务的许可。这就是误解所在：选择器只说明隧道愿意承载哪些流量，完全不说明组织允许哪些服务。一对设备完全可以合法地协商一个很宽的地址范围，而其中的访问策略只放行两个端口，这两句话同时都是真的。

受保护的覆盖范围不是授权

流量选择器是隧道约定的一部分。它收窄或确认双方之间要加密什么，而当两侧都有大量流要承载时，宽泛的选择器往往是最省事的选择。服务过滤器是路径上另一个位置的另一种控制，它决定数据包解密之后实际能用什么。为了让一项测试通过而删掉过滤器，等于把一项策略决定变成了事故。

在设计文档里把两份记录分开保存，因为只看到选择器的读者会推断出从未授予的授权。变更记录里的两行字就能避免这一点，代价比之后的争论小得多。

从两端描述同一条流

写清发起方、响应方、呈现出来的源与目的、协议以及两个端口。然后为另一端点把每个标签都翻转过来，因为客户端的临时源端口会变成应答的目的端口，远端网络会变成本地网络。从一侧照抄到另一侧却不做这个翻转，正是过滤器最终放行完全错误方向的原因。把表格写一次，两份过滤器都从它生成。

在复制任何东西之前先就选择模型达成一致，因为基于策略的设计和基于路由的设计用不同对象表达同一意图。把模型名称写在流旁边，否则下一位工程师会花一个下午去匹配从来就不可比较的对象。

找到真正生效的过滤器

在 ASA 上，VPN 过滤器是挂在组策略上的 ACL，作用于解密之后、加密之前的流量。Cisco 的组策略文档还描述了继承，包括会取代组策略值的用户级取值。所以你编辑的那条 ACL 未必就是管着你眼前这条会话的那条。用户对象同样如此，它可以在不留下多少可见证据的情况下覆盖组策略。

去检查实际生效的会话，而不是你记得改过的那个对象，并记下是哪个策略对象提供了它。仅这一步就能解决多得令人意外的一类反馈——过滤器是对的，但它就是不工作。

方向、端口与反向情形

文档化的约定把远端网络或分配到的远端客户端地址放在源位置，把本地网络放在目的位置，应答则通过交换地址位置来表达。端口规则建立在这套约定之上，比地址更值得多花心思。

按文档描述的模型，一条目的端口规则可能影响使用同一源端口的反向发起，这意味着过滤器并不只是单向的请求规则外加无害的应答。请明确地把两个发起方向都推演一遍，并把打算拒绝的那种情形也纳入。

同一份文档把过滤器限定在初始连接上，所以它并不是对被检查应用打开的每一条次要通道的普遍强制。完整策略若需要那层覆盖，应当落在单独的边界上，而不是硬塞进一条被拉伸到超出用途的 ACL。

在宣布完成之前测三种情形

接受预期的那条流，拒绝策略禁止的服务，再演练你推演过的反向情形。在与将要部署的相同身份和选择器下，按已批准的方案运行它们。只证明被允许的服务能用的测试，证明的是隧道，不是策略。

把协商出的覆盖范围和访问决定作为两份记录保存，因为要解释 VPN 究竟放行了什么，两者缺一不可。