最近 WireGuard 它吸引了許多關注，事實上，它是一顆冉冉升起的新星。 VPN但它真的像看起來那麼好嗎？我想討論一些觀察結果並回顧它的實現方式。 WireGuard為了解釋為什麼它不能取代 IPsec 或 OpenVPN.
在本文中，我想澄清一些關於[ WireGuard是的，這篇文章很長，所以如果你還沒泡杯茶或咖啡，現在就該泡了。我還要感謝彼得幫我校對了我那些雜亂無章的思緒。
我的目的並非詆毀開發者。 WireGuard貶低他們的努力或想法。他們的產品確實有效，但我個人認為它的宣傳方式與它的實際用途完全不同——它被宣傳為IPsec的替代品，但實際上並非如此。 OpenVPN但事實上，它現在根本不存在。
需要指出的是，我想補充一點，這種定位的責任在於… WireGuard 這些言論是由報導此事的媒體發表的，而不是由專案本身或其創建者發表的。
最近關於核心的話題 Linux 沒什麼好消息。我們聽說了處理器存在一些極其嚴重的漏洞，這些漏洞最終透過軟體得到了緩解。但 Linus Torvalds 對此的描述過於粗糙枯燥，充滿了開發者的實用主義語言。調度器或 0 層網路協定堆疊之類的東西，也並非適合光鮮亮麗的雜誌來報道的話題。然後，奇蹟出現了。 WireGuard.
從理論上講，這一切聽起來都很棒：一項令人興奮的新技術。
技術文件 WireGuard
本文基於 官方文檔 WireGuard由 Jason Donenfeld 撰寫，他在文中解釋了概念、目的和技術實現[WireGuard在核心 Linux.
第一句是這樣寫的：
WireGuard […]旨在取代大多數用例中的IPsec，以及其他流行的基於用戶空間和/或TLS的解決方案，例如： OpenVPN同時更安全、更有效率、更易於使用[工具]。
當然，所有新技術的主要優勢在於它們 緩解 [與前輩相比]。 但是VPN也應該是 有效且安全.
那麼，下一步是什麼？
如果你說這不是你需要的 [來自 VPN]，那麼你可以在這裡結束閱讀。 但是，我會注意到，此類任務是為任何其他隧道技術設置的。
上述引述中最有趣的地方在於“在大多數情況下”這幾個字，當然，這兩個字被媒體忽略了。 因此，由於這種疏忽造成的混亂，我們到了本文的結局。
會發生嗎？ WireGuard 替換我的[IPsec]網站到網站VPN？
不，像思科、瞻博網路等大型廠商根本不可能收購並用於自身產品。 WireGuard除非迫不得已，否則他們不會「搭便車」。稍後，我會討論他們可能無法在列車上安裝產品的一些原因。 WireGuard即使他們想這樣做。
它能存活下來嗎？ WireGuard 我的 RoadWarrior 設備從筆記型電腦連接到資料中心？
不。現在在 WireGuard 要實現這樣的功能，還缺少大量重要特性。例如，它無法在隧道伺服器端使用動態 IP 位址，僅此一點就足以破壞該產品的整個應用場景。
IPFire 通常用於廉價的 Internet 鏈接，例如 DSL 或電纜連接。 這對於不需要快速光纖的中小型企業來說很有意義。 [譯者註：不要忘記，在通信方面，俄羅斯和一些獨聯體國家遠遠領先於歐美，因為我們的網絡建設起步較晚，隨著以太網和光纖網絡的出現，標準，我們更容易重建。 在歐盟或美國的同一國家/地區，速度為 3-5 Mbps 的 xDSL 寬帶接入仍然是普遍標準，而光纖連接的成本按照我們的標準來說有些不切實際。 所以，文章作者說的是DSL或者cable連接是常態，而不是古代。] 但是，DSL、電纜、LTE（和其他無線訪問方法）具有動態 IP 地址。 當然，有時它們不會經常更改，但它們確實會更改。
有一個子項目叫做 “工作組動態”，它添加了一個用戶空間守護進程來克服這個缺點。 上述用戶場景的一個巨大問題是動態 IPv6 尋址的惡化。
從經銷商的角度來看，這一切看起來也不太好。 設計目標之一是保持協議簡單明了。
不幸的是，所有這些實際上都變得過於簡單和原始，因此我們必須使用額外的軟件才能使整個設計在實際使用中可行。
WireGuard 真的那麼容易使用嗎？
還沒。我不是那個意思。 WireGuard 它永遠不會成為連接兩點的隧道的好替代方案，但就目前而言，它只是該產品未來發展方向的早期版本。
但他實際上做了什麼？ IPsec 真的那麼難維護嗎？
很明顯不是。 IPsec 供應商已經考慮到這一點，並隨 IPFire 等接口一起提供他們的產品。
要通過 IPsec 設置 VPN 隧道，您需要在配置中輸入五組數據：您自己的公共 IP 地址、接收方的公共 IP 地址、您要通過其公開的子網此 VPN 連接和預共享密鑰。 因此，VPN 可在數分鐘內完成設置，並與任何供應商兼容。
不幸的是，這個故事有一些例外。 任何嘗試通過 IPsec 隧道連接到 OpenBSD 機器的人都知道我在說什麼。 還有幾個更痛苦的例子，但實際上，還有很多很多使用 IPsec 的良好實踐。
關於協議複雜度
最終用戶不必擔心協議的複雜性。
如果我們生活在一個用戶真正關心的世界裡，那麼我們早就擺脫了 SIP、H.323、FTP 和其他十多年前創建的不能很好地與 NAT 配合使用的協議。
IPsec之所以比…更複雜，是有原因的。 WireGuard它的功能遠不止這些。例如，它可以使用登入名稱/密碼或支援 EAP 的 SIM 卡對使用者進行身份驗證。它還具備擴展功能，可以添加新的驗證方式。 加密原語.
並且在 WireGuard 這並不存在。
這意味著 WireGuard 在某個時刻，它終將失效，因為其中某個加密原語會被削弱或完全破解。技術文檔的作者是這樣描述的：
它應該指出的是 WireGuard 它對加密技術過於自信，故意在密碼和協定方面缺乏靈活性。如果底層原語發現嚴重漏洞，所有端點都需要更新。正如目前層出不窮的 SSL/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，而且這種情況只會持續到BLAKE2標準化為止。但這並非重大缺陷，因為VPN使用HMAC來保證完整性，即使與MD5結合使用，HMAC也被認為是強大的解決方案。
因此，我得出結論：所有 VPN 都使用幾乎相同的加密工具集。 WireGuard 在加密或傳輸資料完整性方面，它與其他任何現有產品相比，安全性並無高下之分。
但這還不是最重要的，根據項目的官方文檔，這是值得關注的。 畢竟，最主要的是速度。
WireGuard 比其他 VPN 解決方案更快？
簡而言之：不，不是更快。
ChaCha20 是一種更易於在軟件中實現的流密碼。 它一次加密一位。 像 AES 這樣的塊協議一次加密一個塊 128 位。 需要更多的晶體管來實現硬件支持，因此更大的處理器配備了 AES-NI，這是一種指令集擴展，可以執行加密過程的一些任務以加快速度。
人們預計 AES-NI 永遠不會進入智能手機 [但它確實做到了——大約。 每。]。 為此，ChaCha20 被開發為一種輕便、省電的替代品。 因此，今天您可以買到的每部智能手機都具有某種 AES 加速功能，並且與 ChaCha20 相比，使用這種加密技術運行速度更快、功耗更低，這對您來說可能是個新聞。
顯然，過去幾年購買的幾乎所有台式機/服務器處理器都有 AES-NI。
因此，我預期 AES 在所有情況下都會優於 ChaCha20。官方文件中也提到了這一點。 WireGuard 文中提到，由於 AVX512 的存在，ChaCha20-Poly1305 的效能將優於 AES-NI，但這種指令集擴充僅適用於大型處理器，這對於小型和行動硬體來說並無幫助，因為 AES-NI 始終是最快的。
我不確定這在開發過程中是否可以預見。 WireGuard但如今，它只能使用一種加密方式，這本身就是一個缺點，可能會對其運作產生不太好的影響。
IPsec 允許您自由選擇最適合您情況的加密。 當然，如果您想通過 VPN 連接傳輸 10 GB 或更多的數據，則這是必要的。
整合中的問題 Linux
雖然 WireGuard 我選擇了一種現代加密協議，但它已經引發了許多問題。因此，我沒有使用內核預設支援的方案，而是進行了整合。 WireGuard 由於缺乏這些原始技術，這項工程被推遲了多年。 Linux.
我不太確定其他作業系統上的情況如何，但可能也大同小異。 Linux.
現實是什麼樣的？
不幸的是，每次客戶要求我為他們建立 VPN 連接時，我都會遇到他們使用過時的憑據和加密的問題。 3DES 結合 MD5 仍然是常見的做法，AES-256 和 SHA1 也是如此。 而且後者雖然稍微好一點，但這也不是2020年應該用的東西。
用於密鑰交換 總是 使用 RSA - 一種緩慢但相當安全的工具。
我的客戶與海關當局和其他政府組織和機構以及世界知名的大公司有聯繫。 他們都使用幾十年前創建的申請表，並且從未添加使用 SHA-512 的能力。 我不能說它以某種方式明顯地影響了技術進步，但顯然它減慢了公司流程。
看到這一點讓我很痛苦，因為 IPsec 從 2005 年開始就支持橢圓曲線。Curve25519 也較新並且可以使用。 也有 AES 的替代品，如 Camellia 和 ChaCha20，但顯然並非所有這些都得到 Cisco 等主要供應商的支持。
人們利用它。 有許多 Cisco 工具包，有許多設計用於與 Cisco 合作的工具包。 他們是該領域的市場領導者，對任何類型的創新都不太感興趣。
是的，（企業界的）情況很糟糕，但我們不會因此看到任何改變。 WireGuard製造商可能永遠不會發現他們已經使用的工具和加密技術有任何效能問題，也不會發現 IKEv2 有任何問題——因此他們不會尋找替代方案。
總的來說，你有沒有想過放棄思科？
基準測試
現在讓我們來看看文件中的基準測試。 WireGuard雖然這份文件並非科學論文，但我仍然期望開發人員採取更科學的方法，或至少以科學方法作為基準。如果基準測試結果無法復現，那就毫無意義；而如果是在實驗室環境下獲得的基準測試結果，那就更沒有意義了。
組裝中 WireGuard 為 Linux 它利用通用分段卸載 (GSO) 技術獲得優勢。 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 在家工作簡直就是鴕鳥心態的典範。
來源： www.habr.com
