[开源测试]fknat去中心化内网穿透工具网络测试

FKNAT 第一阶段开测：现在真的可以拿来穿 NAT 了

上一篇帖子里，我花了比较多的篇幅介绍这个项目为什么会从一个**“去中心化存储的网络组件”**，逐渐变成现在这样一个开放的 P2P 网络。

当时其实更多还停留在：

架构怎么设计、节点怎么通信、流量怎么结算，以及这个东西以后到底应该往哪里走。

这一段时间又填了不少坑，现在终于到了一个我觉得可以正式开启 第一阶段折腾 的时候了。

不过在开始之前，有一件事情我还是想放在最前面，而且这件事情以后也不会变：

FKNAT 不论发展到任何阶段，项目方都不会引入任何货币充值、法币兑换、Token 交易之类的机制。

现在 CA Web 里面看到的所谓 “流量额度”，它就是这个网络内部用于使用网络资源和结算网络贡献的资源额度。

你提供 Relay、带宽等网络资源，可以获得额度；

你使用别人的网络资源，则消耗额度。

我希望以后形成的是：

提供网络资源 → 获得流量额度 → 使用网络 → 额度继续流转

而不是：

充值 → 买币 / 买流量 → 提现 → 炒价格

所以如果你是冲着：

“这项目以后会不会发币？”

或者：

“跑节点能不能赚钱？”

来的，那这个项目大概率不适合你。

但如果你和我一样，对 P2P、NAT 穿透、去中心化网络、分布式系统这些东西感兴趣，那现在终于可以开始实际折腾了。

目前第一阶段能干什么？

先不讲那些特别宏大的东西。

现在最直观的功能其实非常简单：

把一台 NAT 后面的机器上的服务，通过 FKNAT 网络提供给另外一台机器访问。

目前用户节点分成两个角色：

Server 和 Client。

例如我家里有一台机器：

家中 Server
192.168.1.100
    │
    └── 127.0.0.1:8080
            │
            └── Web / SSH / API / 其他 TCP/UDP 服务

这台机器没有公网 IPv4，甚至可能处在运营商 CGNAT 后面。

另外我有一台 Client。

正常情况下：

Client
   │
   X
Internet
   │
   X
家中 Server

没法直接连。

现在可以让两边都接入 FKNAT：

Client
   │
   │ 本地监听 :29200
   ▼
FKNAT Client
   │
   ▼
Relay / P2P Network
   │
   ▼
FKNAT Server
   │
   ▼
127.0.0.1:8080

于是对于 Client 上的程序来说，它根本不需要知道后面发生了什么。

它只需要访问：

127.0.0.1:29200

FKNAT 会负责找到对应的 Server，并把这条连接送到 Server 后面真正的服务。

目前已经支持 TCP / UDP，Server 也可以配置多个转发目标。

换句话说，现在它已经不只是上一篇帖子里的那张“架构图”了。

这套链路是真的可以跑起来了。

那怎么开始？

目前第一阶段我还是保留了中心化 CA。

原因上一篇已经解释过：

现在如果直接把身份、准入、结算全部放开，我估计大家还没开始玩，我就得先开始研究网络到底是怎么被薅爆的了。

所以目前所有参与网络的节点，都需要通过 CA Web 获取对应的扣费授权密钥。

CA Web

https://ca.fknat.top/

目前注册暂时采用注册码邀请制。

主要不是为了搞什么饥饿营销，而是因为：

注册码自动分发站我还没写完。

所以这一帖我先直接放 10 个体验注册码：

careg_814edd19b755f45d966df39c2e7b5d202c3fcfbfa4c4686d5c0c5b30f5cd5bf5
careg_69016d12fec8844700bb8c216cd90ed493aec583522442fe87cc293dbb50010c
careg_1409d1ac9eeca34536289d6fea33420b69d28bb317ed4b19b256a35ae327f0af
careg_0e39261b909d0aa4f32f84b38b72e5811ca20cec9e7bfa3b77e8b5c4002d3893
careg_5459dc7c954c03ba3b82035b17e42b9294c699734c53b0428a0faebaf887024f
careg_d6feebe28d829ae4a450d49e606fd123f4d78c810a1807eda7d9a870c7f0e535
careg_4b7a3cf96f4ff5ba136be1d31f38a3c40bd89072473cc06123d017d3047a559f
careg_2660383ede3abde50ce470f8e586411f232ceb368d5e1f87d199d18fb3972412
careg_a9b3115ff60e2763b65c2bc7aee763492b2368b43c2f91af3e2b42b2568d3033
careg_6c8f7d55d9a83856f0f1a88326fdab523da221a39f41981a7555f77c520d06bf

先到先得。

用掉以后可以在评论区说一声，免得后面的人一直试。

等注册码分发页面写完之后，就不需要靠帖子手动发了。

注册以后要干什么？

登录 CA Web 后，可以生成一个扣费授权私钥。

这里稍微强调一下：

扣费私钥 ≠ NodeID ≠ 节点身份私钥

扣费私钥负责的是：

“这个节点产生的网络资源消耗，记到哪个账户上。”

而节点自己的身份文件，则负责保持 NodeID 稳定。

CA Web 在生成扣费密钥的时候，不会保存你的私钥明文，所以生成之后记得把 JSON 文件下载并保存好。

然后把它放到准备运行 FKNAT 的机器上即可。

FKNAT 的项目地址：

https://github.com/wangshiben/fknat

仓库里已经提供了完整的使用说明。

如果不想看一大串参数，也可以直接看里面的 快速上手文档。

实际使用其实比架构看起来简单很多

假设现在有两台机器：

机器 A：Server
机器 B：Client

Server 启动以后会得到一个稳定的：

NodeID

例如：

d9cd214c67cb673af861003155f43a12...

然后 Server 配置一个需要暴露的服务，例如：

TCP
127.0.0.1:3399

假设这个端口跑的是一个 HTTP 服务。

Client 这边主要需要配置：

目标 Server NodeID
        +
本地监听端口
        +
Server 对应转发目标

例如：

Client

0.0.0.0:29200
       │
       ▼
Server NodeID
       │
       ▼
Server
       │
       ▼
127.0.0.1:3399

配置完成之后，我直接访问：

http://Client-IP:29200

就可以访问到 Server 后面的 HTTP 服务。

整个过程中 Client 不需要知道 Server 的公网 IP，也不要求 Server 本身拥有公网 IPv4。

这也是这个项目最开始想解决的那个问题：

我知道我要连接哪个节点。

至于这个节点藏在哪层 NAT 后面、应该经过哪个 Relay、底层最终怎么建立连接，让网络自己去想办法。

Relay 也开放出来了

上一篇帖子里面，中继节点还是整个网络里比较抽象的一部分。

这一阶段 Relay Server 的发布包也已经准备好了。

Relay Server v.r.0.0.2

https://github.com/wangshiben/natp2p/releases/tag/v.r.0.0.2

Relay 的使用方式可以参考：

RELAY_USAGE.md

https://github.com/wangshiben/natp2p/blob/dev/RELAY_USAGE.md

不过这里提前打个预防针：

目前 Relay 的安装包还没有携带 Web 管理界面。

Web UI 正在写了。

所以现阶段如果你只是想体验 NAT 穿透，建议先从 FKNAT Client / Server 开始。

如果你本身就比较喜欢折腾网络，手上又刚好有公网服务器和闲置带宽，那也欢迎直接折腾 Relay。

但毕竟现在还是早期版本：

可能有 Bug，而且我甚至比较希望你们能帮我把 Bug 折腾出来。

这一阶段我真正想测试的东西

其实第一阶段我最关心的，并不是：

“到底能跑多快？”

速度当然重要。

但现在还有很多比速度更基础的问题需要验证。

比如：

不同运营商、不同 NAT 环境下到底表现怎么样？

电信 ↔ 电信
电信 ↔ 联通
移动 ↔ 电信
校园网
家庭宽带
云服务器
CGNAT
IPv4 / IPv6

还有：

Relay 挂掉以后，节点能不能正常恢复？

UDP 被限制以后，底层切换 TCP 的表现怎么样？

不同 RTT、不同丢包率情况下，长连接稳不稳定？

大文件连续传输几个小时以后，会不会出现莫名其妙的断流？

虽然上述几个问题我在单一NAT场景下验证过了，但是仍然不敢保证100%解决了，此项目长测和压测累计测试时长已超过20*24H，所以一般情况下还是可以用的

以及上一篇帖子之后我一直在考虑的：

如果网络里面出现大量恶意 Relay，注册成功以后就是不提供服务，整个网络还能不能正常找到那些真正愿意工作的 Relay？

这些东西很多不是我自己在几台 VPS 上跑测试就能测出来的。

真实世界那些乱七八糟的网络环境，反而才是这个项目现在最需要的测试场。

所以第一阶段，我希望大家怎么玩？

不需要刻意压测，也不需要专门准备什么测试环境。

你甚至可以单纯拿它：

穿一个 Web 服务
穿 SSH
穿 NAS
穿自己的 API
穿游戏服务器
穿家里的开发环境

然后正常用。

如果出现：

连不上

突然断了

速度奇怪

CPU 爆了

内存涨了

Relay 行为不正常

某个 NAT 环境死活穿不过去

Web 页面有奇怪的问题

这些对我来说反而都是很有价值的反馈。

特别是如果能附上：

系统
网络环境
Client / Server / Relay
复现方式
相关日志

那基本就是最舒服的反馈方式了。

最后

上一篇帖子最后我问的是：

“如果是你，你会拿这样的网络做什么？”

现在终于可以把这个问题稍微改一下了：

不用想象了，可以真的拿它去做点东西试试。

现在这个项目离我最开始设想的**“开放 P2P 基础网络”**还差得非常远。

CA 还是中心化的；

结算还是中心化的；

Relay 的信誉和抗女巫机制还在设计；

网络发现和调度策略也还有很多地方需要继续折腾。

所以这不是一个：

“项目做完了，欢迎大家来用。”

的帖子。

更像是：

“第一阶段的东西终于勉强能跑了，来几个人一起把它玩坏看看。”

如果它能在各种奇奇怪怪的 NAT、运营商 QoS、丢包、断网、Relay 故障甚至恶意节点环境下面依然活着，再来谈下一阶段的事情。

项目相关

FKNAT 用户节点：

https://github.com/wangshiben/fknat

natp2p / Relay 核心框架：

https://github.com/wangshiben/natp2p

natP2pSDK：

https://github.com/wangshiben/natP2pSDK

CA Web：

https://ca.fknat.top/

Relay Server v.r.0.0.2：

https://github.com/wangshiben/natp2p/releases/tag/v.r.0.0.2

Relay 使用说明：

https://github.com/wangshiben/natp2p/blob/dev/RELAY_USAGE.md

反馈 / 交流

Bug、使用问题、架构讨论，或者单纯想一起折腾，都可以加入 TG 群：

https://t.me/+lNZG80w0kSthYzMx

10 个注册码还是那句话：先到先得。

这次先看看——

第一批真正跑在别人网络里的 FKNAT，会以什么奇怪的方式挂掉。

先给大家磕一个了orz