WireGuard 最近受到了很多关注，实际上它是 VPN 中的新星。 但他真的像他看起来那么好吗？ 我想讨论一些观察并回顾 WireGuard 的实现，以解释为什么它不是替代 IPsec 或 OpenVPN 的解决方案。
在本文中，我想揭穿一些 [关于 WireGuard] 的神话。 是的，阅读需要很长时间，所以如果您还没有给自己泡杯茶或咖啡，那么是时候去做了。 我还要感谢彼得纠正了我混乱的想法。
我并没有给自己设定目标来诋毁 WireGuard 的开发人员，贬低他们的努力或想法。 他们的产品正在运行，但我个人认为它的呈现方式与实际情况完全不同 - 它被呈现为 IPsec 和 OpenVPN 的替代品，实际上现在根本不存在。
作为说明，我想补充一点，WireGuard 如此定位的责任在于谈论它的媒体，而不是项目本身或其创建者。
最近关于 Linux 内核的好消息并不多。 因此，我们被告知处理器存在巨大的漏洞，这些漏洞由软件修复，Linus Torvalds 以开发人员的功利主义语言过于粗鲁和无聊地谈论它。 调度程序或零级网络堆栈对于光鲜的杂志来说也不是很明确的主题。 WireGuard 来了。
从理论上讲，这一切听起来都很棒：一项令人兴奋的新技术。
但是让我们更仔细地看一下。
WireGuard 白皮书
本文基于 杰森·多南菲尔德 (Jason Donenfeld) 撰写。 他在那里解释了 Linux 内核中 [WireGuard] 的概念、目的和技术实现。
第一句是这样写的：
WireGuard […] 旨在取代大多数用例中的 IPsec 和其他流行的用户空间和/或基于 TLS 的解决方案（例如 OpenVPN），同时更安全、更高效且更易于使用 [工具]。
当然，所有新技术的主要优势在于它们 缓解 [与前辈相比]。 但是VPN也应该是 有效且安全.
接下来是什么？
如果你说这不是你需要的 [来自 VPN]，那么你可以在这里结束阅读。 但是，我会注意到，此类任务是为任何其他隧道技术设置的。
上述引述中最有趣的地方在于“在大多数情况下”这几个字，当然，这两个字被媒体忽略了。 因此，由于这种疏忽造成的混乱，我们到了本文的结局。
WireGuard 会取代我的 [IPsec] 站点到站点 VPN 吗？
不。 Cisco、Juniper 等大型供应商根本没有机会为其产品购买 WireGuard。 他们不会在移动中“跳上经过的火车”，除非有很大的需要这样做。 稍后，我将讨论他们可能无法将 WireGuard 产品带上飞机的一些原因，即使他们愿意。
WireGuard 会把我的 RoadWarrior 从我的笔记本电脑带到数据中心吗？
不。 目前，WireGuard 还没有实现大量重要功能来执行此类操作。 例如，它不能在隧道服务器端使用动态 IP 地址，仅此一项就打破了使用该产品的整个场景。
IPFire 通常用于廉价的 Internet 链接，例如 DSL 或电缆连接。 这对于不需要快速光纤的中小型企业来说很有意义。 [译者注：不要忘记，在通信方面，俄罗斯和一些独联体国家远远领先于欧美，因为我们的网络建设起步较晚，随着以太网和光纤网络的出现，标准，我们更容易重建。 在欧盟或美国的同一国家/地区，速度为 3-5 Mbps 的 xDSL 宽带接入仍然是普遍标准，而光纤连接的成本按照我们的标准来说有些不切实际。 所以，文章作者说的是DSL或者cable连接是常态，而不是古代。] 但是，DSL、电缆、LTE（和其他无线访问方法）具有动态 IP 地址。 当然，有时它们不会经常更改，但它们确实会更改。
有一个子项目叫做 ，它添加了一个用户空间守护进程来克服这个缺点。 上述用户场景的一个巨大问题是动态 IPv6 寻址的恶化。
从经销商的角度来看，这一切看起来也不太好。 设计目标之一是保持协议简单明了。
不幸的是，所有这些实际上都变得过于简单和原始，因此我们必须使用额外的软件才能使整个设计在实际使用中可行。
WireGuard 有那么好用吗？
还没有。 我并不是说 WireGuard 永远不会成为两点之间隧道的好选择，但现在它只是它应该成为的产品的 alpha 版本。
但他实际上做了什么？ IPsec 真的那么难维护吗？
很明显不是。 IPsec 供应商已经考虑到这一点，并随 IPFire 等接口一起提供他们的产品。
要通过 IPsec 设置 VPN 隧道，您需要在配置中输入五组数据：您自己的公共 IP 地址、接收方的公共 IP 地址、您要通过其公开的子网此 VPN 连接和预共享密钥。 因此，VPN 可在数分钟内完成设置，并与任何供应商兼容。
不幸的是，这个故事有一些例外。 任何尝试通过 IPsec 隧道连接到 OpenBSD 机器的人都知道我在说什么。 还有几个更痛苦的例子，但实际上，还有很多很多使用 IPsec 的良好实践。
关于协议复杂度
最终用户不必担心协议的复杂性。
如果我们生活在一个用户真正关心的世界中，那么我们就会摆脱 SIP、H.323、FTP 和其他十多年前创建的不能很好地与 NAT 配合使用的协议。
IPsec 比 WireGuard 更复杂的原因有很多：它做的事情更多。 例如，使用登录名/密码或带有 EAP 的 SIM 卡进行用户身份验证。 它具有添加新的扩展能力 .
而 WireGuard 没有。
这意味着 WireGuard 会在某个时刻崩溃，因为其中一种加密原语会减弱或完全受损。 技术文档的作者是这样说的：
值得注意的是，WireGuard 在密码学上是自以为是的。 它故意缺乏密码和协议的灵活性。 如果在底层原语中发现严重漏洞，则需要更新所有端点。 正如您从持续不断的 SLL/TLS 漏洞流中看到的那样，加密的灵活性现在已大大增加。
最后一句话完全正确。
就使用何种加密达成共识使得 IKE 和 TLS 等协议成为可能 更多 复杂的。 太复杂？ 是的，漏洞在 TLS/SSL 中很常见，而且没有其他选择。
关于忽视实际问题
想象一下，您有一个 VPN 服务器，在世界某个地方有 200 个战斗客户端。 这是一个非常标准的用例。 如果您必须更改加密，则需要将更新传送到这些笔记本电脑、智能手机等设备上的所有 WireGuard 副本。 同时 递送。 这简直是不可能的。 试图这样做的管理员将花费数月时间来部署所需的配置，而中型公司实际上需要数年时间才能完成这样的活动。
IPsec 和 OpenVPN 提供密码协商功能。 因此，在您打开新加密后的一段时间内，旧加密也会起作用。 这将允许当前客户升级到新版本。 推出更新后，您只需关闭易受攻击的加密即可。 就是这样！ 准备好！ 你太美了！ 客户甚至不会注意到它。
对于大型部署，这实际上是一种非常常见的情况，甚至 OpenVPN 在这方面也有一些困难。 向后兼容性很重要，即使您使用较弱的加密，对许多人来说，这也不是关闭业务的理由。 因为它会因为无法完成他们的工作而导致数百名客户的工作瘫痪。
WireGuard 团队使他们的协议更简单，但对于那些不能持续控制隧道中的两个对等点的人来说完全无法使用。 根据我的经验，这是最常见的情况。
密码学！
但是 WireGuard 使用的这种有趣的新加密是什么？
WireGuard 使用 Curve25519 进行密钥交换，使用 ChaCha20 进行加密，使用 Poly1305 进行数据认证。 它还适用于哈希键的 SipHash 和哈希的 BLAKE2。
ChaCha20-Poly1305 针对 IPsec 和 OpenVPN（通过 TLS）进行了标准化。
很明显，Daniel Bernstein 的开发经常被使用。 BLAKE2 是 BLAKE 的继任者，BLAKE 是 SHA-3 决赛选手，由于与 SHA-2 的相似性而没有获胜。 如果 SHA-2 被破解，那么 BLAKE 也很有可能被攻破。
由于 IPsec 和 OpenVPN 的设计，它们不需要 SipHash。 所以目前唯一不能与它们一起使用的是 BLAKE2，而且只有在它被标准化之前。 这不是一个大缺点，因为 VPN 使用 HMAC 来创建完整性，这被认为是一个强大的解决方案，即使与 MD5 结合使用也是如此。
所以我得出结论，所有 VPN 都使用几乎相同的加密工具集。 因此，在加密或传输数据的完整性方面，WireGuard 的安全性不比任何其他当前产品高或低。
但这还不是最重要的，根据项目的官方文档，这是值得关注的。 毕竟，最主要的是速度。
WireGuard 是否比其他 VPN 解决方案更快？
简而言之：不，不是更快。
ChaCha20 是一种更易于在软件中实现的流密码。 它一次加密一位。 像 AES 这样的块协议一次加密一个块 128 位。 需要更多的晶体管来实现硬件支持，因此更大的处理器配备了 AES-NI，这是一种指令集扩展，可以执行加密过程的一些任务以加快速度。
人们预计 AES-NI 永远不会进入智能手机 [但它确实做到了——大约。 每。]。 为此，ChaCha20 被开发为一种轻便、省电的替代品。 因此，今天您可以买到的每部智能手机都具有某种 AES 加速功能，并且与 ChaCha20 相比，使用这种加密技术运行速度更快、功耗更低，这对您来说可能是个新闻。
显然，过去几年购买的几乎所有台式机/服务器处理器都有 AES-NI。
因此，我希望 AES 在每个场景中都能胜过 ChaCha20。 WireGuard 的官方文档提到，对于 AVX512，ChaCha20-Poly1305 将优于 AES-NI，但此指令集扩展仅适用于较大的 CPU，这同样无助于更小和更移动的硬件，AES 总是更快- N.I.
我不确定在 WireGuard 的开发过程中是否可以预见到这一点，但今天它被单独钉在加密上的事实已经是一个可能不会很好地影响其运行的缺点。
IPsec 允许您自由选择最适合您情况的加密。 当然，如果您想通过 VPN 连接传输 10 GB 或更多的数据，则这是必要的。
Linux 中的集成问题
尽管 WireGuard 选择了现代加密协议，但这已经造成了很多问题。 因此，由于 Linux 中缺少这些原语，WireGuard 的集成已被推迟多年，而不是使用开箱即用的内核支持。
我不完全确定其他操作系统上的情况如何，但它可能与 Linux 上没有太大区别。
现实是什么样的？
不幸的是，每次客户要求我为他们建立 VPN 连接时，我都会遇到他们使用过时的凭据和加密的问题。 3DES 结合 MD5 仍然是常见的做法，AES-256 和 SHA1 也是如此。 而且后者虽然稍微好一点，但这也不是2020年应该用的东西。
用于密钥交换 всегда 使用 RSA - 一种缓慢但相当安全的工具。
我的客户与海关当局和其他政府组织和机构有联系，也与世界知名的大公司有联系。 他们都使用几十年前创建的申请表，并且从未添加使用 SHA-512 的能力。 我不能说它以某种方式明显地影响了技术进步，但显然它减慢了公司流程。
看到这一点让我很痛苦，因为 IPsec 自 2005 年以来一直支持椭圆曲线。Curve25519 也较新并且可以使用。 也有 AES 的替代品，如 Camellia 和 ChaCha20，但显然并非所有这些都得到 Cisco 等主要供应商的支持。
人们利用它。 有许多 Cisco 工具包，有许多设计用于与 Cisco 合作的工具包。 他们是该领域的市场领导者，对任何类型的创新都不太感兴趣。
是的，[企业部门]的情况很糟糕，但我们不会因为 WireGuard 而看到任何变化。 供应商可能永远不会发现他们已经使用的工具和加密有任何性能问题，也不会发现 IKEv2 有任何问题，因此他们不会寻找替代方案。
总的来说，你有没有想过放弃思科？
基准
现在让我们继续使用 WireGuard 文档中的基准测试。 虽然这篇[文档]不是一篇科学文章，但我还是希望开发者采取更科学的方法，或者使用科学的方法作为参考。 任何benchmark如果不能复现就没有用，在实验室得到就更没用了。
在 WireGuard 的 Linux 构建中，它利用了 GSO - 通用分段卸载。 多亏了他，客户端创建了一个 64 KB 的巨大数据包，并一次性对其进行加密/解密。 因此，调用和实施密码操作的成本降低了。 如果您想最大化 VPN 连接的吞吐量，这是个好主意。
但是，像往常一样，现实并不是那么简单。 将如此大的数据包发送到网络适配器需要将其切割成许多较小的数据包。 正常发送大小为 1500 字节。 也就是说，我们的 64 KB 巨人将被分成 45 个数据包（1240 字节的信息和 20 字节的 IP 标头）。 然后，有一段时间，它们将完全阻塞网络适配器的工作，因为它们必须同时发送。 结果，这将导致优先级跳跃，例如 VoIP 等数据包将排队。
因此，WireGuard 如此大胆宣称的高吞吐量是以减慢其他应用程序的网络速度为代价的。 而 WireGuard 团队已经 这是我的结论。
但让我们继续前进。
根据技术文档中的基准测试，该连接显示的吞吐量为 1011 Mbps。
令人印象深刻。
这尤其令人印象深刻，因为单个千兆以太网连接的最大理论吞吐量为 966 Mbps，数据包大小为 1500 字节减去 20 个字节的 IP 标头，8 个字节的 UDP 标头和 16 个字节的标头WireGuard 本身。 封装后的数据包中多了一个IP头，TCP中多了一个20字节。 那么这个额外的带宽是从哪里来的呢？
对于巨大的帧和我们上面讨论的 GSO 的好处，9000 字节的帧大小的理论最大值为 1014 Mbps。 通常这样的吞吐量在现实中是无法实现的，因为它伴随着很大的困难。 因此，我只能假设测试是使用更大的 64 KB 超大帧执行的，理论最大值为 1023 Mbps，只有某些网络适配器支持。 但这在实际条件下是绝对不适用的，或者只能在两个直接相连的站点之间使用，只能在测试台内使用。
但是，由于 VPN 隧道是在使用完全不支持巨型帧的 Internet 连接的两台主机之间转发的，因此在工作台上取得的结果不能作为基准。 这简直是一个不切实际的实验室成果，在实战条件下是不可能的，也不适用的。
即使坐在数据中心，我也无法传输大于 9000 字节的帧。
绝对违反了现实生活中的适用性标准，而且我认为，出于显而易见的原因，进行“测量”的作者严重诋毁了自己。
最后一线希望
WireGuard 网站谈论了很多关于容器的内容，并且它的真正用途变得很清楚。
一种简单快速的 VPN，无需配置，可以使用亚马逊云中的大量编排工具进行部署和配置。 具体来说，亚马逊使用了我之前提到的最新硬件功能，例如 AVX512。 这样做是为了加快工作速度，而不是绑定到 x86 或任何其他架构。
他们优化吞吐量和大于 9000 字节的数据包——这些将是巨大的封装帧，供容器相互通信，或用于备份操作、创建快照或部署这些相同的容器。 在我描述的场景中，即使是动态 IP 地址也不会以任何方式影响 WireGuard 的运行。
打的好。 出色的实现和非常薄的，几乎是参考协议。
但它不适合您完全控制的数据中心之外的世界。 如果您冒险并开始使用 WireGuard，您将不得不在加密协议的设计和实现中不断做出妥协。
结论
我很容易得出 WireGuard 尚未准备就绪的结论。
它被认为是一种轻量级且快速的解决方案，可以解决现有解决方案中的许多问题。 不幸的是，为了这些解决方案，他牺牲了许多与大多数用户相关的功能。 这就是它不能替代 IPsec 或 OpenVPN 的原因。
为了使 WireGuard 具有竞争力，它至少需要添加 IP 地址设置以及路由和 DNS 配置。 显然，这就是加密通道的用途。
安全是我的首要任务，现在我没有理由相信 IKE 或 TLS 以某种方式受到损害或损坏。 两者都支持现代加密，并且经过数十年的运行证明。 仅仅因为某些东西是新的并不意味着它是更好的。
当您与不受您控制的站点的第三方通信时，互操作性非常重要。 IPsec 是事实上的标准，几乎在任何地方都得到支持。 他工作。 而且不管怎么看，理论上以后的WireGuard即使是自身的不同版本也可能不兼容。
任何密码保护迟早会被破坏，因此必须更换或更新。
否认所有这些事实并盲目地想使用 WireGuard 将你的 iPhone 连接到你的家庭工作站只是一个把你的头埋在沙子里的大师班。
来源： habr.com