文档名称IPSec VPN应用 文档密级
ACL Number 3111 #for Spoke1
rule 0 permit ip source 10.0.0.0 0.255.255.255 destination 10.0.64.0 0.0.0.255 ACL Number 3112 #for Spoke2
rule 0 permit ip source 10.0.0.0 0.255.255.255 destination 10.0.65.0 0.0.0.255 ACL Number 3113 #for Spoke3
rule 0 permit ip source 10.0.0.0 0.255.255.255 destination 10.0.66.0 0.0.0.255 ACL Number 3114 #for Spoke4
rule 0 permit ip source 10.0.0.0 0.255.255.255 destination 10.0.67.0 0.0.0.255 Spoke的IPSec相关配置如下： ACL Number 3111
rule 0 permit ip source 10.0.64.0 0.0.0.255 destination 10.0.0.0 0.255.255.255
在前面所讲的两个例子中，安全网关都是在本地提供Internet访问的功能，也就是说各个Spoke和Hub都能够为本地私网主机提供Internet连接，通过在IPSec策略中不保护访问Internet主机为目的地址的报文来实现，即所有加密报文和不加密报文都通过安全网关的外网接口出去，符合IPSec策略的报文通过VPN离开本地网络，不符合IPSec策略的报文直接通过NAT离开本地网络，这种实现方式称为“隧道分离”技术。
随着企业对于网络安全认识的不断加深，其对于网络的安全设计要求也越来越严格，典型的，对于安全网关的Internet访问功能也提出了更高的要求。一般情况下，为了统一的管理，大部分企业都要求访问Internet的需求集中在总部实现，也就是在Hub上实现，各个Spoke不能提供本地的Internet访问功能，这样可以将安全的风险降到最低，并且也便于管理。
我们仍然以图2为例，需求如下
? Hub和各个Spoke之间有一条IPSec VPN隧道，各个Spoke之间没有IPSec VPN隧道。 ? Hub内部的私网和各个Spoke内部的私网通过IPSec VPN通信，各个Spoke私网之间
不需要通信。
? 各个Spoke和Hub的私网主机只能通过Hub设备访问Internet资源。
在上面的例子中Spoke1定义要保护的流为10.0.64.0/24-10.0.0.0/8，而对于其它目的地址的流没有进行IPSec保护，这样就造成了隧道的“分离”，不符合IPSec策略的报文于是通过分离的隧道离开了本地，解决的方法很简单，只需要将Spoke1要保护的流定义为
2006-04-13
华为三康机密，未经许可不得扩散
第11页, 共26页
文档名称IPSec VPN应用 文档密级
10.0.64.0/24-any即可。在Hub上和各个Spoke之间原来的要保护的流源地址为10.0.0.0/8，由于从Internet上返回的报文需要经过Hub到达各个Spoke，而这些报文的源地址为Internet的公网地址，为了使这些地址能够通过IPSec VPN从Hub返回到Spoke，需要将Hub和各个Spoke之间要保护的流源地址改为any。
综上所述，Hub的IPSec相关配置如下(只列出了关键配置)： ACL Number 3111 #for Spoke1
rule 0 permit ip source any destination 10.0.64.0 0.0.0.255 ACL Number 3112 #for Spoke2
rule 0 permit ip sourc any destination 10.0.65.0 0.0.0.255 ACL Number 3113 #for Spoke3
rule 0 permit ip source any estination 10.0.66.0 0.0.0.255 ACL Number 3114 #for Spoke4
rule 0 permit ip source any destination 10.0.67.0 0.0.0.255 Spoke的IPSec相关配置如下： ACL Number 3111
rule 0 permit ip source 10.0.64.0 0.0.0.255 destination any
2.1.2 IPSec+GRE模型
IPSec+GRE模型采用IPSec保护的GRE隧道，最大的优势就是将我们从IPSec复杂的配置中解脱出来，尤其是要保护的流，我们不必关心接口流入和流出的报文地址是什么，要保护的流是什么，只要保护GRE隧道的起点和终点即可。
另外，我们也不需要费尽心思的设计如何分配各个站点的网络地址，因为GRE已经隐藏了报文的原始地址，简化的配置带来的另一个惊喜就是安全网关性能的节约，更少的IPSec SA减少了设备性能资源的占用，提高了VPN网络的可靠性。
我们仍然以一个实际的应用场景来学习IPSec+GRE的应用：
企业总部为Hub，各个分支站点为Spoke，设计IPSec VPN满足如下要求 ? Hub和各个Spoke之间有一条GRE隧道，各个Spoke之间没有GRE隧道。 ? Hub内部的私网和各个Spoke内部的私网通过GRE VPN通信，并且通信收到IPSec
2006-04-13
华为三康机密，未经许可不得扩散
第12页, 共26页
文档名称IPSec VPN应用 文档密级
的保护。各个Spoke私网之间不需要通信。
? 各个Spoke内网主机不能访问Internet，Hub内网主机可以访问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
图3 IPSec+GRE VPN
假定我们首先采用静态路由的方式完成该场景，Hub的相关配置如下 interface Tunnel0
ip unnumbered Ethernet4/0 tunnel source 9.1.1.22 tunnel destination 9.1.1.130 interface Tunnel1
ip unnumbered Ethernet4/0 tunnel source 9.1.1.22 tunnel destination 9.1.1.134 interface Tunnel2
ip unnumbered Ethernet4/0 tunnel source 9.1.1.22 tunnel destination 9.1.1.138
2006-04-13
华为三康机密，未经许可不得扩散
第13页, 共26页
文档名称IPSec VPN应用 文档密级
interface Tunnel3
ip unnumbered Ethernet4/0 tunnel source 9.1.1.22 tunnel destination 9.1.1.142 interface Serial1/0:0
ip address 9.1.1.22 255.255.255.252 ipsec policy gre interface Ethernet4/0
ip address 10.1.0.1 255.255.255.0 #定义访问各个Spoke的出口为GRE接口# ip route 10.0.64.0 255.255.255.0 Tunnel0 ip route 10.0.65.0 255.255.255.0 Tunnel1 ip route 10.0.66.0 255.255.255.0 Tunnel2 ip route 10.0.67.0 255.255.255.0 Tunnel3 ip route 0.0.0.0 0.0.0.0 9.1.1.21 acl num 3111 #for spoke1
rule 0 permit ip source 9.1.1.22 0.0.0.0 destinationt 9.1.1.138 0.0.0.0 acl num 3112 #for spoke2
rule 0 permit ip source 9.1.1.22 0.0.0.0 destinationt 9.1.1.146 0.0.0.0 acl num 3113 #for spoke3
rule 0 permit ip source 9.1.1.22 0.0.0.0 destinationt 9.1.1.130 0.0.0.0 acl num 3114 #for spoke4
rule 0 permit ip source 9.1.1.22 0.0.0.0 destinationt 9.1.1.142 0.0.0.0 (IKE Peer和IPSec Policy配置略) Spoke2的相关配置如下 interface Ethernet0
ip address 10.0.65.1 255.255.255.0 interface Tunnel0
2006-04-13
华为三康机密，未经许可不得扩散
第14页, 共26页
文档名称IPSec VPN应用 文档密级
ip unnumbered Loopback1 tunnel source 9.1.1.134 tunnel destination 9.1.1.22 interface Serial0
ip address 9.1.1.134 255.255.255.252 ipsec policy gre
ip route 9.1.1.20 255.255.255.252 9.1.1.133 ip route 10.1.0.0 255.255.255.0 Tunnel0 acl num 3111
rule 0 permit ip source 9.1.1.134 0.0.0.0 destinationt 9.1.1.22 0.0.0.0
上面的配置中，由于Hub上定义了缺省路由，因此Hub内部的私网可以通过隧道分离的方式访问Internet(当然前提是必须配置NAT)，而Spoke1则只定义了到达Hub公网和私网地址的静态路由，因此Spoke1内网主机不能访问Internet，同时，Spoke1也没有到达其它Spoke私网的路由，因此各个Spoke之间也不能够互访。
如果采用动态路由的方式完成上面场景的目标，则动态路由的选择上必须要考虑全面。如果在各个Spoke和Hub之间启用动态路由协议，那么Hub会学习到所有Spoke的私网路由，同时，所有的Spoke不仅可以学习到Hub的私网路由，还会通过Hub学习到其它Spoke的路由，当Spoke1和Spoke2之间存在了指向Tunnel接口的路由以后，Spoke1和Spoke2之间就会通过IPSec保护的GRE VPN互通，请注意我们是以Spoke1-Hub的GRE起点和终点的地址为保护的流，而不管GRE内部的报文的初始地址，因此无法用要保护的流来控制报文的走向，只能通过路由来控制。
解决这个问题的方式是采用路由过滤的方式，Hub向Spoke发送路由时只发送自己私网的路由，而不发送其它Spoke私网的路由。采用路由过滤就意味着这种情况下不能够使用联络状态算法的路由协议(OSPF/IS-IS)，因为这些路由协议的路由过滤是无法过滤LSA的，只能够采用距离矢量算法的路由协议，如RIP等。
在这个例子里我们选择RIPv2作为路由协议，并且在Hub设备上定义路由过滤策略。 值得注意的是为了保证GRE隧道的建立，各个设备首先必须配置静态路由来完成安全网关公网地址的可达性。
2006-04-13
华为三康机密，未经许可不得扩散
第15页, 共26页