共计 5172 个字符，预计需要花费 13 分钟才能阅读完成。
原文链接：https://fuckcloudnative.io/posts/why-not-wireguard/
最近有一款新型 VPN 工具备受瞩目，置信很多人曾经据说过了，没错就是 WireGuard，传言它无望取代 IPSec 和 OpenVPN。那么 WireGuard 是否真的有传说中的那么神奇？明天我就来一一解读。
这是一篇十分长的文章，我倡议你先去冲杯咖啡，而后边喝咖啡边看。
首先要申明：我并没有诽谤 WireGuard 的意思，WireGuard 很棒很优良，但总是有某些无脑媒体天天说 WireGuard 行将取代 IPSec 和 OpenVPN，这我就不能忍了，明天就来和你们好好掰扯掰扯 WireGuard。
WireGuard 白皮书
本文所有的观点都是针对 Jason Donenfeld 撰写的 WireGuard 白皮书，其余的博客和文档不在我的探讨范畴之内。白皮书的第一句话是这么说的：
WireGuard 的指标是在大多数场景下取代
IPsec和其余基于用户空间和 TLS 的 VPN（例如OpenVPN），与其余 VPN 相比，它更简略、更高效、更容易应用。
能够看到，WireGuard 最大的卖点就是简略，大多数新技术也都是这个营销套路。当然，作为一款 VPN 产品，它还有性能和平安这两个卖点。
乏味的是，作为 VPN，如果你不简略、不平安、性能不好，那你可能就没有机会了。这不止是你 WireGuard 的设计指标，其余的 VPN 产品也是这么干的好吗？
最乏味的局部是 “在大多数场景下” 这几个字，媒体报道时间接将其删除了，混同公众的视听。
WireGuard 是否取代 IPSec？
不！Cisco 和 Juniper 等大厂不可能应用 WireGuard，除非无可奈何，他们是不会上 WireGuard 的车的。前面我会具体解释为什么即便他们想卖 WireGuard 服务也卖不出去。
WireGuard 实现了 Road Warrior？
当然没有。Road Warrior 是具备动态分配 IP 地址的挪动客户端，比方笔记本电脑。你能够间接了解为漫游。WireGuard 目前不能应用动静 IP 来建设连贯，要想实现漫游性能，还有很长的路要走。
WireGuard 有一个子项目叫 wg-dynamic，它减少了一个用户空间守护程序来使 WireGuard 反对动静 IP。然而这个我的项目最初一次更新是在 2019 年，不晓得还保护不保护了。。。
大家都晓得，IPv6 就是动静寻址的，如果未来全面进入 IPv6 的世界，WireGuard 还怎么用？从商业角度来看，这是相当令人悲观的。
WireGuard 的设计指标之一是放弃协定的精简，当初看来是精简过头了，以至于须要更多的辅助软件能力使它施展弱小的效用。
WireGuard 真的好用吗？
并没有。我并没有说 WireGuard 最终不能代替其余 VPN 产品，我只是说目前 WireGuard 还不行，如果它的指标和咱们了解的一样，目前它还只是处在 Alpha 阶段。
WireGuard 到底想解决什么问题？IPsec 真的很难用吗？
恐怕不是这样，如果厂商做了正确的功课，并提供了易于应用的界面（比方，IPFire），就不会难用。
要想建设一个 IPSec 隧道，只须要输出 5 组信息：你的公网地址、peer 的公网地址、子网、你的预共享秘钥和 peer 的预共享秘钥。这样看来，几分钟就能够建设一个隧道，而且每个厂商之间都是兼容的。
当然，也有一些例外，比方与 OpenBSD 零碎之间建设隧道，过程可能会比拟苦楚。
协定复杂度真的很重要吗？
作为终端用户，其实无需思考协定的复杂度。
如果复杂度真的影响很大，咱们必定早就解脱 SIP、H.323 和 FTP 等不能很好地应答 NAT 的协定了，然而并没有。讲道理，IPsec 比 WireGuard 更简单是有起因的： 它能做的事件太多了 。比方，应用用户名 / 明码或带有 EAP 的 SIM 卡进行用户认证；也能够扩大新的加密形式。
而 WireGuard 呢？这些性能都没有。这就意味着当某一天它的固定的那些加密形式被破解或减弱了之后，就彻底崩盘了。
WireGuard 作者说过：
WireGuard 在加密形式上比拟偏执，成心砍掉了加密协议的敏捷性，不反对扩大加密协议，因为这么做会大大降低软件的复杂度。如果底层的加密协议呈现了破绽，只能更新所有端点来修复破绽。
我十分批准他这句话里论述的观点，因为协商应用何种形式来加密会使 IKE 和 TLS 等协定变得更简单。那么，是咱们想不开刻意要搞这么简单吗？当然不是啊，即便这样，在握手过程中也会常常发现各种破绽，不简单能行吗？除此以外，别无他法。
如何更新明码？
设想一下，你有一个 VPN 服务器，为 200 多个 Road Warrior 客户端提供服务，而且这些客户端散布在世界各地。假如当初你改了明码，那么就须要同时更新所有客户端的明码能力失常工作，这几乎就是不可能的事件，作为管理员，你可能会须要几个月的工夫来下方更改后的配置。
IPsec 和 OpenVPN 就没有这些懊恼，它们都有秘钥协商性能，能够将新秘钥逐渐更新到所有客户端，在漫长的更新过程中，仍在应用旧秘钥的客户端依然无效，直到所有客户端更新结束后，才会弃用旧秘钥。整个过程中客户端不会有任何觉察，也不须要重启。
加密形式
WireGuard 应用以下加密技术来保障数据的平安：
- 应用
ChaCha20进行对称加密，应用Poly1305进行数据验证。 - 利用
Curve25519进行密钥替换。 - 应用
BLAKE2作为哈希函数。 - 应用
HKDF进行解密。
而 IPSec 和 OpenVPN 应用的都是规范的 ChaCha20-Poly1305 加密算法。
BLAKE2 算法是 BLAKE 算法的升级版，而 BLAKE 是 SHA-3 的入围者，与 SHA-2 十分类似，所以没有获奖。如果哪天 SHA-2 被破解了，BLAKE 也很有可能被破解。
IPSec 和 OpenVPN 应用的加密形式和 WireGuard 是相似的，比方对称加密应用的是规范的 ChaCha20-Poly1305 算法。惟一没有用到的就是 BLAKE2，因为它目前没有列入规范。即便不必 BLAKE2，也没什么大不了的，因为 VPN 是应用 HMACs 来保障数据的完整性，即便应用 MD5 也依然没问题。
我的论断是： 实际上所有的 VPN 都能够应用雷同的加密技术，WireGuard 在加密或数据完整性方面并没有比其余的 VPN 更平安或更不平安。
然而白皮书上说了，加密不是重点，速度才是。
好吧，那咱们就来看看速度是不是真的有那么快。
WireGuard 真的很快吗？
答案是否定的。
ChaCha20 是一种流加密算法，一次只加密一个比特，应用软件更容易实现。而像 AES 这样的分块加密形式，会将明文分成多个等长的模块，每次加密 128 位的模块。这种加密形式在硬件中实现时须要更多的晶体管，所以大型处理器都带有一个指令集扩大 — AES-NI，它能够进步加密和解密的速度。
明天你能买到的任何一款智能手机都带有 AES 的硬件加速性能，在这些硬件中应用 AES 会比 ChaCha20 加密解密更快、更节能。简直所有的集体 PC 和服务器的 CPU 都带有 AES-NI，加密解密速度就更不用说了。因而，我预计 AES 在简直所有场景下体现都会优于 ChaCha20。
然而，WireGuard 的白皮书又说了，ChaCha20-Poly1305 的性能优于 AES-NI，但该指令集只实用于大型处理器，对一般 PC 和挪动硬件没有任何帮忙，所以并没有什么卵用。
WireGuard 执着于一种加密算法，我感觉不好。而 IPSec 容许你抉择不同的加密算法，这样就能够依据不同的应用场景抉择最合适的加密算法，例如，传输 10G 或更多的数据。
既然 WireGuard 抉择了更古代的加密形式，就会带来很多问题。比方，因为 Linux 内核中不足反对这些加密形式的模块，导致 WireGuard 并没有应用 Linux 内核提供的模块，要推延好几年能力用上 Linux 内核提供的模块。我不晓得其余操作系统是什么状况，但可能也没有什么不同。
现实与事实
假如 WireGuard 真的很完满，大厂就肯定会用吗？
现实情况是，每次当客户要求我帮他们搭建 VPN 时，给到他们手里的证书都是应用旧的加密形式，通常是 3DES 和 MD5 联合，或者 AES-256 和 SHA1 联合。至于秘钥替换，咱们始终在应用 RSA，尽管速度很慢，但足够平安。
大部分客户都和政府机构或巨头公司无关，他们在咱们这里的订单表还是几十年前的，基本就没有增加过 SHA-512 的选项。所以阻止翻新的不肯定是技术，而是迟缓的企业流程。
看到这种状况，我也很痛心？我就不想应用新技术吗？当然想啊。IPsec 从 2005 年左右就开始反对椭圆曲线加密算法了，Curve25519 算法当初也反对了，也有了 AES 的代替计划（比方 Camellia 和 ChaCha20），但很显然并不是所有的大厂都违心去适配，比方思科等。思科是这个畛域的市场领导者，他们对推动翻新其实并不感兴趣。
基准测试
白皮书中还提到了 WIreGuard 的基准测试，尽管这不是一篇科学论文，但我依然心愿以迷信的办法来进行基准测试。如果测试不能反复，那么它就毫无价值；如果测试没有思考理论场景，也毫无价值。
WireGuard 的 Linux 版本应用 GSO（Generic Segmentation Offloading，通用分段卸载）来创立一个 64k 字节的微小数据包，并一次性对其进行加密或解密，以此来取得速度劣势。这样一来，初始化和调用加密操作的开销就被节俭了。如果你想最大限度地进步吞吐量，这倒是一个好主见。
然而事实不是这样的，你想向网络适配器发送如此大的数据包，就须要将其切割成许多小数据包，通常为 1500 字节。对于 64k 字节的超大数据包来说，会被切割成 45 个数据包（每个数据包有 1480 字节的有效载荷和 20 字节的 IP 头），这些数据包将会阻塞网络适配器相当长的工夫，因为它们想要被一次性发送进来。像 VoIP 呼叫这样应该优先解决的数据包也不得不缓缓等着。
因而，WireGuard 声称的高吞吐量是通过让其余利用变慢来取得的，官网团队曾经抵赖了这一点。
咱们再来看看基准测试的最终数据，吞吐量为 1011 MBit/s！
这个数据令人印象粗浅，我至今仍感到纳闷，在数据包大小为 1500 字节的状况下，一个千兆以太网链路的最大实践吞吐量为 966 MBit/s，减去 20 个字节的 IP 头、8 个字节的 UDP 头和 16 个字节的 WireGuard 头，再减去封装数据包中的另一个 IP 头和另一个 20 个字节的 TCP 头，额定的带宽到底从哪来的？
OK，假如启用了巨型帧和 GSO，9000 字节帧大小时的实践最大值将是 1014 MBit/s。如果应用更大的巨型帧，实践最大值为 1023 MBit/s。然而这在事实中是相对不实用的，因为开销太大了，而且只能在服务器直连的状况下应用。通常 VPN 都是通过互联网连贯的，齐全不反对巨型帧，所以这样的基准测试基本不切实际，永远不可能在事实世界中应用。
最终幻想
WireGuard 的官方网站写了很多对于容器的内容，很显著这应该就是 WireGuard 的目标。
通过一个简略迅速的 VPN 来实现容器通信的 CNI，能够通过 Kubernetes 等大型容器编排工具来疾速部署，针对吞吐量和大于 9000 字节的数据包进行了优化，能够疾速散发容器镜像，等等。
这所有的种种都如同是为容器而设计的，不得不抵赖超精简、超优雅、超疾速。
然而，它基本不是为数据中心以外的世界而设计的，在里面的世界，你必须要在协定的设计和实现上做出斗争。
总结
我最终的论断是：WireGuard 还没有筹备好。
它是作为一个轻量级和疾速的解决方案来起草的，以解决现有解决方案中的一些问题，但可怜的是，它就义了许多与用户相干的性能，因而无奈取代 IPsec 和 OpenVPN。
你至多得有动静地址调配和推送路由等配置的性能吧？这些性能都是须要进行秘钥协商的。
此外，安全性是重中之重，目前我还没发现 IKE 或者 TLS 有啥显著的缺点，它们都反对古代加密形式，而且都通过了几十年的审计。不能仅仅因为某些货色是新的，就感觉它是好的。
加密形式总会过期，押注在一种加密形式身上，当这种加密形式不再平安时，你该何去何从？
Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12 离线安装包公布地址 http://store.lameleg.com，欢送体验。应用了最新的 sealos v3.3.6 版本。作了主机名解析配置优化，lvscare 挂载 /lib/module 解决开机启动 ipvs 加载问题，修复 lvscare 社区 netlink 与 3.10 内核不兼容问题,sealos 生成百年证书等个性。更多个性 https://github.com/fanux/sealos。欢送扫描下方的二维码退出钉钉群，钉钉群曾经集成 sealos 的机器人实时能够看到 sealos 的动静。
