IPSec
IPSec
IPSec简介
定义
IPSec（Internet Protocol Security）是IETF（Internet Engineering Task Force）制定的一组开放的网络安全协议。它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合，如图1所示。
图1 IPSec协议体系
IPSec通过验证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两个安全协议实现IP报文的安全保护：
AH是报文头验证协议，主要提供数据源验证、数据完整性验证和防报文重放功能，不提供加密功能。
ESP是封装安全载荷协议，主要提供加密、数据源验证、数据完整性验证和防报文重放功能。
AH和ESP协议提供的安全功能依赖于协议采用的验证、加密算法:
AH和ESP都能够提供数据源验证和数据完整性验证，使用的验证算法为MD5（Message Digest 5）、SHA1（Secure Hash Algorithm 1）、SHA2-256、SHA2-384和SHA2-512，以及SM3（Senior Middle 3）算法。
ESP还能够对IP报文内容进行加密，使用的加密算法为对称加密算法，包括DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、AES（Advanced Encryption Standard）、SM4。
说明：
MD5和SHA1验证算法存在安全隐患，建议优先使用SHA2或SM3算法。
DES和3DES加密算法存在安全隐患，建议优先使用AES或SM4算法。
IPSec加密和验证算法所使用的密钥可以手工配置，也可以通过因特网密钥交换IKE（Internet Key Exchange）协议动态协商。IKE协议建立在Internet安全联盟和密钥管理协议ISAKMP（Internet Security Association and Key Management Protocol）框架之上，采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥、验证身份，以保证数据传输的安全性。IKE协议可提升密钥的安全性，并降低IPSec管理复杂度。
目的
在Internet的传输中，绝大部分数据的内容都是明文传输的，这样就会存在很多潜在的危险，比如：密码、银行帐户的信息被窃取、篡改，用户的身份被冒充，遭受网络恶意攻击等。网络中部署IPSec后，可对传输的数据进行保护处理，降低信息泄露的风险。
受益
IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：
数据来源验证：接收方验证发送方身份是否合法。
数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发。
数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改。
抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
IPSec基本概念
IPSec安全传输数据的前提是在IPSec对等体（即运行IPSec协议的两个端点）之间成功建立安全联盟SA（Security Association）。SA是通信的IPSec对等体间对某些要素的约定，例如：对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密算法、验证算法，对等体间使用何种密钥交换和IKE协议，以及SA的生存周期等。
安全联盟
SA由一个三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。
SA是单向的逻辑连接，因此两个IPSec对等体之间的双向通信，最少需要建立两个SA来分别对两个方向的数据流进行安全保护。如图1所示，为了在对等体A和对等体B之间建立IPSec隧道，需要建立两个安全联盟，其中，SA1规定了从对等体A发送到对等体B的数据采取的保护方式，SA2规定了从对等体B发送到对等体A的数据采取的保护方式。
图1 IPSec安全联盟
另外，SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。
有两种方式建立IPSec安全联盟：手工方式和IKE自动协商方式。二者的主要区别为：
密钥生成方式不同
手工方式下，建立SA所需的全部参数，包括加密、验证密钥，都需要用户手工配置，也只能手工刷新，在中大型网络中，这种方式的密钥管理成本很高；IKE方式下，建立SA需要的加密、验证密钥是通过DH算法生成的，可以动态刷新，因而密钥管理成本低，且安全性较高。
生存周期不同
手工方式建立的SA，一经建立永久存在；IKE方式建立的SA，其生存周期由双方配置的生存周期参数控制。
因此，手工方式适用于对等体设备数量较少时，或是在小型网络中。对于中大型网络，推荐使用IKE自动协商建立SA。
安全协议
IPSec使用认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两种安全协议来传输和封装数据，提供认证或加密等安全服务。
AH协议
AH是一种基于IP的传输层协议，协议号为51。其工作原理是在每一个数据包的标准IP报头后面添加一个AH报文头，如封装模式所示。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
AH报文头结构如图1所示。
图1 AH报文头结构
AH报文头字段含义如表1所述。
表1 AH报文头字段含义
| 字段 | 长度 | 含义 |
|---|---|---|
| 下一头部 | 8比特 | 标识AH报文头后面的负载类型。传输模式下，是被保护的上层协议（TCP或UDP）或ESP协议的编号；隧道模式下，是IP协议或ESP协议的编号。 说明： 当AH与ESP协议同时使用时，AH报文头的下一头部为ESP报文头。 |
| 负载长度 | 8比特 | 表示以32比特为单位的AH报文头长度减2，缺省为4。 |
| 保留字段 | 16比特 | 保留将来使用，缺省为0。 |
| SPI | 32比特 | IPSec安全参数索引，用于唯一标识IPSec安全联盟。 |
| 序列号 | 32比特 | 是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。 |
| 认证数据 | 一个变长字段，长度为32比特的整数倍，通常为96比特。 | 该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。 说明： MD5和SHA1验证算法存在安全隐患，建议优先使用SHA2或SM3算法。 |
ESP协议
ESP是一种基于IP的传输层协议，协议号为50。其工作原理是在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Tail和ESP Auth data），如封装模式所示。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护。ESP报文头结构如图2所示。
图2 ESP报文头结构
ESP报文头字段含义如表2所述。
表2 ESP报文头字段含义
| 字段 | 长度 | 含义 |
|---|---|---|
| SPI | 32比特 | IPSec安全参数索引，用于唯一标识IPSec安全联盟。 |
| 序列号 | 32比特 | 是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。 |
| 负载数据 | — | 包含由下一头部字段给出的变长数据。 |
| 填充字段 | — | 用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的明文长度不是加密算法所要求的块长度时，需要进行填充补齐。 |
| 填充长度 | 8比特 | 给出前面填充字段的长度，置0时表示没有填充。 |
| 下一头部 | 8比特 | 标识ESP报文头后面的下一个负载类型。传输模式下，是被保护的上层协议（TCP或UDP）的编号；隧道模式下，是IP协议的编号。 |
| 认证数据 | 一个变长字段，长度为32比特的整数倍，通常为96比特。 | 该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。可选择的认证算法与AH的相同。 |
ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。
AH协议和ESP协议比较
AH和ESP协议的简单比较如表3所示。
表3 AH协议与ESP协议比较
| 安全特性 | AH | ESP |
|---|---|---|
| 协议号 | 51 | 50 |
| 数据完整性校验 | 支持（验证整个IP报文） | 支持（不验证IP头） |
| 数据源验证 | 支持 | 支持 |
| 数据加密 | 不支持 | 支持 |
| 防报文重放攻击 | 支持 | 支持 |
| IPSec NAT-T（NAT穿越） | 不支持 | 支持 |
从表中可以看出两个协议各有优缺点，AH协议不提供数据加密功能，ESP的验证范围不包括IP头，故在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。
封装模式
封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。
传输模式
在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。传输模式不改变报文头，故隧道的源和目的地址必须与IP报文头中的源和目的地址一致，所以只适合两台主机或一台主机和一台VPN网关之间通信。
以TCP报文为例，原始报文经过传输模式封装后，报文格式如图1所示。
图1 传输模式下报文封装
传输模式下，AH协议的完整性验证范围为整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、传输层协议头、数据和ESP报尾，但不包括IP头，因此ESP协议无法保证IP头的安全。ESP的加密部分包括传输层协议头、数据和ESP报尾。
隧道模式
在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。
以TCP报文为例，原始报文经隧道模式封装后的报文结构如图2所示。
图2 隧道模式下报文封装
隧道模式下，AH协议的完整性验证范围为包括新增IP头在内的整个IP报文。ESP协议验证报文的完整性检查部分包括ESP头、原IP头、传输层协议头、数据和ESP报尾，但不包括新IP头，因此ESP协议无法保证新IP头的安全。ESP的加密部分包括原IP头、传输层协议头、数据和ESP报尾。
传输模式和隧道模式比较
传输模式和隧道模式的区别在于：
从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据报进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。
从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。
加密
加密是一种将数据按照某种算法从明文转换成密文的过程，接收方只有在拥有正确的密钥的情况下才能对密文进行解密，从而保证数据的机密性，防止数据在传输过程中被窃听。IPSec工作过程中涉及数据加密和协议消息加密两种加密情况。
数据加密
IPSec采用对称加密算法对数据进行加密和解密。对称加密算法是指数据发送方和接收方使用相同的密钥进行加密、解密。
采用对称加密算法进行数据加密和解密的过程如图1所示。
图1 加密和解密的过程
用于加密和解密的对称密钥可以手工配置，也可以通过IKE协议自动协商生成。常用的对称加密算法包括：
数据加密标准DES（Data Encryption Standard）
DES是由美国国家标准与技术研究院（NIST）开发的。它使用56位的密钥对一个64位的明文块进行加密。
3DES（Triple Data Encryption Standard）
3DES是一种增强型的DES标准，它在需要保护的数据上使用3次DES，即使用三个不同的56位的DES密钥（共168位密钥）对明文进行加密。
3DES与DES相比，3DES具有更高的安全性，但其加密数据的速度要比DES慢得多。
先进加密标准AES（Advanced Encryption Standard）
AES被设计用来替代3DES，提供更快和更安全的加密功能。AES可以采用三种密钥：AES-128、AES-192和AES-256，其密钥长度分为128位、192位、256位。随着密钥长度的提升，加密算法的保密及安全性要求越高，但计算速度也越慢。一般情况下128bit就可以充分满足安全需求。
国密算法（SM4）
国密算法是由国家密码管理局编制的一种商用密码分组标准对称算法，国密算法的分组长度和密钥长度都为128bit。
在安全级别要求较高的情况下，使用SM4国密算法可以充分满足加密需求。
协议消息加密
协议消息加密用于IKE协商阶段。协议消息加密所用的算法也是DES、3DES、AES和SM4等对称加密算法。用于加密的对称密钥通过IKE协议自动协商生成。
验证
验证指IP通信的接收方确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。前者称为数据源验证，后者称为数据完整性验证，IPSec通过这两种验证保证数据真实可靠。数据源验证和数据完整性验证这两种安全服务总是绑定在一起提供的。
虽然加密后的数据只能通过原始的加密密钥进行解密，但是无法验证解密后的信息是否是原始发送的信息。另外加密和解密的过程非常的消耗CPU，恶意用户可能会通过发送欺骗数据包，占用CPU资源。HMAC（Keyed-Hash Message Authentication Code）功能通过比较数字签名进行数据包完整性和真实性验证，这个过程消耗的CPU资源非常少，效率非常高。因此，IPSec采用HMAC功能进行验证。
在IPSec发送方，加密和验证通常配合使用。加密后的报文经HMAC生成数字签名，IP报文和数字签名同时发给对端（数字签名填写在AH和ESP报文头的完整性校验值ICV字段，请参见安全协议）；在IPSec接收方，通过比较数字签名进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。加密和HMAC验证配合使用的过程如图1所示。
图1 HMAC验证过程
同加密一样，用于验证的对称密钥也可以手工配置，或者通过IKE协议自动协商生成。常用的验证算法包括：
MD5
消息摘要MD5（Message Digest 5）在RFC1321中有明文规定。输入任意长度的消息，MD5产生128位的签名。
MD5比SHA更快，但是安全性稍差。
SHA1
安全散列算法SHA（Secure Hash Algorithm）是由NIST开发的。在1994年对原始的HMAC功能进行了修订，被称为SHA1。SHA1在RFC2404中描述。输入长度小于264bit的消息，SHA1产生160位的消息摘要。
SHA1比MD5要慢，但是更安全。因为它的签名比较长，具有更强大的防攻破功能，并可以更有效的发现共享的密钥。
SHA2
SHA2是SHA1的加强版本，SHA2算法相对于SHA1加密数据长度有所上升，安全性能要远远高于SHA1。SHA2算法包括SHA2-256、SHA2-384和SHA2-512，密钥长度分别为256位、384位和512位。随着密钥长度的上升，认证算法安全强度更高，但计算速度越慢。一般情况下256位就可以充分满足安全需求。
SM3国密算法SM3（Senior Middle 3）是国家密码管理局编制的商用算法，用于密码应用中的数字签名和验证、消息认证码的生成与验证以及随机数的生成，可满足多种密码应用的安全需求。
以上几种算法各有特点，MD5算法的计算速度比SHA1算法快，而SHA1算法的安全强度比MD5算法高，SHA2、SM3算法相对于SHA1来说，加密数据位数的上升增加了破解的难度，使得安全性能要远远高于SHA1。
密钥交换
使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：
带外共享密钥
在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。
使用一个安全的密钥分发协议
通过IKE协议自动协商密钥。IKE采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。同时，通信双方通过交换密钥交换材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。
IKE协议
因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的使用和管理，大大简化IPSec的配置和维护工作。
IKE与IPSec的关系如图1所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。
图1 IKE与IPSec的关系图
IKE的安全机制
IKE具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA：
身份认证
身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证。
在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。
对于预共享密钥认证方法，当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。而数字信封认证用于设备需要符合国家密码管理局要求时使用，此认证方法只能在IKEv1的主模式协商过程中支持。
IKE支持的认证算法有：MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、AES-XCBC-MAC-96、SM3。
身份保护
身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
IKE支持的加密算法有：DES、3DES、AES-128、AES-192、AES-256和SM4。
DH
DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
MD5、SHA1、DES、3DES、AES等算法都可以采用DH算法来共享对称密钥。
DH使用密钥组定义自己产生的密钥长度。密钥组长度越长，产生的密钥就越强壮。
表1 DH密钥组
| 密钥组 | 长度 |
|---|---|
| 1 | 768位 |
| 2 | 1024位 |
| 5 | 1536位 |
| 14 | 2048位 |
| 15 | 3072位 |
| 16 | 4096位 |
| 18 | 8192位 |
| 19 | 256位ECP（Elliptic Curve Groups modulo a Prime） |
| 20 | 384位ECP |
| 21 | 521位ECP |
PFS
完善的前向安全性PFS（Perfect Forward Secrecy）是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。IPSec SA的密钥是从IKE SA的密钥导出的，由于一个IKE SA协商生成一对或多对IPSec SA，当IKE的密钥被窃取后，攻击者将可能收集到足够的信息来导出IPSec SA的密钥，PFS通过执行一次额外的DH交换，保证IPSec SA密钥的安全。
说明：
MD5和SHA1认证算法不安全，建议使用SHA2-256、SHA2-384、SHA2-512、AES-XCBC-MAC-96、SM3算法。DES和3DES加密算法不安全，建议使用AES或SM算法。
IKEv1协议和IKEv2协议比较
IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：
简化了安全联盟的协商过程，提高了协商效率。
IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
加入对EAP（Extensible Authentication Protocol）身份认证方式的支持，提高了认证方式的灵活性和可扩展性。
EAP是一种支持多种认证方法的认证协议，可扩展性是其最大的优点，即若想加入新的认证方式，可以像组件一样加入，而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。
IPSec基本原理
IPSec通过在IPSec对等体间建立双向安全联盟形成一个安全互通的IPSec隧道，并通过定义IPSec保护的数据流将要保护的数据引入该IPSec隧道，然后对流经IPSec隧道的数据通过安全协议进行加密和验证，进而实现在Internet上安全传输指定的数据。
IPSec安全联盟可以手工建立，也可以通过IKEv1或IKEv2协议自动协商建立。手工方式与IKE自动协商方式建立安全联盟的主要区别在于，前者建立安全联盟的所有参数都要用户手工配置和维护，在IPSec对等体两端参数匹配和协商通过后建立安全联盟；后者只需要配置IKE协商的信息，由IKE自动协商来建立和维护安全联盟。后者的配置维护更简单，且密钥更安全，因此通常推荐采用IKE自动协商方式建立安全联盟。本文仅介绍IKE自动协商建立安全联盟的过程。
定义IPSec保护的数据流
IPSec对需要保护的数据流的定义基于以下两种方式：
ACL方式
手工方式和IKE自动协商方式建立的IPSec隧道是由ACL来指定要保护的数据流范围，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，ACL规则拒绝（deny）的报文将不被保护。这种方式可以利用ACL的丰富配置功能，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定IPSec的保护方法。
安全框架方式
安全框架方式通过IPSec虚拟隧道接口建立IPSec隧道，将所有路由到IPSec虚拟隧道接口的报文都进行IPSec保护。其中IPSec虚拟隧道接口是一种三层逻辑接口。
安全框架方式通过IPSec虚拟隧道接口建立IPSec隧道具有以下优点：
简化配置
将需要IPSec保护的数据流引到虚拟隧道接口，不需使用ACL定义待加/解密的流量特征。
支持范围更广
点对点IPSec虚拟隧道接口可以支持动态路由协议，同时还可以通过GRE over IPSec对组播流量进行保护。
IKEv1协商安全联盟的过程
采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。
IKEv1协商阶段1
IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。IKE SA是一个双向的逻辑连接，两个IPSec对等体间只建立一个IKE SA。
IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。
主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：
1.消息①和②用于策略交换
发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
2.消息③和④用于密钥信息交换
双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
3.消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
说明：
IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
nonce是个随机数，用于保证IKE SA存活和抗重放攻击。
野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。IKEv1协商阶段1的协商过程如图1所示。
图1 IKEv1协商阶段1的协商过程图
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。
IKEv1协商阶段2
IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图2所示。
图2 IKEv1协商阶段2的协商过程图
IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：
1.协商发起方发送本端的安全参数和身份认证信息。
安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
说明： IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。
2.协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。
IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。
如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
3.发送方发送确认信息，确认与响应方可以通信，协商结束。
IKEv2协商安全联盟的过程
采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。
初始交换
正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息，如图1所示。
图1 初始交换过程图
消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。
消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。EAP认证是作为附加的IKE_AUTH交换在IKE中实现的，发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
创建子SA交换
当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。
创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。
类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
通知交换
运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的，如图2所示。
通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。
图2 通知交换过程图 
IPSec增强原理
DHCP over IPSec
在LTE场景下，eNodeB位于不安全的接入网络内，eNodeB需要通过汇聚网络中的DHCP服务器获取一个私网IP地址，用于与M2000相连，建立临时OM通道，获取OM配置等。由于eNodeB跟DHCP服务器不在同一个网络内，汇聚网络的网关设备需要开启DHCP中继功能。同时，由于中间穿越不安全的接入网络，为了防止在接入网络中传输时，DHCP协议报文被拦截、修改或者仿冒，可使用IPSec对DHCP协议进行加密和验证，提高传输的安全性。
如图1所示为DHCP over IPSec的典型组网，FW为汇聚网络的网关设备。eNodeB和FW上同时部署DHCP over IPSec功能，其间建立IPSec隧道。隧道建立后FW作为DHCP客户端（eNodeB）跟DHCP服务器之间DHCP中继，将eNodeB的DHCP请求报文转发给DHCP服务器，并将DHCP服务器的DHCP应答报文转发给eNodeB。
图1 DHCP over IPSec典型组网
DHCP over IPSec的工作原理如下：
1.eNodeB跟FW之间通过IKE主模式或野蛮模式协商IKE SA。
2.eNodeB跟FW通过快速模式协商第二阶段的IPSec SA。该IPSec SA只能用来保护eNodeB跟FW之间发生的DHCP流量。
3.eNodeB向DHCP服务器发起DHCP地址分配请求。DHCP请求报文由作为DHCP中继的FW转发。eNodeB到FW之间经过IPSec隧道，DHCP报文由其进行加密传输。
4.DHCP服务器响应eNodeB的DHCP请求。DHCP响应报文同样由FW转发。DHCP服务器位于安全的骨干网络中，DHCP服务器与FW之间的DHCP报文不进行加密。
5.DHCP交互完成后，eNodeB获取一个动态IP地址。然后，eNodeB跟FW之间协商新的IPSec SA，用于保护eNodeB承载的业务流量。
说明： 图中的DHCP服务器只能为eNodeB分配私网IP地址，不能分配公网IP地址。
IKEv1+XAUTH认证
如图1所示，PC用户远程接入企业总部，PC和总部之间通信通过IPSec隧道进行安全传输。
通常情况下，PC用户采用预共享密钥方式与总部协商建立IPSec。多个PC远程接入总部时，总部为每一个PC用户设置不同IPSec策略和预共享密钥用以区分每一个用户，此工作量是巨大的，管理也不方便。如果总部配置相同的IPSec策略和预共享密钥，则提高了方便性和降低了工作量，但是又降低了远程接入的安全性。
还有一种方案，PC用户采用RSA方式与总部协商建立IPSec。此方式的PC用户无需输入用户名和密码用证书与总部进行认证，如果PC被盗，则非法获取该设备的人可以毫无障碍地接入总部，获取机密信息，存在安全隐患。
为了解决以上问题，IKEv1+XAUTH认证（即IKEv1扩展认证）方案被提出，在IKE协商时，第一阶段IKE SA协商完成后，总部会对PC用户发起IKEv1扩展认证来验证用户的用户名和密码，如果扩展认证通过，则继续进行第二阶段IPSec SA的协商；如果扩展认证失败，则停止IKE协商，建立IPSec隧道失败。
说明：
在IKEv1+XAUTH认证场景中，客户端需支持IKEv1+XAUTH认证。
图1 IKEv1+XAUTH认证组网图
IIKEv1+XAUTH认证有两种认证方式：
PAP认证：支持本地和服务器认证。
PAP认证过程如图2所示。
图2 PAP认证过程（服务器认证）
1.PC与FW进行IKE SA协商。
2.IKE SA协商成功后，FW根据配置的扩展认证，向PC发送扩展认证请求报文。
3.PC收到FW的扩展认证请求报文，向FW发送扩展认证请求应答报文（携带用户名和密码信息）。
4.FW收到PC的应答后，向RADIUS服务器发送扩展认证请求报文（携带用户名和密码信息）。
5.RADIUS服务器收到扩展认证请求报文后，将PC的用户名和密码与本端配置的用户名和密码进行比较，如果用户名和密码一致，则认证通过。RADIUS服务器向FW发送扩展认证请求应答报文。
6.FW收到RADIUS服务器的应答后，向PC发送扩展认证结果。
7.PC收到FW的扩展认证结果后，向FW发送确认消息，确认收到了扩展认证结果。
8.PC与FW进行IPSec SA协商。
如果采用本地认证，则FW收到PC的应答后，将PC的用户名和密码与本端配置的用户名和密码进行比较，如果用户名和密码一致，则认证通过。然后，FW向PC发送扩展认证结果。
CHAP认证：支持本地和服务器认证。
CHAP认证过程如图3所示。
图3 CHAP认证过程（服务器认证）
1.PC与FW进行IKE SA协商。
2.IKE SA协商成功后，FW根据配置的扩展认证，向PC发送随机报文（Challenge）。
3.PC收到FW的Challenge后，对用户的密码进行MD5 HASH计算生成摘要，向FW发送扩展认证信息（携带用户名、摘要和Challenge等）。
4.FW收到PC的应答后，向RADIUS服务器发送扩展认证请求报文（携带用户名、摘要和Challenge等）。
5.RADIUS服务器收到扩展认证请求报文后，对本端配置的密码进行MD5 HASH计算生成摘要，并与接收到的摘要进行比较，如果一致，则认证通过。RADIUS服务器向FW发送扩展认证请求应答报文。
6.FW收到RADIUS服务器的应答后，向PC发送扩展认证结果。
7.PC收到FW的扩展认证结果后，向FW确认消息，确认收到了扩展认证结果。
8.PC与FW进行IPSec SA协商。
IKEv2+EAP认证
如图1所示，无线设备通过基站远程接入IP核心网，或者移动PC通过Internet远程接入IP核心网，基站/移动用户与IP核心网网关FW之间通过建立IPSec隧道进行安全传输。基站采用EAP（Extensible Authentication Protocol）认证接入总部网关，EAP认证的认证服务器（以RADIUS服务器为例）部署在IP核心网。为此，需要在IKE报文中传递EAP认证报文以实现EAP认证。
可部署IKEv2+EAP认证，IKEv2协议支持采用EAP方式对协商的发起方进行附加的用户身份认证。IKEv2+EAP认证中，EAP认证作为附加的IKE_AUTH交换，IKEv2通过在IKE_AUTH交换的消息3中省去认证数据来表明需要使用EAP认证。交换过程中，EAP认证报文作为认证载荷由IKEv2协议报文传递到FW，FW将EAP载荷从IKEv2协议报文中提取出来，然后转给RADIUS服务器，进而实现EAP认证。EAP认证通过后，IKEv2协议才会协商建立IPSec隧道。
相对于L2TP方式接入，这种方式配置更简单，协商速度更快。
图1 IKEv2+EAP认证典型组网图
说明： 移动PC需要安装IKEv2拨号软件才能支持IKEv2+EAP认证。
EAP协议有20多种，目前设备只支持基本的EAP-MD5（Message Digest 5）协议、基于SIM（Subscriber Identity Module）卡的EAP-AKA（Authenticantion and Key Agreement）和EAP-SIM协议：
EAP-MD5
当远程接入终端是PC时，EAP认证一般采用EAP-MD5协议。
EAP-SIM
当远程接入终端是2G手机时，EAP认证采用EAP-SIM协议。EAP-SIM协议在无线局域网WLAN（Wireless LAN）上提供了基于GSM-SIM（即2G手机SIM卡）的认证和密钥分发机制。
EAP-AKA
当远程接入终端是3G手机或安装了USIM集成电路卡UICC（USIM Integrated Circuit Card）的PC时，EAP认证采用EAP-AKA协议。EAP-AKA协议在WLAN上提供了基于全球用户识别卡USIM（Universal Subscriber Identity Module，即3G手机的SIM卡）的认证和密钥分发机制。
L2TP over IPSec
L2TP over IPSec，即先用L2TP封装报文再用IPSec封装，这样可以综合两种VPN的优势，通过L2TP实现用户验证和地址分配，并利用IPSec保障通信的安全性。L2TP over IPSec既可以用于分支接入总部，也可以用于出差员工接入总部。
分支接入总部网络的L2TP over IPSec的工作原理如图1所示，这里以NAS-Initiated L2TP VPN为例。对于其他L2TP VPN场景，请参见L2TP VPN中的描述。
图1 L2TP over IPSec报文封装和隧道协商过程
报文在隧道中传输时先进行L2TP封装再进行IPSec封装。IPSec封装过程中增加的IP头即源地址为IPSec网关应用IPSec安全策略的接口IP地址，目的地址即IPSec对等体中应用IPSec安全策略的接口IP地址。
IPSec需要保护的是从L2TP的起点到L2TP的终点数据流。L2TP封装过程中增加的IP头即源IP地址为L2TP起点地址，目的IP地址为L2TP终点的地址。分支接入总部组网中L2TP起点地址为LAC出接口的IP地址，L2TP终点的地址为LNS入接口的IP地址。
由于L2TP封装时已经增加了一个公网IP头，而隧道模式跟传输模式相比又多增加了一个公网IP头，导致报文长度更长，更容易导致分片。所以推荐采用传输模式L2TP over IPSec。出差用户远程接入总部网络的组网中L2TP over IPSec的协商顺序和报文封装顺序跟分支接入总部网络的组网中的协商顺序和报文封装顺序是一样的。所不同的是出差用户远程接入总部网络的组网中，用户侧的L2TP和IPSec封装是在客户端上完成的。L2TP起点的地址为客户端将要获取的内网地址，此地址可以是LNS上配置的IP地址池中的任意地址。L2TP终点地址为LNS入接口的地址。
GRE over IPSec
GRE over IPSec可利用GRE和IPSec的优势，通过GRE将组播、广播和非IP报文封装成普通的IP报文，通过IPSec为封装后的IP报文提供安全地通信，进而可以提供在总部和分支之间安全地传送广播、组播的业务，例如视频会议或动态路由协议消息等。
当网关之间采用GRE over IPSec连接时，先进行GRE封装，再进行IPSec封装。GRE over IPSec使用的封装模式为可以是隧道模式也可以是传输模式。因为隧道模式跟传输模式相比增加了IPSec头，导致报文长度更长，更容易导致分片，所以推荐采用传输模式GRE over IPSec。
图1 GRE over IPSec报文封装和隧道协商过程
IPSec封装过程中增加的IP头即源地址为IPSec网关应用IPSec安全策略的接口地址，目的地址即IPSec对等体中应用IPSec安全策略的接口地址。
IPSec需要保护的数据流为从GRE起点到GRE终点的数据流。GRE封装过程中增加的IP头即源地址为GRE隧道的源端地址，目的地址为GRE隧道的目的端地址。
IPSec多实例
IPSec多实例主要用于向小企业提供防火墙租赁业务和实现企业内部网络隔离。
如图1所示，三个小企业的分支共用一台VPN网关。三个企业之间需要保持网络独立，互相之间不会产生影响。三个企业的分支内部网络IP地址是各自规划的，可能出现IP地址重叠（即不同私网出现使用相同IP地址的情况），此时需要在网关上应用IPSec多实例功能，将三个企业的IPSec隧道与三个IPSec多实例绑定，保证相同IP地址的报文能够正确转发。
图1 IPSec多实例典型组网
TCP-MSS自动调整
设备支持对TCP建链阶段的SYN或SYN-ACK报文的最大报文长度MSS（Maximum Segment Size）进行动态调整。
背景信息
TCP建链阶段，SYN或SYN-ACK报文的Option选项中可能会携带MSS字段，用来告知对端设备本端能够接收的最大报文段长度。设备交换过MSS值后会进行比较，选择较小MSS的值用于转发报文，保证网络中不存在分片报文。在不存在报文分片的情况下，MSS值越大允许每个报文段传送的数据就越大，网络利用率就越高。适当调整MSS值可以使得TCP报文端到端传输过程中尽量不分片，同时尽量传输大字节的数据报文，提高端到端TCP传输效率。
实现机制
当SYN或SYN-ACK报文中没有带MSS字段时，设备会自动插入合适的MSS值：
MSS=MTU-40–APPENDLEN
其中，MSS表示自动插入的MSS值，MTU表示接口的最大传输单元，APPENDLEN表示进行VPN加密封装时增加的报文长度。
当SYN或SYN-ACK报文中带有MSS字段时，设备会比较MSS-APPENDLEN与MTU-40-APPENDLEN的大小，并把过大的MSS值改小： 其中，MSS表示自动插入的MSS值，MTU表示接口的最大传输单元，APPENDLEN表示进行VPN加密封装时增加的报文长度。 使用限制 设备上VPN通过的接口的MTU值必须完全一致。 只有当接口的MTU值在256～9600时才进行TCP-MSS自动调整。 仅单纯的IPSec、GRE、L2TP业务支持此功能，L2TP over IPSec、GRE over IPSec等业务不支持此功能。 IPSec可靠性 IPSec智能选路 FW作为分支的网关时，可以通过配置IPSec智能选路功能实现多条IPSec隧道动态切换。 IPSec智能选路功能按照链路切换机制的不同有两种使用场景，一种是基于链路质量探测结果切换链路，另一种是基于路由状态变化切换链路。 基于链路质量探测结果切换链路 如图1所示，隧道两端的网关设备有多个公网接口，网关设备之间存在多条可通信的链路。通过在FW_B上配置IPSec智能选路功能，可以实现分支和总部之间多条IPSec隧道动态切换。使用其中一条链路建立IPSec隧道后，网关设备会实时检测已有IPSec隧道的时延或丢包率。在时延或丢包率高于设定的阈值时，动态切换到备用链路上重新建立IPSec隧道。 图1 基于链路质量探测结果切换链路 基于路由状态变化切换链路 如图2所示，从分支网关FW_B到总部网关FW_A之间有两条链路Link1和Link2，FW_B与Internet之间运行动态路由协议（此处以OSPF为例）。在FW_B上配置IPSec智能选路功能，可以实现分支和总部之间多条IPSec隧道动态切换。 图2 基于路由状态变化切换链路 为提高网络可靠性，企业分支一般通过两条或多条链路与企业总部建立IPSec连接，如何在一条链路故障后将流量及时切换到其他链路，以保证业务的正常运行就成为需要解决的问题。为此，设备提供IPSec主备链路冗余备份和IPSec多链路冗余备份两种功能。 IPSec主备链路冗余备份 如图1所示，FW_A通过主备两条链路连接FW_B。在FW_A上创建两个Tunnel接口，借用同一个物理接口的IP地址，分别应用不同的IPSec安全策略，在FW_B的两个物理接口上也分别应用不同的IPSec安全策略，这样可以创建主备两条IPSec隧道。正常情况下，流量通过由主链路和Tunnel1接口建立的IPSec隧道传输；当主链路故障时，FW_A感知变化，采用Tunnel2接口与FW_B的备份链路建立IPSec隧道，旧的IPSec隧道被拆除，流量切换也随之完成。 图1 主备链路冗余备份 如图2所示，FW_A通过主备两条链路连接FW_B。系统在FW_A的物理接口与FW_B的Tunnel接口之间建立一个IPSec隧道，流量通过Tunnel接口进行IPSec处理，然后通过路由表选择物理接口发送。当主物理链路失效时，其路由变为不可达，流量自然切换到备用链路。这种情况下，IPSec隧道不需要进行重协商，故可快速完成流量切换。 图2 通过Tunnel接口进行链路冗余备份 注意 IPSec双机热备 FW支持主备方式和负载分担方式两种双机热备。需根据实际组网情况进行选择。 说明： IPSec双机热备（主备方式） 如图1所示，FW_A1和FW_A2对外配置VRRP备份组1，并在VRRP备份组1和分支网关FW_B的物理接口之间建立IPSec隧道。当主用FW_A1物理接口、链路或主机故障时，流量被引导到备用FW_A2进行IPSec和转发处理。这种情况下，原有的IPSec隧道并不会被拆除，切换速度更具优势。 图1 IPSec双机热备 负载分担方式的IPSec双机热备主要应用在LTE场景下，又分为以下3种典型场景，不同场景下的实现机制略有不同。 IPSec网关负载分担，隧道不备份 如图2所示，FW_A1和FW_A2以负载分担方式工作。eNodeB1和FW_A1、FW_A2各建了一条IPSec隧道，这两条IPSec隧道共同分担了分支发往总部的流量。这两条IPSec隧道之间不存在备份关系，彼此独立，因而互不影响。当FW_A1发生故障时，eNodeB1与FW_A1的IPSec隧道将断开，分支发往总部的流量将全部通过eNodeB1与FW_A2之间的IPSec隧道发往总部。反之，当FW_A2发生故障时，流量将会全部通过eNodeB1与FW_A1之间的IPSec隧道发往总部。 图2 IPSec网关负载分担，隧道不备份 建立隧道的基本原理是：分别在FW_A1和FW_A2的物理接口上配置相同的两个IP地址IP_1和IP_2。eNodeB1会以IP_1地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel1，eNodeB2会以IP_2地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel2。FW_A1和FW_A2运行正常时，eNodeB1下的用户发给总部的流量将由eNodeB1与FW_A1之间的主IPSec Tunnel1发往总部；eNodeB2下的用户发给总部的流量将由eNodeB2与FW_A2之间的主IPSec Tunnel2发往总部。当FW_A1出现故障时，eNodeB1则会将流量通过eNodeB1与FW_A2之间的备IPSec Tunnel1发往总部。同样，当FW_A2出现故障时，eNodeB2也将会使用备IPSec Tunnel2发送流量。 图3 IPSec网关负载分担，上下行连接路由器 图4 IPSec网关负载分担，上下行连接交换机
若MTU-40-APPENDLEN>MSS-APPENDLEN，则保留并使用原有的MSS值。
若MTU-40-APPENDLEN
在FW_B上配置IPSec智能选路功能后，FW_B会选择一条链路建立IPSec隧道。而后FW_B通过发送ICMP报文检测IPSec隧道的时延或丢包率。当隧道的时延或丢包率高于设定的阈值时，FW_B会拆除当前的IPSec隧道，并选择另一条链路建立IPSec隧道。新的隧道建立后，FW_B继续检测隧道的时延或丢包率，如果时延或丢包率仍然高于设定的阈值，FW_B会继续切换链路，直至隧道的时延和丢包率达标或者循环切换次数达到设定的上限值时停止。这样，就能确保分支和总部之间始终使用满足质量要求的IPSec隧道通信。
Link1和Link2链路状态都正常的情况下，FW_B会选择一条链路建立IPSec隧道，例如选择Link1链路。当Link1链路出现故障时，通过Link1到达FW_A的路由就会消失，于是FW_B会根路由变化自动将IPSec隧道切换到Link2上。
链路冗余备份
IPSec多链路冗余备份
通过Tunnel接口进行链路冗余备份可以实现多条链路的冗余备份，而且与主备链路冗余备份相比，配置更简单，流量切换速度更快。
当IPSec网关连接不同的运营商网络或者即使连接的是同一个运营商的网络，但存在主备两条链路跨局域网、跨区域连接到一个运营商的不同接入路由器上，都可能存在主链路故障后，备链路设备发现IPSec报文的源地址属于不同运营商或不同接入路由器而将报文丢弃的问题。因此进行配置时一定要先测试一下，看看实际网络环境是否允许主备链路倒换。
双机热备场景下，要求两台网关的软硬件配置完全一致，包括硬件插板的数量、位置，硬件版本和驱动软件版本、主机软件版本等。
IPSec双机热备（负载分担方式）
IPSec网关负载分担，上下行连接路由器
如图3所示，FW_A1和FW_A2以负载分担方式工作。eNodeB1/eNodeB2分别与FW_A1和FW_A2建立了主、备IPSec隧道。
IPSec网关负载分担，上下行连接交换机
如图4所示，FW_A1和FW_A2以负载分担方式工作。eNodeB1和eNodeB2分别与FW_A1和FW_A2建立了主、备IPSec隧道。
建立隧道的基本原理是：在FW_A1和FW_A2上分别创建一个VRRP备份组1，eNodeB1将会以VRRP备份组1的虚拟IP地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel1。同样，在FW_A1和FW_A2上分别创建一个VRRP备份组2，eNodeB2将会以VRRP备份组2的虚拟地址作为隧道对端地址与FW_A1和FW_A2建立主、备IPSec Tunnel2。当FW_A1和FW_A2运行正常时，eNodeB1下的用户发给总部的流量将由eNodeB1与FW_A1之间的主IPSec Tunnel1发往总部。eNodeB2下的用户发给总部的流量将由eNodeB2与FW_A2之间的主IPSec Tunnel2发往总部。当FW_A1出现故障时，eNodeB1则会将流量通过eNodeB1与FW_A2之间的备IPSec Tunnel1发往总部。同样，当FW_A2出现故障时，eNodeB2也将会使用备IPSec Tunnel2发送流量。
