这不是重复的帖子/相同的问题！请仔细阅读！！
大家好，
在最近的一个项目中，我们正在为其设置 VPN 的供应商向他们的服务提议我们的加密 ACL 如下：
access-list outside_30_crypto extended permit ip any any
他们建议我们使用额外的 ACL 来限制通过此隧道的流量。他们引用的原因是因为像这样保持加密 ACL 开放，然后在接口上使用 ACL 限制它，您将减少构建的 SA 数量。这如何减少 SA 的数量，这是设计 VPN 的最有效方法吗？
与点对点 VPN 关联的 ACL 应始终包含源信息和目标信息。为了对“有趣的流量”进行分类，即要保护的流量然后发送到远程端点，思科设备（路由器和 L3 交换机和 ASA 哦，我的天）将查看源地址和目标地址。如果您希望单个主机能够将流量发送到整个远程 C 类，那么您的 ACL 将如下所示：
permit ip host 192.168.1.100 10.10.10.0 0.0.0.255
如果未指定，而您只有
permit ip any any
那么您的路由器如何知道它不应该从另一个本地 sunbnet 获取流量并对其进行加密。此外，如果您在同一设备上运行 NAT，则会进一步混淆。如果您在此 VPN 设备上的外部 IP 是公共 IP，那么它也属于该 ACL 的“any”语句。
“他们引用的原因是因为像这样保持加密 ACL 打开，然后在接口上使用 ACL 限制它，您将减少构建的 SA 数量。这如何减少 SA 的数量，这是设计 VPN 的最有效方法是什么？”
这在技术上是不正确的，每个隧道的设备之间只会有一个单一的 SA（安全关联），而不是每个单独的 TCP 会话或流量流。
根据以下Cisco 文档：
“强烈建议不要使用 permit any any 语句，因为这会导致所有出站流量受到保护（并且所有受保护的流量都被发送到相应的加密映射条目中指定的对等方）并且需要对所有入站流量进行保护。然后，所有入站数据包缺少 IPsec 保护会被静默丢弃，包括路由协议、网络时间协议 (NTP)、echo、echo 响应等的数据包。您需要确保定义要保护的数据包。如果必须使用 any 关键字在 permit 语句中，您必须在该语句前面加上一系列 deny 语句，以过滤掉您不想受到保护的任何流量（否则会属于该 permit 语句范围内）”
我相信，在减少 SA 数量方面，添加这些拒绝声明可能就是他们所谈论的内容。如果您的流量不需要为了效率而受到保护，那么这样做是有意义的。