Deivids Millers (), kas atbild par Linux kodola tīkla apakšsistēmu, uz tīklu-nākamo filiāli ar VPN saskarnes ieviešanu no projekta . Nākamā gada sākumā net-next filiālē uzkrātās izmaiņas veidos pamatu Linux kodola 5.6 izlaišanai.
Dažu pēdējo gadu laikā ir veikti mēģinājumi ievietot WireGuard kodu galvenajā kodolā, taču tie joprojām ir bijuši neveiksmīgi, jo tie bija saistīti ar patentētu kriptogrāfijas funkciju ieviešanu, kas tika izmantota veiktspējas uzlabošanai. Sākotnēji šīs funkcijas bija kodolam kā papildu zema līmeņa cinka API, kas galu galā varētu aizstāt standarta Crypto API.
Pēc diskusijām Kernel Recipes konferencē WireGuard veidotāji septembrī pārsūtiet savus ielāpus, lai izmantotu kodolā pieejamo Crypto API, pret kuru WireGuard izstrādātājiem ir sūdzības veiktspējas un vispārējās drošības jomā. Tika nolemts turpināt attīstīt Zinc API, bet kā atsevišķu projektu.
Novembrī kodola izstrādātāji atbildot uz kompromisu, un piekrita pārsūtīt daļu koda no Zinc uz galveno kodolu. Būtībā daži cinka komponenti tiks pārvietoti uz kodolu, bet ne kā atsevišķs API, bet gan kā daļa no Crypto API apakšsistēmas. Piemēram, jau Crypto API ātras ChaCha20 un Poly1305 algoritmu ieviešanas, kas sagatavotas programmā WireGuard.
Saistībā ar gaidāmo WireGuard piegādi galvenajā kodolā, projekta dibinātājs par repozitorija pārstrukturēšanu. Lai vienkāršotu izstrādi, monolītā “WireGuard.git” repozitorija, kas bija paredzēta pastāvēšanai atsevišķi, tiks aizstāta ar trim atsevišķiem repozitorijiem, kas ir labāk piemēroti darba organizēšanai ar kodu galvenajā kodolā:
- - pilns kodola koks ar izmaiņām no Wireguard projekta, no kura tiks pārskatīti ielāpi iekļaušanai kodolā un regulāri pārsūtīti uz net/net-next zariem.
- - repozitorijs utilītprogrammām un skriptiem, kas darbojas lietotāja telpā, piemēram, wg un wg-quick. Repozitoriju var izmantot, lai izveidotu izplatīšanas pakotnes.
- - repozitorijs ar moduļa variantu, kas tiek piegādāts atsevišķi no kodola un ietver compat.h slāni, lai nodrošinātu saderību ar vecākiem kodoliem. Galvenā izstrāde tiks veikta wireguard-linux.git repozitorijā, taču, ja vien lietotāju vidū būs iespēja un vajadzība, darba formā tiks atbalstīta arī atsevišķa ielāpu versija.
Atgādinām, ka VPN WireGuard ir ieviests uz modernu šifrēšanas metožu bāzes, nodrošina ļoti augstu veiktspēju, ir viegli lietojams, bez sarežģījumiem un ir pierādījis sevi vairākos lielos izvietojumos, kas apstrādā lielu trafika apjomu. Projekts tiek izstrādāts kopš 2015. gada, ir veikts audits un izmantotās šifrēšanas metodes. WireGuard atbalsts jau ir integrēts NetworkManager un systemd, un kodola ielāpi ir iekļauti bāzes izplatījumos , Mageia, Alpine, Arch, Gentoo, OpenWrt, NixOS, и .
WireGuard izmanto šifrēšanas atslēgu maršrutēšanas koncepciju, kas ietver privātās atslēgas pievienošanu katram tīkla interfeisam un tās izmantošanu publisko atslēgu saistīšanai. Publiskās atslēgas tiek apmainītas, lai izveidotu savienojumu līdzīgi kā SSH. Lai vienotos par atslēgām un izveidotu savienojumu, nepalaižot atsevišķu dēmonu lietotāja telpā, Noise_IK mehānisms no līdzīgi kā Author_keys uzturēšana SSH. Datu pārraide tiek veikta, iekapsulējot UDP paketēs. Tā atbalsta VPN servera IP adreses maiņu (viesabonēšana), neatvienojot savienojumu un automātiski pārkonfigurējot klientu.
Šifrēšanai straumes šifrs un ziņojumu autentifikācijas algoritms (MAC) , dizains Daniels Bernsteins (), Tanja Lange
(Tanja Lange) un Pīters Švābe. ChaCha20 un Poly1305 ir pozicionēti kā ātrāki un drošāki AES-256-CTR un HMAC analogi, kuru programmatūras ieviešana ļauj sasniegt fiksētu izpildes laiku, neizmantojot īpašu aparatūras atbalstu. Lai ģenerētu koplietotu slepeno atslēgu, ieviešanā tiek izmantots eliptiskās līknes Difija-Helmana protokols , ko ierosinājis arī Daniels Bernsteins. Jaukšanai izmantotais algoritms ir .
Pie Performance WireGuard demonstrēja 3.9 reizes lielāku caurlaidspēju un 3.8 reizes lielāku atsaucību salīdzinājumā ar OpenVPN (256 bitu AES ar HMAC-SHA2-256). Salīdzinot ar IPsec (256 bitu ChaCha20+Poly1305 un AES-256-GCM-128), WireGuard uzrāda nelielu veiktspējas uzlabojumu (13–18%) un mazāku latentumu (21–23%). Pārbaudes tika veiktas, izmantojot projekta izstrādāto šifrēšanas algoritmu ātras ieviešanas - pāreja uz kodola standarta Crypto API var izraisīt sliktāku veiktspēju.
Avots: opennet.ru