6.7 虚拟成分之间的互联
Cisco防火墙
在上文中分析了虚拟成份的一些基本行为，下面我们开始介绍它们之间的互联方式。
6.7.1 将VRF与外部路由器互联
VRF互联的标准方式是使用外部路由成份。在图6-11中，路由器R1就是这样的外部设备。虽然6500B上的每个VRF都有一条穿过R1指向汇总地址172.20.0.0/14的静态路由，但是R1知道每个VRF所连接的网络。
例6-17使用了图6-11所示的拓扑，并提供了下述细节。
例6-17 使用外部路由器连接VRF
6500B上每个VRF的静态路由。
R1上的路由表通过网关172.21.1.1指向主网络172.20.0.0/16（受VRF VPN1的控制）。R1不是VRF可感知的，因此它会将6500B上的VRF VPN1当作一台常规的路由器。
在VRF VPN1上向位于VRF VPN3上的主机172.23.100.100发起traceroute测试。该案例显示了R1（172.20.1.2）为该路径中（3层）的一跳。
6.7.2 两个没有共享接口的虚拟防火墙互联
两个没有共享接口的虚拟防火墙互联与（上文刚刚介绍的）两个没有共享接口的VRF互联类似。图6-12所示为两个基于ASA的虚拟防火墙之间，通过外部路由器EXT进行路由转发的拓扑。
在该方案中，如果有去往主机H2的数据包到达虚拟防火墙C1的inside1接口，它就会通过EXT进行路由。同样，如果有去往主机H1的数据包到达虚拟防火墙C2的inside2接口，它就会通过out2接口被转发给网关EXT。
6.7.3 共享一个接口的两个FWSM虚拟防火墙互联
将共享一个接口的两个FWSM虚拟防火墙互联起来还是存在一定的问题。图6-13所示即为这类方案的参考拓扑。在该图中，接口VLAN 1242同时分配给了CR1和CR2这两个路由模式的虚拟防火墙例。6-18是以图6-13为基础设计的方案。其中R0与虚拟防火墙CR1上的VLAN 1240相连，而R1则与虚拟防火墙CR2上的VLAN 1241相连。R0需要使用静态路由穿越CR1到达路由器R2（与VLAN 1242上的共享接口相连），同样，R1也需要CR2来充当自己的网关。
对于从外部（VLAN 1240或1241）发起的连接，FWSM会根据数据包的源接口来执行数据包分类。从VLAN 1240到达FWSM的数据包会由CLASSIFIER1映射到CR1，因为该接口是虚拟防火墙CR1中的接口。同样，通过VLAN 1241到达FWSM的数据包则会被指派给CR2，因为该接口属于CR2这个虚拟防火墙。
到现在为止，一切正常。但是当流量从相反的方向发来（或者说，从与VLAN 1242上的共享接口相连的主机发来）时，这个环境就会遇到上文中提到的挑战。如例6-18所示，从R2发往R1的ping数据包无法通过FWSM，因为CLASSIFIER2无法判断出应该将该数据包分配给哪个虚拟防火墙。出现这种情况一方面是因为这两个虚拟防火墙都不认为自己拥有该ping数据包的目的地址，同时也是因为VLAN 1242是CR1和CR2共享的接口，于是设备就无法再根据源接口来执行分类了。
例6-19也使用了图6-13中所示的拓扑，同时应用了例6-18所示的配置。在这个方案中，虚拟防火墙CR2使用静态NAT来处理dmz1接口（VLAN 1242接口）上看到的地址172.16.241.10（该地址位于outside接口）。通过这种方式，CR2就会认为自己具有地址172.16.241.10；于是从R2发往R1就数据包就可以穿过FWSM了（这就相当于NAT给CLASSIFIER2进程帮了个忙）。
虽然如上面的示例所示，配置NAT可以解决例6-18中的问题，但是这种方法不能解决所有潜在的问题。据此，我们不妨通过下面几点来总结一下FWSM的行为。
FWSM在所有接口上使用的都是同一个全局MAC地址（如需查看这个地址，请参考例6-11中命令show interface的输出信息）。例6-18介绍了共享接口带来的问题。既然多个IP地址对应同一个MAC地址，那么路由器如何才能将数据包发送给某个给定网络的IP地址呢？这个公共MAC地址经常会从一个VLAN接口移动到另一个VLAN接口，因此也会导致Catalyst上的桥接表出现变化。
如果数据包到达的接口属于多个虚拟防火墙，那么设备在分类时就会根据目的地址执行查找，因此设备也就必须掌握每个虚拟防火墙身后的子网。为了实现这个目的，分类器就需要借助活动的NAT会话（而不是路由表）。如例6-18所示（方案参照图6-13），仅仅在R2上配置静态路由还不够。只有在添加了相应的NAT语句之后，R2才能成功穿越FWSM向R1发送数据包。
从虚拟防火墙CR1的dmz接口（172.16.242.22），发往虚拟防火墙CR2 dmz1接口（172.16.242.50）的数据包，永远也不会离开设备。比如，即使能够在位于VLAN 1242上几个FWSM地址之间成功进行ping测试，接收端也不会看到这些数据包。
图6-13显示了R0有一条去往R1（172.16.241.10/24）的路由指向CR1，同时R1也需要通过CR2到达R0（172.16.240.10/24）。该图也显示出了CR1和CR2上分别指向R1和R0的路由（它们均以共享接口另一端的地址作为网关地址）。除了上述内容之外，CR2不能穿越CR1到达R0。因此R1也不能穿越CR2与R0建立联系。同样，R0也不能穿越CR1到达R1。这是因为FWSM不能对从共享接口一侧发往另一侧的数据包进行分类。
当共享接口与外部（通常就是Internet）相连时，由于内部的目的地址是可控的，也是已知的，因此在这种方案中，通过配置NAT来建立虚拟防火墙之间的连接是可行的。相反，共享内部接口的方案中，由于外部地址不受限制，因此采取NAT的变通方法就会遇到困难。
如果让虚拟防火墙工作在透明模式下，那么需要为其分配唯一的接口。因为源接口经常会被用作数据包分类的标准。
注释上述例子（在一张图中）使用CLASSIFIER1和CLASSIFIER2只是为了说明源接口或目的接口都可以作为数据包分类的标准。实际上，分类软件模块只有一个。
注释本书的第8章将会用一整章的篇幅来介绍ASA防火墙上的NAT功能。
6.7.4 共享一个接口的两个ASA虚拟防火墙互联
有一个特性可以让ASA接口共享的方案具备FWSM所不具有的优势，那就是管理员可以在每个虚拟防火墙上分别为共享接口配置不同的MAC地址。这项任务需要在接口配置模式下输入命令mac-address来实现。实现该功能的另一种简单做法是在系统执行空间的全局配置模式下输入命令mac-address auto。
图6-14所示为图6-13方案的ASA近似版。在这个拓扑中，接口G0/1.1222是虚拟防火墙LAB5和LAB6的共享接口。
例6-20参考了图6-14中所示的拓扑，并显示了接口G0/1.1222的源MAC地址中，最后4个十六进制数在虚拟防火墙LAB5和LAB6上分别被修改为了5555和6666。这种方案与FWSM操作方式还具有以下几点重要差异。
从LAB6接口地址发送的ping测试会穿越虚拟防火墙LAB5，成功到达172.16.221.11（R1）。
从172.16.220.10（R0）发送的ping数据包会将LAB6作为网关，并在穿越虚拟防火墙LAB5后，最终到达172.16.221.11（R1）。
管理员甚至可以向172.16.221.11执行traceroute测试，并进一步找到数据包到达该目的地址所依次经历的3层设备。至于如何让ASA将自己显示为traceroute测试中的一跳，将在本书的第7章中进行详细的介绍。
例6-20中的各种测试都显示了，选择唯一的MAC地址是避免虚拟防火墙接口共享问题的最有效手段。
例6-20 在ASA上通过配置静态NAT地址实现数据包分类