原文鏈接：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的動態，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/253862.html
標籤：其他