【翻译】 WireGuard 何去何从？

请考虑订阅 LWN 订阅是 LWN.net 的生命线。 如果您喜欢这些内容并希望看到更多，您的订阅将有助于确保 LWN 继续蓬勃发展。 请访问此页面加入我们，让 LWN 继续在网络上传播。

自本文 发表以来，WireGuard 虚拟专用网络实施方案已经走过了整整一年多的时间。 自本文发表以来，WireGuard 在许多方面都取得了进步：它获得了许多满意的用户，得到了 Linus Torvalds 的认可，现在还得到了 NetworkManager 等工具的支持。 不过，有一件值得注意的事情还 没有发生：WireGuard 还没有并入主线内核。 在沉寂了一段时间后，WireGuard 又回来了，看来进入上游的漫长过程已接近尾声。

新版的 WireGuard 补丁已于 3 月 22 日发布。 WireGuard 本身并无特别争议；很少有人对其设计或实施提出抱怨。 症结在于 WireGuard 使用的"Zinc "加密库。 Zinc 的诞生源于对内核当前加密层的不满，许多人认为该加密层太难使用。 从本质上讲，Zinc 是一个全新的加密层，与当前代码并存，重复了内核中的大量功能，但为加密任务提供了一个更简单的界面。

人们对 Zinc 有一些抱怨。 其中之一就是，Zinc 不仅是一个用于访问加密算法的新 API，它还包含了自己对这些算法的实现，重复了内核已有的功能。 WireGuard 的作者 Jason Donenfeld 为这些新的实现进行了辩护，认为它们经过了更高级别的加密审查，这可能是正确的。 不过，内核开发人员非常不喜欢这种重复；他们会认为，如果特定算法的新实现更好，就应该直接取代现有算法，而不是重复。 这样，只需维护一个版本，所有用户都能享受到它带来的好处。

一段时间以来，重复算法一直是一个棘手的问题，但现在似乎有了一个解决方案。 加密货币维护者赫伯特-徐（Herbert Xu）发布了一个版本的 Zinc，其中引入了新的 API，但使用的是现有的算法实现，而不是多南菲尔德的新算法。 这样一来，像 WireGuard 这样的用户就可以使用 API，而新算法的实现则暂时不在讨论之列。 将来，我们可以根据这些算法实现本身的优点对其进行评估，并在达成共识认为它们更好时逐一合并。

以往的讨论可能会让人以为多南菲尔德会抵制这一举动，但这次他回应说："我认为我们稍微接近了同一起跑线"。 他计划对徐的 Zinc 版本做一些修改，但他打算发布的版本仍将使用现有的内核算法。 假设大家都喜欢这样的结果，WireGuard 合并的主要长期障碍之一将被克服。

加密功能的重复并不是对 Zinc 的唯一抱怨，阿德-比舍维尔（Ard Biesheuvel）也表达了对 Zinc 的其他抱怨。 Biesheuvel 将 Zinc 描述为"分层违规"，并抱怨它无法使用内核中的异步算法实现。 这是设计所致：Zinc 只明确支持同步实现（即调用者等待每个操作完成）。 异步实现（通常在外部加速器上并行运行，同时调用者做其他事情）被认为过于复杂，带来的好处太少。

Biesheuvel 不同意异步操作的这种观点，他担心将来会有人在 Zinc 上附加异步支持。 他更希望看到开发人员致力于修复现有加密 API 的缺陷。 持这种观点的不只他一个人，其他人也有不同意见，包括托瓦尔兹，他曾宣称自己是 Zinc 阵营的坚定支持者：

他接着说："异步加速器代码在真实硬件和任何正常真实负载上都没有任何价值。 如果异步加密加速器在现实世界中缺乏价值，那么引入一个可以有效忽略它们的应用程序接口就有一定意义了。 当然，这种对异步加密设备的看法并不被普遍认同，否则内核中就不会存在对它们的支持。 请特别参阅帕斯卡尔-范-里欧文（Pascal Van Leeuwen）对托瓦尔兹某些批评意见的反驳。 但很明显，异步加密对于各种用例来说并不是特别有用。

如果 Torvalds 所表达的观点（以及 Xu 暗含的观点）胜出，如果 Zinc 的下一篇文章能充分解决有关重复算法的问题，那么 Zinc 进入主线的道路将开始变得相对清晰。 除非 WireGuard 出现新的问题（这似乎不太可能，因为即使是反对 Zinc 的人也倾向于支持 WireGuard），否则它应该会在 Zinc 加入后立即被合并。 这样，让 WireGuard 进入主线的漫长故事就可以画上一个圆满的句号了。

---

(登录以发表评论)