GRE隧道与IPSec加密结合

IPSec加密网络的拓扑可以是星形结构(hub?and?spoke)也能够是网状结构(fullmesh)。实际利用中，数据流量主要散布在分支与中心之间，分支与分支之间的流量散布较少，所以星形结构(hub?and?spoke)通常是最经常使用的，并且它更经济。由于星形结构(hub?and?spoke)比网状结构(fullmesh)使用更少的点到点链路，可以减少线路费用。

在星形拓扑中，分支机构到分支机构(spoke?to?spoke)的连通不需要额外的通讯费用。但在星形结构中，分支到分支的通讯一定要逾越中心，这会耗费中心的资源并引入延时。

特别在用IPSec加密时，中心需要在发送数据分支的隧道上解密，而在接收数据的分支隧道上重新加密。还有一种情况是：通讯的两个分支在同一个城市，而中心在另外一个城市，这便引入了没必要要的延时。

当星形IPSec网络(hub?and?spoke)范围不断扩大时，传统方案的配置则越发繁琐，且不便于保护和排错。因此IP数据包的动态路由将非常成心义。但IPSec隧道和动态路由协议之间存在一个基础问题，动态路由协议依赖于多播或广播包进行路由更新，而IPSec隧道不支持多播或广播包的加密。

这里便引入了动态多点方案(DM方案)的概念。这里将引入两个协议：GRE和NHRPGRE：通用路由封装。由IETF在RFC2784中定义。它是一个可在任意一种网络层协议上封装任意一个其它网络层协议的协议。GRE将有效载荷封装在一个GRE包中，然后再将此GRE包封装基于实际利用的传输协议上进行转发。(我觉得：GRE类似木马的壳。^_^)

IPSec不支持广播和组播传输，可是GRE能很好的支持运载广播和组播包到对端，并且GRE隧道的数据包是单播的。这就意味着GRE隧道的数据包是可被IPSec加密的，也即GREOverIPSec。

通过GRE隧道与IPSec加密相结合，利用动态路由协议在加密隧道两真个路由器上更新路由表。从隧道对端学到的子网在路由表条目里将会包括隧道对真个IP地址作为到达对端子网的下一跳地址。这样，隧道任何一真个网络产生变化，另外一端都会动态地学习到这个变化，并保持网络的连通性而无需改变路由器的配置。

IPSec利用访问控制列表(ACL)来匹配感兴趣数据流。当有数据包匹配所定义的ACL时，IPSec加密隧道便会建立。当利用GREOverIPSec时，GRE隧道的配置已包括了GRE隧道对真个地址，这个地址同时也是IPSec隧道的对端地址。所以，没有必要再单独为IPSec定义匹配ACL。

通过将GRE隧道与IPSec绑定，GRE隧道一旦建立，将立刻触发IPSec加密。在用IPSec对GRE包进行加密时，可以将IPSec配置为传输模式，由于GRE已将原始数据包封装为单播的IP包，没必要让IPSec再封装一个包头。

GRE的特点使得IPSec加密也能时兴的运行动态协议了。至此，IPSec加密不支持动态路由的历史改变了，DM方案中的“多点”被摆平接下来，让我们看看“动态”的特性是怎样被引入的。GRE建立了隧道，IPSec加密完成了方案网络的加密部份。想要建立GRE隧道，隧道的一端一定要知道另外一真个IP地址，并且一定要能够在Internet上路由。这就要求中心和所有分支路由器一定要具有静态的公共IP地址。

可是向ISP申请静态IP地址的费用是非常昂贵的。通常，为节俭地址资源并提高有效利用率，不管是ADSL或直接线缆接入，ISP会通过DHCP服务来提供动态IP地址。(注：IPv4的瓶颈引发的地址匮乏。IPv6不会存在该问题，号称可以给地球上的每粒沙子都分个IP，口气很大的说)

明显，GRE+IPSec需要明确知道隧道两真个IP地址，而分支路由器网络接口的IP地址由其本地ISP动态分配，每次拨入网络的IP地址是不同的。GRE隧道没办法建立，那末方案或没法工作。这样，NHRP在钓足大家胃口之时，应市场需求，在万众期盼的眼光中闪亮登场了，给它些掌声乐乐。噼里啪啦。

TikTok千粉号购买平台：https://tiktokusername.com/