IPSecVPN中隧道模式和传输模式区别.docx

IPSecVPN中隧道模式和传输模式区别.docx

《IPSecVPN中隧道模式和传输模式区别.docx》由会员分享，可在线阅读，更多相关《IPSecVPN中隧道模式和传输模式区别.docx（8页珍藏版）》请在冰豆网上搜索。

IPSecVPN中隧道模式和传输模式区别

IPSec-VPN中隧道模式和传输模式区别

IPSecVPN基本原理

IPSecVPN是目前VPN技术中点击率非常高的一种技术，同时提供VPN和信息加密两项技术，这一期专栏就来介绍一下IPSecVPN的原理。

IPSecVPN应用场景

IPSecVPN的应用场景分为3种：

1.Site-to-Site（站点到站点或者网关到网关）：

如弯曲评论的3个机构分布在互联网的3个不同的地方，各使用一个商务领航网关相互建立VPN隧道，企业内网（若干PC）之间的数据通过这些网关建立的IPSec隧道实现安全互联。

2.End-to-End（端到端或者PC到PC）：

两个PC之间的通信由两个PC之间的IPSec会话保护，而不是网关。

3.End-to-Site（端到站点或者PC到网关）：

两个PC之间的通信由网关和异地PC之间的IPSec进行保护。

VPN只是IPSec的一种应用方式，IPSec其实是IPSecurity的简称，它的目的是为IP提供高安全性特性，VPN则是在实现这种安全特性的方式下产生的解决方案。

IPSec是一个框架性架构，具体由两类协议组成：

1.AH协议（AuthenticationHeader，使用较少）：

可以同时提供数据完整性确认、数据来源确认、防重放等安全特性；AH常用摘要算法（单向Hash函数）MD5和SHA1实现该特性。

2.ESP协议（EncapsulatedSecurityPayload，使用较广）：

可以同时提供数据完整性确认、数据加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5或SHA1来实现数据完整性。

为何AH使用较少呢？

因为AH无法提供数据加密，所有数据在传输时以明文传输，而ESP提供数据加密；其次AH因为提供数据来源确认（源IP一旦改变，AH校验失败），所以无法穿越NAT。

当然，IPSec在极端的情况下可以同时使用AH和ESP实现最完整的安全特性，但是此种方案极其少见。

IPSec封装模式

介绍完IPSecVPN的场景和IPSec协议组成，再来看一下IPSec提供的两种封装模式（传输Transport模式和隧道Tunnel模式）

上图是传输模式的封装结构，再来对比一下隧道模式：

可以发现传输模式和隧道模式的区别：

1.传输模式在AH、ESP处理前后IP头部保持不变，主要用于End-to-End的应用场景。

2.隧道模式则在AH、ESP处理之后再封装了一个外网IP头，主要用于Site-to-Site的应用场景。

从上图我们还可以验证上一节所介绍AH和ESP的差别。

下图是对传输模式、隧道模式适用于何种场景的说明。

从这张图的对比可以看出：

1.隧道模式可以适用于任何场景

2.传输模式只能适合PC到PC的场景

隧道模式虽然可以适用于任何场景，但是隧道模式需要多一层IP头（通常为20字节长度）开销，所以在PC到PC的场景，建议还是使用传输模式。

为了使大家有个更直观的了解，我们看看下图，分析一下为何在Site-to-Site场景中只能使用隧道模式：

如上图所示，如果发起方内网PC发往响应方内网PC的流量满足网关的兴趣流匹配条件，发起方使用传输模式进行封装：

1.IPSec会话建立在发起方、响应方两个网关之间。

5.最杯具的是响应方内网PC收到数据包了，因为没有参与IPSec会话的协商会议，没有对应的SA，这个数据包无法解密，而被丢弃。

IPSec协商

IPSec除了一些协议原理外，我们更关注的是协议中涉及到方案制定的内容：

2.发起方：

Initiator，IPSec会话协商的触发方，IPSec会话通常是由指定兴趣流触发协商，触发的过程通常是将数据包中的源、目的、协议以及源、目的端口号与提前指定的IPSec兴趣流匹配模板如ACL进行匹配，如果匹配成功则属于指定兴趣流。

指定兴趣流只是用于触发协商，至于是否会被IPSec保护要看是否匹配协商兴趣流，但是在通常实施方案过程中，通常会设计成发起方指定兴趣流属于协商兴趣流。

3.响应方：

Responder，IPSec会话协商的接收方，响应方是被动协商，响应方可以指定兴趣流，也可以不指定（完全由发起方指定）。

4.发起方和响应方协商的内容主要包括：

双方身份的确认和密钥种子刷新周期、AH/ESP的组合方式及各自使用的算法，还包括兴趣流、封装模式等。

5.SA：

发起方、响应方协商的结果就是曝光率很高的SA，SA通常是包括密钥及密钥生存期、算法、封装模式、发起方、响应方、兴趣流等内容。

我们以最常见的IPSec隧道模式为例，解释一下IPSec的协商过程：

上图描述了由兴趣流触发的IPSec协商流程，原生IPSec并无身份确认等协商过程，在方案上存在诸多缺陷，如无法支持发起方动态变化情况下的身份确认、密钥动态更新等。

伴随IPSec出现的IKE（InternetKeyExchange）协议专门用来弥补这些不足：

2.满足兴趣流条件，在转发接口上检查SA不存在、过期或不可用，都会进行协商，否则使用当前SA对数据包进行处理。

3.协商的过程通常分为两个阶段，第一阶段是为第二阶段服务，第二阶段是真正的为兴趣流服务的SA，两个阶段协商的侧重有所不同，第一阶段主要确认双方身份的正确性，第二阶段则是为兴趣流创建一个指定的安全套件，其最显著的结果就是第二阶段中的兴趣流在会话中是密文。

IPSec中安全性还体现在第二阶段SA永远是单向的：

从上图可以发现，在协商第二阶段SA时，SA是分方向性的，发起方到响应方所用SA和响应放到发起方SA是单独协商的，这样做的好处在于即使某个方向的SA被破解并不会波及到另一个方向的SA。

这种设计类似于双向车道设计。

IPSec虽然只是5个字母的排列组合，但其所涉及的协议功能众多、方案又极其灵活，本期主要介绍IPSec的基本原理，在后续专栏还会继续介绍IPSec的其它方面知识。

。