这样，即便子节点处在NAT之后，依然可以建立正常的点对点互联，并且如果二者在同一个NAT后面，还可以建立直连互联，这真是强大！事实上，开奖，这种模式早就被我们使用了好多年，伟大的腾讯公司早就使用这种方式运作QQ了。难道QQ不是一种特殊的VPN吗？QQ是什么：

　　(1) QQ对等客户端双方加密通信；

　　(2) QQ自带打洞功能，处在不同NAT后面的客户端依然可以直接建立连接(若真不行，经由服务器中转是补偿方案)；

　　(3) QQ自带打洞功能，处在同一NAT后面的客户端可以不经NAT而直连。

　　3. 对协议设计的影响

　　BadVPN无需在协议中区分控制信息和数据，BadVPN是完全的带外控制，而不像OpenVPN那般的带内控制。

　　我们看看BadVPN的数据通道协议，即子节点之间互发数据的协议，非常简单。它经由下图所述的封装即可传输：

　　因为数据发给谁是“交换机查表”的结果，不会错的，所以无需在接收端进一步判断。接收端收到之后，可以信任一定是发给自己的(当然为了安全起见，还是要判断一下的，但这不是根本)。

　　这有点类似于全双工交换式以太网的运作方式，一条网线连接且仅仅连着两台设备，如果这条网线上有流量，那一定是这两台设备之间的流量，如果其中一台设备发出数据，那么接收端一定是网线另一端的设备，这就是点对点全双工通信。

　　除了数据通道不再需要中心节点中转，对于控制通道协议而言，我们依然可以看到这里解除控制和数据的耦合后的好处。仅举一例，即子节点之间的密钥协商过程。假设子节点A和B同时连接于中心节点X，当B节点接入后，B要和A之间建立SSL通道，这个SSL通道是SSL中的SSL，分为A到X以及X到B两段，如下图所示：

　　然后A和B之间的对称密钥就是在这两段的SSL通道中协商出来的。协商方式非常多，可以让A或者B随意一方生成一个密钥，经由A-X-B或者B-X-A的SSL通道传输给B或者A，也可以使用简单的DH算法来直接交换生成密钥，总之，就跟IPSec的IKE两阶段协商一个道理，第一节点通道要为第二阶段提供保护。

　　这种事情在OpenVPN就会非常复杂，因为在数据通道层面上，必须将整个控制通道分为不同数据通道的不同控制通道，而不是一个统一的控制通道，因此，对于OpenVPN而言，只能将两种通道彻底分开，然后依靠“类似深度包解析”的方式来判断哪个数据属于哪个通道的控制面还是数据面，从而导致了大量的冗余。这有点类似于数据库表的设计，要通过键沟通的方式来建立关联，而不是把所有数据都塞入一张复杂的大表中：

　　我说过，BadVPN是靠点对点的方式完成VPN通信的，那么完成这种通信的基础就是底层的TCP/IP网络，显然需要对五元组。和OpenVPN的理由一样，BadVPN建议使用UDP来作为传输协议以防重传叠加。但是即便是UDP，也要确定哪个4元组不是吗？是的。

　　对于在文章《BadVPN详解之编译与运行》（）中的“运行”一节，命令行中的ext-addr参数所指定的IP地址和端口就是VPN数据通信的IP地址和端口，也是上面图示中中心节点向新接入的子节点通告的既已经接入的子节点的IP地址和端口，这个元组是控制通道的元组。

　　与ext-addr参数不同的是，中心节点的listen-addr参数以及子节点中的server-addr参数均指代控制通道的数据通信元组。