为何GRE可以封装组播报文而IPSEC却不行？

• Author       :
• Email         : vip_13031075266@163.com
• Date          : 2021.01.24
• Copyright : 未经同意不得转载！！！
• Version    ： ubantu-18.04.02
• Reference：

---

目录

一、前言

二、明确两个问题

三、GRE封装原理

四、IPsec为什么不行？

五、说明

---

一、前言

这个问题可能是在学习IPsec协议时，比较有意思的话题。而一般得到的答案是：IPsec在协议设计时定位便是一个点对点的协议，这个特点可以通过Ipsec SA看出：IPsecSA通过三元组来唯一标识(目的IP，SPI, 协议号)，目的IP都是单播地址，因此一个SA只能对应一个V.P.N节点，总而言之：ipsec不支持保护组播报文和广播报文。提出的解决办法一般是：GRE over Ipsec。

理由是：GRE虽然同样是点对点协议，却可以封装组播报文和广播报文，但是不具备机密性和源认证等特点；IPsec协议虽然具有机密性和完整性保护的优势，但是无法封装组播报文和广播报文，因此结合两个协议的优势，GRE over IPSec应运而生，这样既可以封装单播、组播、广播报文，还可以加密数据流。

那么问题来了：既然都是点对点的协议，为何IPsec不能封装广播组播报文，而GRE却可以？ 这个问题我寻觅了比较久，但是没有让我满意的答案，更多的是：用结论来回答我的原因，然而结论我知道，原因不知道，答非所问。还是自己整理下吧，以下很多是个人观点，如有错误，欢迎指正

二、明确两个问题

• 问题一：IPsec是否支持组播？
• 问题二：IPsec是否可以保护组播、广播报文？

这两个问题可以认为是不同的问题，因为难度不一样，强调的对象不同。

首先说明问题一：

它更强调IPsec协议是否可以只通过一条隧道和多个对端建立V.P.N，本端不需要关心有几个对端设备，他们对我而言共用一个IpsecSA。 这个问题根本原因是ipsec协议设计的问题，SA不支持一对多的模式，也是网上说的比较多的原因。当前普通ipsec协议完全不支持该功能(支持组播ipsec协议已有RFC标准，没有看过，暂不讨论)

然后讨论问题二：

它不要求ipsec隧道与多个对端建立V.P.N，只是希望能够在隧道中传输组播、广播报文；这个问题原因不能完全归咎于ipsec协议本身，ipsec是否支持此功能与实现方式密切相关。ipsec协议有什么实现方式呢？

一般情况下，IPsec存在两种实现方式：

• 基于ACL
• 基于虚拟隧道接口

2.1 基于ACL

基于ACL(Acess Control List，访问控制列表)的实现，可以对ipsec流量进行更加精确的控制，如：使用报文IP地址、UDP/TCP协议、端口号、应用层协议等进行精确控制，使得ipsec更加智能化。它将引用了 ACL 的 IPsec 安全策略应用到接口上(包括物理接口和虚接口)后，该接口上匹配 ACL 的报文将会受到 IPsec 保护。

2.2 基于虚拟隧道接口

在隧道接口上应用 IPsec 安全框架后，路由到该隧道接口的报文都会受到 IPsec 的保护，同时还可以支持对组播流量、广播流量的保护。此方式建立的 IPsec 的封装模式必须为隧道模式。 该类应用通常也被称为在 VTI（Virtual Tunnel Interface）上应用 IPsec

注意：这种方式是支持保护组播、广播流量的。它的原理与GRE支持组播、广播报文应该是相同的。

从这两种实现方式来看，IPsec协议封装组播、广播报文也不是不可能的，既然是这样那就不能说人家协议本身不能封装组播广播报文。

接下来说明下GRE为啥可以封装组播、广播报文。这同样是基于虚接口的ipsec可以封装组播广播报文的原因。

三、GRE封装原理

以前整理的一篇基础GRE文章：GRE隧道协议

GRE协议理论并不复杂，也没有说支持组播的原因。于是我从Linux系统自带的gre隧道功能出发，搭建GRE隧道配置使用环境，来分析其原因。基本环境搭建可参考此文ubantu与CentOS虚拟机之间搭建GRE隧道

使用Linux操作系统自带的GRE功能配置隧道有以下几点注意事项(通过配置总结下来的)：

• 添加GRE隧道实际上就是添加新的虚拟隧道接口
• 添加GRE隧道时必须指定隧道的本端对端隧道地址
• 需要为新添加的虚拟隧道接口配置IP地址
• 如果GRE隧道连接两个不同的子网，需要添加一条静态路由：目的IP为对端子网，下一条为虚拟隧道接口
• GRE本端对端隧道地址相同的只能添加一个虚接口(即两个不同的虚接口，GRE隧道地址相同是不允许滴)
• 不能为同一个虚接口配置不同的GRE隧道

通过上面总结的配置注意事项，可以得出一个结论：每一条GRE隧道都唯一绑定一个虚拟隧道接口，反之亦然。

这能说明什么呢？ 说明GRE数量和虚拟隧道接口的数量是一一对应的。这样的话GRE封装组播功能便不是梦。基于此前提，我绘制了一个简单的图（如果是组播报文，则应该查询组播路由表）：

组播报文是需要查询组播路由表来确定向哪些接口转发组播报文。通过查询组播路由表，路由器会将组播报文复制多份，然后分别转发到不同接口。也就是说转发到GRE虚接口上的报文已经是组播分发后的报文，由于GRE虚接口上只有一种封装策略(上文中提到的一一对应关系)，因此直接按照策略封装报文即可，无需关心报文的类型(单播、组播、广播等)。因此GRE支持封装组播报文的原因在于：GRE处理在组播报文分发之后，而GRE的封装不会影响其他接口处理组播报文，因为该接口持有的是组播报文副本中的一个，互不影响。 从上图的结构中也可以看出报文可以进行重复多次隧道封装。

四、IPsec为什么不行？

上面已经说过，不是IPsec不行，而是使用ACL的方式不行，采用虚拟隧道接口的方式是可以滴。使用虚接口的原理和GRE封装原理相同，但需要保证一点：每一个虚接口有且只有一个封装策略，即不能多条ipsec隧道共用一个虚拟隧道接口。这里有一点蛮有意思的：以下面的处理架构，GRE over Ipsec 或者 Ipsec over GRE都是比较简单实现的，只要通过路由来控制引流即可。

那么基于ACL的为什么不行能？

基于ACL实现的ipsec虽然同样可以配置到物理接口，虚拟隧道接口上，但是由于存在过滤条件，因此只有满足过滤条件的才能进行ipsec封装。除此之外，即使组播报文满足过滤条件，但是该接口上可能配置有多个IPsec的ACL过滤条件，组播报文可能同时满足其中的多个ACL, 那么采用哪种条隧道的SA进行封装便成了问题，由于现阶段标准IPsec的SA不支持一对多，无论采用哪一条隧道的SA进行封装，都会导致组播报文变成单播报文，造成组播报文功能丢失。因此说基于ACL方式实现的ipsec无法进行组播、广播报文的封装。

五、说明

关于ipsec和GRE封装组播报文的解析，纯属个人观点。如果面试回答错误，我可不负责哈。