JIT WireGuard

原文 ↗ Hacker News 讨论 ↗

基于 WireGuard 的 VPN 工具与 AWS 访问

  • 讨论了 Netmaker：它是一个可自托管、基于 WireGuard 的 mesh，类似 Tailscale；Netbird 也被推荐，但有人批评它的数据收集很多，而且守护进程行为有风险（例如创建 root SSH 隧道）。
  • 有人问为什么不用 AWS 原生选项（VPC peering、PrivateLink、AWS VPN、SSM）。回复是：这些方案主要面向 VPC 之间的互联，而不是跨很多账户的廉价、简单的 SSH 式访问；AWS VPN 的出口费用在大流量场景下会很高，而 SSM + SSH 虽然可行，但需要 agent/权限和更多配套工具。

JIT WireGuard 概念与实现细节

  • 文章里的“just-in-time” WireGuard peer 解决了内核版 WireGuard 没有原生“按需安装 peer” API 的问题。
  • 它们只拦截启动数据包，使用 eBPF（udp[8] = 1），然后在用户态决定是否授权并安装 peer；过期的 peer 之后会被移除。
  • 有人建议使用 NFQUEUE 将数据包排队到用户态，在配置完成后再对其给出 verdict（drop/allow），这样可以实现 fail-open 并扩展到多个 worker。
  • 讨论了在 peer 安装后重放初始握手包；有人认为这可行而且是个很好的优化，但文章里没有实现。
  • 这种方法旨在支持大量潜在 peer，而无需把它们全部预加载到内核；peer 主要存在于数据库中，并按需安装。其他基于 WireGuard 的系统也使用类似技术来控制资源占用。
  • JIT 被澄清为“just-in-time configuration”，不是编译；有人指出这个词在编译之外也很常见（例如制造业）。

关于 WireGuard 设计与局限性的争论

  • 一种批评是：WireGuard 与网络接口绑得太死；有人希望它能成为通用的“filter”，可与任意文件句柄一起使用，从而实现更灵活的组合。
  • 也有人为其设计目标辩护：尽量小的配置面更利于审计，也更实际安全，相比之下 IPSec 更复杂。
  • 抱怨更多集中在工具层面：.ini 风格配置、wg 与 wg-quick 的不一致，以及客户端 UX 的笨拙（尤其是在 Windows 上）。
  • 有几位评论者指出，WireGuard 并不是完整的“VPN 解决方案”：它没有内建的路由/DNS 下发或集中式策略分发。替代办法包括运行 BGP 或自己写客户端，但这对很多人来说太复杂，尤其在移动端。
  • “cryptokey routing” 模型被视为基础；像 Tailscale、Netmaker 等更高层产品之所以存在，正是为了在其上增加管理、策略和路由分发。

浏览器、用户态与替代网络栈

  • 在浏览器里运行 WireGuard 受限于缺少原始套接字；只有基于 HTTP/WebSocket 的路径可行。一些项目使用中继（例如通过专用 relay 服务器的 WebSocket）和 WebAssembly 来近似实现 VPN 行为。
  • OpenZiti/BrowZer 被拿来举例：它采用 service-worker + WebAssembly 模型，让浏览器通过 WebSockets 加入一个私有 overlay 网络，前提是先完成脚本注入启动。
  • Fly 的 flyctl 使用了用户态 TCP/IP 栈加用户态 WireGuard；宿主操作系统并不是 WireGuard peer，只有 CLI 进程是。它也提供一个单独的“真实”peer 模式，用于操作系统级访问。
  • 有人觉得用户态 TCP/IP 栈在概念上很怪，但也有人指出它们在历史上很常见，而且现在越来越实用。

控制平面消息传递（NATS vs HTTP）

  • 评论者对基于 NATS 的协调居然会有足以影响可靠性的消息丢失感到惊讶。
  • 有人指出，“core” NATS 不提供持久化/重投递；JetStream 增加了这些功能，但在设计时可能还没有配置或尚不可用。
  • Fly 员工表示，他们大概是“把 NATS 用错了”，并意识到消息代理在他们这种简单、单消息的用例里增加了复杂性，却没有带来额外的表达能力；直接使用 HTTP 请求模型更容易推理和监控。

Apple/macOS 的 VPN 限制

  • 有一种说法称，官方 WireGuard macOS 图形界面必须通过 App Store 分发，因为 Apple 不向网页分发或自分发应用提供必要的 VPN entitlement；这被描述为对隐私不友好，因为 App Store 绑定了用户身份和硬件。
  • 也有人对此提出异议，指出有些非 App Store 的 VPN 客户端也能正常工作，说明前述说法有些夸张。
  • 进一步澄清：较新的 Network Extension/System Extension API 需要特定 entitlement，Apple 现在会发给 Developer Program 成员，所以从源码构建 WireGuard 的确切应用、但又不是 Program 成员的话，在不关闭安全功能的情况下无法完整运行。旧的或不同的 VPN API 对非 App Store 应用仍然可用。

Fly.io 平台体验

  • 多位用户称赞 Fly.io 的开发体验：全球快速部署、工作负载启动极快、Anycast 网络，以及 FLY_REPLAY 和 LiteFS 等功能，让全球集群和低延迟访问比传统 VPS 提供商更容易。
  • 也有人报告了严重的可靠性问题：关键服务多日宕机、“db”/Postgres 产品不稳定且明确“not managed”，以及 API/控制平面故障阻塞部署。这让一些人迁移到 GCP（Cloud Run 或 GKE），以减少意外并获得更好的文档。
  • 也有人继续使用 Fly.io，尽管它还有粗糙之处，希望这个平台最终成熟为一个稳定、以 Anycast 为中心的替代方案。

传输选择与连通性

  • 对于 flyctl，WireGuard 通常默认通过 WebSockets 隧道化，以穿过限制性网络——即使 UDP（哪怕是 443）被阻断或不稳定也能工作；纯 UDP 的 WireGuard 作为可选项支持。
  • 选择这个默认值是为了尽量减少难以排查的 UDP 故障；在 Fly 的定位下（云平台，而不是通用 VPN 服务），去做“happy eyeballs”式探测来在 UDP 与 WebSocket 之间选择，被认为是没必要的复杂性。
  • 讨论确认，只要 4-tuple（源/目标 IP + 端口）保持一致，JIT 握手技巧就能穿过 NAT，因为典型的 UDP NAT 不会检查包内容。

杂项

  • 有人对 Fly 对“内核 WireGuard 不支持按需 peer”的解释感到困惑，后来澄清：peer 可以在运行时添加，但 JIT 方案要求在添加前先认证并做决策，以避免存储大量从未使用过的 peer。
  • 还提到了各种用户态 WireGuard/Noise 项目（例如 Go 库），以及应用级隧道、类似 magic-wormhole 的文件传输和 service-mesh 风格 overlay 的想法。
  • 在 Fly 上部署 Docker 化应用被描述为很直接：在包含 Dockerfile 的目录中运行 flyctl launch。