3.2 IPSec框架

一些传统的安全技术（如HTTPS）以及无线安全技术（如WEP/WPA），往往会采用某种固定的加密和散列函数。这种做法带有明显的赌博性质，因为如果某天这个加密算法曝出严重漏洞，那么使用这个加密算法或者散列函数的安全技术也就难免要遭到淘汰。为了避免这种在一棵树上吊死的悲惨事件发生，IPSec并没有定义具体的加密和散列函数。IPSec的做法是提供一个框架性的结构，但每一次IPSec会话所使用的具体算法，都是通过协商来决定的。也就是说如果我们觉得 3DES 这个算法所提供的 168 位的加密强度能够满足当前的需要，那么就不妨暂且使用这个协议来加密数据。但是只要有一天 3DES 出现了严重漏洞，或者出现了一个更好的加密协议，那么我们也可以马上更换加密协议，使 IPSec VPN 总是使用最新最好的协议来进行加密。图3-2所示为IPSec框架示意图，这张图旨在说明，不仅仅是散列函数、加密算法，还包括封装协议和模式、密钥有效期等内容都可以通过协商决定，在两个IPSec对等体之间协商的协议叫做IKE，这个协议会在本章的后续部分详细进行介绍，我们现在就以 IPSec 框架涉及的技术为主线，详细介绍这些技术的特点和工作原理。

3.2.1 散列函数

散列函数也叫做HASH函数，主流的散列算法有MD5与SHA-1。散列函数的主要任务是验证数据的完整性。通过散列函数计算得到的结果叫做散列值，这个散列值也常常被称为数据的指纹（Fingerprint）。为什么散列函数会被称为数据的指纹呢？这是因为散列函数的工作原理和日常我们对指纹采集和使用的原理几乎一样。在说明散列函数工作原理之前，我们不妨先来回想一下日常生活中我们是如何对指纹进行采集和使用的。

图3-3所示为日常生活中的指纹采集和使用示意图。

图3-2 IPSec框架示意图

图3-3 日常生活中指纹的采集和使用示意图

步骤1：公安机关预先记录“用户X”的指纹“指纹一”。

步骤2：在某一犯罪现场，公安机关获取到了“嫌疑犯”的指纹“指纹二”。

步骤3：通过查询指纹数据库发现“指纹一”等于“指纹二”。

步骤4：由于指纹的唯一性（冲突避免），可以确定犯罪“嫌疑犯”就是“用户X”。

以上就是日常生活中指纹的采集和使用方法。接下来我们通过图3-4来了解一下散列函数的工作原理，看看它是如何验证数据完整性的。

步骤1：对“重要文件”执行散列函数计算，得到散列值“散列值一”。

步骤2：现在我们收到另外一个文件“文件？”，对“文件？”进行散列函数计算得到散列值“散列值二”。

步骤 3：将“散列值一”和“散列值二”进行对比，发现“散列值一”等于“散列值二”。

步骤4：由于散列值的唯一性（冲突避免），因此可以确定“文件？”就是“重要文件”。这两份文件的每一个比特（bit）都完全相同。

图3-4 散列函数的工作原理

散列函数具有下面4个特点。

1．固定大小

散列函数可以接收任意大小的数据，并输出固定大小的散列值。以 MD5 这个散列算法为例，不管原始数据有多大，通过 MD5计算得到的散列值总是 128比特，而SHA-1的输出长度则为160比特。

2．雪崩效应

原始数据就算修改哪怕一个比特，计算得到的散列值也会发生巨大的变化。

3．单向

只可能从原始数据计算得到散列值，不可能从散列值恢复哪怕一个比特的原始数据。

4．冲突避免

几乎不能够找到另外一个数据和当前数据计算的散列值相同，因此散列函数能够确保数据的唯一性。

现在我们来看一下散列算法如何验证数据的完整性。

图3-5所示为散列函数验证数据完整性的方式。

图3-5 散列函数如何验证数据完整性

步骤 1：使用散列函数，计算需要发送的“重要文件”的散列值，得到“散列值一”。

步骤2：对需要发送的“重要文件”和步骤1计算得到的“散列值一”进行打包，然后一起发送给接收方。

步骤3：接收方对收到的“重要文件”进行散列函数计算，得到“散列值二”。

步骤4：接收方将收到文件中的“散列值一”和步骤3计算得到的“散列值二”进行对比，如果两个散列值相同，那么根据散列函数雪崩效应和冲突避免的特点，就可以确定“重要文件”的完整性，也就是这份“重要文件”在整个传输过程中没有遭到过别人的篡改。

散列函数虽然能够很好地确认数据的完整性，但是却容易遭受中间人攻击，我们来看看中间人攻击是如何进行的，如图3-6所示。

从图3-6中可以发现，合法与非法用户都可以对他们发送的信息进行散列函数计算，并得到散列值。因此他们也都能像图3-5一样把明文信息和散列值一起打包发送给接收方，而接收方也都能够通过散列函数来校验数据的完整性。因此，散列函数虽然能够确认数据的完整性，却不能确保这个数据来自于可信的源（不提供源认证），所以散列函数存在中间人攻击的问题。

为了弥补这个漏洞，我们可以使用一个叫做密钥化散列信息认证代码（HMAC， Keyed-hash Message Authentication Code）的技术，这项技术不仅仅能够实现完整性校验，还能完成源认证的任务，图3-7介绍了HMAC技术如何帮助OSPF动态路由协议实现对路由更新包的验证。

图3-6 散列函数的中间人攻击问题

图3-7 HMAC技术如何验证OSPF路由更新包（发送方）

步骤1：首先，网络管理员需要预先在要建立OSPF邻居关系的两台路由器上，通过ipospf message-digest-key 1 md5 cisco命令，配臵预共享秘密“cisco”。

步骤 2：发送方把要发送的路由更新信息加上预共享秘密一起进行散列计算，得到“散列值一”，这种联合共享秘密一起计算散列值的技术就叫做HMAC。

步骤3：发送方路由器把步骤2通过HMAC技术得到的“散列值一”和明文的路由更新信息进行封装，一起发送给接收方（注意路由更新信息是明文发送的，绝对没有进行任何加密处理）。

接下来的图3-8介绍了接收方一侧所执行的对HMAC验证的步骤。

图3-8 HMAC技术如何验证OSPF路由更新包（接收方）

步骤1：从收到的信息中提取明文的路由更新信息。

步骤2：把步骤1提取出来的明文路由更新信息加上接收方路由器预先配臵的共享密钥“cisco”一起进行散列计算，得到“散列值二”。

步骤3：提取出收到信息中的“散列值一”，用它和步骤2计算得到的“散列值二”进行比较，如果相同，表示路由更新信息是没有被篡改过的，也就是完整的。同时，还可以确定这是预先配臵共享秘密的那台比邻路由器所发送的路由更新，因为只有这台路由器才知道共享秘密的内容，因此也只有它才能够通过HMAC技术制造出能够校验成功的散列值。

上述对OSPF路由更新的介绍，可以体现出HMAC的两大安全特性，完整性校验和源认证。应该说在实际运用中，基本不会单纯地使用散列函数，绝大多数情况都会使用HMAC技术。例如，IPSec和HTTPS技术都采用了HMAC技术来对每一个传输的数据包做完整性校验和源认证。

3.2.2 加密算法

说完了散列函数，接下来我们花一点时间来介绍加密算法。加密，顾名思义就是把明文数据转换为密文数据。这样一来，即使第三方截获到了密文数据，也无法将其恢复为明文。而解密过程则正好相反，合法的接收者通过正确的解密算法和密钥恢复密文到明文。加密算法可以分为如下两大类：

对称密钥算法；

非对称密钥算法。

1．对称密钥算法

图3-9所示为对称密钥算法的工作示意图，从图中可以看到一个很明显的特点，加解密双方使用相同的密钥与算法进行加解密。因此，使用相同密钥与算法进行加解密运算的算法就叫做对称密钥算法，对称密钥算法有如下特点。

图3-9 对称密钥算法的工作示意图

优点：

速度快；

安全；

紧凑。

缺点：

明文传输共享密钥，容易出现中途劫持和窃听的问题；

随着参与者数量的增加，密钥数量急剧膨胀（（n×（n-1））/2）；

因为密钥数量过多，对密钥的管理和存储是一个很大的问题；

不支持数字签名和不可否认性。

对称密钥算法的主流协议：

1．DES；

2．3DES；

3．AES；

4．RC4。

我们先来讨论对称密钥算法的优点。它的首要优点就是速度快。作一个比较直观的比较，想必大多数读者都有使用压缩软件的经历，而对称密钥算法加密的速度应该比压缩的速度稍快（不同的算法有差异）。另外，现在无线网络的使用也很普及，绝大部分用户所使用的都是最新的无线安全技术WPA2，而WPA2就是使用AES来加密的。无线用户在上网冲浪时，似乎并不会感觉到由于加密造成的网络延时。而且只要他们的路由器或者交换机配上硬件加速模块，那就基本上能够实现线速加密，因此速度是对称密钥算法的一大优势。

现在我们来介绍对称密钥算法紧凑性的特点，DES是一个典型的块加密算法。所谓块加密，顾名思义就是把需要加密的数据包预先切分成为很多个相同大小的块（DES的块大小为64比特），然后使用DES算法逐块进行加密。如果不够块边界，就添加数据补齐块边界，这些添加的数据就会造成加密后的数据比原始数据略大。以一个1500个字节大小的数据包为例，通过DES块加密后，最多（极限值）会增加8个字节（64个比特）的大小。所以可以认为对称密钥算法加密后的数据是紧凑的。

图3-10所示为DES的两种块加密方式。

图3-10 DES的两种块加密方式

接下来我们再来说说DES 的两种块加密方式：电子代码本（Electronic Code Book， ECB）和密码块链接（Cipher Block Chaining，CBC）。对于ECB 这种加密方式来说，所有的块都是使用相同的DES密钥进行加密的。这种加密方式有一个问题，那就是相同的明文块加密后的结果也肯定相同。虽然中间截获数据的攻击者并不能解密数据，但是他们至少知道通信的双方正在反复加密相同的数据包。为了解决这个问题，CBC技术孕育而生，使用CBC技术加密的数据包，会随机产生一个明文的初始化向量（IV）字段，这个IV字段会和第一个明文块进行异或操作，然后使用DES算法对异或后的结果进行加密，所得到的密文块又会和下一个明文块进行异或操作，然后再加密。这个操作过程就叫做CBC。由于每一个数据包都使用随机产生的IV字段进行了扰乱，因此就算传输的明文内容一样，加密后的结果也会出现本质差异，并且整个加密的块是链接在一起的，任何一个块解密失败，剩余部分都无法进行解密了，这就增加了中途劫持者解密数据的难度。

说完了对称密钥算法的优势，我们再来讨论一下它的缺点。对称密钥算法的首要问题是，如何把相同的密钥发送给通信的双方。在这里，采用明文的方式传输密钥显然是非常不明智的，因为如果明文传输的密钥被中间人获取，那么中间人就能够解密使用这个密钥所加密的数据，这也就与直接采用明文传送数据没有什么区别了。第二个问题是，使用相同的一个密钥来加密去往所有用户的数据显然是非常不安全的。因此，我们希望两两用户之间共享一个唯一的密钥，并且在一次加密任务完成以后更新这个密钥。我们可以试想一下，假如只有4个用户要传送信息，且两两之间共享一个密钥的话，这个环境中就一共需要使用6个密钥（（n×（n-1））/2）；依此类推，5个用户需要10个密钥，那么100个用户？1000个用户呢？密钥数量将是一个不折不扣的天文数字。问题是，我们所讨论的都是互联网的加密解决方案。说得夸张一些，用户数上万也很正常。因此，对称密钥算法需要使用的密钥数量过多，不好管理与存储是一个比较严重的问题。另外，对称密钥算法也不支持数字签名技术（该技术我们将在后文中进行详细地介绍）。由于这一系列的缺点，我们一般不会在一套加密解决方案中单纯地使用对称密钥算法。

2．非对称密钥算法

图3-11所示为非对称密钥的产生和维护。

如图3-11所示，在使用非对称密钥技术之前，所有参与者，不管是用户还是路由器等网络设备，都需要预先使用非对称密钥算法（例如RSA）产生一对密钥，其中包括一个公钥和一个私钥。公钥可以放在服务器上共享给属于这个密钥系统的所有用户与设备，而私钥需要由持有者严格保护，确保只有持有者才能唯一拥有。

非对称密钥算法的特点是一个密钥加密的信息，必须使用另一个密钥来解密。也就是说公钥加密私钥解密，私钥加密公钥解密。公钥加密的数据，无法再使用公钥解密，私钥加密的数据，也无法再使用私钥解密。我们可以使用非对称密钥算法来加密数据和对数据进行数字签名。

图3-11 非对称密钥的产生和维护

图3-12所示为使用非对称密钥算法实现数据加密。

图3-12 使用非对称密钥算法实现数据加密

首先我们通过图3-12，来介绍如何使用非对称密钥算法来完成加密数据。

步骤1：“用户一”（发起方）需要预先获取“用户二”（接收方）的公钥。

步骤2：“用户一”使用“用户二”的公钥对重要的信息进行加密。

步骤 3：中途截获数据的攻击者由于没有“用户二”的私钥而无法对数据进行解密。

步骤4：用户二使用自己的私钥对加密后的数据（由用户二公钥加密）进行解密，使用公钥加密私钥解密的方法实现了数据的私密性。

但是由于非对称密钥算法运算速度极慢（和对称密钥算法相比有上千倍的差距），因此基本不可能使用非对称密钥算法对实际数据进行加密。在实际运用中，我们主要使用非对称密钥算法的这个特点来对密钥进行加密，以进行密钥交换。具体操作方式将在本章的后续部分进行详细介绍。

非对称密钥算法的第二个用途就是实现数字签名，在介绍数字签名前，我们不妨先来讨论一下实际生活中的签名。为什么要签名呢？签名的目的无非是对某一份文件进行确认。例如，欠条。张三欠李四10000元钱，欠款人张三在欠条上签名确认。签名的主要作用就是张三对这张欠条进行确认，事后不能抵赖（不可否认性）。到底最后谁会看这个签名呢？李四很明显没有必要反复去确认签名。一般都是在出现纠纷后，例如，张三抵赖不还的时候，李四就可以把欠条拿出来，给村长或者法官这些有权威的第三方来进行验证，如果他们确认此欠条上的签名确实来自张三无疑，张三就不能再否认欠李四钱这一既定事实了。

图3-13所示为使用非对称密钥算法实现数字签名。

了解了实际生活中签名的工作原理后，我们可以通过图3-13来看看数字签名是如何工作的。

步骤1：重要明文信息通过散列函数计算得到散列值。

步骤2：“用户一”（发起者）使用自己的私钥对步骤1计算的散列值进行加密，加密后的散列就叫做数字签名。

步骤3：把重要明文信息和数字签名一起打包发送给“用户二”（接收方）。

步骤4：“用户二”从打包文件中提取出重要明文信息。

步骤5：“用户二”使用和“用户一”相同的散列函数对步骤4提取出来的重要明文信息计算散列值，得到的结果简称“散列值1”。

步骤6：“用户二”从打包文件中提取出数字签名。

步骤7：“用户二”使用预先获取的“用户一”的公钥，对步骤6提取出的数字签名进行解密，得到明文的“散列值2”。

步骤8：比较“散列值1”和“散列值2”是否相等。如果相等，数字签名校验成功。

图3-13 使用非对称密钥算法实现数字签名

数字签名校验成功能够说明哪些问题呢？第一，保障了传输的重要明文信息的完整性。因为散列函数拥有冲突避免和雪崩效应两大特点。第二，可以确定对重要明文信息进行数字签名的用户为“用户一”，因为我们使用“用户一”的公钥成功解密了数字签名，只有“用户一”才能使用他的私钥加密散列产生数字签名，才能够使用“用户一”的公钥进行解密。通过数字签名的实例说明，数字签名和前面已经讲过的HMAC技术一样，可以提供如下两大安全特性：

完整性校验；

源认证。

下面我们对非对称密钥算法的特点进行总结。

工作特点：

用一个密钥加密的数据只能用另一个密钥来解密；

仅用于密钥交换（加密密钥）和数字签名（加密散列）。

优点：

安全；

由于不必担心交换的公钥被劫持，所以非对称密钥的分发更安全；

密钥数目和参与者数目相同；

在交换公钥之前不需要预先建立某种信任关系；

支持数字签名和不可否认性。

缺点：

加密速度很慢；

密文会变长。

非对称密钥算法的主流协议：

1．RSA（数字签名和数字证书的主流协议）；

2．DH（IPSec产生密钥资源的主要协议）；

3．ECC（椭圆曲线算法）。

介绍完非对称密钥算法如何工作以后，我们再来谈谈它的优缺点。非对称密钥算法的优点是很突出的：由于非对称密钥算法的特点，公钥是共享的，不用保障公钥的安全性，所以密钥交换比较简单，并且不必担心中途被截获。此外，在使用非对称密钥算法的环境中，每增加一个用户，只需要增加一个公钥，密钥的数量与参与者数量相同，也就是说一万个用户只需要管理和存储一万个公钥，相对于对称密钥算法，密钥的数量可以减少很多。另外，非对称密钥算法还可以支持数字签名和不可否认性，而不可否认性的依据就是，只有私钥的持有者才能唯一拥有这个私钥。

说完非对称密钥算法的优点，我们也来看看它的严重缺陷。非对称密钥算法的主要问题就是它的加密速度奇慢。如果拿RSA这个非对称密钥算法和DES这个对称密钥算法相比，加密相同大小的数据，DES大概要比RSA快几百倍。所以想要如图3-12所示那样，使用非对称密钥算法来加密实际的数据几乎是不可能的。另外，使用非对称加密算法加密后的密文会变得很长。举一个夸张点的例子，用RSA来加密1GB的数据（当然RSA肯定没法加密1GB的数据），加密后的密文可能变成2GB，与对称密钥算法相比这就太不紧凑了。由于这些缺点，与对称密钥算法一样，我们在一套安全解决方案中不可能单独使用非对称密钥算法。那么我们应该如何利用对称和非对称密钥算法的优势来加密实际的数据呢？我们紧接着来看一个“巧妙的加密解决方案”。

3．巧妙的加密解决方案

我们已经学习过了对称密钥算法和非对称密钥算法，你会发现两种算法都各有其优缺点。对称密钥算法加密速度快，但是密钥数量过多不好管理，并且密钥分发不安全。非对称密钥算法密钥数量少，密钥分发方便并且不存在安全隐患，但是加密速度奇慢，不可能用于大流量数据的加密。所以在实际使用加密算法的时候，一般会让两种算法共同工作，发挥各自优点。下面是一个非常巧妙的联合对称和非对称算法的解决方案，这种解决问题的思路被大量运用到实际加密技术中。

图3-14所示为联合使用两种密钥算法的巧妙加密解决方案（发起方处理过程）。

图3-14 巧妙的加密解决方案（发起方处理过程）

步骤1：“用户一”（发起方）使用本地随机数产生器，产生用于对称密钥算法的随机密钥。如果使用的对称密钥算法是DES，DES的密钥长度为56比特，也就是说随机数产生器需要产生56个随机的“00011101001000110000111…”用于加密数据。

步骤 2：使用步骤1 产生的随机密钥，对重要的明文信息通过对称密钥算法进行加密，并得到密文（很好地利用了对称密钥算法速度快和结果紧凑的特点）。

步骤3：“用户一”（发送方）需要预先获取“用户二”（接收方）的公钥，并且使用“用户二”的公钥对步骤1产生的随机密钥进行加密，得到加密的密钥包。

步骤4：对步骤2和步骤3产生的密文和密钥包进行打包，一起发送给“用户二”（接收方）。

图3-15所示为接收方处理过程。

步骤1：“用户二”首先提取出密钥包，并且使用自己的私钥对它进行解密，并得到明文的随机密钥（使用非对称密钥算法进行密钥交换，有效防止密钥被中途劫持）。

步骤2：“用户二”提取出密文，并且使用步骤1解密得到的随机密钥进行解密，得到明文的重要信息。

图3-15 巧妙的加密解决方案（接收方处理过程）

在这个巧妙的加密解决方案中，我们使用了对称密钥算法对大量的实际数据（重要信息）进行加密，因而很好地利用了对称密钥算法加密速度快、密文紧凑的优势。同时我们又使用非对称密钥算法，对对称密钥算法使用的随机密钥进行加密，因而实现了安全的密钥交换，很好地利用了非对称密钥不怕中途劫持的特点。这个巧妙的解决方案大量地运用在实际加密技术中，我们后面要介绍的IPSecVPN 也是先使用非对称密钥算法DH来产生密钥资源，然后再使用对称密钥算法（DES、3DES……）来加密实际数据的。

3.2.3 封装协议

IPSec有ESP和AH两种封装协议。

1．ESP协议

ESP（Encapsulation Security Payload）的IP 协议号为50，ESP 能够为数据提供私密性（加密）、完整性和源认证3大方面的保护，并且能够抵御重放攻击（反复发送相同的包，接收方由于不断地解密消耗系统资源，实现拒绝服务攻击（DOS））。ESP只能保护IP负载数据，不对原始IP头部进行任何安全防护。

图3-16所示为ESP数据包的结构示意图，下面我们分别对ESP包的各个字段逐一进行介绍。

（1）安全参数索引（SPI）

一个32 比特的字段，用来标识处理数据包的安全关联（Security Association），关于安全关联相关的内容我们会在本章的后续部分进行介绍。

图3-16 ESP包结构示意图

（2）序列号（SN）

一个单调增长的序号，用来标识一个ESP数据包。例如，当前发送的ESP包序列号是X，下一个传输的ESP包序列号就是X+1，再下一个就是X+2。接收方通过序列号来防止重放攻击，原理也很简单，当接收方收到序列号X的ESP包后，如果再次收到序列号为X的ESP包就被视为重放攻击，采取丢弃处理。

（3）初始化向量（Initialization Vector）

我们在前面介绍过CBC这种块加密方式，每一个需要使用CBC来加密的数据包都会产生一个随机数，用于加密时对数据进行扰乱，这个随机产生的数就叫做初始化向量（IV）。当然 IPSec VPN 也可以选择不加密（加密不是必须的，虽然我们一般都会采用），如果不加密就不存在IV字段。所以在图3-16中有两个ESP包结构示意图，左边白底的ESP包没有IV字段表示不加密，右边深色底的存在IV字段则表示要加密。

（4）负载数据（Payload Data）

负载数据就是IPSec加密所保护的数据，它很有可能就是TCP头部加相应的应用层数据。当然我们后面还会介绍两种封装模式，封装模式的不同也会影响负载数据的内容。

（5）垫片（Padding）

Cisco 的IPSecVPN 都采用了CBC 的块加密方式，既然采用块加密，就需要把数据补齐块边界。以DES为例，就需要补齐64比特的块边界，追加的补齐块边界的数据就叫做垫片。如果不加密就不存在垫片字段。

（6）垫片长度（Pad Length）

垫片长度顾名思义就是告诉接收方，垫片数据有多长，接收方解密后就可以清除这部分多余数据。如果不加密就不存在垫片长度字段。

（7）下一个头部（Next Header）

下一个头部标识IPSec封装负载数据里边的下一个头部，根据封装模式的不同下一个头部也会发生变化，如果是传输模式，下一个头部一般都是传输层头部（TCP/UDP）；如果是隧道模式，下一个头部肯定是IP。关于传输和隧道模式我们会在本章后续部分进行介绍。这里顺便提一下，从“下一个头部”这个字段中，我们可以看到 IPv6 的影子。IPv6 的头部就是使用很多个“下一个头部”串接在一起的，这也说明IPSec最初是为IPv6而设计的。

（8）认证数据（Authentication Data）

ESP会对从ESP头部到ESP尾部的所有数据进行验证，也就是做HMAC的散列计算，得到的散列值就会被放到认证数据部分，接收方可以通过这个认证数据部分对ESP数据包进行完整性和源认证的校验。

2．AH协议

AH（Authentication Header）IP 协议号为 51，AH 只能够为数据提供完整性和源认证两方面的安全服务，并且抵御重放攻击。AH 并不能为数据提供私密性服务，也就是说不加密，所以在实际部署IPSecVPN 的时候很少使用AH，绝大部分IPSecVPN都会使用ESP进行封装。当然AH不提供私密性服务，只是它不被广泛采用的其中一个原因，后面部分我们还会介绍AH没有得到广泛使用的另外一个原因。

图3-17 AH包结构示意图

图 3-17 所示为AH 包结构示意图，从图中我们可以看到AH 与ESP 的关键性区别，即AH对数据验证的范围更广，不仅包含原始数据，还包含了原始IP头部，AH认证头部的名称就由此而得名。

图3-18所示为AH验证的IP头部字段。

图3-18 AH验证IP头部字段

虽然AH要验证原始IP头部，但并不是IP头部的每一个字段都要进行完整性验证。在图3-18中，灰色部分字段就是AH不进行验证的范围。也就是说，AH只会对剩余的白色部分字段进行完整性校验。可以看到IP地址字段是需要验证的，因而不能被修改。AH这么选择也有它自身的原因。IPSec的AH封装最初是为IPv6设计的。而在IPv6的网络中，地址不改变非常正常，但是我们现在使用的主要是IPv4的网络，网络地址转换（NAT）技术经常被采用。一旦AH封装的IPSec数据包穿越NAT，地址就会改变，抵达目的地之后就不能通过验证，所以AH协议封装的IPSec数据包不能穿越NAT，这就是AH现在没有得到大量部署的第二大原因。

3．2.4封装模式

IPSec有如下两种数据封装模式：

传输模式（Transport mode）；

隧道模式（Tunnel mode）。

图3-19所示为传输模式的封装示意图。

我们先通过图3-19来看传输模式是如何对数据进行封装的，因为AH很少使用，所以封装模式示意图中我们都以ESP封装协议为例来进行介绍。

传输模式实现起来很简单，主要就是在原始IP头部和IP负载（TCP头部和应用层数据）之间插入一个ESP头部。当然ESP还会在最后追加上ESP尾部和ESP验证数据部分，并且对IP负载和ESP尾部进行加密和验证处理，但原始IP头部被完整地保留了下来。

图3-19 传输模式封装示意图

图3-20 所示为传输模式IPSec VPN 实例分析。

我们现在通过部署在Yeslab安全实验室内部的一个IPSec VPN来说明传输模式是如何工作的，图3-20 是这个IPSec VPN 的示意图。

图3-20 传输模式IPSec VPN实例分析

设计这个IPSec VPN 的主要目的是，对我的电脑访问内部重要文件服务器的流量进行安全保护。我电脑的IP地址为10.1.1.5，服务器的IP地址为10.1.19.5。这两个地址是实验室网络的内部地址，至少在Yeslab实验室内部是全局可路由的。传输模式只是在原始IP头部和IP负载中间插入了一个ESP头部（图例中省略了ESP尾部和ESP验证数据部分），并且对IP负载进行加密和验证操作。我们把实际通信的设备叫做通信点，加密数据的设备叫做加密点，在这幅传输模式IPSec示意图中，实际通信和加密设备都是我的电脑（10.1.1.5）和服务器（10.1.19.5），所以加密点等于通信点。只要能够满足加密点等于通信点的条件就可以进行传输模式封装。其实根据个人的经验，要使用传输模式进行封装，通信设备（接收方和发起方）的IP地址，必须在位于其间的网络可路由，否则就必须使用隧道模式。通信点和加密点是很重要的一个概念，因为它直接影响着IPSec VPN 关于路由的配臵。在下一章我们还会进一步讨论加密点和通信点如何影响IPSec VPN 的路由。

讲完了传输模式，我们紧接着来看一下隧道模式是如何对数据进行封装的。

图3-21所示为隧道模式的封装示意图。隧道模式把原始IP数据包整个封装到了一个新的IP数据包中，并且在新IP头部和原始IP头部中间插入了ESP头部，以此对整个原始IP数据包进行了加密和验证处理。那么，什么样的网络拓扑适合使用隧道模式来封装IP 数据包呢？站点到站点的IPSec VPN 就是一个经典的实例，我们可以分析一下站点到站点的IPSec VPN 是如何使用隧道模式来封装数据包的。

图3-21 隧道模式封装示意图

图3-22是一个典型的站点到站点IPSec VPN示意图，分支站点身后保护网络为10.1.1.0/24，中心站点身后保护网络为 10.1.2.0/24。分支站点有一台终端电脑要通过站点到站点的IPSec VPN来访问中心站点的数据库服务器。这两台电脑就是我们所说的通信点。真正对数据进行加密的设备是两个站点连接互联网的路由器，假设分支站点路由器获取的互联网地址为202.100.1.1，中心站点的互联网地址为61.128.1.1。那么路由器的这两个地址就是加密点。很明显加密点不等于通信点，因此这个时候就应该采用隧道模式来对数据进行封装。封装后在互联网上传输的IPSec数据包如图3-22所示，最外层头部为加密点为源和目的IP头部，紧接着是ESP头部，最内层为被安全保护的原始IP数据包。

图3-22 站点到站点隧道模式分析示意图

图3-23 所示为站点到站点IPSec VPN 使用传输模式的封装包结构。

图3-23 站点到站点IPSec VPN使用传输模式的封装包结构

我们也可以假设如果在图3-22所示的拓扑中，依然进行传输模式封装，那么封装后的结果如图3-23所示。如果将这样封装的数据包直接发送到互联网，那么它一定会被互联网路由器丢弃，因为10.1.1.0/24和10.1.2.0/24都是客户内部网络，在互联网上不可路由。为了让站点到站点的流量能够通过IPSecVPN 加密后穿越互联网，我们需要在两个站点间制造一个“隧道”，把站点间的流量封装到这个隧道内，并穿越互联网。这个隧道其实就是通过插入全新的 IP 头部和ESP头部来实现的。再次重复一遍使用隧道模式的条件：只要加密点不等于通信点我们就应该采用隧道模式封装，或者说通信点的IP地址在其间的网络是不可路由的，就应该采用隧道模式封装。

3.2.4 密钥有效期

长期使用相同密钥来加密数据是不明智的，我们应该周期性地更新密钥， Cisco的IPSec VPN 用于加密实际数据的密钥，默认每一个小时（3600 秒）就要更新一次。我们也可以根据自身的情况对密钥有效期进行调整。但是这种调整应该遵循一个简单的原则，那就是密钥加密的数据越多，这个密钥的有效期就应该越短；加密的数据越少，它的有效期就可以越长。

Cisco 的 IPSec VPN 虽然默认每小时更换一次密钥，但下一个小时使用的密钥，是由当前这个小时使用的密钥，通过一系列的算法衍生得出的。也就是说这些密钥之间存在推演关系。这样的密钥更新就不能叫做完美向前保密 PFS（Perfect Forward Secrecy）。PFS 要求每一次密钥更新，都需要重新产生全新的密钥，和以前使用的密钥不存在任何衍生关系。Cisco 的IPSec VPN 一旦启用了PFS 技术，就会在每一个小时结束的时候，展开一次全新的DH交换（本章后续内容将会详细介绍这种算法），产生全新的密钥用于下一个小时加密。关于PFS的配臵我们会在后面部分介绍。