元旦那天出去玩,路上骑着自行车突然想起来之前自己在计划表里写通过IPv6传输IPv4单栈应用的TCP/UDP数据,这个想法实际上已经有协议实现了:DNS64配合NAT64实现IPv6 Client访问IPv4 Server,而此操作的主要难点需求就是具有一个IPv4和IPv6双栈服务器运行DNS64程序进行不同IP协议流量的转换。不过我想要的并不是以转发为解决方案,因为这会导致通讯带宽受到ISP限制,特别是在中国这种ISP向云服务用户“勒索式”收取高昂带宽费用的国家,有限的Server上行带宽显然不利于任何服务器转发式解决方案的开展。我当时的想法是,能不能通过IPv6 P2P客户端对仅支持IPv4的应用(比如Unturned)进行代理,实现IPv6下完成软件层的IPv4虚拟组网。换句话说,用IPv6实现游侠联机平台的功能。

组网方案总结

既然转发可行但是受限,我就想到P2P了,总结以下几种方案:

基于IPv4 组网:

难点需求:Server公网IP4地址

基于IPv6 组网:

难点需求: Server和Client均具有IPv6地址,前者必须是公网,后者即使有IPv6地址,也可能存在防火墙阻拦(但基于V6的STUN穿透成功率可能较于IPv4更高。)

目标需求

1.首选基于IPv6 P2P传输在用户本地构建IPv4虚拟专用网络,可设立配置服务器进行引导完成自动化。
2.对于不支持IPv6的客户端通过IPv4/6双栈公网Server进行地址转发完成通讯(高延迟,非硬性需求)
3.通过IPv4 P2P/转发进行组网(高延迟,非硬性需求)

已有的实现

Zerotier是较为知名的,不过我更看好其开源替代:tailscale (专有操作系统的GUI客户端和控制服务器不开源,但是Linux及其他Unixlike相对自由)以及自由的控制服务器替代headscale

折腾headscale一天了

发现最大障碍是宝塔面板这种毒瘤。我必须得早日切换到新的运作模式去。

🤔我意识到我并不需要tls加密混淆或者web控制面板等复杂的东西,所以我应该使用更轻量级且成熟的C语言项目:N2N
所以本文结束

标签: none

添加新评论