目录
协议概述
IP Sec全称：IP Security
IPSec协议，不是一个单独的协议，而是一系列为IP网络提供完整安全性的协议和服务的集合。
IPSec协议是一个工作在IP网络层的协议
作为一个隧道协议实现了v*n通信
第三层隧道协议，可以在IP层上创建一个安全的隧道，使两个异地的私有网络连接起来，或者使公网上的计算机可以访问远程的企业私有网络。
2、IPSec作用
1、保证数据来源可靠
在IPSec通信之前双方要先用IKE认证对方身份并协商**，只有IKE协商成功之后才能通信。由于第三方不可能知道验证和加密的算法以及相关**，因此无法冒充发送方，即使冒充，也会被接收方检测出来。
2、保证数据完整性
IPSec通过验证算法保证数据从发送方到接收方的传送过程中的任何数据篡改和丢失都可以被检测。
3、保证数据机密性
IPSec通过加密算法使只有真正的接收方才能获取真正的发送内容，而他人无法获知数据的真正内容
3、认证方式
3.1、预共享**
预共享**认证是IPSec双方配置时手工指定的**，无需在网络中互相告知**
3.2、数字证书
- 响应端发送数字证书到客户端
- 发送端收到响应端的数字证书后，会取出附带的数字证书，并读取证书中的发布机构（Issuer），然后从操作系统的受信任证书机构列表中查找该证书办发机构的公钥，如果找不到，说明这个证书颁发机构是个不受信任的，响应端发过来的信息是不安全的。
- 使用上一步取到的证书颁发机构的公钥，解出数字证书，得到响应端的用户信息和数字签名
- 发送端通过证书中指定的加密算法对响应端的用户信息进行hash加密
- 加密后的结果和证书中解出的数字签名进行对比，如果相同，就说明这份用户信息确实是响应端的，也就是说用户信息中包含的公钥确实是响应端的
- 后续响应端使用私钥加密数据，发送端使用公钥解密。
- 发送端使用公钥加密，响应端使用私钥解密
4、ESP加密算法
4.1、ESP完整性检测
ESP报文最后有一个验证数据字段，数据验证字段包含完整性校验值 (ICV)，也称为消息身份验证码，用于验证消息身份验证与完整性。接收方计算 ICV 值并对照发送方计算的值校验它，以验证完整性。ICV 是通过 ESP 报头、负载数据与 ESP 尾端计算的。
4.2、ESP防重放
作为可选功能，ESP还能进行防重放保护。防重放保护验证每个报文是唯一的且没有被复制，这种保护确保黑客不能拦截报文和在数据流中插入改变后的报文。
防重放的工作原理：
- 跟踪报文顺序号并在目的端使用一个滑动窗口。当在源和目的间建立了一条连接时，两端的计数器被初始化为0。
- 每次有报文发送时，源给报文追加一个顺序号，目的端使用滑动窗口确定预期的顺序号。目的端验证的报文的顺序号不是复制的，并且以正确的顺序被接收。
例：
1、客户端发送ESP封装报文到服务端，***为81
2、服务端响应报文通过ESP加密，响应报文的***为81
3、客户端收到服务端发送的ESP报文后，查看ESP***，***排序正确则没有重放，排序错误则出现重放。
4.3、ESP防窃听
ESP通过3DES、DES、AES机密算法加密数据，做到防窃听功能
5、IPSec工作原理
ESP有两种模式：隧道模式和传输模式。
隧道模式将发送的整个数据报文作为一个数据整体来处理，在整段数据前加上新的IP进行传输，不修改原报文。
对于传输模式而言，需要拆解报文，对原报文的数据部分进行处理，加上ESP头部后，再装上原报文的IP部分。
5.1、传输模式
ESP处理流程：
1、 将原IP报文的IP头和数据报文部分分离，在数据报文部分的尾部添加ESP尾部。ESP尾部包含：选择的加密算法需要对明文进行填充的数据Padding、填充长度Padding Length、下一头部Next Header标注被加密的数据报文类型，例如TCP协议。
2、 对第一步得到的整体信息（原数据报文和ESP尾部）进行加密。具体的加密算法以及**由SA给出。
3、对第二步得到的已经加密的信息添加ESP头部(SPI和***)，组装成Enchilada。
4、对第三步得到的Enchilada做摘要，得到完整性度量结果(ICV)，附加在Enchilada尾部
5、在第四步得到的数据前加上原IP头，将原IP头中的Protocol中的值改成50，代表ESP
5.2、隧道模式
ESP处理流程：
1. 在原IP报文末尾添加尾部(ESP trailer)信息。如上图所示,尾部包含三部分。由所选加密算法可能是块加密,那么当最后一块长度不够时就需要进行填充(padding),附上填充长度(Pad length)方便解包时顺利找出用来填充的那一段数据。而Next header则用来标明被加密的数据报文的类型，例如TCP协议。
2. 将原IP报文以及第1步得到的ESP尾部作为一个整体进行加密。具体的加密算法与**由SA给出。
3. 为第2步得到的加密数据添加ESP头部。如上图所示,ESP头由两部分组成,SPI和序号(Sequence number)。加密数据与ESP头合称为“enchilada”。
4. 附加完整性度量结果(ICV,Integrity check value)。对第三步得到的“enchilada”做摘要,得到一个完整性度量值,并附在ESP报文的尾部。
5. 加上新的IP头。新构造的IP头附在ESP报文的前面组成一个新的IP报文。注意这个新的IP头的目的地址跟源地址可以不一样。协议类型为50,说明它里面装的是一个IPsec报文。
- IPSec协商模式
IPSec建立分为两个阶段，第一接端为IKE协商，第二阶段为IPSec协商。
6.1、主动模式
6.1.1、Ikev1协商
包1：发起端协商SA，使用的是UDP协议，端口号是500，上层协议是ISAKMP，该协议提供的是一个框架，里面的负载Next payload类似模块，可以*使用。可以看到发起端提供了自己的cookie值，以及SA的加密套件，加密套件主要是加密算法，哈希算法，认证算法，生存时间等。
- Initiator SPI：b0b5887b632a532b
发起者的SPI值，告知响应端主机要使用IPSEC的哪一把**来加密这个封包。
- Responder SPI：
响应者的SPI值，第一个包只有发起者没有响应者所以响应者的SPI为空
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
- IKE Attribute (t=12,l=4): Life-Duration: 86400
**周期86400，**周期超过86400后会重新协商IKE
- IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC
IKE使用DES-CBC加密算法加密数据
- IKE Attribute (t=2,l=2): Hash-Algorithm: MD5
IKE使用MD5算法校验数据完整性
- IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key
使用预共享**认证
- IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group
Diffie-Hellman (DH) 组在**交换进程中使用的1024 bit的**的强度。
包2：响应端收到发送端发送的加密套件后，对比自己是否有相对应的加密套件，如果有就使用和发送端相同的加密套件加密数据，把自己的cookie值和选择好的加密套件发送给发送端；如果没有相同加密套件则IKE建立失败响应。
- Initiator SPI：b0b5887b632a532b
发送端的SPI值，告知响应端主机要使用IPSEC的哪一把**来加密这个封包。
- Responder SPI：e5dd838c8d5138b9
响应者的SPI值，告知发送端使用哪一把**加密数据包
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
- IKE Attribute (t=12,l=4): Life-Duration: 86400
**周期86400，**周期超过86400后会重新协商IKE
- IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC
IKE使用DES-CBC加密算法加密数据
- IKE Attribute (t=2,l=2): Hash-Algorithm: MD5
IKE使用MD5算法校验数据完整性
- IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key
使用预共享**认证
- IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group
Diffie-Hellman (DH) 组在**交换进程中使用的1024 bit的**的强度。
包3：发送端生成随机数和DH公共值，包3的主要目的是向响应端发送自己的DH公共值和Nonce随机数。用于生成加密时所需要的KEY值。
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
- Key Exchange Data: aba538345be9d5bfa1dff1e169b2db2a72d3771038f4cc8e...
DH公共值，DH公共值通过Diffie-Hellman算法计算出来；在包1和包2中所协商的算法，它们必须需要一个相同的KEY（即，共享**中设置的密码），但同时这个KEY不能在链路中传递。所以，该过程的目的是分别在两个对等体间独立地生成一个DH公共值，然后在报文中发送给对端，对端通过公式计算出相同的KEY值
包4：响应端收到包3后，自己生成一个随机数，然后通过Diffie-Hellman算法计算出DH公共值，把随机数和DH公共值传输给发送端。
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
- Key Exchange Data：74d204991cd082a20289989380d3b953e1505fc21af6bafc...
DH公共值，用于生成加密时所需要的KEY值
包5：发起方发起身份验证，报文中带有认证的数据（预共享**或者数字签名）。由于包1和包2已经协商好了加密算法，包3和包4协商好了加密的KEY值，所以包5的消息被加密了。
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
包6：响应端回应报文，同样发送认证的数据（预共享**或者数字签名），验证对方身份信息。包6的数据同样使用包1、包2协商的算法和包3、包4协商的key值加密数据，所以包6的认证数据是加密的。双方身份验证通过后，IKE协商结束。
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
IKE协商模式为主模式
6.1.2、IPSec加密协商
包7：发起方主要是进行IPSEC SA的协商，建立安全联盟，报文内容主要是协商用的封装方式以及后面的加密算法以及生存时间和感兴趣流等等。由于数据加密所以无法查看。
- Initiator SPI：b0b5887b632a532b
发起者的SPI值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的SPI
- Responder SPI：e5dd838c8d5138b9
响应者的SPI值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的SPI
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type：Quick Mode（32）
交换类型使用快速模式，IPSec协商时只有快速模式
包8：响应方回包，同意包7发送的封装方式、加密算法、生存时间、感兴趣流等等，同时，也能起到确认收到对端消息的作用。由于数据加密所以无法查看。
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type：Quick Mode（32）
交换类型使用快速模式，IPSec协商时只有快速模式
包9：发送确认报文。其中包含一个HASH，其作用是确认接收方的消息以及证明发送方处于主动状态（表示发送方的第一条消息不是伪造的）。由于数据加密所以无法查看。
- Version：1.0
IKE版本号，1.0表示使用ikev1建立连接
- Exchange type：Quick Mode（32）
交换类型使用快速模式，IPSec协商时只有快速模式
6.2、野蛮模式
野蛮模式使用3个报文进行交换加密方式等消息
- 发起端协商SA，发起端提供了自己的cookie值，以及SA的传输集
- 响应端收到后，会将自己的sa协商消息附上签名认证信息后发回给sa的发起者
- 发起端发送自己的数字签名认证等信息
野蛮模式无论是共享**认证还是证书认证都支持NAT穿越
7、IPsec穿越NAT
7.1、IPSec穿越NAT遇到的问题
1、穿越NAT后的身份确认问题
IPSec v*n中标准身份标识是IP地址，NAT处理过程中会改变IP地址，因此IPSec的身份确认机制必须能够适应IP地址变化；
解决此问题的方法主要有两种：第一种是使用数字证书替代IP地址作为身份标识，第二种是使用字符串取代IP地址作为身份标识。
2、IP地址复用
IPSec由AH和ESP两个协议组成。
因为AH对数据进行完整性检查，会对包括IP地址在内的整个IP包进行Hash运算。而NAT会改变IP地址，从而破坏AH的Hash值。因此AH报文无法通过NAT网关。
ESP对数据进行完整性检查，不包括外部的IP头，IP地址转换不会破坏ESP的Hash值。但ESP报文中TCP的端口已经加密无法修改，所以对于同时转换端口的NAT来说，ESP没法支持。
7.2、IKE身份确认及协商
IPSec的身份确认最常见是通过IKE协议代劳，IKE支持的身份认证机制有两种：
1、数字证书方式，通过CA数字证书体系确认身份，是最为安全、可靠的方式。
2、身份标识+预共享**方式，通过发起方和响应方预先配置相同的**，如bigtree，完成双方对彼此身份的认证，这是最为常见的方式；在预共享秘**认证机制中，身份标识则可以分为几类：
a> 指定IP地址，使用IP地址作为身份标识，是IKE的默认方式，响应方只允许指定IP地址发起协商，安全性比较高；
认证成功：
认证失败：
b> 指定IP地址范围，这种方式依然使用IP地址作为身份标识，由于发起方必须要指定IP地址，否则无法发起协商，指定IP地址范围是响应方特性，如响应方可以指定2.0.0.0/8范围内的地址都可以发起协商，而不是只允许2.1.1.2发起协商，能够减少配置，但安全性略有下降；
认证成功：
认证失败：
c> 什么都不指定，也是使用IP地址作为身份标识，但允许任意IP地址发起协商，只要预共享**一致，双方就能够通过身份确认，这种方式虽然不是非常安全，但是可以简化配置，安全性再次下降；
认证成功：
认证失败：
d> 指定对端名字，发起方和响应方都预先配置好本端名字，使用该名字作为身份标识，与指定IP地址类似，通过指定对端名字方式，即使双方预共享**一致，只要对端名字不合法，立即中断协商，由于名字未与IP地址进行绑定，而且名字在网络中明文传递，故安全性不如指定IP地址方式高，但这种身份标识方式可以穿越NAT。
认证成功：
认证失败：
7.3、穿越NAT原理抓包解释
1. 开启NAT穿越时，IKEv1协商第一阶段的前两个消息会发送标识NAT穿越（NAT Traversal，简称NAT-T）能力的Vendor ID载荷（主模式和野蛮模式都是）。用于检查通信双方是否支持NAT-T。
当双方都在各自的消息中包含了该载荷时，才会进行相关的NAT-T协商。
2. 主模式消息3和消息4（野蛮模式消息2和消息3）中发送NAT-D（NAT Discovery）载荷。NAT-D载荷用于探测两个要建立IPSec隧道的网关之间是否存在NAT网关以及NAT网关的位置。
通过协商双方向对端发送源和目的的IP地址与端口的Hash值，就可以检测到地址和端口在传输过程中是否发生变化。若果协商双方计算出来的Hash值与它收到的Hash值一样，则表示它们之间没有NAT。否则，则说明传输过程中对IP或端口进行了NAT转换。
第一个NAT-D载荷为对端IP和端口的Hash值，第二个NAT-D载荷为本端IP和端口的Hash值。
3. 发现NAT网关后，后续ISAKMP消息（主模式从消息5、野蛮模式从消息3开始）的端口号转换为4500。ISAKMP报文标识了“Non-ESP Marker”。
4. 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPSec报文封装模式：UDP封装隧道模式报文（UDP-Encapsulated-Tunnel）和UDP封装传输模式报文（UDP-Encapsulated-Transport）通过为ESP报文封装UDP头，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。
