作者因所在国家封锁WireGuard而寻求替代方案。虽然存在流量混淆工具如udp2raw和wstunnel，但会导致数据包MTU降低。作者希望找到更好的VPN解决方案来突破审查。

探索非传统Mesh VPN方案：从Wireguard封锁到替代工具实测

背景困境

作者日常使用Wireguard组建点对点网络，但部分家庭基础设施位于封锁Wireguard的国家。这种基于流量特征识别的封锁已演变成不受法律约束的"黑箱"系统，促使作者寻找突破方案。

备选方案评估

流量混淆工具的局限性

虽然存在udp2raw、wstunnel等Wireguard混淆工具，以及Amnezia VPN这类专门对抗审查的分支，但封装导致的MTU效率下降成为硬伤。

理想VPN的五大标准

1. 真正的P2P网状网络：避免单点故障和绕路传输
2. 开源自托管：规避第三方服务的地理限制（如Tailscale）
3. 理念正确：反对Headscale/Zerotier等阉割开源推广商业的行为
4. 非Wireguard协议：规避特征检测
5. Nixpkgs集成：简化部署

三大候选方案深度测评

1. EasyTier

• 特点：中国开发者打造的极简方案，自动尝试TCP/UDP/WS等多协议穿透
• 优势：零配置启动，支持多平台客户端，适合非技术用户组局域网
• 缺陷：无法绑定固定IP，中国背景可能引发意识形态顾虑
• 配置示例：通过systemd服务管理核心进程，开放11010-11012端口

2. Nebula

• 特点：Slack团队开发的商业方案，采用Noise协议和椭圆曲线加密
• 优势：内置PKI体系，支持防火墙分区
• 缺陷：反人类的SSH配置界面，手动证书分发繁琐
• 配置逻辑：需指定"灯塔"节点协调网络，UDP 4242单端口通信

3. Tinc

• 特点：10年老牌项目，采用自有UDP协议和黑魔法文档
• 优势：真正的去中心化，任意节点可作引导节点
• 缺陷：1.1pre18版本多年未更新，配置依赖tinc-up/down脚本
• 网络拓扑：通过ED25519密钥实现节点认证，需手动配置子网路由

实测方法论

采用三节点架构（西班牙笔记本、芬兰服务器、俄罗斯防火墙后树莓派），通过六维度测试： 1. ICMP测试：300次ping统计延迟/抖动/丢包 2. SSH隧道：传输/dev/zero测试实时交互体验 3. Wget下载：获取384MB测试文件 4. iperf2/3：标准化带宽测试（结果需从Mb换算为MB）

结果揭晓

| 方案 | 丢包率 | 延迟(ms) | 抖动(ms) | SSH传输(MB/s) | Wget(MB/s) | |---------------------|--------|----------|----------|---------------|------------| | 基准值 | 0% | 123.751 | 1.422 | 9.0 | 超时 | | Wireguard+udp2raw | 49.6% | 108.806 | 3.724 | 超时 | 超时 | | EasyTier | 0% | 153.163 | 36.290 | 2.7 | 8.09 | | Nebula | 0% | 122.173 | 15.054 | 2.7 | 3.40 | | Tinc | 2.3% | 115.065 | 3.393 | 14.7 | 5.16 |

结论

• 性能王者：Tinc以14.7MB/s的SSH传输速度夺冠，延迟抖动控制最佳
• 特殊场景：EasyTier适合需要快速组网的临时场景
• 失望之作：Nebula表现低于预期，可能与Slack的Electron客户端"血脉相承"
• 最终方案：作者选择多方案并存，避免"发射火星车"式的应急切换

文末呼应开篇的家庭维修需求，暗示技术探索往往始于生活琐事。

以下是评论内容的总结：

1. Tinc VPN的实用性与便捷性

   • 用户jasonjayr认为Tinc配置简单高效，是其跨云平台和办公网络的核心工具。
   • 关键引用：
     "the configuration of tinc + the 'right defaults' make it pretty neat"
     "deploying it to a new machine is a git pull, generate key, push public key, and pull on the other nodes"

2. P2P流管理替代方案

   • coppsilgold推荐Iroh（基于QUIC的P2P方案），强调其打洞和发现功能。
   • 关键引用：
     "A somewhat nice solution for that is Iroh (QUIC P2P w/ hole punching)"
     "They also provide a solution to discoverability"

3. 历史P2P VPN的消亡

   • ValdikSS指出多个早期P2P VPN方案（如Social VPN、Remobo）已消失。
   • 关键引用：
     "There used to be many p2p vpn (full mesh) solutions, which disappeared into obscurity"

4. 创新传输层实验

   • Imustaskforhelp提出基于piping-server的独立传输层构想，强调其去中心化潜力。
   • 关键引用：
     "I want something which can be independent of udp or whatever"
     "just having the fun of installing curl and then being ready to go makes it so much more easier"

5. WireGuard混淆技术争议

   • ignoramous澄清Amnezia VPN的分支未缩减MTU，而是修改头部数据。
   • 关键引用：
     "The 'obfuscation' in Amnezia's fork does not shrink the available MTU"
     "modifies the 4 WireGuard header values & occasionally appends 'junk' data"

6. Nebula的配置误解

   • c0balt和dfc反驳Nebula需SSH配置的批评，指出其实际基于声明式文件和CA证书。
   • 关键引用：
     "The ssh interface is for debugging only"
     "configuration is solely handled by the daemon configuration file"

7. Headscale的遗漏争议

   • Jnr质疑为何排除Headscale，认为其满足开源、自托管和P2P网格需求。
   • 关键引用：
     "Headscale kind of ticks all the other boxes mentioned"
     "you can host your own derp servers"

8. 其他技术推荐

   • 包括vpncloud（Rust实现）、Yggdrasil（自动网格）和L2层VPN构想。
   • 关键引用：
     "vpncloud... used it in production for several years" (jis)
     "yggdrasil private mesh might be worth evaluating" (sunshine-o)
     "a VPN in layer 2 mode would work better" (sznio)

9. 传统工具的持续使用

   • kragen提到仍依赖ssh -L等传统工具，反映实际场景的多样性。
   • 关键引用：
     "mostly plain old ssh -L"

总结：讨论涵盖从成熟方案（Tinc/WireGuard）到新兴技术（Iroh/piping-server），既有对历史方案的反思，也有对配置误解的澄清，整体呈现P2P VPN领域的技术多样性和实践偏好。