一、概述：什么是VPN；认识数据加/解密；；数据加/解密的类型；散列算法；IPSec Base VPN；Linux下的IPSec架构
1. VPN（Virtual Private Network）的中文意思为“虚拟专用网络”，而VPN的功能是将因特网虚拟成企业网络来使用，这样的叙述似乎不是很容易理解，笔者以图8-1 为例来说明VPN 的功能及使用VPN 的必要性。
笔者假设某企业有两个分点，分别为台北总公司及上海分公司，而这两个分部的企业网络都设置有防火墙，且内部网络都是使用PrivateIP，另外，公司的老板经常会到世界各地出差，所以在这个网络架构下，请你思考一个问题，上海分公司及经常出差的老板是否能够正常访问台北总公司内的File Server ？答案当然是“不可能”，因为台北总公司内的File Server 是放在NAT 后方的Private IP 区段上，因此上海分公司及出差的老板不可能访问到总公司内的File Server，但这样的需求在现实网络应用中却是需要的，难道没有完整的解决方案吗？
VPN 正是为了解决此问题而设计出来的技术。在以往，我们为了连接两个远程Private IP 网段，必须向电信业者申请Frame Relay 的服务，而FrameRelay 感觉就像电信业者帮我们拉了一条很长的网线，然后运用这条网线来连接两个Private IP 的网段，虽然Frame Relay 也可以帮我们解决以上的问题，但Frame Relay 并不是万能的，下面我们来看看Frame Relay 的优缺点。
Frame Relay的优点：Frame Relay最大的优点在于“带宽保证”，也就是说，如果你申请的是1Mbps的Frame Relay，就一定会有1Mbps的带宽可以使用，不会因为因特网的拥塞而有任何折扣。
Frame Relay的缺点：Frame Relay服务的费用并不是很便宜，而且在F r ame Re l ay网络中所传送的数据并没有加密，故其安全性较差；此外，Frame Relay服务仅能应用于固定的位置（地理环境），如图8-2所示是老板带着Note Book到处出差，并没有固定的位置，因此，就无法使用Frame Relay的服务。
相对于VPN 就不一样了，在早期由于局限在因特网频宽的限制下，如果企业想高速跨越因特网来连接两个网段，那么Frame Relay 绝对是首选，但近年来，因为ISP 业者不断加大其所拥有的频宽，使得我们上网的连接速度不像以前极不稳定，再加上数据加/ 解密技术已成熟且CPU 运算速度够快，因此，VPN 技术已逐渐被企业所接受。那VPN 究竟是哪种技术呢？如果以图8-1 为例来套用VPN 技术，其逻辑上的架构就会如同图8-2，也就是说，VPN 把整个因特网虚拟成一个Router，因此，上海分公司及出差的老板就可以借助这个Router 来访问企业内部的File Server。
1.1 VPN的原理
说到这里，你或许会有疑问：来源及目的端IP 都是Private IP，VPN 如何让这些Private IP 可以在因特网上的路由呢？这就是VPN 最为重要的一个特点，笔者以图8-3 为例来说明VPN 技术是如何让两部Private IP 的主机能够跨越因特网来连接。
从图8-3 中我们可以看到两部VPN Server，且各自都有两块网卡，其中一块连接在因特网，我们假设其IP 分别为A 及B 两个Public IP，另外一块网卡则分别连接至192.168.1.0/24 及192.168.2.0/24 两个Private IP 的网段，接着我们来看看192.168.1.10 主机如何借助VPN 技术跨越因特网来连接192.168.2.20主机。
首先192.168.1.10 主机送封包给192.168.2.20 主机，当这个封包传送至①的位置时，其封包的来源端IP 为192.168.1.10，目的端IP 为192.168.2.20，如图8-4 所示。
但是这个封包被送到VPN Server（A）之后②，VPN Server 会把这个封包以特殊的方式来处理，如图8-5 所示，VPN Server 会把原本的整个封包当做其所要传递的数据内容，并且重新产生一个新的IP 包头，而这个新的IP 包头中的来源端IP 为VPN Server（A）上的Public IP A，目的端IP 则为VPNServer（B）上的Public IP B，这样这个封包当然就可以从VPN Server（A）跨越因特网传送到VPN Server（B）。
待VPN Server（B）收到这个封包之后③，其内容应该还是如图8-5 所示，接着VPN Server（B）就执行其该做的事，就是将新的IP 包头整个去除掉，而去除新IP 包头之后的内容就如图8-4 所示，最后VPN Server（B）将这个封包送至192.168.2.0/24 的网段上④，这样两个Private IP 的主机就可以跨越因特网来连接。
接着，请你想象以上这样的原理，像不像是使用A 及B 两个IP 来搭建出一条隧道，然后让192.168.1.10 及192.168.2.20 两部主机所传送的封包得以穿梭于隧道之中，这种逻辑上的技术我们称为Tunnel。而VPN 的隧道技术有很多种方式，一般较常见的有IP in IP Tunnel、L2TP Tunnel 及PPTP Tunnel，目前我们所讨论的是IP in IP Tunnel。
1.2 常见的VPN架构
VPN 的架构大概可分为两种，以图8-1 为例，我们使用VPN 将台北总公司与上海分公司的两个网段串接起来，这称为Site-to-Site 或是Subnet-to-Subnet 的VPN架构；此外，老板以便携计算机通过VPN 来串接台北总公司的网段，则称之为Client-to-Site 或是Client-to-Subnet 的VPN 架构。
1.3 VPN的安全性问题
在看完VPN 的原理之后，你或许无法接受VPN 的技术，如图8-5 所示，如果192.168.1.10 与192.168.2.20 所传递的是极机密的数据，那么图8-3 中我们在VPN Server A 与B 之间启动Wire Shark 之类的封包提取软件不就可以看到这些机密的数据内容吗？如果你有这样的想法，就代表你对网络数据传递的安全性已有正确的概念，不过，这个问题我们并不需要太在意，因为VPN 机制允许我们在VPN Server A 与B 之间进行数据加密，因此，你可以暂时把加密过后的封包想象成如图8-6 的样子，这样就不必担心企业内的机密数据被窃取了。
1.4 VPN机制的优缺点
VPN 机制除了提供Site-to-Site 及Client-to-Site 的功能之外，VPN 还可以提供安全的通信环境。例如，当你到客户的公司洽谈生意时，如果借助客户公司的网络连回公司查询产品成本信息，难道你不担心公司的成本信息会被窃取吗？因为你的客户只需要在机房内就可以提取到你传递的所有数据，为此，我们就可以运用Client-to-Site 的VPN 架构从你的便携计算机里建立VPNTunnel 连回到公司，并运用VPN 加密的特性来保护传递中的所有数据。
再者，谈到VPN 的通信加密，就不免拿来与一般应用层的加密机制比较一番。以图8-7 中的HTTP 通信协议为例，来说明应用层加密机制与VPN 加密机制的差异，首先，我们可以看到，在HTTP 的应用中可选择两条路径将数据传递出去，其一是将HTTP 封包直接送入传输层，接着转送至网络层，最后由物理网络接口送离本机，如果是这条路径，那么HTTP 封包将无法得到SSL的加密保护；其二是将HTTP 封包先送给SSL 加密机制处理，再将封包转送到传输层、网络层，最后由物理网络接口送离本机。因此，如果是选择这条路径，那么HTTP 封包将可以受到SSL 的加密保护。
从以上的流程，我们不难发现应用层加密机制的缺点，就是这些加密机制只能加密特定的应用层协议。例如，ICMP 封包就无法受到这些加密协议的保护，因为ICMP 协议是工作在网络层偏上的应用，因此，ICMP 封包根本不可能受到SSL 的加密保护，反过来VPN 就不是这样了，VPN 是工作在网络层偏下一点的应用，因此，跑在IP 上的协议通通都可以受到VPN 的加密保护。
虽然VPN 机制有这么多的优点，但如果在你的企业中有居心不良的员工，将企业的机密数据借助VPN 连接传送给竞争对手，我们将束手无策，因为VPN 将所有的数据封包都加密了，所以我们无法使用任何方式来监控这类的行为，因此，笔者的建议是：限制从企业内部网络对因特网建立VPN 连接，即可杜绝这类行为发生。
2 认识数据加/解密
由于因特网技术不断演进，使得新的应用不断推陈出新，在过去，企业网络的安全课题几乎都落在防火墙上，但由于网络远程访问需求与日俱增，使得通信加密的议题也逐渐受到重视，其中又以VPN 的应用最受企业的青睐，因此，我们必须先对“加/ 解密”技术的原理有所了解，这样才能对VPN 的原理及组态有充分的了解及掌握。
2.1 什么是明文
“明文”泛指任何未经处理的原始数据，例如，“I Love You”即是明文，明文在网络上传送是非常不安全的。如图8-8 所示为POP 3 协议应用下所提取到的封包，而POP 3 协议就是以明文的方式来传送数据的，因此，我们可以直接阅读这些封包所承载的数据内容。
2.2 什么是密文
由于明文在网络上传递极不安全，因此，就有人创造出数据加密及解密的技术；所谓的加密及解密是指我们可以使用数学算法将明文数据运算成密文，同样地，也可以将密文运算回明文，这样即为数据的加密及解密。
3 数据加/解密的类型
在所有的加/ 解密算法中，可以分为对称式加密及非对称式加密两种，以下是其差异及优缺点。
3.1. 对称式加密
图8-11 为数据加密及解密的流程，图中我们试着将“I Love You.”字符串进行加密及解密的动作，首先必须将待加密的数据及加密时所使用的密钥提供给加密算法，这样即可将“I Love You.”加密，而加密之后的内容就变成一堆无法被阅读的数据，但是当我们需要阅读这些数据时，就必须将被加密过的数据及解密时所需要的密钥提供给解密算法，这样即可将被加密过的数据还原成我们可以直接阅读的信息了。
图那什么是对称式加密呢？如果加密及解密所使用的密钥相等，就称为对称式加密，而对称式加密的优缺点如下。
优点：对称式加密最大的优点在于加/解密速度快，也就是说，对称式加密比较不占用CPU的运算资源。
缺点：对称式加密最大的缺点在于密钥传递不易，如图8-11所示，如果数据的加密者位于中国台湾，而数据的接收者却位于地球的另一端，试问数据的接收者如何得知加密者所使用的加密密钥？是用E - m a i l、电话或Fax吗？以上这些方式我们都无法确保加密密钥在传递的过程中不会被第三者提取，但如果不幸被他人提取，我们的机密数据也就等于被他人窃取了。
3.2. 非对称式加密
在开始讨论非对称式加密前，必须先了解什么是密钥系统。在公开密钥系统中，文件的接收者必须拥有一对密钥，分别为Public Key（公开密钥）及Private Key（私密密钥），而这两把密钥有一个很重要的特性，就是都可拿来加密数据，而且加密后的数据就只能使用另一半来解密，例如，使用PublicKey 加密后的数据，只有Private Key 能解开；而使用Private Key 加密后的数据，只有Public Key 才解开。所以从Public Key 及Private Key 的字义上来看，不难想象Public Key 应该是可以让他人轻易取得的信息，但Private Key 就该好好保存不能被他人取得。
在了解Public Key 及Private Key 之后，接着我们以图8-12 为例来说明非对称式加密的运行流程。首先，因为加密者可以轻易取得文件接收者的PublicKey，因此，以Public Key 来对资料进行加密动作，而这份被加密过后的数据就只有“拥有这把Public Key 所对应的Private Key”才可以解开，但由于这把Private Key 只有一个人拥有，因此，当接收者收到这份文件之后，就可以使用Private Key 将数据解密。
以下说明非对称式加密的优缺点。
优点：由于非对称式加密系统以Public Key及Private Key来进行加/解密运算，因此，非对称式加密系统没有“密钥”传递上的问题，所以比对称式加密系统安全。
缺点：非对称式加密系统的最大缺点在于其执行加密及解密时所消耗的CPU运算资源较多。
4 散列算法
散列（Hash）算法在加密学中占很重要的地位，在散列算法中，我们可以拿任意的数据来运算，如下是使用openssl 指令对file.txt 进行MD5 的散列运算，而运算完毕所得的“92ab70b47c2285708f83ae097053df8e”则称为Fingerprint（数字指纹）。
[[email protected] tmp]# openssl md5 file.txt MD5（file.txt）= 92ab70b47c2285708f83ae097053df8e
指纹有什么特性呢？就如同我们的指纹一样，你不可能找到两个不同人的指纹是相同的，在散列算法的应用下也是如此，不相同的两个文件（文件的内容）不可能运算出相同的Fingerprint，这种“唯一”的特性可以让我们运用在很多不同地方。例如，通过因特网下载文件回来，该如何确认这些文件在传送的过程中完全没有错误？因此，我们在下载某些文件时，这些网站的管理人员会很贴心地提供如图8.13 所示的信息，也就是说，网站的管理人员会告诉我们，这些文件在正确的情况下，文件的Fingerprint 应该是多少，这样我们就可以使用与网站管理者相同的散列算法来对下载的文件进行散列运算，并将运算后得到的Fingerprint 与网站所提供的Fingerprint 进行匹配，如果匹配的结果相等，就足以证明下载回来的文件内容是正确的，反之，就请你再下载一次。
4.1. 常见的散列算法
散列算法只是个统称名词，实际上，散列算法可以分为好几种，例如MD2、MD4、MD5、RMD160、SHA、SHA1 等，一般比较常用的是MD5、SHA 及SHA1，下面的范例则是以openssl 工具执行各种不同散列算法的方式：
[[email protected] tmp]# openssl md2 file.txt MD2（file.txt）= 913af0b1a393c31f5d41a3e835945d3f [[email protected] tmp]# openssl md4 file.txt MD4（file.txt）= e4a7fbca4857a2943104a3453311a4c0 [[email protected] tmp]# openssl md5 file.txt MD5（file.txt）= 92ab70b47c2285708f83ae097053df8e [[email protected] tmp]# openssl rmd160 file.txt RIPEMD160（file.txt）= 369d3ba14770918e40c2f71e0edd5210fbfbf26f [[email protected] tmp]# openssl sha file.txt SHA（file.txt）= 759b33290657faadd48df6f78d61c4a87ff6d1e2 [[email protected] tmp]# openssl sha1 file.txt SHA1（file.txt）= 8a1af798345bd3b1b8769973786bb96fcfa38631
4.2. 散列算法的特性
散列算法使用的方式非常容易，如果我们可以对此详加了解，那么应用就可更加完整，其特性如下。
运算的数据来源没有大小限制。
相同的散列算法会有固定长度的Fingerprint输出。
不同的数据内容运算后所得到的Fingerprint值会不同。
无法由Fingerprint反推回源文件的内容。
5 IPSec Base VPN
市场上谈论IPSec 技术的书籍有很多，且大部分都写得太过于详尽又着重于理论，对于IPSec 技术的初学者来说，并不容易理解其内容，为此，笔者所讨论的重点将着重于IPSec 设置有关的议题，至于一些与设置无关的理论部分，碍于篇幅的限制在此就不加以论述了，如果你有心研究IPSec 协议，相信在研读完本书之后，你应该可以轻松地阅读市场上其他的IPSec 书籍。
要了解IPSec 的运行及设置并没有想象中困难，只要依笔者的内容顺序来阅读，应该很容易就可以了解IPSec 技术，这样对整个IPSec 设定及设置上就不会有太大的问题。
5.1 IPSec的工作模式
IPSec 在不同的应用需求下会有不同的工作方式，分别为传输模式（TransportMode）及隧道模式（Tunnel Mode），接下来看这两种工作模式的使用时机。
1. 传输模式
如图8-14 所示，所谓传输模式的IPSec VPN 是指可以将两部主机之间所传递的数据加密。例如，我们使用便携计算机通过POP 3 协议连回公司的邮件服务器收取信件时，就可以在Mail Server 与便携计算机之间建立传输模式的IPSec VPN，以确保信件的内容不会被他人窃取。
2. 隧道模式
如图8-15 所示，如果我们需要让两个不同网段所传送的数据内容都经由IPSec VPN 来加密，或者需要将两个Private IP 的网段通过IPSec VPN 来跨越因特网连接，就会需要用到隧道模式的IPSec VPN。
5.2 IPSec的组成要素（1）
IPSec 通信协议其实是由两个不同的协议所组成的，分别为AH（AuthenticationHeader）与ESP（Encapsulated Secutiry Payload），而这两个协议所负责的任务功能是不同的，其中AH 协议的功能为“完整性验证”，ESP 协议的功能则为“完整性验证与加密”。接着，我们来看AH 与ESP 协议的原理及运行方式。
1. AH
AH（Authentication Header）协议以数字签章的方式来确保数据的完整性。例如，我们可以使用AH 协议来确认传送过程中的数据内容没有遭到窜改或因传送质量不良所造成的数据错误，另外，AH 协议可以工作于传输模式及隧道模式两种，但请注意，AH 协议不包含加密的功能。以下说明AH 协议在传输模式及隧道模式下的运行原理。
1）传输模式下的AH 协议
如图8-16 所示，如果我们要在两部主机之间以AH 协议来保护传送的数据封包，那么必须先为两台主机设置一把“加密密钥”。我们假设主机A 的密钥为Key（A），主机B 的密钥为Key（B），但因为AH 协议是使用“对称式加密”，因此，我们必须把主机A 的密钥送给主机B，主机B 的密钥送给主机A，不过，目前请你先不要理会密钥的产生方式、设置方式及交换方式，稍后笔者将会有完整的解说。
当准备好AH 协议执行所需要的加密密钥后，接下来就可以推演AH 协议的运行原理。以图8-17 的主机A 送数据给主机B 为例，首先，AH 协议会在原有的IP 包头及TCP 包头之间插入一段AH 包头，接着对整个封包进行散列运算，事实上，某些在IP 包头及AH 包头中的数据并不包含在内，因为这些数据可能是变动的，例如，IP 包头中的TTL 值就不包含在内，因此在运算之前，这些数据字段会被设定为0，而运算后所得到的Fingerprint 会以Key（A）为加密密钥来进行对称式加密，加密完成之后的结果就称为验证数据，最后将验证数据填入AH 包头中。
待主机B 收到封包之后，主机B 就以Key（A）为解密密钥将AH 包头中的验证数据解密，这样即可得到主机A 所计算出来的Fingerprint，我们令其为F（A），接着主机B 也对收到的整个封包进行散列运算，当然，也会得到一个Fingerprint，而这个Fingerprint 是当下立即计算出来的，我们令其为F（B），最后如果F（A）等于F（B），那么依据散列算法的特性，我们就可以确认封包在传送的过程中，其数据内容并没有任何改变。
在了解了AH 协议在传输模式下的运行方式之后，或许你会觉得很奇怪，为什么A、B 主机各需要一把加密密钥？而不是只要一把加密密钥就够了？这是因为IPSec 当初在设计时，特别把AH 协议设计成“单向”的，也就是说，我们可以只选择主机A 送数据给主机B 时要走AH 协议，而主机B 送数据给主机A 时则不要走AH 协议。当然，你也可以反过来设定，不过，通常我们的选择会是“双向”都走AH 协议。
AH 之所以被设计成单向的最大考虑是在于 “安全”，如果A、B 主机只有一把共享的加密密钥，可能因为加密密钥易被他人猜中，而导致A、B 主机双向传递数据的不安全，但如果A、B 主机的加密密钥是各自独立的，至少以上的风险可以降低一半，因此AH 协议才被设计成单向。
图8-18 为传输模式下AH 协议的实际封包结构，从结构中我们可以印证图8-17 的内容，也就是AH 协议在IP 包头及TCP 包头之间安插了AH 包头，另外，在AH 包头中的IV（Integrity Value）字段，即为前面所提到的“验证信息”（被加密后的Fingerprint）。最后我们要了解，AH 协议并不提供任何对数据封包做“加密”的机制，因此，从图8-18 右下角可以直接看到封包内所承载的数据内容。
2）隧道模式下的AH 协议
如图8-19 所示，如果我们希望借助两部VPN 主机来保护192.168.0.0/24及192.168.2.0/24 两个网段所传递的数据封包，就如同在传输模式下我们必须先将加密密钥准备好，并且互相交换好两部主机上的加密密钥，这部分的概念与传输模式并无太大差异。
接下来看在隧道模式下AH 协议如何处理封包，如图8-20 所示，当ClientA 送数据封包给Client B 时，其数据封包就如图中上半部的结构，当这个封包送到VPN 主机A 时，主机A 会将整个封包当成数据来看，并在这个旧的封包前加入一个AH 包头，然后再产生出一个新的IP 包头，接着以散列算法运算出整个封包的Fingerprint，再以Key（A）将Fingerprint 加密，然后置入于AH 包头中，这个运行规则其实与传输模式的运行规则是一样的。
当VPN 主机B 收到这个封包后，VPN 主机B 即会以AH 包头中的验证码来执行完整性验证，这个运行的方式与AH 的传输模式相同，如果验证没成功就丢弃该封包；反之，VPN 主机B 会将新的IP 包头及AH 包头去除掉，此时这个封包就可以借助VPN 主机B 的路由表将封包传送到正确的地方。
图8-21 为隧道模式下AH 协议的实际封包结构，从结构中可以印证图8-20的内容，我们可以看到新的IP 包头内有“Src：10.0.1.200”、“Dst ：10.0.1.210”，也可以看到AH 包头及其内的验证码，再来就是原始IP 包头，从其中可以看到“Src ：192.168.2.10”、“Dst ：192.168.0.10”，接着是一个TCP 包头，最后，我们可以看到封包所承载的是POP 3 的应用。
2. ESP
在ESP（Encapsulated Secutiry Payload）协议中，笔者所要讨论的是“加密”及“完整性验证”两项功能，其中加密的目的在于避免数据封包传递时遭到提取而泄露；完整性验证的目的则是确认数据封包在传递的过程中是否遭到窜改，或因网络传输质量不良而造成数据错误。这两项功能在ESP 协议下可以分开使用，也可以合并使用，这完全依照使用者的需求来决定，只不过一般在启用ESP 协议的情况下，通常都会选择加密的功能，至于完整性验证的部分就不一定会使用，当然，如果可以一并使用，那么对于数据封包的安全性就能得到更高的保障，接下来看ESP 协定下的加密及完整性验证是如何运行的。
1）传输模式下的ESP 协议
如图8-22 所示，相信你会有相同的反应，怎么会有这么多的Key ！如果你对于前面所提及的数据加/ 解密有很好的了解，那么这一堆Key 一定难不倒你。首先来认识这几把加密密钥的用途，因为在ESP 协议中有加密及完整性验证两项功能，如果我们启用了加密的功能，就必须提供一把加密密钥，即图中的Host-A_key-E ；另外，如果我们也要启用完整性验证，则必须提供另一把完整性验证时所需要的加密密钥，即图中的Host-A_key_A。最后，为了让主机B 可以解开主机A 所送来的数据封包，我们必须将主机A 的两把密钥传送给主机B，所以主机B 也会有Host-A_key-E 及Host-A_key_A 两把密钥。
同AH 协议一样，ESP 协议也是单向的，因此，如果我们要执行双向的ESP 协议，就必须帮主机B 也准备两把密钥，分别为数据封包加密用的Host-B_key-E，以及数据封包完整性验证用的Host-B_key-A，当然，这两把Key也必须被传送给主机A，这样主机A 及主机B 上分别会有4 把密钥。
了解ESP 协议运行时所需要的密钥之后，接下来要讨论的是ESP 协议加密运行的流程。我们假设主机A 封包传送给主机B，如果不走ESP 协议，其封包的结构就如同图8-23 上半部的样子，但如果走ESP 协议，首先会在IP 包头及TCP 包头之间插入一个ESP 包头，以及在封包的末端加入ESP Trailer 区块，而这个区块内主要是存放ESP 协议在运行时的一些参数，但这部分并不在我们的讨论范围，是否了解都不会影响到我们对于IPSec VPN 的设定。当以上动作完成之后，接着将TCP 包头、DATA 及ESP Trailer 这3 个部分以Host-A_key-E 加密起来，习惯上，我们会以Host-A_key-E（TCP 包头、DATA、ESP Trailer）来表示加密动作及加密范围，这样即完成ESP 协议的加密动作。
但如果我们启用ESP 的完整性验证功能，接下来系统就会对ESP 包头及Host-A_key-E（TCP 包头、DATA、ESP Trailer）执行散列运算，接着再以Host-A_key-A 对Fingerprint 进行加密，加密完成后的数据再附加于封包的最末端，这样即完成ESP 协议的完整性验证处理。
当主机B 接到这个封包后，主机B 会先对ESP 包头及Host-A_key-E（TCP包头、DATA、ESP Trailer）执行散列运算，运算完成后的Fingerprint 我们假设为F（A），接着再以主机B 上的Host-A_key-A 把ESP Auth Trailer 部分解开，这样即可得到当初主机A 所运算出来的Fingerprint，我们令其为F（B），如果F（A）等于F（B），就可以判定封包从主机A 送到主机B 的过程中封包的内容都没有任何异动，这样即完成完整性验证的检查；最后主机B 就以其上的Host-A_key-E 把Host-A_key-E（TCP 包头、DATA、ESP Trailer）解密，此时，主机B 就可以完全取得主机A 所传送过来的数据封包。
我们可以从图8-24 看到ESP 协议在传输模式下的封包结构，而图中的内容也印证了图8-23 的内容，在IP 包头下，除了ESP 包头之外，什么也看不到，因为所有的数据内容都被加密了。
2）隧道模式下的ESP 协议
以图8-25 为例，隧道模式与传输模式下的ESP 协议，其所要准备的加密密钥基本上都是相同的，因此，对于密钥的部分笔者就不再多做说明了。
接下来看Client A 与Client B 如何通过ESP 协议来跨越因特网传送数据。首先，当Client A 送出封包要给Client B 时，其封包结构就如同图8-26 上半部的内容，但是当这个封包送到VPN 主机A 时，主机A 随即在原封包前面加上一个ESP 包头，并在封包末端加上ESP Trailer，然后以Host-A_key-E 密钥将原有IP 包头、TCP 包头、DATA 及ESP Trailer 进行加密，接着产生一个新的IP 包头，到目前为止，ESP 协议的加密动作就算完成了。
如果我们启动ESP 协议下的完整性验证，接着，系统会以散列算法对ESP包头、Host-A_key-E（原有IP 包头、TCP 包头、DATA 及ESP Trailer）运算，运算完成之后所产生的Fingerprint 再以Host-A_key-A 进行加密，最后再把加密后的Fingerprint 置入整个封包的最末端，即ESP Auth Trailer 区块内。
当主机B 收到封包后，就可借助ESP Auth Trailer 的内容来验证封包的完整性，如果验证的结果没有问题，就把封包内被加密的部分解开，并将解密后的封包交由系统的路由表来决定封包该如何传送，这样Client B 即可接到Client A 所送过来的封包。
图8-27 为ESP 协议在隧道模式下的封包结构，其实这个结构与传输模式下的ESP 封包结构相同，但从图中可以看到，这个封包的来源端为10.0.1.200，而目的端IP 为10.0.1.210，并不是Client A 及Client B 的IP，同时也印证了图8-26 的内容。
在IPSec 的协议中，我们除了可以单独使用AH 或ESP 协议之外，也可以同时使用，甚至还可以决定在IPSec 的环境中先执行AH 或是ESP 协议，不过，在大多数情况下，都只会使用ESP 协议，而不使用AH 协议，因为在使用VPN 机制时，通常都会执行加密处理。此外，因为AH 协议较为少用，所以在RFC 中已经有人提案废除IPSec 协议下的AH 协议，至于是否使用AH 协议就由你自行决定，如果你的VPN Server 硬件够好，启动AH 协议应该也不是什么大问题。以笔者来说，通常只会启用ESP 协定。
5.3 AH及 ESP协议执行时所需设定的参数
在完整了解AH 及ESP 协议的运行流程及原理之后，接下来，我们就可以试着把传输模式及隧道模式的IPSec VPN 构建起来，不过，在开始构建VPN之前，得先整理一下AH 协议及ESP 协议所需要的参数有哪些，以及用途是什么，这样才能顺利将VPN 构建起来。
1. AH协议所需的参数
工作模式：指定AH的工作模式为Transport或Tunnel模式。
目的端IP：指定VPN另一个端点的IP位置。
目的端Port：在IPSec的运行中，我们可以指定哪些流量需要经过IPSec处理，哪些流量不需要经由IP S ec处理，而流量的划分方式则是依据Protocol（TCP、UDP或ICMP）及Port。
指定封包传送的方向：在IPSec的环境下，我们需要指定封包的方向，例如，封包是送入或送出。
验证算法：AH协议的完整性验证是以散列算法来达成的，因此，我们必须指定所要使用的验证算法是什么，在AH协议下验证算法的选择有hmac-md5及hmac-sha1两种。
加密密钥：验证算法运算出来的Fingerprint需要加密，我们必须准备加密用的密钥，而加密密钥的长度会因验证算法的不同而有差异，笔者将其整理成表8-1。
表8-1 加密算法及长度
2. ESP协议所需的参数
工作模式：指定ESP的工作模式为Transport或Tunnel模式。
目的端IP：指定VPN另一个端点的IP位置。
目的端Port：在IPSec的运行中，我们可以指定哪些流量需要经过IPSec处理，哪些流量不需要经由IP S ec处理，而流量的划分方式则是依据Protocol（TCP、UDP或ICMP）及Port的。
指定封包传送的方向：在IPSec的环境下，我们需要指定封包的方向，例如，封包是送入或送出。
验证算法：ESP协议的完整性验证是以散列算法来达成的，我们必须指定所要使用的验证算法，而在验证算法的选择中有hmac-md5及hmacsha1两种。
完整性验证所需的加密密钥：验证算法运算出来的Fingerprint需要加密，我们必须准备加密用的密钥，而加密密钥的长度会因验证算法的不同而有差异，笔者将其整理成表8-2。
表8-2 加密算法及长度
加密算法：在ESP协议的加密机制中，我们可以选择des及3des两种，实际上，在Linux平台上所能选择的加密协议众多，若你有兴趣可以在Linux环境下以man setkey指令来查询，不过，因为Windows系统极大多数的商用VPN系统只支持des及3des两种，所以我们如果要选择更安全的加密算法如rijndael-cbc时，则VPN系统的两个端点必须都为Linux才行。
加密算法所需的加密密钥：加密算法的密钥长度与我们所挑选的加密算法有关，笔者将加密算法及其长度整理成表8-3。
表8-3 加密算法及长度
5.4 设置Transport模式IPSec VPN（1）
现在以图8-28 为例来实际构建Transport VPN，因为这是我们第一次构建IPSec VPN，因此，笔者将范例尽量缩小，由简单然后慢慢让它变得更完整，这样才能清楚了解到IPSec VPN 的组态，而这个范例的最终目标是完成AH 协议、ESP 协议（包含完整性验证及加密）。
［范例8-1］启动Database Server及Client之间IPSec的AH协议
1. flush; 2. spdflush; 3. #====================<< SAD >>=========================== 4. add 192.168.0.1 192.168.0.10 ah 0x200 -m transport 5. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 6. add 192.168.0.10 192.168.0.1 ah 0x300 -m transport 7. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107; 8. #====================<< SPD >>=========================== 9. spdadd 192.168.0.1 192.168.0.10 any -P out ipsec 10. ah/transport//require; 11. 12. spdadd 192.168.0.10 192.168.0.1 any -P in ipsec 13. ah/transport//require;
以上就是一个只启动AH 协议的IPSec VPN 设定文件，请将这些内容存储成/root/192-168-0-1.conf 文件，代表这是Database Server 上的设定文件，对于设定文件的内容，在阅读时请特别注意两点。第一，如果看到“＃”符号，就代表其后的所有字符都是批注；第二，如果没有看到“;”符号，则代表目前这一行与下一行对系统而言是同一行。下面笔者以区块的方式来讨论这个设定文件的内容：
1. flush; 2. spdflush;
以上的设定是指在加载文件内所定的IPSec 参数前先清除系统上IPSec 旧的参数内容，而IPSec 的参数内容会分别存在SAD（ecurity Association Database）及SPD（Security Policy Database）两个数据库中。其中，flush 命令是指清除SAD 数据库的内容，spdflush 则是指清除SPD 数据库的内容，至于什么是SAD ？什么又是SPD ？在稍后的内容中将会解释，现阶段请先忽略。
3. #====================<< SAD >>=========================== 4. add 192.168.0.1 192.168.0.10 ah 0x200 -m transport 5. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 6. add 192.168.0.10 192.168.0.1 ah 0x300 -m transport 7. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107;
以上内容就是加入到SAD 数据库的参数，此外，别忘了我们在8.5.2 节“IPSec 的组成要素”中提过AH 及ESP 协议是单向的，因此，如果我们要执行双向的AH 协议，参数就得准备两份。因为第4 行及第5 行之间并没有“;”符号，因此，第4、5 行是同一行，第6、7 行也是同一行，下面分别介绍这些参数的意义。
第4 行的意义有以下几个。
“add”是将其后的参数加入到SAD数据库的命令。
“1 9 2 . 1 6 8 . 0 . 1 1 9 2 . 1 6 8 . 0 . 1 0”则代表1 9 2 . 1 6 8 . 0 . 1传递数据给192.168.0.10，也就是代表方向的意思。
“ah”指这些参数是定义给AH协议来使用的。
“0x200”暂时不介绍，后面的内容将有详尽的说明，不过请先记住，这个数值不能重复。
“-m t ranspor t”表示执行的传输模式，如果不指定预设就是传输模式，另外，如果要执行隧道模式，其参数为“-m tunnel”。
“-A hmac-sha1”代表我们选用的验证算法为hmac-sha1。
“0x……b5”为加密密钥的指定，而密钥的指定方式有两种，以hmacsha1算法为例，因为hmac-sha1算法所需搭配的加密密钥长度为20Bytes，因此，我们可以使用“-A hmac-sha1 ‘12345678901234567890’;”的方式来指定，只要‘’中的字符为20By t es即可，至于内容是什么并不重要。此外，我们也可以使用Linux系统下的指令来产生加密用的密钥，如下：
[[email protected] ~]# dd if=/dev/random count=20 bs=1 | xxd -ps 0bffdce8e51d9b39b1d200818882f75225d95952 20+0 records in 20+0 records out 20 bytes （20 B） copied0.000304166 65.8 kB/s
其中“0bffdce8e51d9b39b1d200818882f75225d95952”即为以随机数产生出来的十六进制随机数，而指令中的“count=20”表示要产生160 bits（20×8=160，因为1Bytes=8bits）的长度，这样我们就可以把这些数据当做加密密钥来使用，不过，因为这是十六进制的数据，因此我们需在密钥的最前端加上0x，以表示这是十六进制的数据。
第6 行与第4 行参数的意义是相同的，只不过“方向”是不同的，而且这些参数可以与第4 行完全不同。例如在第4 行中我们选用hmac-sha1 算法，但在第6 行选用hmac-md5 算法，不过，通常是建议设定成较安全的hmac-sha1算法。此外，关于加密密钥的部分最好不要相同，这样对整个加密的应用会更安全。
8. #====================<< SPD >>=========================== 9. spdadd 192.168.0.1 192.168.0.10 any -P out ipsec 10. ah/transport//require; 11. spdadd 192.168.0.10 192.168.0.1 any -P in ipsec 12. ah/transport//require;
以上为加入SPD 数据库的内容，而这些参数的目的是控制进出VPN 主机的封包流量中哪些流量需要走IPSec 协议，以及走IPSec 协议中的哪些协议，下面就来看这些参数所代表的意义。
第9 行的意义有以下几个。
“spdadd”是将其后参数加入到SPD数据库中的命令。
“192.168.0.1 192.168.0.10 any -P out ipsec”参数为指定需要走IPSec的流量是哪些，只不过这些参数有点复杂，下面是这些规则定义的方式：
192.168.0.1 [any] 192.168.0.10[110] tcp -P out ipsec
我们先假设以上的参数是设定在192.168.0.1 主机上，而这些参数的意思是说：如果“192.168.0.1”以“任何”一个Port 送封包给“192.168.0.10”的“110”这个Port，且通信协议为TCP 时，这些流量必须走IPSec 协议。另外，如果Port 的部分没有定义，其默认值就为any，也就是指任何一个Port 的意思。
192.168.0.1 [any] 192.168.0.10[53] udp -P out ipsec
在本例中，我们还是假设参数是设定在192.168.0.1 主机上，这些参数的意思是说：192.168.0.1 主机如果通过192.168.0.10 主机进行名称解析，那么这些流量都要经过IPSec 处理。
192.168.0.1 192.168.0.10 icmp -P out ipsec
本例的意义你应该可以很容易理解，不过笔者要特别说明一点，因为Port的观念不适用于ICMP 协议，因此，在处理ICMP 协议时，就不该指定Port，否则将会成命令的语法错误。
第10 行中的“ah/transport//require”参数是指如果封包流量符合第9 行的定义，那么这些封包是“必须”以“传输模式”的AH 协议来处理。第11 行及第12 行其实只是第9 行及第10 行的反方向定义而已。
在所有参数都定义完成之后，我们可以把/root/192-168-0-1.conf 文件以scp 工具传送到192.168.0.10 主机的/root 目录下，并且存储成192-168-0-10.conf 文件，操作方式如下：
scp /root/192-168-0-1.conf 192.168.0.10:/root/192-168-0-10.conf
目前192-168-0-10.conf 与192-168-0-1.conf 的内容是相同的，请思考一个问题，这两部主机上的IPSec 参数定义完全相同，你觉得合理吗？还是有什么地方需要修改呢？其实这两个文件的内容除了SPD 部分out 及in 的方向要颠倒之外，其他内容应该完全相同，笔者将这两个文件的内容列表如下：
1. flush; 2. spdflush; 3. #====================<< SAD >>=========================== 4. add 192.168.0.1 192.168.0.10 ah 0x200 -m transport 5. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 6. add 192.168.0.10 192.168.0.1 ah 0x300 -m transport 7. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107; 8. #====================<< SPD >>=========================== 9. spdadd 192.168.0.1 192.168.0.10 any -P out ipsec 10. ah/transport//require; 11. spdadd 192.168.0.10 192.168.0.1 any -P in ipsec 12. ah/transport//require; 192-168-0-1.conf的文件内容 1. flush; 2. spdflush; 3. #====================<< SAD >>=========================== 4. add 192.168.0.1 192.168.0.10 ah 0x200 -m transport 5. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 6. add 192.168.0.10 192.168.0.1 ah 0x300 -m transport 7. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107; 8. #====================<< SPD >>=========================== 9. spdadd 192.168.0.1 192.168.0.10 any -P in ipsec 10. ah/transport//require; 11. spdadd 192.168.0.10 192.168.0.1 any -P out ipsec 12. ah/transport//require; 192-168-0-10.conf的文件内容
在这两个文件设定完成之后，接下来，我们就可以运用setkey 指令来启动IPSec，操作方式如下：
setkey -f 192-168-0-1.conf
当两部主机上的IPSec 都启动后，我们就可以在192.168.0.1 主机上使用任意协议与192.168.0.10 主机沟通。如ping 192.168.0.10，因为在本范例中，我们是对any（任何协议）流量进行IPSec 的处理，因此，如果我们以Wireshark来提取网络封包，封包的内容应该如图8-29 所示，从图中可以看到192.168.0.1 与192.168.0.10 两部主机正以ICMP 协议在沟通，并从封包的结构可以看到，在IP 包头与ICMP 包头之间多了一个AH 包头，这样即可证明我们的实验是成功的，最后可以使用如下指令来取消IPSec 的运行：
［范例8-2］启动Database Server及 Client之间IPSec的ESP协议
2. spdflush; 3. #====================<< SAD >>=========================== 4. add 192.168.0.1 192.168.0.10 esp 0x201 -m transport 5. -E 3des-cbc 0xb99d4139d9976665eede3f74d4e897617c5a7452e5789f9f 6. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107; 7. add 192.168.0.10 192.168.0.1 esp 0x301 -m transport 8. -E 3des-cbc 0xbb025b18e28ea7fb15479ba25346e24fd9acb1e7cd502a25 9. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 10. #====================<< SPD >>=========================== 11. spdadd 192.168.0.1 192.168.0.10 icmp -P out ipsec 12. esp/transport//require; 13. spdadd 192.168.0.10 192.168.0.1 icmp -P in ipsec 14. esp/transport//require;
在了解了AH 协议的设定之后，以上的内容就可以很容易理解了，其实这些参数与AH 协议参数的设定上大致都相同，下面就让笔者来解释这个设定文件的内容。
第5行为指定ESP协议中所要使用的加密算法及加密密钥，密钥的产生方式可以与AH协议下产生密钥的方法相同，只不过要注意密钥的长度。
第6行为指定ESP协议中完整性验证所要使用的验证算法及加密密钥，如果省略这一行则代表不启用ESP的完整性验证。
第7行及第9行为指定反方向ESP协议的参数。
第12行及第14行则为指定启用ESP协议下的传输模式。
在两部主机都启动IPSec 机制后，我们可以提取到结构如图8-30 所示的封包，从图中我们已无法看到封包内实际传送的数据内容，因为所有数据都被ESP 协议加密了，所以可以从封包的结构部分看到，在IP 包头之后就只剩下ESP 包头及被加密的数据，这样即可证明我们的实验是成功的。
［范例8-3］启动D a t a b a s e S e r v e r及Cl i e n t之间I P S e c的A H及ESP协议
1. flush; 2. spdflush; 3. #=====================<< SAD >>============================== 4. add 192.168.0.1 192.168.0.10 ah 0x200 -m transport 5. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 6. add 192.168.0.10 192.168.0.1 ah 0x300 -m transport 7. -A hmac-md5 0x570e55a9560bf191e38398979aa6e967; 8. add 192.168.0.1 192.168.0.10 esp 0x201 -m transport 9. -E 3des-cbc 0xb99d4139d9976665eede3f74d4e897617c5a7452e5789f9f; 10. add 192.168.0.10 192.168.0.1 esp 0x301 -m transport 11. -E des-cbc 0xcce630577afbaa83; 12. #=====================<< SPD >>=============================== 13. spdadd 192.168.0.1 192.168.0.10 icmp -P out ipsec 14. esp/transport//require 15. ah/transport//require; 16. spdadd 192.168.0.10 192.168.0.1 icmp -P in ipsec 17. esp/transport//require 18. ah/transport//require;
经过范例8-1 及范例8-2 的解说之后，相信范例8-3 的内容你一看就可以理解，其实这只是把前两个范例的内容加在一起而已，不过，为了加深你对AH 及ESP 议的单向性了解，在本范例中，笔者故意把双向的验证算法及加密算法设为不一样，当然加密密钥也就需要跟着改变。
此外，差异较大的部分大概是在第14、15、17 及18 行，不过，这样的写法相信你应该都能接受，其实也就是AH 及ESP 协议都要执行的意思。不过，在AH 及ESP 协议都需要的情况下，是AH 先执行，还是ESP 先执行呢？其实都可以，只要两端的VPN 主机设定成一样就可被接受。Windows 系统在预设情况下是先执行ESP，再执行AH，这部分你可要记清楚。而目前范例中的设定是先执行ESP，然后再执行AH 协议，因此，我们实际提取到的封包结构就如图8-31 所示，并可以清楚看到ESP 包头在AH 包头之后。
但如果我们把范例8-3 的SPD 部分更改如下，那么AH 协议将会先被执行，然后才执行ESP 协议，这样我们在网络上实际提取到的封包结构就会如图8-32所示，因为ESP 协议是在后面才执行的，所以先执行而产生出来的AH 包头也会被加密，因此我们只能从图中看到ESP 包头。
12. #=====================<< SPD >>=============================== 13. spdadd 192.168.0.1 192.168.0.10 icmp -P out ipsec 14. ah/transport//require 15. esp/transport//require; 16. spdadd 192.168.0.10 192.168.0.1 icmp -P in ipsec 17. ah/transport//require 18. esp/transport//require;
以上的范例都是以传输模式为例，接下来，以图8-33 为例来构建隧道模式的IPSec VPN，并同时启动AH 及ESP 协议。
1. flush; 2. spdflush; 3. #=====================<< SAD >>============================== 4. add 10.0.1.200 10.0.1.210 ah 0x300 -m tunnel 5. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107; 6. add 10.0.1.210 10.0.1.200 ah 0x200 -m tunnel 7. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 8. add 10.0.1.200 10.0.1.210 esp 0x201 -m tunnel 9. -E 3des-cbc 0xb99d4139d9976665eede3f74d4e897617c5a7452e5789f9f; 10. add 10.0.1.210 10.0.1.200 esp 0x301 -m tunnel 11. -E 3des-cbc 0xbb025b18e28ea7fb15479ba25346e24fd9acb1e7cd502a25; 12. #=====================<< SPD >>============================== 13. spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec 14. esp/tunnel/10.0.1.210-10.0.1.200/require 15. ah/tunnel/10.0.1.210-10.0.1.200/require; 16. spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec 17. esp/tunnel/10.0.1.200-10.0.1.210/require 18. ah/tunnel/10.0.1.200-10.0.1.210/require;
以上为启动隧道模式VPN 的设定参数，其参数的定义与传输模式的参数几乎相同，而其中有差异的大概是SPD 的部分，因此，笔者只针对SPD 的部分来解说，我们先以第13、14 及15 行为例来说明。
第13行定义凡是由192.168.0.0/24网段送给192.168.1.0/24网段的任何数据封包都需要通过IPSec来处理。
第14行是定义执行ESP协议的隧道模式，而隧道的起点是10.0.1.210、终点是10.0.1.200。
第15行是定义执行AH协议的隧道模式，而隧道的起点是10.0.1.210、终点是10.0.1.200。
对于隧道模式的IPSec VPN 来说，其AH 及ESP 依旧是单向的，如果我们希望双向流量都是走IPSec 协议，那么就必须定义另一个反方向的规则，其中第16、17 及18 行即为反方向的IPSec VPN 定义。
6 Linux下的IPSec架构
同Netfilter 一样，Linux 也是利用外挂模块的方式来支持IPSec 机制，而这些模块的位置如图8-34 所示。其中ah4.ko 及esp4.ko 就是Linux 于IPv 4 环境下支持IPSec 的模块，不过ah4.ko 及esp4.ko 其实只是执行AH 及ESP 协议的一个机制而已，如果我们没给予验证算法、加密算法及加密密钥等，除了只能拿来占用内存之外，什么事也不能做，那AH 及ESP 的工作参数我们又该如何指定给它们呢？这就得使用setkey 管理工具将IPSec 执行时所需要的参数写入到SPD（Security Policy Database，安全策略数据库）及SAD（SecurityAssociation Database，安全参数数据库）。回想一下，我们在启动IPSec VPN 时，是不是执行了setkey -f 192-168-0-1.conf 的动作，而192-168-0-10.conf 文件内有====<SPD>==== 及====<SAD>==== 两个段落，这两个段落的参数就是分别要汇入到SPD 及SAD 的内容，待参数汇入到SPD 及SAD 之后，IPSec 机制就可以遵照SPD 及SAD 中的参数来执行任务；相反地，如果我们使用setkey 管理工具将SPD 及SAD 中的参数清除，IPSec 的执行任务也就宣告停止。
6.1 IPSec机制的SPD
SPD 的内容用来存放IPSec 的规则，而这些规则用来定义哪些流量需要走IPSec，这个数据库的内容相当多，笔者仅介绍我们需要知道的部分，这些信息有目的端IP、来源端IP、只执行AH 或ESP、同时执行AH 及ESP、目的端Port、来源端Port、走Transport 或Tunnel 模式。图8-35 即为SPD 的结构，从结构内容我们可以看到第一笔及第二笔数据刚好构成一条双向的VPN 连接，此外，因为一台主机可能同时与多部主机进行IPSec 连接，因此数据库的内容可能同时存在多笔数据。
有了以上的信息，当VPN 主机有数据封包要送出时，这个封包会由SPD进行匹配，如果封包的来源端及目的端IP 不等于SPD 所记载的内容，那么这个封包就不会交由AH 或ESP 协议来处理；反之，封包就会被送交给AH 或ESP 协议来处埋，至于会送给谁来处理，就由SPD 的“执行协议”这个字段的内容来决定。
至于SPD 的内容我们可以利用setkey 工具来管理，例如，可以使用setkey-D -P 来查看SPD 的内容，也可以使用setkey -P -F 来清除SPD 的内容。
6.2 IPSec机制的SAD
存放在SAD 数据库中的参数有SPI 值、目的端IP、AH 或ESP、AH 验证算法、AH 验证的加密密钥、ESP 验证算法、ESP 验证的加密密钥、ESP 的加密算法、ESP 的加密密钥、走Transport 或Tunnel 模式，其中SPI（Security ParameterIndex，索引值）是两部VPN 主机之间以随机数或手动指定的唯一值，其目的是要作为数据库的索引值，这对整个IPSec 的运行没有其他用途。此外，需要注意AH 与ESP 协议的参数是分开的，因此，笔者刻意把SAD 划分成两个部分，并以执行协议来区分。
封包在SPD 中被决定必须执行AH、ESP 或AH 及ESP 协议之后，就会从SAD 数据库中找到处理这个流量的参数。例如，我们是192.168.0.1 主机，当SPD 决定192.168.0.1 送到192.168.0.10 的TCP Port 110 的封包时，需要执行AH 及ESP 协议，在封包交给ESP 机制之后，ESP 机制会以目的端IP 来找到处理这个封包的参数，如图8-36 中的第一条数据。此外，ESP 机制在处理的过程中会将SPI 值加入到ESP 包头内，就如图8-37 中ESP 包头内的SPI 值，至于这个SPI 值的用途，本节稍后会有完整的解说。
ESP 协议处理完成之后，接着把封包交由AH 机制来处理，AH 机制从图8.36 中找到目的端IP 为192.68.0.10 的那一条数据，并从数据中找到处理这个封包的参数。此外，在AH 处理的过程中，也会将SPI 值一并包在AH 包头之中，也就是如图8-37 中AH 包头内所看到的SPI 值，至于SPI 值的用途稍后也会有完整的介绍。
我们同样可以借助setkey 工具来管理SAD 的内容，例如，可以使用setkey-D 来检查SAD 的内容，或是使用setkey -D -F 来清除。
接下来以图8-38 为例来说明IPSec 的运行流程。假设主机A 要送数据给主机B，当数据送达网络层的较下端时①，IPSec 的Filter 会将封包的特征与SPD 数据库的内容匹配②，如果封包特征与SPD 数据库的内容都没有符合，这个封包就会直接通过网络传送给主机B ③，在这个封包进入到主机B 之后，主机B 的IPSec Filter 会将这个封包的特征与其SPD 数据库的内容匹配④，如果匹配的结果不符合，那么封包就直接往上层传送⑤。
但如果主机A 送给主机B 的封包特征有符合主机A 上SPD 数据库内容，封包就会被送入到IPSec 的AH 及ESP 机制中⑥，接着，AH、ESP 就会到SAD 数据库中找到处理这个封包的参数⑦，完成处理后的封包随即被送往主机B ⑧，在主机B 找到这个封包之后，就把这个封包的特征与其SPD 数据库的内容进行匹配④，如果匹配的结果符合，这个封包就会送入AH 及ESP 机制处理⑨，接着，AH、ESP 就会从SAD 数据库中找到处理这个封包的参数，最后，将处理完成的数据往上层传递。看完以上的流程之后，相信你可以更加了解IPSec 的运行流程。
最后，我们来看AH 及ESP 包头内SPI 值的用途是什么。试想，如果你是192.168.0.10 这台VPN 主机，当你从网络上收到一个IPSec 处理后的封包，请问要如何去验证这个封包的完整性及解开这个封包的加密部分呢？首要任务就是找到AH 及ESP 的参数，因为有这些参数我们才能知道封包是以何种验证算法来计算，且AH 的加密密钥、ESP 的加密算法及ESP 的加密密钥又各是什么。
由于我们在启动IPSec VPN 时会将AH 及ESP 的参数分别汇入到两部VPN 主机的SPD 及SAD 两个数据库，因此，处理这个封包的AH 及ESP 参数在本机的SAD 数据库内一定找得到，但问题是要如何找到？我们可以从图8-39看到这个封包的来源端IP 是192.168.0.1、目的端IP 是192.168.0.10，而且在第封包内AH 及ESP 包头的部分分别可以看到一个SPI 的参数，这个例子为“AH：0x200”、“ESP ：0x201”，这样，当我们收到这个封包之后，就可以从目前使用的协议AH、封包的目的端IP 及封包内AH 包头内的SPI 值来匹配出SAD 的其中一条数据，而这笔数据一定会是唯一的，这样一来，就可以取得处理这个封包的AH 及ESP 参数。这个SPI 值是从何而来的呢？ SPI 值产生的方式有两种，其一是由系统自动产生，其二是我们先回顾IPSec 设定文件的内容后，如下第4、6、8、10 这4 行中的0x200 字段就是手动指定SPI 的位置。
1. flush; 2. spdflush; 3. #=====================<< SAD >>============================== 4. add 10.0.1.200 10.0.1.210 ah 0x300 -m tunnel 5. -A hmac-sha1 0x3f3f0cd71d0e300d5788127cc78db64ea3f21107; 6. add 10.0.1.210 10.0.1.200 ah 0x200 -m tunnel 7. -A hmac-sha1 0x73f6e61bf4c8307020c230b367296e26a5262fb5; 8. add 10.0.1.200 10.0.1.210 esp 0x201 -m tunnel 9. -E 3des-cbc 0xb99d4139d9976665eede3f74d4e897617c5a7452e5789f9f; 10. add 10.0.1.210 10.0.1.200 esp 0x301 -m tunnel 11. -E 3des-cbc 0xbb025b18e28ea7fb15479ba25346e24fd9acb1e7cd502a25; 12. #=====================<< SPD >>============================== 13. spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec 14. esp/tunnel/10.0.1.210-10.0.1.200/require 15. ah/tunnel/10.0.1.210-10.0.1.200/require; 16. spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec 17. esp/tunnel/10.0.1.200-10.0.1.210/require 18. ah/tunnel/10.0.1.200-10.0.1.210/require;
7 实战演练
实战8-1 构建传输模式的ESP VPN（1）
本例图示如图8-40 所示。
环境确认：
1．确认主机A 与主机B 的网络是畅通的。
2．确认主机A 与主机B 没有启动任防火墙功能。
练习目标：
以ESP 协议加密任何主机A 与主机B 之间的封包。
参考解答：
192-168-0-1.conf
flush; spdflush; #=======================<< SAD >>========================= add 192.168.0.1 192.168.0.10 esp 0x201 -E 3des-cbc 0xb99d4139d9976665eede3f74d4e897617c5a7452e5789f9f; add 192.168.0.10 192.168.0.1 esp 0x301 -E 3des-cbc 0xbb025b18e28ea7fb15479ba25346e24fd9acb1e7cd502a25; #=======================<< SPD >>========================= spdadd 192.168.0.1 192.168.0.10 any -P out ipsec esp/transport//require; spdadd 192.168.0.10 192.168.0.1 any -P in ipsec esp/transport//require;
192-168-0-10.conf
请将192-168-0-1.conf复制到192.168.0.10主机上，并且修改SPD封包的进出方向即可结果验证：
1．在192.168.0.1 主机上执行“ping 192.168.0.10”。
2．在192.168.0.1 主机上以Wireshark 软件提取Vmnet1 接口上的封包。
3．确认所有封包都是被ESP 协议加密的，否则实验并未成功。
实战8-2 构建传输模式的ESP VPN（2）
本例图示如图8-41 所示。
环境确认：
1．确认VPN Server ( A )与VPN Server ( B )的网络是畅通的。
2．确认Client A 与VPN Server ( A )的网络是畅通的。
3．确认Client B 与VPN Server ( B )的网络是畅通的。
4．确认Client A 与Client B 的网络是“不会”通的。
5．确认VPN Server ( A )及VPN Server ( B )的ip_forward 是开启的。
练习目标：
1．以VPN 连接192.168.0.0/24 及192.168.1.0/24 两个网段。
2．任何1921.68.0.0/24 及192.168.1.0/24 网段互通的封包都由ESP 协议加密。
参考解答：
vpn-server-a.conf
flush; spdflush; #=====================<< SAD >>========================== add 10.0.1.200 10.0.1.210 esp 0x201 -m tunnel -E 3des-cbc 0xb99d4139d9976665eede3f74d4e897617c5a7452e5789f9f; add 10.0.1.210 10.0.1.200 esp 0x301 -m tunnel -E 3des-cbc 0xbb025b18e28ea7fb15479ba25346e24fd9acb1e7cd502a25; #=====================<< SPD >>========================== spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/10.0.1.210-10.0.1.200/require; spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec esp/tunnel/10.0.1.200-10.0.1.210/require;
vpn-server-b.conf
请将vpn-server-a.conf复制到10.0.1.200主机上，并且修改SPD封包的进出方向即可。结果验证：
1．确认192.168.0.10 可以ping 到192.168.1.10。
2．在10.0.1.200 主机上以Wireshark 软件提取eth0 接口上的封包。
3．确认所有封包都是被ESP 协议加密的，否则实验并未成功。
参考： http://book.51cto.com/art/200903/114593.htm
http://os.51cto.com/art/201001/177074_all.htm