vpn协议之ipsec
2013-12-08 11:10:06 
阿炯
IPSec VPN是目前VPN技术中应用比较高的一种技术，同时提供VPN和信息加密两项技术。
IPSec VPN协议简介
IPSec(IP Security)协议族是IETF制定的一系列协议，它为IP数据报提供了高质量的、可互操作的、基于密码学的安全性。
特定的通信方之间在IP层通过加密与数据源验证等方式，来保证数据报在网络上传输时的私有性、完整性、真实性和防重放。具体介绍如下：
私有性(Confidentiality)
指对用户数据进行加密保护，用密文的形式传送。
完整性(Data integrity)
指对接收的数据进行验证，以判定报文是否被篡改。
真实性(Data authentication)
指验证数据源，以保证数据来自真实的发送者。
防重放(Anti-replay)
指防止恶意用户通过重复发送捕获到的数据包所进行的攻击，即接收方会拒绝旧的或重复的数据包。
IPSec协议具有完整性、机密性、真实性和实现方法的灵活性（支持多个厂商)。它是一种融合协议（IPSec=AH+ESP+IPComp+IKE)：
验证头(Authentication Header，AH)：一个为整个分组提供的密码安全保护的、不可逆的校验和(checksum)。AH用于确保分组的可信性。
封装安全有效负载（Encapsulating Security Payload，ESP)：加密分组，从而使数据不可读。IP有效负载压缩(IP Payload Compression，IPComp)：压缩分组。加密分组会增加分组的大小，IPComp可以抵消分组大小的增加。
Internet密钥交换(Internet Key Exchange，IKE)：为端点提供一种安全协商公共密钥的方法。
为了运行AH，交换双方都必须使用相同的密钥，从而防止“中间人”在链接中进行欺骗。尽管IPSec在IPv4中是可选的，但是在IPv6中要求强制使用它。
IPSec通过AH(Authentication Header)和ESP(Encapsulating Security Payload)两个安全协议实现了上述目标。为简化IPSec的使用和管理，IPSec还可以通过IKE(Internet Key Exchange)进行自动协商交换密钥、建立和维护安全联盟的服务。具体介绍如下：
AH协议
AH是报文头验证协议，主要提供的功能有数据源验证、数据完整性校验和防报文重放功能。然而，AH并不加密所保护的数据报。
ESP协议
ESP是封装安全载荷协议。它除提供AH协议的所有功能外(但其数据完整性校验不包括IP报文头)，还可提供对IP报文的加密功能。
AH和ESP可以单独使用，也可以同时使用。对于AH和ESP，都有两种封装模式：传输模式和隧道模式。详细介绍请参见“IPSec协议的封装模式”。
IKE协议
IKE协议用于自动协商AH和ESP所使用的密码算法，并将算法所需的必备密钥放到恰当位置。
IKE协商并不是必须的，IPSec所使用的策略和算法等也可以手工方式进行协商。关于两种协商方式的比较，请参见“IKE的协商模式”。
IKEv2协议
IKEv2协议作为IKE协议的继任者，在延续IKE基本功能的同时，简化了协议的复杂性，提高了协议效率和加强了协议扩展性。
IPSec VPN的应用场景分为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其实是IP Security的简称，它的目的是为IP提供高安全性特性，VPN则是在实现这种安全特性的方式下产生的解决方案。IPSec是一个框架性架构，具体由两类协议组成：
1.AH协议(Authentication Header，使用较少)：可以同时提供数据完整性确认、数据来源确认、防重放等安全特性；AH常用摘要算法(单向Hash函数)MD5和SHA1实现该特性。
2.ESP协议(Encapsulated Security Payload，使用较广)：可以同时提供数据完整性确认、数据加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5或SHA1来实现数据完整性。
为何AH使用较少呢？因为AH无法提供数据加密，所有数据在传输时以明文传输，而ESP提供数据加密；其次AH因为提供数据来源确认(源IP地址一旦改变，AH校验失败)，所以无法穿越NAT。当然，IPSec在极端的情况下可以同时使用AH和ESP实现最完整的安全特性，但是此种方案极其少见。
IPSec封装模式
介绍完IPSec VPN的场景和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会话建立在发起方、响应方两个网关之间。
2.由于使用传输模式，所以IP头部并不会有任何变化，IP源地址是192.168.1.2，目的地址是10.1.1.2。
3.这个数据包发到互联网后，其命运注定是杯具的，为什么这么讲，就因为其目的地址是10.1.1.2吗？这并不是根源，根源在于互联网并不会维护企业网络的路由，所以丢弃的可能性很大。
4.即使数据包没有在互联网中丢弃，并且幸运地抵达了响应方网关，那么我们指望响应方网关进行解密工作吗？凭什么，的确没什么好的凭据，数据包的目的地址是内网PC的10.1.1.2，所以直接转发了事。
5.最杯具的是响应方内网PC收到数据包了，因为没有参与IPSec会话的协商会议，没有对应的SA，这个数据包无法解密，而被丢弃。
我们利用这个反证法，巧妙地解释了在Site-to-Site情况下不能使用传输模式的原因。并且提出了使用传输模式的充要条件：兴趣流必须完全在发起方、响应方IP地址范围内的流量。比如在图中，发起方IP地址为6.24.1.2，响应方IP地址为2.17.1.2，那么兴趣流可以是源6.24.1.2/32、目的是2.17.1.2/32，协议可以是任意的，倘若数据包的源、目的IP地址稍有不同，对不起，请使用隧道模式。
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。这种设计类似于双向车道设计。
IPSec虽然只是5个字母的排列组合，但其所涉及的协议功能众多、方案又极其灵活。
本文源自：IPSec VPN基本原理
IPSec VPN协议简介
IPSec(IP Security)协议族是IETF制定的一系列协议，它为IP数据报提供了高质量的、可互操作的、基于密码学的安全性。
特定的通信方之间在IP层通过加密与数据源验证等方式，来保证数据报在网络上传输时的私有性、完整性、真实性和防重放。具体介绍如下：
私有性(Confidentiality)
指对用户数据进行加密保护，用密文的形式传送。
完整性(Data integrity)
指对接收的数据进行验证，以判定报文是否被篡改。
真实性(Data authentication)
指验证数据源，以保证数据来自真实的发送者。
防重放(Anti-replay)
指防止恶意用户通过重复发送捕获到的数据包所进行的攻击，即接收方会拒绝旧的或重复的数据包。
IPSec协议具有完整性、机密性、真实性和实现方法的灵活性（支持多个厂商)。它是一种融合协议（IPSec=AH+ESP+IPComp+IKE)：
验证头(Authentication Header，AH)：一个为整个分组提供的密码安全保护的、不可逆的校验和(checksum)。AH用于确保分组的可信性。
封装安全有效负载（Encapsulating Security Payload，ESP)：加密分组，从而使数据不可读。IP有效负载压缩(IP Payload Compression，IPComp)：压缩分组。加密分组会增加分组的大小，IPComp可以抵消分组大小的增加。
Internet密钥交换(Internet Key Exchange，IKE)：为端点提供一种安全协商公共密钥的方法。
为了运行AH，交换双方都必须使用相同的密钥，从而防止“中间人”在链接中进行欺骗。尽管IPSec在IPv4中是可选的，但是在IPv6中要求强制使用它。
IPSec通过AH(Authentication Header)和ESP(Encapsulating Security Payload)两个安全协议实现了上述目标。为简化IPSec的使用和管理，IPSec还可以通过IKE(Internet Key Exchange)进行自动协商交换密钥、建立和维护安全联盟的服务。具体介绍如下：
AH协议
AH是报文头验证协议，主要提供的功能有数据源验证、数据完整性校验和防报文重放功能。然而，AH并不加密所保护的数据报。
ESP协议
ESP是封装安全载荷协议。它除提供AH协议的所有功能外(但其数据完整性校验不包括IP报文头)，还可提供对IP报文的加密功能。
AH和ESP可以单独使用，也可以同时使用。对于AH和ESP，都有两种封装模式：传输模式和隧道模式。详细介绍请参见“IPSec协议的封装模式”。
IKE协议
IKE协议用于自动协商AH和ESP所使用的密码算法，并将算法所需的必备密钥放到恰当位置。
IKE协商并不是必须的，IPSec所使用的策略和算法等也可以手工方式进行协商。关于两种协商方式的比较，请参见“IKE的协商模式”。
IKEv2协议
IKEv2协议作为IKE协议的继任者，在延续IKE基本功能的同时，简化了协议的复杂性，提高了协议效率和加强了协议扩展性。
IPSec VPN的应用场景分为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其实是IP Security的简称，它的目的是为IP提供高安全性特性，VPN则是在实现这种安全特性的方式下产生的解决方案。IPSec是一个框架性架构，具体由两类协议组成：
1.AH协议(Authentication Header，使用较少)：可以同时提供数据完整性确认、数据来源确认、防重放等安全特性；AH常用摘要算法(单向Hash函数)MD5和SHA1实现该特性。
2.ESP协议(Encapsulated Security Payload，使用较广)：可以同时提供数据完整性确认、数据加密、防重放等安全特性；ESP通常使用DES、3DES、AES等加密算法实现数据加密，使用MD5或SHA1来实现数据完整性。
为何AH使用较少呢？因为AH无法提供数据加密，所有数据在传输时以明文传输，而ESP提供数据加密；其次AH因为提供数据来源确认(源IP地址一旦改变，AH校验失败)，所以无法穿越NAT。当然，IPSec在极端的情况下可以同时使用AH和ESP实现最完整的安全特性，但是此种方案极其少见。
IPSec封装模式
介绍完IPSec VPN的场景和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会话建立在发起方、响应方两个网关之间。
2.由于使用传输模式，所以IP头部并不会有任何变化，IP源地址是192.168.1.2，目的地址是10.1.1.2。
3.这个数据包发到互联网后，其命运注定是杯具的，为什么这么讲，就因为其目的地址是10.1.1.2吗？这并不是根源，根源在于互联网并不会维护企业网络的路由，所以丢弃的可能性很大。
4.即使数据包没有在互联网中丢弃，并且幸运地抵达了响应方网关，那么我们指望响应方网关进行解密工作吗？凭什么，的确没什么好的凭据，数据包的目的地址是内网PC的10.1.1.2，所以直接转发了事。
5.最杯具的是响应方内网PC收到数据包了，因为没有参与IPSec会话的协商会议，没有对应的SA，这个数据包无法解密，而被丢弃。
我们利用这个反证法，巧妙地解释了在Site-to-Site情况下不能使用传输模式的原因。并且提出了使用传输模式的充要条件：兴趣流必须完全在发起方、响应方IP地址范围内的流量。比如在图中，发起方IP地址为6.24.1.2，响应方IP地址为2.17.1.2，那么兴趣流可以是源6.24.1.2/32、目的是2.17.1.2/32，协议可以是任意的，倘若数据包的源、目的IP地址稍有不同，对不起，请使用隧道模式。
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。这种设计类似于双向车道设计。
IPSec虽然只是5个字母的排列组合，但其所涉及的协议功能众多、方案又极其灵活。
本文源自：IPSec VPN基本原理