关闭

IPSec VPN原理

193人阅读 评论(0) 收藏 举报
分类:

工作中需要,参考网上的资料对IPSecVPN进行学习,并通过博客记录下一些知识点作为学习和后续发复习的材料。

其中主要参考了以下文档:

http://www.h3c.com.cn/Service/Channel_Service/Operational_Service/ICG_Technology/201005/675214_30005_0.htm

定义

IPSec VPN即指采用IPSec协议来实现远程接入的一种VPN技术,IPSec全称为Internet Protocol Security,是由Internet Engineering Task Force (IETF) 定义的安全标准框架,用以提供公用和专用网络的端对端加密和验证服务。

IPSEC协议通过包封装技术,能够利用Internet可路由的地址,封装内部网络的IP地址,实现异地网络的互联

IPSec是一个框架协议,直接构建在IP层之上,具体协议由AH和ESP组成,ESP协议号50,AH协议号51,它们都没有类似于UDP/TCP端口号的概念,因此也就没有NAT复用标识,ESP要穿越NAT还需要想其它办法,而AH则因为保护源IP地址的关系,在NAT穿越中属于天生无法支持。

应用场景

1、Site-to-Site(网关到网关),三个有安全要求的组织分布在不同地理位置上,但需要安全通信,则使用Site-to-Site网关实现内网中的多个PC或者服务器之间的通信。

2、End-to-End (端到端):两个PC之间的通信由IPSec会话保护,即在本地封装。

3、End-to-Site (PC到网关):两个PC之间的通信由网关和异地PC之间的IPSec会话保护。

封装模式

封装模式和加密协议


传输Transport模式和隧道Tunnel模式,使用两种协议来加密。

1.      AH协议(Authentication Header,使用较少):可以同时提供数据完整性确认、数据来源确认、防重放等安全特性;AH常用摘要算法(单向Hash函数)MD5和SHA1实现该特性。

2.      ESP协议(Encapsulated Security Payload,使用较广):可以同时提供数据完整性确认、数据加密、防重放等安全特性;ESP通常使用DES、3DES、AES等加密算法实现数据加密,使用MD5或SHA1来实现数据完整性。


传输模式的封装结构


隧道模式的封装结构



两个封装模式的区别

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

传输模式下end-to-end中的两端必须都使用公网IP。

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

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


隧道建立过程

IPSec协商

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

1.      兴趣流:IPSec是需要消耗资源的保护措施,并非所有流量都需要IPSec进行处理,而需要IPSec进行保护的流量就称为兴趣流,最后协商出来的兴趣流是由发起方和响应方所指定兴趣流的交集,如发起方指定兴趣流为192.168.1.0/24à10.0.0.0/8,而响应方的兴趣流为10.0.0.0/8à192.168.0.0/16,那么其交集是192.168.1.0/24ßà10.0.0.0/8,这就是最后会被IPSec所保护的兴趣流。

2.      发起方:Initiator,IPSec会话协商的触发方,IPSec会话通常是由指定兴趣流触发协商,触发的过程通常是将数据包中的源、目的地址、协议以及源、目的端口号与提前指定的IPSec兴趣流匹配模板如ACL进行匹配,如果匹配成功则属于指定兴趣流。指定兴趣流只是用于触发协商,至于是否会被IPSec保护要看是否匹配协商兴趣流,但是在通常实施方案过程中,通常会设计成发起方指定兴趣流属于协商兴趣流。

3.      响应方:Responder,IPSec会话协商的接收方,响应方是被动协商,响应方可以指定兴趣流,也可以不指定(完全由发起方指定)。

4.      发起方和响应方协商的内容主要包括:双方身份的确认和密钥种子刷新周期、AH/ESP的组合方式及各自使用的算法,还包括兴趣流、封装模式等。

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

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

上图描述了由兴趣流触发的IPSec协商流程,原生IPSec并无身份确认等协商过程,在方案上存在诸多缺陷,如无法支持发起方地址动态变化情况下的身份确认、密钥动态更新等。伴随IPSec出现的IKE(Internet Key Exchange)协议专门用来弥补这些不足:

1.      发起方定义的兴趣流是源192.168.1.0/24目的10.0.0.0/8,所以在接口发送发起方内网PC发给响应方内网PC的数据包,能够得以匹配。

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

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

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

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








要点:

1、如何找到与本VPN节点相关的其他节点。
2、协商出一个可以通讯的隧道。如果是nat之后,应该怎么处理。
IPsec协商:

3、建立隧道路由表,确定不同的目标地址,走不同的隧道。

如何建立隧道

解决了Ip地址动态寻址的问题,现在来说一下Nat穿越的问题。我们知道,Udp和TCP是可以穿越防火墙的。直接的IPsec封装,不能穿越防火墙,因为防火墙需要更改端口信息,这样回来的数据包,才能转到正确的内部主机。用UDP显然比较合适,因为使用tcp的话,不仅三次握手占据时间很长,而且还有来回的确认。而实际上,这些工作属于ipsec内部封装的报文要干的事情,放在这里完成是不合适的。因此,用udp来封装ipsec报文,以穿越nat,几乎是唯一可以选择的方案。


遗留问题:

UdpTCP是可以穿越防火墙的???如何理解?


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1480次
    • 积分:75
    • 等级:
    • 排名:千里之外
    • 原创:5篇
    • 转载:4篇
    • 译文:0篇
    • 评论:0条
    文章存档