xFsRedir程序2021年09月更新（进一步扩展虚拟局域网和代理功能）

Posted 2022-11-24 雨中风华

                                     by fanxiushu 2021-09-30 转载或引用请注明原始作者。
其实xFsRedir项目的开发的文章也是一个系列，而且持续的时间比 xdisp_virt 项目更久，
只是文章的标题取得有点乱七八糟的， 容易让人看不出来。

xFsRedir的本次更新主要集中在虚拟局域网和代理功能上。
主要包括：
1，修改驱动和应用层 ，用以支持不同网段的局域网组网的功能，
2，修改驱动和应用层，调整和扩展NAT路由以及网络代理功能。
3，修改应用层，支持UDP和P2P传输，主要用于虚拟局域网的隧道传输部分，
      在UDP打洞成功，可以支持P2P点对点传输时候，减少虚拟局域网数据包转发的服务器压力。
4，修改驱动和应用层的BUG，同时调整程序界面。

以上看起有些繁多和杂乱，功能的升级本来就是不断完善和修补的过程。
本文就以比较典型的，跨区域的不同网段的局域网如何组网，以及应用层采用P2P传输虚拟局域的网数据包做重点讲述。

在上一篇的文章中，简单讲述过什么是不同网段的局域网组网功能。
其实就是在不同地区，甚至是不同国家，不论是在公司，还是在家庭中，还是各行各业的其他什么地方，
都会存在各种各样的局域网，因为现在是信息社会，我们的生活与网络是分不开的。
这些局域网都是各行其是，利用NAT路由，接入到internet公网。但是这些局域网之间的互联互通，就是一个大问题。
正如上文所述的，比如各个分公司的内网需要互相连通，但是因为在不同地区，是没办法直接使用路由器连接起来的。
其中一个办法就是利用internet公网，建立一条通讯隧道，让这些局域网互相连通。

如何让这些不同地区的不同网段的局域网连接起来，就好像是直接使用路由器连接起来一样呢？
其实从原理上来说，并不算太难。
既然是不同地区，无法直接使用路由器连接，那我们就把路由器给 “延长了”，
这感觉像不像是远程USB设备的访问，也是把USB设备 ”延长了“ ！
只是USB设备的“延长”更复杂而已。

我们先来看看不同网段的网络如何通过路由器进行通讯
（为了容易理解，举个简单例子，阅读需要有基本的网络基础知识）。
A网段:  192.168.1.0 MASK 255.255.255.0 , 网关地址是   192.168.1.1     网关取名 Agw
B网段：192.168.2.0 MASK 255.255.255.0，网关地址是   192.168.2.1    网关取名 Bgw
A和B两个网段是直接使用路由器连接起来的，这样的话，Agw 和 Bgw 都直接在这个路由器中。

现在A网段的 m设备192.168.1.10， 想要和B网段的n设备192.168.2.100 通讯，
m设备发给n设备的数据包会发往A网段的网关 Agw 192.168.1.1， 于是路由器根据路由规则，把数据包转发给 Bgw 网关，
Bgw 网关再把数据包发往 n设备。反过来n设备发送数据到m设备，也是同样道理。
这样m和n设备就能互相通信了。

现在我们再来考虑A网段和B网段不能用路由器直接连起来的情况，也就是Agw和Bgw不在同一个路由器中，
如何建立起一个 “无形的线缆”，把Bgw和Agw关联起来呢？
当然Agw和Bgw网关要能互相连通，他们彼此能互相通讯。
最通用的就是都连接到internet公网上，Agw和Bgw都连接到一个公网服务器。

m发给n的数据包，同样会发往 Agw 网关，我们在这个网关中实现一个程序，拦截到发往B网段的数据包。
然后封装处理一下，发给Agw连接的公网服务器，公网服务器再把数据发给Bgw网关，
Bgw网关中的程序接收到这个数据包，然后解包，再然后通过Bgw网关把数据包发给n机器，
反过来，n机器发往m机器的数据包也是同样的原理。
这样， m和n在不能互相用路由器连接的A网段和B网段的网络环境下，也能互相通信了。

这个就是通过公网建立隧道，让不同网段的局域网互相访问的原理。其实并不复杂。
我们也能找到好些集成这种功能的路由器硬件，在路由器中集成这种”隧道“功能也不是什么难事。
不过需要提供专门的公网服务器，这也是生产这种功能的路由器厂商应该考虑的事。

还有一部分需求，就是不通过集成到路由器硬件来实现这样的功能，就像xFsRedir这样的软件来实现组网功能。
因为软件不是运行在路由器设备上，
但是m机器发往n机器的数据包，肯定是会被转发到Agw网关的，这是网络通讯的基本属性决定的。
因此，我们只好在Agw网关上手动添加一条静态路由策略（路由器都支持手动添加静态路由的）
大致伪命令如下（因为不同路由器有不同添加脚本，下面命令理解其中意义即可）：
route add 192.168.2.0 mask 255.255.255.0 gateway 192.168.1.55
意思就是在Agw网关中添加这样一条静态路由：
凡是目标地址是发往网段192.168.2.0，也就是B网段的数据包，
都会被Agw再次转发到 192.168.1.55 这个地址上。

这样，192.168.1.55 机器就会接收到m机器发给n机器的数据包，
我们在192.168.1.55 这个机器运行我们的程序，比如xFsRedir。
然后截获到这个数据包，封包处理一下，发给公网服务器。
同样的，B网段，也需要做类似操作，假设B网段同样的添加路由策略到 192.168.2.50 这个机器上。
192.168.2.50 也运行xFsRedir程序，也连接到公网服务器，公网服务器就会把m机器发给n机器的数据包
转发到 192.168.2.50 的xFsRedir程序中，xFsRedir程序再把这个数据包解包处理，
然后直接发给处于同一个网段内的n机器。
于是m和n通过这种绕来绕去的迂回战斗策略，再次又能互相通信了。

下图是使用xFsRedir软件组网的一个例子：


这个图可能有点看不明白，
最左边的是 网段 192.168.81.0的机器，在上面配置xFsRedir 设置的当前网段就是 192.168.81.0
图的中间是我笔记本电脑上的xFsRedir的配置，xFsRedir被当成NAT路由器，左边的vmware系统的macOS，
设置的网关就是我笔记本电脑，因此xFsRedir在这里充当NAT路由和组网双重角色。
可以看到，成功组网之后， macOS系统里已经可以成功ping通  192.168.81.132地址，也就是图中最左边的winserver2012系统。

只是看这个图的解释，可能让你感觉不实在，有兴趣可以去GITHUB下载最新版本使用。
本文对应的xFsRedir版本是 5.5

在上图中，我们还能注意到一个复选框选项;
"使用UDP转发，如果UDP打洞成功开启P2P点对点传输" 这么一个功能，这个就是下面将会讲述的内容。

其实原本开发xFsRedir的的虚拟局域网功能的时候，是没打算实现P2P打洞传输的。
只是后来去购买云服务器，他们提供的带宽实在小的可怜，比如1M带宽的，2M带宽的，
再有可以提供很高带宽，但是那种价格实在不是普通人能承担的。
这么小的带宽，如何能负担得起中转数据包，局域网通讯，动不动就是几M几十M的数据。
实在没办法，就只好实现P2P打洞功能传输的功能。

关于P2P传输，其实网上的资料比较多，P2P传输以UDP协议为主。
关于P2P评价，其实有好有坏。
如果作为提供流量服务的运营商，是很讨厌P2P的，因为大部分流量不会通过服务器，
而且还会无形中让主干网承担大量的流量传输，很不利于TCP这类主要协议的传输。
可以形容成P2P是网络传输中的流氓，它只会让拥塞的网络更加拥塞。
因此有些运营商实际是对UDP做了某种减速的QOS，更有甚者，直接阻断UDP传输。

UDP如何能成功打洞，取决于NAT路由设备的种类。
这里也不再深入讲述哪些种类的NAT设备有利于UDP打洞。

这里所谓的UDP打洞，其实就是建立起处于NAT后面的设备能使用UDP协议直接通讯的一条通道。
因为NAT的特性。处于NAT后面的机器，外面的网络是无法直接访问的，只有当NAT后面的机器主动发起通讯请求，
然后在NAT中留下一条短暂的连通记录，这样外面的机器根据这个短暂的连通记录，才能把数据发给NAT后面的机器。

现在要在NAT中建立起这么一个短暂的连通记录，就需要打洞这种行为。
虽然原理比较复杂，但是实现起来并不复杂。

简单的说，就是部署一个公网服务器S，
然后 处于NAT1 之后的 A电脑通过UDP 连接到 S服务器，
同样的，处于NAT2 之后的B电脑通过UDP也连接到S服务器。

当A想直接跟Ｂ进行UDP通讯， A就发一个命令告诉S服务器， S接着通知B，A想跟你直接联系。
然后A就开始不停的发送探测数据包给B，至于B的NAT2外网地址，A通过S服务器获取。
一开始A的探测包是被NAT2直接丢弃的，因为NAT2中没有A到B的这么一条记录。
直到B收到S的命令，B也开始发送探测数据包给A，这样NAT2就有了B到A的记录，
同时NAT路由器的实现中A到B和B到A是一回事的话，下次A的探测数据包就能直接通过NAT2传给B了。
同样的道理，A也是这么收到B的探测数据包的。
这么一来二去的，A和B就建立了 UDP传输通道，也就是打洞成功了。

至于说打洞成功与否，是跟NAT路由器的实现方式有直接关系的。
因为NAT路由的实现方式直接决定了探测数据包是否能成功。
就比如上面的打洞过程，如果B到A和A到B的记录是一回事，打洞就会成功。

P2P的这些原理解释的比较简单，有兴趣可以去查找相关资料，也有一个标准化的打洞协议叫STUN，有兴趣也可去研究。

xFsRedir底层实现的打洞是定义的协议，实现方式跟上面提到 A和B打洞过程基本一样。
同时因为xFsRedir的虚拟局域网传输的是底层的IP数据包，IP数据包是可以丢包和乱序的，
因此也用不着专门处理丢包和乱序这些问题，直接把IP数据包通过UDP封装发送就行了。
不过在做UDP传输的时候，考虑到IP分组会影响效率等问题，
是首先对TCP的SYN数据包修改了 MSS大小的，
把MSS改小，用于UDP封装的时候不过界（不超过MTU大小）。

本次xFsRedir的更新基本就介绍到这里，其实xFsRedir许多其他小更新也没讲述到，
如果有兴趣，可以去GITHUB下载最新版本使用：
https://github.com/fanxiushu/xFsRedir

本文对应的最新版本是 5.5 。