OpenVPN中TAP-win32d的net30问题

OpenVPN中有个topology参数，该参数控制了tun模式下如何为OpenVPN客户端分配虚拟IP地址。在OpenVPN的manpage中，明确指出tun模式下对于windows平台不能使用p2p拓扑，有人说这是没有必要的，因为从TAP-win32的“字符设备”(姑且这么叫吧)中取到的数据包中是一个完整的以太帧，如果是tun模式，截去以太头即可，为何要专门为windows的tap-win32网卡单独划分一个30位掩码的子网呢，这是没有必要的啊！
理论上，是没有必要的，然而tap-win32并不仅仅是openvpn的一部分，它只是一个单独的虚拟网卡的驱动程序而已，因此openvpn必须迎合tap-win32，而不是反过来。我们知道，windows平台上的tap虚拟网卡需要DHCP机制来分配IP地址(也可以不用DHCP，但是这就交叉到了另一个问题：用什么机制设置IP地址的问题)，这个DHCP服务器实现在TAP-win32驱动中，且必须有一个IP地址，而这个IP地址也是需要OpenVPN服务器推送下来的。tun模式下对于三种拓扑，OpenVPN推下来的IP如下：
net30：ifconfig 客户端虚拟IP 客户端对端
p2p：ifconfig 客户端虚拟IP 服务器端虚拟网卡IP
subnet：ifconfig 客户端虚拟IP 客户端虚拟IP掩码
对于net30拓扑，服务器一下子推下来4个地址，该4个地址构成一个30位掩码的子网，因此DHCP服务器的地址可以设置成“IP 客户端对端”，不会和任何地址冲突；对于subnet，默认子网全0地址作为DHCP服务器地址，另外还可以通过ip-win32参数来控制，其实就是选一个没有用过的只是本地有效的即可。下面来看看p2p的情景，OpenVPN在p2p拓扑时会把服务器虚拟IP推送下去，而tap-win32却不能使用这个地址作为DHCP服务器的地址，因为这会造成地址冲突，找一个别的可以么？可以，但是找哪个呢？因此tap-win32网卡不能使用p2p拓扑。
这一切在OpenVPN的代码中都有体现，在do_ifconfig中，有以下逻辑：

#elif defined (WIN32)
      {
        /*
         * Make sure that both ifconfig addresses are part of the
         * same .252 subnet.
         */
        if (tun)
          {
            verify_255_255_255_252 (tt->local, tt->remote_netmask);
            tt->adapter_netmask = ~3;
          }
    …
}

注意看注释。而verify_255_255_255_252函数的实现中有如下代码：

if ((local & (~mask)) != (remote & (~mask)))
    {
      err = "must exist within the same 255.255.255.252 subnet.  This is a limitation of --dev tun when used with the TAP-WIN32 driver";
      goto error;
    }

这就要求，tap-win32的DHCP服务器的地址必须和tap-win32的虚拟地址在同一子网中(这难道不是DHCP的基本点么？~~)，使用p2p拓扑，满足了这个要求，然而DHCP服务器的地址怎能设置成OpenVPN服务器的虚拟IP地址呢？这难道不乱了么？乱了，彻底乱了！
不光在代码中，manpage中也有相关说明，具体看topology和ip-win32之dynamic章节，这里就不粘贴了。
以上就是windows上不支持p2p拓扑的原因，很多人都有这样的疑问，我要说的是，每当你为一些细节绞尽脑汁不知其所以然时，那么请正确划分问题的边界。在这个问题中，其实并不是tap-win32绝对不能用p2p模式，而是要照顾OpenVPN实现的一致性，服务器端就是那么推送地址的，客户端就只能接受，或许你为了让tap-win32支持p2p模式，可以自行配置客户端的虚拟IP地址和DHCP服务器地址，或者干脆改了OpenVPN或者TAP-win32的实现，这除了可以加深对OpenVPN的理解之外，没有其它更大的意义，很多概念是没有为什么的，这类问题的答案很大一部分是历史问题，要么就是为了设计方便而进行的规定。