文档名称IPSec VPN应用 文档密级
由于IPSec+GRE的显著优势，这种组合已经成为目前IPSec VPN应用最广泛的一种模型。在后面的拓扑结构介绍中，也会重点来介绍这种模型的实际应用例子。
1.3 IPSec+L2TP模型
IPSec+L2TP模型和IPSec+GRE模型类似，借助L2TP对于远程移动用户的强大支持，扩展了IPSec的应用。这种模型同样首先采用L2TP封装，然后再对其使用IPSec封装，大大提高了IPSec对于远程移动用户拨号的支持。
IPSec+L2TP的应用模型比较简单，一般只用于远程拨入用户和企业核心网络的互连，很少考虑到拓扑的变化和路由的设计问题，在IPSec+L2TP中IPSec需要保护的流只需要以L2TP的起点为源、终点为目的即可，因此本文不重点介绍IPSec+L2TP。
2 IPSec VPN拓扑结构
在实际的企业应用中，一般很少有只在两点之间建立IPSec VPN的情况，大多数情况都需要核心站点和多个远程节点之间建立IPSec VPN，根据网络的需求和配置的复杂程度等因素，可以选择采用Hub-Spoke VPN结构或者Full-Mesh VPN结构。
2.1 Hub-Spoke
Hub-Spoke VPN模型如图所示。
2006-04-13
华为三康机密，未经许可不得扩散 第6页, 共26页
文档名称IPSec VPN应用 文档密级
10.1.0.0/24 Hub Spoke1 10.0.64.0/24 Spoke2 10.0.65.0/24 Spoke3 10.0.66.0/24 Spoke4 10.0.67.0/24
图1 Hub-Spoke VPN
这种拓扑结构是所有的Spoke站点都有一条VPN隧道连接HUB站点，Spoke之间没有VPN隧道，如果Spoke之间需要通过VPN通信，则必须借助Hub转发来完成。
这种拓扑结构的特点是VPN链路较少，拓扑清晰，配置相对简单，尤其适合对于Spoke和Spoke之间没有流量的情况。
但是这种模型也有其缺点：过分依赖Hub设备，可以说Hub设备是整个网络的心脏，Hub Down掉，整个网络就会瘫痪，因此使用Hub-Spoke VPN模型的当务之急就是采用冗余结构保护网络的可靠性。另外，这种模型对Hub的性能要求也比较高，尤其是Spoke较多，并且Spoke流量需要Hub转发的时候，此时，合理的分配地址以及配置多Hub的负载均衡也应该是我们重点需要考虑的。合理的分配地址可以减少Hub的IPSec SA，节约Hub的性能资源；多Hub负载均衡可以将性能压力分摊到其它设备上。
对于IPSec的冗余以及负载均衡的讨论我们放在后面章节进行，在接下来的讨论中暂时不考虑这两点，请读者注意。
在Hub-Spoke拓扑之上，我们可以选择前面介绍的几种IPSec应用模型，下面就分别介绍一下：
2006-04-13
华为三康机密，未经许可不得扩散 第7页, 共26页
文档名称IPSec VPN应用 文档密级
2.1.1 IPSec模型
采用IPSec模型一定要特别关注路由以及要保护流的设计。我们以一个实际网络为例：假设我们有下面的场景：
企业总部为Hub，各个分支站点为Spoke，设计IPSec VPN满足如下要求
? Hub和各个Spoke之间有一条IPSec VPN隧道，各个Spoke之间没有IPSec VPN隧道。 ? Hub内部的私网和各个Spoke内部的私网通过IPSec VPN通信，各个Spoke私网之间
不需要通信。
? Hub和各个Spoke都能使内部网段访问Internet资源。
10.1.0.0/24 Hub 9.1.1.22/30 9.1.1.130/30 Spoke1 10.0.64.0/24 9.1.1.134/30 9.1.1.138/30 9.1.1.142/30 Spoke2 10.0.65.0/24 Spoke3 10.0.66.0/24 10.0.67.0/24 Spoke4
图2 IPSec VPN Hub-Spoke拓扑
首先考虑路由的设计，显而易见，必须采用静态路由来保证各个站点之间的通信。路由的任务有三个：
? 完成各个站点安全网关的公网地址的互通 ? 完成Hub和Spoke之间私网地址的互通 ? 完成Hub和Spoke对于Internet地址的互通
完成各个站点安全网关的公网地址的互通是建立VPN的前提，完成这个目标最简单的方法是每个安全网关设备都有一条指向其默认ISP路由器的缺省路由，这样也同时使各个安全
2006-04-13
华为三康机密，未经许可不得扩散
第8页, 共26页
文档名称IPSec VPN应用 文档密级
网关有了到达其它目的私网的路由和访问Internet的路由。当然，我们也可以在各个安全网关上定义目的安全网关的明细路由，但是，这样我们就必须在各个安全网关上再定义一个或者多个目的私网的静态路由，同时还需要为访问Internet额外配置路由。所以，在各个安全网关上定义缺省路由是一个比较合理的选择。
其次，需要考虑在Hub和Spoke上如何定义要保护的流。实际上，这个任务非常简单，各个安全网关要保护的流以自己私网地址为源，目的站点的私网地址为目的即可。以Hub和Spoke1为例(Hub和其它Spoke的配置类似)：在Hub上为10.1.0.0/24-10.0.64.0/24；在Spoke1上为10.0.64.0/24-10.1.0.0/24。
综上所述，Hub的IPSec相关配置如下(只列出了关键配置)： ACL Number 3111 #for Spoke1
rule 0 permit ip source 10.1.0.0 0.0.0.255 destination 10.0.64.0 0.0.0.255 ACL Number 3112 #for Spoke2
rule 0 permit ip source 10.1.0.0 0.0.0.255 destination 10.0.65.0 0.0.0.255 ACL Number 3113 #for Spoke3
rule 0 permit ip source 10.1.0.0 0.0.0.255 destination 10.0.66.0 0.0.0.255 ACL Number 3114 #for Spoke4
rule 0 permit ip source 10.1.0.0 0.0.0.255 destination 10.0.67.0 0.0.0.255 ip route-static 0.0.0.0 0.0.0.0 9.1.1.21 preference 60 Spoke的IPSec相关配置如下： ACL Number 3111
rule 0 permit ip source 10.0.64.0 0.0.0.255 destination 10.1.0.0 0.0.0.255 ip route-static 0.0.0.0 0.0.0.0 9.1.1.129 preference 60
另外，如果我们希望简化配置，可以配置Hub的保护流如下： rule 0 permit ip source 10.1.0.0 0.0.0.255 destination any
但是，这样定义Hub的保护流只能采用Spoke来触发IPSec VPN，因为这样的保护流无法唯一的标识某个Spoke。
通过上面的配置可以很好的完成Hub和Spoke之间通信的需求，但是很多情况下，Spoke-Spoke之间的通信也是必须的，在不改变现有VPN拓扑结构的情况下能否完成这个任
2006-04-13
华为三康机密，未经许可不得扩散
第9页, 共26页
文档名称IPSec VPN应用 文档密级
务呢？答案是肯定的，我们只需要修改一下路由和保护流的配置即可。
由于Spoke之间没有VPN，因此Spoke之间的通信只能够通过Hub的转发完成，我们来分析一下Spoke1和Spoke2之间的通信过程：
1. Spoke1到Spoke2的报文首先路由到出接口。
2. 报文经过Spoke1-Hub的VPN到达Hub，Hub完成报文的解密。 3. Hub对报文进行路由，到达出接口。 4. 报文经过Hub-Spoke2的VPN到达Spoke2。 5. Spoke2完成报文的解密。
通过上面的处理过程我们可以看到：问题的关键在于Spoke1是否有到达Spoke2的路由(步骤1)；Spoke1-Spoke2的报文是否匹配Spoke1-Hub VPN的要保护的流(步骤2)；Spoke1到Spoke2的报文是否符合Hub-Spoke2 VPN的要保护的流(步骤4)。
在采用上面配置的前提下，由于各个安全网关配置了缺省路由，因此可以保证Spoke1到Spoke2的路由可达。而10.0.64.0/24-10.0.65.0/24的报文(Spoke1到Spoke2)是不匹配Spoke1-Hub VPN的要保护流的，因此需要修改Spoke1的ACL。
我们注意到，ACL要修改的只是目的地址部分，需要增加10.0.64.0/24-10.0.65.0/24、10.0.64.0/24-10.0.66.0/24……等配置。如果Spoke设备较多，配置的繁琐和复杂也是不可想象的，如果采用10.0.64.0/24-any的配置呢？这样定义虽然可以匹配Spoke1访问其它Spoke和Hub的数据包，但是对于Spoke1内部网络访问Internet主机也进行了IPSec加密，造成Internet访问的失败。如何能够简化配置同时满足需求呢？这个时候合理的地址设计就显现出强大的作用，按照图2的地址分配原则，我们可以在Spoke1上采用如下配置10.0.64.0/24-10.0.0.0/8，即可轻松解决问题，因为10.0.0.0/8这个目的地址可以包含Hub和所有其它Spoke，并且，如果网络以后进行扩展，增加了大量的Spoke(10.0.70.0/24、10.0.71.0/24……)，可以不用修改Spoke1上的要保护的流。但是如果地址设计混乱，就只能在Spoke1上为Hub以及其它Spoke分别定义要保护的流了。
同样的道理，10.0.64.0/24-10.0.65.0/24的报文(Spoke1到Spoke2)是不匹配Hub-Spoke2 VPN要保护流的，也需要修改Hub的感兴趣流。相应的，Hub上针对所有Spoke的感兴趣流源地址应该是10.0.0.0/8而不是10.1.0.0/24了。
综上所述，Hub的IPSec相关配置如下(只列出了关键配置)：
2006-04-13
华为三康机密，未经许可不得扩散
第10页, 共26页