计划：基于IPv6实现IPv4应用层组网

元旦那天出去玩，路上骑着自行车突然想起来之前自己在计划表里写通过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
所以本文结束