简述

今天我们来聊一聊VMware NSX的分布式防火墙DFW，本文提及的NSX，均指NSX for vSphere，即NSX-V，有关NSX-T的讨论，将在后续推出。

了解过NSX的朋友一定很清楚，NSX的管理平面、控制平面和转发平面是相互独立分离的。对于管理平面，大家比较熟悉的是vCenter和NSX Manager；对于vsfwd，可能就比较陌生。那么，这是个什么组件？与我们讨论的NSX分布式防火墙又有什么千丝万缕的联系呢？

在部署NSX解决方案的时候，其中有一个关键的步骤，叫Host Preparation主机准备。在这个阶段，NSX Manager通过vCenter的ESX Agent Manager Service(EAM)，以集群为单位，在每一台ESXi主机上安装一个叫做esx-nsxv的vSphere Installation Bundle(VIB)。

我们可以通过以下命令在ESXi安装的VIB列表中找到这条记录：# esxcli software vib list

这个小小的VIB会在ESXi的Kernal Space内核空间运行三个非常关键的模块，其中的vsip module就和我们今天所讲述的NSX DFW息息相关。

我们可以通过以下命令找到这个加载并运行的模块：# vmkload_mod -l

除此以外，esx-nsxv还会在ESXi的User Space用户空间运行一个名为vShield-Stateful-Firewall的服务，这就是我们所说的vsfwd。

我们可以通过以下命令验证这个服务是否运行：# /etc/init.d/vShield-Stateful-Firewall status

在了解了上述内容后，我们再回过头来看NSX的DFW原理图。

在ESXi用户空间运行的vsfwd，会和NSX Manager的TCP5671端口保持连接，用以接受NSX Manager下发的分布式防火墙规则。vsfwd通过Virtual Machine Communication Interface(VMCI)，与在ESXi内核空间运行的vsip module通信，vsip module会将接收到的分布式防火墙规则下发到对应虚拟机的虚拟网卡vnic上。

在VM虚拟机的虚拟网卡vnic和上联的虚拟机端口组之间，有一条隐性的链路，叫IO Chain。这条IO链上有很多插槽，其中Slot0-3，Slot12-15是VMware预留，Slot4-11提供给合作伙伴，NSX的分布式防火墙就作用在Slot2插槽。

举个简单的例子，当流量从VM向外转发时，会首先经过IO Chain的Slot2插槽，此时vsip module会根据应用在vnic上的规则进行匹配和控制，如果规则禁止转发，那么流量根本不会经过ESXi主机的上联物理网卡vmnic到达物理网络。由于IO链一直存在，除非特殊情况，否则虚拟机的迁移不会影响分布式防火墙生效。VMware NSX的安全无处不在，就是通过这种方式实现的。

下面，我们做一个简单的实验，来验证上文所说的内容。

1.验证ESXi的vsfwd，与NSX Manager的TCP5671端口保持连接

esxcli network ip connection list | grep 5671

2.我们开启一台ESXi虚拟机作为测试用例，该虚拟机共有6个vnic，其中vnic0和vnic1作为管理网络负载网卡，管理地址为172.20.5.53

3.管理员通过Web Client，添加一条防火墙规则，禁止所有到该虚拟机的流量

4.可以看到外部已经无法PING通该虚拟机

5.在承载该虚拟机的ESXi命令行，查阅并找到该虚拟机的网卡信息

summarize-dvfilter | more

6.可以看到该虚拟机一共有6块网卡，分别是eth0-eth5，同时分布式防火墙运行在每一块vnic与虚拟机端口组之间IO链的Slot2插槽

7.我们可以进一步查看作用在每一块vnic上的分布式防火墙规则集合

vsipioctl getrules -f 网卡名称
可以看到图中rule 1018就是阻止所有入向流量的规则，它被包含在规则集合domain-c80中

8.此时，我们通过命令停止ESXi用户空间运行的vsfwd

/etc/init.d/vShield-Stateful-Firewall stop

9.可以看到，即使我们停止了vsfwd，分布式防火墙规则依旧生效，我们还是无法PING通虚拟机

各位可以回顾一下，vsfwd只在接受并传达给vip module分布式防火墙规则阶段有参与，而VM流量能否通过Slot2，是由vsip module根据规则去处理，与vsfwd无关

10.那么，如果我们删除应用在vnic上的防火墙规则，结果又会如何呢？

vsipioctl vsipfwcli Override -f 网卡名称 -c “create ruleset 规则集合名称;”
有些版本，命令可能是# vsipioctl vsipfwcli -Override -f 网卡名称 -c “create ruleset 规则集合名称;”

11.我们发现，即使删除了eth0的防火墙规则，虚拟机依旧无法访问，这和我们之前的描述大相径庭，问题出在哪里呢？别忘了，承载该esxi-1a虚拟机管理网络的还有eth1，我们还需要删除应用给eth1的防火墙规则

12.可以看到，在删除eth0和eth1两块vnic的分布式防火墙规则后，外部终于可以PING通172.20.5.53，即esxi-1a的管理地址

这种方式可以用来解决vCenter被DFW屏蔽的情况，详情可以关注我好友，来自VMware张大大的公众号 NSX很可爱的

13.但是对于eth2-eth5，可以看到之前的防火墙规则依旧存在。只是esxi-1a虚拟机的管理流量不会经过它们的iochains，因此这些规则是否存在不会影响外界能否PING通172.20.5.53

14.我们保持vsfwd停止运行的状态，通过Web Client新建一条策略，允许任意源SSH访问esxi-1a

15.可以看到，虽然管理员添加并应用了该防火墙规则，但由于vsfwd未正常运行，因此ESXi虚拟机无法接受NSX Manager下发的规则，也无法将这些规则通过vsip module应用到对应的虚拟机，虚拟机vnic上的规则集合保持着之前空的状态

16.此时，我们重新启动vsfwd

/etc/init.d/vShield-Stateful-Firewall start

17.很快，我们就能发现原本可以PING通的esxi-1a虚拟机又不可达了，原因是防火墙策略重新下发并应用给该虚拟机后阻止了一切非SSH入向流量

18.通过命令行，我们可以看到这些变化

19.根据防火墙规则，外部是可以通过SSH访问esxi-1a的

怎么样，现在通过上文的论述和实验，大家对NSX的分布式防火墙是否有所了解了呢？
本文最后，特别感谢好友Coco，Eagle在工作和学习中对我的帮助，在与他们的交流过程中，学到了不少非常有用的虚拟化技术和项目经验。