让 Tailscale 更快

原文 ↗ Hacker News 讨论 ↗

Tailscale 最近为让其基于 WireGuard 的 mesh VPN 更快而做的工作，再次引发了关于取舍的争论：用户态、跨平台的数据面与内核级或硬件加速替代方案之间应如何平衡。评论者指出，虽然 Tailscale 在易用性、设备接入和 NAT 穿透方面明显优于自管 WireGuard 或 IPsec，但它在充分利用多千兆链路方面仍有困难，并且可能增加移动设备的电池消耗。大家也对未来方向表现出浓厚兴趣，包括更好的中继策略、后量子与硬件加速加密，以及对路由器、微控制器和无应用访问模式的更丰富支持。

平台重点与数据面工作

  • 讨论指出，博文强调 Linux/Android，是因为许多包级优化依赖操作系统特性，而这些平台暴露了所需功能。
  • 据称，像多队列和内存优化这样的架构变更通常也适用于其他操作系统。

性能、用户态 vs 内核态

  • 多位评论者认为 Tailscale “慢”，理由是在桌面客户端上很难超过 1 Gbps，以及在 Linux 上的合成测试中大约只能到 10 Gbps。
  • 批评者说，带有额外拷贝和上下文切换的用户态网络存在固有上限，并呼吁采用内核版 WireGuard 或 DPDK/XDP 风格的零拷贝方法。
  • 也有人反驳说，内存拷贝和系统调用并不是主要瓶颈；协议和实现选择更重要。
  • 一位 Tailscale 代表回应称，内核并不一定更快；他们的用户态 WireGuard 曾一度跑得比内核版本更快，而高端的 DPDK 风格路径本身也属于用户态。

WireGuard vs Tailscale vs 替代方案

  • 一些用户从 Tailscale 切换回纯 WireGuard，原因是稳定性更好、感觉更快，而且在路由器集成和简单密钥设置下更简洁。
  • 另一些用户则反向迁移，称赞 Tailscale 上手极其简单、设备注册动态化（包括 CI 作业）、DNS 集成方便，以及能绕过 NAT 和端口转发限制（例如亲属家里的网络）。
  • Cloudflare Tunnels 被提及为某些场景下的“无应用”替代方案。

加密、硬件加速与后量子

  • 讨论集中在 Tailscale 是否应偏离 WireGuard 的 ChaCha20/Poly1305，改用 AES-GCM 以利用 NIC 硬件卸载，支持 100–400+ Gbps。
  • 有人担心，偏离 WireGuard 经过仔细分析的设计会失去形式化保证；也有人认为，替换密码算法可以保留核心属性。
  • 一些人认为 IPsec 过于复杂且历史上容易出问题；也有人指出它可以配合简化的控制平面和强大的硬件加速使用。
  • 还讨论了后量子支持：有人认为 WireGuard v2 或更新的数据平面不可避免；也有人提到 PSK 作为有限的“抗量子”临时方案。

中继、路由与 DERP

  • 有人抱怨 DERP 延迟，希望有更灵活的中继方式。
  • 点对点中继功能已经存在，但目前要求中继节点不能位于 NAT 之后；评论者希望更机会式地利用可穿越 NAT 的节点作为临时中继。

客户端体验、电池与平台怪癖

  • 多条评论反映 iOS 以及使用出口节点时电池消耗很高；用户希望能持续保持 Tailscale 连接，而不会明显耗电。
  • Apple TV 的出口节点性能据说很差；系统会激进地终止后台应用，限制了 Tailscale 能做的事情。
  • 对 Android 应用被排除在 VPN 路径之外存在一些困惑/抱怨；也有人指出 Android 允许应用选择退出，而“在无 VPN 时阻止连接”可以缓解泄漏。
  • DNS 隐私方面：有人请求支持 DoH；Tailscale 表示，使用 tailnet DNS 服务器已经能让 DNS 查询通过隧道保持私密，而 DoH 会增加 TLS 复杂性。

高级/边缘用例与功能请求

  • 有人请求：
    • 更好地支持微控制器/IoT。
    • 当设备不能直接运行 Tailscale 时，更容易配置多节点代理/sidecar（目前通常需要为每个被代理设备部署一个容器）。
    • 更清楚地解释博文网络图中的“队列”和“深度”。
  • 一些用户明确要求 Tailscale 不要“enshitify”，这反映出强烈的热情，同时也体现了对产品长期走向的担忧。