如果您说的是 Cisco，则每个 acl 记录都是它自己的 SA（隧道）。FWIW，Cisco PIX/ASA 将不允许“任何”规则。（这就是 IOS 隧道接口不能终止到 PIX/ASA 的原因。）

你看到什么样的不稳定？如果一个规则有效，它们都应该有效。是的，如果 SA 尚未设置，将会有延迟。我能想到的唯一问题是 IPsec 在哪里通过无法跟踪多个流的 NAT 设备。

只有当 VPN 隧道的两端对任一侧的子网（也就是“加密域”）使用不同的值时，才会存在“不稳定性”。让我解释...

有3种如果子网不完全匹配，你会遇到不稳定的主要症状。我将首先描述一个“完全工作”的隧道，然后列出子网不相同的错误配置隧道的可能情况。

完全有效的例子

Site A                                         Site B
10.1.0.0/24                               10.2.2.0/24
10.1.1.0/24                               10.2.3.0/24

两个站点都有两个 /24 网络。如果 SiteA 配置为单独列出每个 /24，则 SiteA 在其加密域中将具有以下内容：

10.1.0.0/24 --> 10.2.2.0/24
10.1.0.0/24 --> 10.2.2.0/24
10.1.1.0/24 --> 10.2.3.0/24
10.1.1.0/24 --> 10.2.3.0/24

这些/24 网络对中的每一对都将接收自己的一组 IPsec 隧道（一个用于传出流量，一个用于传入流量），由特定的 SPI（安全参数索引——花哨的术语，它只是一个 8 位十六进制数字）标识一组安全算法和密钥的标签——也称为安全关联）。

例如，SiteA 可能有如下标签：

SiteA Pairs                      Outbound SPI    Inbound SPI             
10.1.0.0/24 --> 10.2.2.0/24      0xBBBB1022      0xAAAA1022
10.1.0.0/24 --> 10.2.3.0/24      0xBBBB1023      0xAAAA1023
10.1.1.0/24 --> 10.2.2.0/24      0xBBBB1122      0xAAAA1122
10.1.1.0/24 --> 10.2.3.0/24      0xBBBB1123      0xAAAA1123

如果 SiteB 想要完全正确配置，则必须对其加密域进行准确的镜像配置。所以在一个完美的世界里，它看起来像这样：

SiteB Pairs                      Outbound SPI    Inbound SPI
10.2.2.0/24 --> 10.1.0.0/24      0xAAAA1022      0xBBBB1022
10.2.3.0/24 --> 10.1.0.0/24      0xAAAA1023      0xBBBB1023
10.2.2.0/24 --> 10.1.1.0/24      0xAAAA1122      0xBBBB1122
10.2.3.0/24 --> 10.1.1.0/24      0xAAAA1123      0xBBBB1123

请注意，SPI 和网络完全颠倒了。SiteA 用于 10.1.0.0/24 与 10.2.2.0/24 通话的出站 SPI 是 SiteB 用于 10.2.2.0/24 与 10.1.0.0/24 通话的入站 SPI。这是设计使然。

症状#1

现在，假设 SiteB 配置错误，并决定使用 10.1.0.0/23 来汇总 SiteA。从纯粹的子网划分角度来看，这应该是完全可以接受的，对吧？我的意思是，两个 /24 肯定加起来就是一个 /23。但是，由于 IPsec 协商其隧道的方式，它会导致一些问题。

如果 SiteB通过提议 a启动10.2.2.0/24 --> 10.1.0.0/23，SiteA 将拒绝该请求，因为 SiteB 正在尝试为 SiteA 打算保护的“外部”事物创建隧道（请记住，SiteA 仍在使用四个单独列出的 /24 对） .

如果 SiteA通过提议 a发起10.1.0.0/24 --> 10.2.2.0/24，SiteB 将接受请求，因为 10.1.0.0/24 位于 SiteB 配置保护的范围内 (10.1.0.0/23)。

(1)所以最初，第一组症状看起来像隧道只能在一个方向上建立（如果 SiteA 启动）。

症状#2

如果站点B 配置了/23，并且站点A 启动...隧道将建立。当 10.1.0.0/24 和 10.2.2.0/24 尝试通信时......一切都会正常进行。 但是，请记住，SiteB 不会将 10.1.0.0/24 视为 /24，而是将其视为 /23。因此，如果在未来的某个时间点，SiteB 尝试向 10.1 发送一些流量。1 .0/24，它将使用预先存在的 SPI/隧道。这意味着 SiteA 将从 SiteB 接收一些来源为 10.2.2.0/24（预期）和目的地为 10.1.1.0/24（意外）的东西。在 Cisco 世界中，这将导致生成这样的系统日志消息：

%PIX|ASA-4-402116: IPSEC: Received an protocol packet (SPI=spi, sequence 
number= seq_num) from remote_IP (username) to local_IP. The decapsulated inner packet 
doesn't match the negotiated policy in the SA. The packet specifies its destination 
as pkt_daddr, its source as pkt_saddr, and its protocol as pkt_prot. The SA specifies 
its local proxy as id_daddr /id_dmask /id_dprot /id_dport and its remote proxy as 
id_saddr /id_smask /id_sprot /id_sport.

详情在这里

(2)第二组症状看起来像某些子网无法通过 VPN 通信，并且您的系统日志中充满了上述消息。

症状#3

与上次相同的场景，除了这次 SiteA 决定要从 10.1 发送一些流量。1 .0/24 到 10.2.2.0/24。请记住，从站点 A 的角度来看，已经存在的 SPI 是 10.1.0.0/24 到 10.2.2.0/24。因此，这种新流量将需要一个全新的隧道。SiteB 将收到对新隧道/SPI 的请求，并且可以拒绝它，因为它认为 10.1.0.0/23 的原始 SPI（尽管这种情况很少见）。更多的时候，SiteB 会接受从 10.1.0.0/23 到 10.2.2.0/24建立新隧道的请求，这会导致 SiteB 拆除旧隧道。现在你有一组相反的症状，10.1.1.0/24 对 10.2.2.0/24 说话有效，但 10.1.0.0/24 对 10.2.2.0/24 说话没有。

(3)这里的第三组可能的症状看起来像是“随机”重建隧道，并且某些子网不断失去与另一端的连接。

_{注意：许多关于防火墙/路由器如何工作的反应会因您使用的供应商而异。上面的大多数示例都来自我多年使用 Cisco ASA 和 PIX 产品的经验。YMMV，但即便如此，这些概念仍然相关且适用}

所以你有它。它应该看起来是彼此完美的镜面反射。如果您想将 /24 总结为一个 /23，那完全没问题，只要双方都以相同的方式进行即可。如果一方决定做另一方不做的事情，您将遇到上述一些问题。