BadVPN详解之--题外话:我之前自研的一个设计

说实话，这个与BadVPN无关，是我去年年初时想的一个东西，只是觉得与BadVPN类似就单列一篇文章来说，在看到BadVPN之前，我一直都想用这个思路来重构OpenVPN，无奈场面过于宏大，加之工作又再也与VPN无关，就一直搁置了，现在知道了有BadVPN这个东西，我也就再也没有必要去想这个事了，就当是个了结吧。我把我去年自研的基于OpenVPN的重构思路在本文中阐述一下，本文中我把我的这个VPN叫做ZyVPN，其实它是基于OpenVPN改的。

总览

有了前面对BadVPN和OpenVPN的介绍以及比较，我在介绍我的ZyVPN时就简单多了，因为我的这个版本可以看成是从OpenVPN到BadVPN的过渡版本。当然也可以看成是一个OpenVPN的Bugfix版本，属于那种见招拆招的方案，主要是为了解决主从模式的OpenVPN点对点对等组网问题。
       参照Cisco EzVPN的思路，ZyVPN引入一个控制节点，负责接入控制，地址分配，路由推送，策略推送，地址学习Cache等，这个控制节点其实就是去掉了数据通道支持的OpenVPN服务端，数据通道被彻底分离出来，这也降低了OpenVPN的协议设计复杂度，可是说是OpenVPN的成功瘦身减负。ZyVPN总框图如下所示：

可以看到，中心节点已经不再承受数据。

ZyVPN的三张表

BadVPN中有两张表，分为控制节点的接入表和VPN子节点的邻居表。ZyVPN里也一样有这两张表，这个跟BadVPN几乎完全一致。它们的结构和相关过程如下，我依然用A，B，C三个节点接入的情景来展示：
A接入VPN网络：

B接入VPN网络：

C接入VPN网络：

控制中心依靠这张表来帮各个子节点建立邻居表，这个和BadVPN一样，不再多说。

       本地邻居表在结构上和BadVPN也是一致的，但是在用法上和BadVPN的还是有区别的，在BadVPN中，子节点依靠以太帧的MAC地址和节点ID的关系来判断这个帧要发给谁：

这个表类似交换机的MAC/端口映射转发表。我们考虑一下如果以帧的目标MAC作为查找键在这张表中查找，要是找不到会怎样。BadVPN的做法是往所有的节点FLOOD这个数据帧。
       这确实是一种合理的方式，以太网交换机就是这么做的，但是BadVPN构建的只是一个虚拟的二层网络，它事实上是Ethernet over UDP的，虽然FLOOD方式很合理，但这优雅吗？无论怎样，即便不优雅，这就是BadVPN的处理方式，作者肯定会给出他之所以这么设计的理由，而我的ZyVPN则采用了一种完全不同的方式来对付此事。
       我引入了一个Cache层，这就是第三张表，即控制中心的中心邻居表，出现查找本地邻居表未果时，将帧发给控制中心，由它来决定该如何做。
       我的理由是，尽量避免在规模比较大的网络上进行FLOOD，而我们知道BadVPN，ZyVPN可以构建于任意规模的TCP/IP网络之上。所以说，我希望引入一个新的Cache层，试图减缓FLOOD对带宽带来的冲击。最终ZyVPN的三级Cache体系的逻辑就是：
1.首先查本地的邻居表
2.如果邻居表找不到就发往控制中心，查找中心邻居表
3.控制中心的中心邻居表也没找到再由控制中心来FLOOD(FLOOD的数据帧要加上FLOOD标记，以便反向数据帧副本发挥控制中心供其学习)
4.返回的结果首先返回给控制中心，控制中心学习其到中心邻居表
加入了控制中心的邻居表这个Cache层之后，将会大大减少FLOOD的数量。
       下面是一个情景分析：

仔细想想，是不是SDN也是这个理儿呢？答案是肯定的。当数据匹配不到流表项的时候，控制器就要来做决定。
       打住！当你看了上面的情景分析后，可能会有个疑问。A怎么可能往MacX发数据而不知道它在节点C呢？数据帧发送前不是有个ARP过程，ARP回应时，照理说A就应该能学习到MacX了吧？！确实这是事实，但是我上面的分析仅仅是举一个例子，不是通用场景，要知道ARP和邻居表并没有必然的关联，也并不是说邻居解析一定会有ARP，比如静态配置的IP/MAC映射怎么办？

ZyVPN与BadVPN的其它不同

我这个ZyVPN本质上还是从OpenVPN改来的，还带着OpenVPN的影子，比如：

1.ZyVPN依然支持TAP和TUN两种组网方式

而BadVPN则直接去掉了TUN的支持，这样BadVPN节点之间就构成了一个大二层的VPN虚拟网络。

2.ZyVPN依然支持控制节点向子节点的推送机制

BadVPN不支持推送，也就是说所有的关于虚拟子网的任何配置都要在各个子节点上一一各自配置，我们也可以看出，BadVPN的TAP网卡的配置并非是BadVPN的一部分，需要你自己来配置。这些也许是BadVPN的一个使用上的限制，然而增加策略推送机制并不是什么难事。

英雄所见略同？

我不敢说自己的本事有多大，但事实证明我的ZyVPN和BadVPN非常类似，我只是编程编的不好，所以我只能基于现成的OpenVPN来修改，让我用自己的代码把自己的设计重新来写，我没那能力，所以我还是借力了OpenVPN...
       但不管怎样吧，在设计上，我的思路与BadVPN出奇的一致，而且我的降Flood的中心邻居表要比BadVPN更酷，至少我个人是这么认为的。我现在的问题是，为什么我的ZyVPN和BadVPN这么像？其实原因很简单，因为正确的道路往往只有一条，引用《安娜.卡列尼娜》里说的那句经典：幸福的人都是相似的,不幸的人各有各的不幸。唉，这句话在我们中国人眼里就变成了英雄所见略同。其实与英不英雄，是不是猛士无关，即便草根走在正确的道路上，那也是一条正道。