IPSec不是一个单独的协议，而是一套网络安全协议族，包括网络认证协议AH（Authentication Header，认证头）、ESP（Encapsulating Security Payload，封装载荷）和密钥管理协议IKE（Internet Key Exchange， 因特网密钥交换）以及用户网络认证及加密的一些算法等。
IPSec工作模式分为：传输模式（transport）和隧道模式（tunnel）两种。简单来说传输模式是原始二层数据包不再附加二三四层头、隧道模式是原始二层数据包经过协议隧道封装是添加上二三四层头，IPSec的隧道模式就是在原始的ip数据包外面再封装了一层ip头，所以IPSec也经常被大家称作三层隧道协议。下面就带大家详细的了解一些这些具体的协议，以及IPSec协议实际应用中占据重要地位的穿越NAT实现。
Part 01、安全协议——AH协议
AH协议是一种基于IP的传输协议，协议号为51。具体工作方式是在每一个数据包的标准IP报文头部后面添加一个AH报文头：
AH协议发送方会对数据包和认证密钥进行hash计算，接收方收到报文之后，按照一样的算法进行hash计算并与原计算结果进行比较，如果不一致，可以推断出数据包在传输过程中遭到了修改或者破坏。通过这样的方式，能提供数据来源认证和数据完整性校验。值得一提的是AH协议的完整性校验范围是整个IP报文。
AH报文头中有几个重要的字段值得关注：安全参数索引（SPI）用于唯一标识IPSec安全联盟，序列号唯一标识每一个数据包，能用于防重放攻击。
Part 02、安全协议——ESP协议
和AH协议一样，ESP协议也是一种基于IP的传输层协议，协议号为50。具体的工作方式是在每一个数据包的IP报文头后面添加一个ESP报文头，值得注意的是，在数据包尾部还追加一个ESP尾部（ESP Tail和ESP Auth Data），同时还有一点与AH协议不同的是，ESP协议仅对IP数据包的有效载荷进行加密，对IP报文头是没有进行加密保护的。
和AH协议类似，ESP报文头中也有安全参数索引（SPI）和序列号两个字段，并且，AH协议和ESP协议的认证算法是相通的。
AH协议和ESP协议具体的比较如下：
总结：AH协议不能提供数据包加密功能，ESP协议验证范围不包括IP头部，故在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。
Part 03、 IKE协议
简单来说，IKE协议是动态协商IPSec隧道的协议，能完成身份验证、密钥交换、生成IPSec SA，协商过程中，数据包具体采用AH协议还是ESP协议封装以及身份认证就定下来了。
IKE协议目前有两个版本：IKEv1和IKEv2，IKEv2在v1的基础上，不仅简化了SA的协商过程，提高了协商效率，而且修复了多处公认的密码学方面的安全漏洞，提高了安全性能，所以实际IKEv2应用更加广泛。
以IKEv2为例，通过初始交换可以协商建立第一对IPSec SA，这其中包含两次交互四条消息，包含加密和验证算法等参数协商，生成共享密钥，完成身份认证、消息认证。如果需要创建多对IPSec SA，可以通过创建子SA交换过程协商出来，同时在协商过程中存在一些控制信息的传递，例如错误消息或者通告消息，这些信息是通过通知交换完成的。
Part 04、 NAT穿越
IPSec协议能得到广泛应用，除了能提供安全加密的传输之外，另一个重要原因是能够实现NAT穿越，这在现网传输中是极其重要的，因为公网IP资源有限，绝大部分设备都是通过NAT转换之后共享公网IP资源传输交换报文的，所以穿越NAT在现网应用中是极其重要的。
如前文描述的AH协议和ESP协议的特点，我们发现AH协议不能穿越NAT，原因是NAT会修改报文的IP头，但是AH完整性校验是基于整个IP报文的，所以导致AH协议下IPSec不能穿越NAT。而ESP报文的完整性校验不包括IP头，IP地址转换也不会破坏ESP的hash值，所以在只做IP转换的NAT场景下，ESP协议封装是支持NAT穿越的。但是很多时候，公网IP是共用的，所以NAT转换不仅需要转换IP，同时需要转换端口，但是ESP协议对IP有效载荷进行加密了，导致无法对端口号进行修改，这也是很多IP in IP的隧道无法穿越NAT的根本原因，解决办法是再加一个UDP报文头——NAT-T（NAT Traversal），源目的端口号均是4500。
NAT-T的方式隧道能解决IPSec穿越NAT的问题，但是穿越NAT之后同样存在以下两个问题：一是穿越NAT后的身份认证及IP地址复用的问题。在目前的IP网络中，IP即为身份标识，但是NAT之后IP会发生变化，当前国内主要采用字符串取代IP地址作为身份标识的方式，这样就不受NAT影响了。二是ESP协议是基于IP的协议，当NAT网关背后存在多个ESP应用端，且地址复用一个，那么无法只根据IP协议号进行反向映射，ESP协议必须要做出改变。这一点在NAT-T流程中会有具体的体现，下面我们详细阐述NAT-T流程。
首先判断双方是否支持NAT-T。当开启NAT穿越时，IKE协商过程中会发送标识NAT-T能力的vendor ID载荷，用于检查通信双方是否支持NAT-T，只有当双方都在各自的消息中包含了该载荷，后续才会进行相关的NAT-T协商。其次是判断链路上是否存在NAT设备。在IKE协商中，会发送NAT-D（NAT Discovery）载荷，这个载荷用于探测NAT设备，双方都会向对方发送源目的IP和端口的hash值，存放在该载荷中，如果在传输过程中发生改变，hash值会相应的改变，判断hash值就可以判断链路中是否存在NAT转换。最后是ESP处理，在前两步的前提下，当发现NAT网关之后，后续的IKE报文端口号转换成4500。
上述技术虽然能实现NAT穿越，但是也存在一定的局限性：使用NAT-T功能会导致在IKE协商过程中增加大约200字节的开销，数据传输过程中也会增加大约20字节的开销；同时不能采用AH协议，一定程度上也会降低安全性；NAT设备无法保证始终固定的IP和固定的端口为内部主机提供访问映射，所以IPSec必须能够自动检测变化，以保证通讯始终畅通。
Part 05、 后记
IPSec自从1990年被开发出来以来，目前为止已经应用超过30年，技术的发展经过一代代的积累也日渐成熟，基础的交换流程也比较完备，未来的发展方向大概率是在认证和加密算法上面。美国NIST在2020年也发布过特别出版物《IPSec VPNs指南》，文中指出IETF正着力于研究各类IKE与IPSec扩展议题，同时也介绍了在组播与组认证、ESP中的隐式IV、后量子密钥交换等方面的努力。未来我们将及时关注最新的IPSec技术，在实际生产和工作中进行应用，为中国移动新型网络架构添砖加瓦。
