2014年7月19日，周六。我好像发现了Linux net namespace是如此的简单好用，以至于我觉得可以用它来做模拟多OpenVPN客户端以检测VPN最大隧道容量的方案。只可惜，当时只是一个预研，且我的工作重点也不在此，只有搁置。
今年3月底，跑了一趟北京，跟人聊起了VPN最大隧道数的测试方案，姑且以OpenVPN为例吧，其实IPSec也一样。我是多么想取点精华，谁知对方也
是同样的想法，相视无比尴尬...回到上海，我也一直在思考这个问题，遍布天地的找啊找。经过同事的提醒，原来方案一直都在手边，就是使用net
namespace，多么简单易行的方案啊，自己曾经做过的事情怎么自己都忘了，多么痛的领悟。
如果我用一台4核心i5处理器，插4G内存，那么我可以在一台机器上模拟将近1000个客户端，即建立1000个net
namespace。这样需要十几台机器，就可以模拟上万客户端了。如果硬件再高大上一点，所需的机器数量还会进一步降低。这个测试方案中，你可以认为是
我在一台机器上创建了1000个虚拟机，但虚拟机创建以及运行的代价却极低，远远低于真正的虚拟机，因为这1000个“虚拟机”仅仅虚拟了必须要虚拟的东
西，其它的部分共享。
必须要虚拟的部分就是网络协议栈。
而这正是net namespace的用武之地。我的总体测试拓扑如下：
具体的配置可以参见《OpenVPN多处理之-netns容器与iptables CLUSTER》，只需要将单独的net ns以及veth的创建过程封装成一个内置循环1000次的脚本即可。但是还是有另外两点要说的：
1.难点
难
点不在net
ns本身，而在IP地址的规划。既然模拟了10000个OpenVPN客户端，那么就相当于拥有10000台独立的主机，如何分配以及管理IP地址并不是
简单得放开16位掩码那么简单。我自己折腾了两个多小时才搞定这种看似简单至极，做起来却风生水起的繁琐事。
2.非要用veth虚拟网卡吗
只能说veth只是一种看起来比较直接的方式，Linux内核2.6.26以来，增加了很多别的选择，特别是3.19以后。在下一篇文章中，我会详细描述，现在只是敢说，使用veth虚拟网卡这种方式，配置太复杂，效率也不见得很高。