基于IPSEC的GRE用例

Question

我试图通过IPSEC理解GRE的用例。在下图中，每个站点都使用GRE封装与OSPF相关的多个广播。(仍然需要在每个站点之间配置SAs。)在这种情况下，在GRE中通过ospf隧道可以节省在站点之间配置静态路由的复杂性。

这是一个有效的用例吗？是否有其他通用部署的应用程序(例如需要多播的应用程序)？

Answer 1

运行多播或基于组播的路由协议不一定需要GRE。“基于隧道”或“基于路由”的VPN (tunnel mode ipsec ipv4 a.k.a. )IPsec虚拟隧道接口在思科林戈)将传输多播和EIGRP或OSPF愉快。

但是，当您需要跨IPSec运行非IP协议时，GRE是必需的：

在我以前的雇主那里，我们曾经广泛地运行，主要使用GRE上的EIGRP作为GRT路由协议，并在其下面使用基于证书的IKEv1和IKEv2。

这使得我们能够在客户站点上拥有一个与思科890系列一样小/便宜的多VRF CPE，同时允许路径隔离或“分区”：一个用于自动取款机的VRF或"zone“，一个用于视频监视，一个用于内部数据，一个用于来宾WiFi，一个用于设施管理等等。

同时，这些IPSec隧道几乎适用于任何类型的底层传输(暗光纤、照明光纤、点对点L2VPN、多点L2VPN、L3-VPN、有线或xDSL internet等)。

当然，我们更愿意直接在IPSec上运行MPLS (tunnel mode ipsec ipv4，见上文)，但是IPsec不支持MPLS(我相信有--或者曾经--) RFC草案，但它从未成功)。

Addon 2018-12-13:

是的，穿过广域网的MTU被缩短到1400或更少(如果客户端的本地循环是基于PPPoE!)用MPLS-o GRE-o IPSEC。PMTUd变得更加困难，因为隧道接口实际上不再是IP接口，而是MPLS接口。因此，ip tcp adjust-mss对隧道接口没有影响，因此必须在面向CE的接口上执行TCP夹紧。

当IKEv1密钥变大时，IKEv2消息的碎片也是一个困难的话题，最终通过IKEv2和它对明确定义有效负载大小(crypto ikev2 fragmentation mtu <size>)的支持得到了适当的解决。