„WireGuard“ pastaruoju metu sulaukia daug dėmesio, iš tikrųjų tai yra nauja žvaigždė tarp VPN. Bet ar jis toks geras, kaip atrodo? Norėčiau aptarti keletą pastebėjimų ir apžvelgti „WireGuard“ diegimą, kad paaiškinčiau, kodėl tai nėra sprendimas pakeisti „IPsec“ ar „OpenVPN“.
Šiame straipsnyje norėčiau paneigti kai kuriuos mitus [apie WireGuard]. Taip, skaitymas užtruks ilgai, tad jei nepasidarėte arbatos ar kavos puodelio, pats laikas tai padaryti. Taip pat norėčiau padėkoti Petrui už mano chaotiškų minčių pataisymą.
Nekeliu sau tikslo diskredituoti „WireGuard“ kūrėjus, nuvertinti jų pastangas ar idėjas. Jų produktas veikia, bet asmeniškai manau, kad jis pateikiamas visiškai kitaip nei yra iš tikrųjų – jis pristatomas kaip IPsec ir OpenVPN pakaitalas, kurių iš tikrųjų dabar tiesiog nėra.
Kaip pastabą noriu pridurti, kad atsakomybė už tokį „WireGuard“ pozicionavimą tenka žiniasklaidai, kuri apie tai kalbėjo, o ne pačiam projektui ar jo kūrėjams.
Pastaruoju metu nebuvo daug gerų naujienų apie Linux branduolį. Taigi, mums buvo pasakyta apie siaubingus procesoriaus pažeidžiamumus, kuriuos išlygino programinė įranga, o Linus Torvaldsas apie tai kalbėjo pernelyg grubiai ir nuobodžiai, utilitarine kūrėjo kalba. Tvarkaraštis arba nulinio lygio tinklo dėklas taip pat nėra labai aiškios blizgių žurnalų temos. Ir čia ateina „WireGuard“.
Ant popieriaus viskas skamba puikiai: nauja įdomi technologija.
Bet pažvelkime į tai šiek tiek atidžiau.
WireGuard baltas popierius
Šis straipsnis yra pagrįstas parašė Jasonas Donenfeldas. Ten jis paaiškina [WireGuard] koncepciją, paskirtį ir techninį įgyvendinimą Linux branduolyje.
Pirmas sakinys skamba:
„WireGuard […]“ siekia pakeisti tiek IPsec, tiek daugeliu atvejų, ir kitus populiarius vartotojo erdvės ir (arba) TLS pagrindu veikiančius sprendimus, tokius kaip „OpenVPN“, tuo pačiu užtikrinant saugumą, našumą ir lengviau naudojamą [įrankį].
Žinoma, pagrindinis visų naujų technologijų pranašumas yra jų paprastumas [lyginant su pirmtakais]. Tačiau VPN taip pat turėtų būti efektyvus ir saugus.
Taigi, kas toliau?
Jei sakote, kad tai nėra tai, ko jums reikia [iš VPN], skaitymą galite baigti čia. Tačiau atkreipsiu dėmesį, kad tokios užduotys keliamos bet kuriai kitai tuneliavimo technologijai.
Įdomiausia iš minėtos citatos slypi žodžiais „daugeliu atvejų“, kuriuos, žinoma, spauda ignoravo. Taigi, mes esame ten, kur atsidūrėme dėl šio aplaidumo sukurto chaoso – šiame straipsnyje.
Ar „WireGuard“ pakeis mano [IPsec] svetainių VPN?
Nr. Tiesiog nėra jokios tikimybės, kad dideli pardavėjai, tokie kaip „Cisco“, „Juniper“ ir kiti, pirks „WireGuard“ savo produktams. Jie „nešoka į pravažiuojančius traukinius“ važiuodami, nebent tam labai reikia. Vėliau apžvelgsiu kai kurias priežastis, kodėl jie tikriausiai negalės gauti savo „WireGuard“ produktų, net jei to norėtų.
Ar WireGuard nuneš mano RoadWarrior iš nešiojamojo kompiuterio į duomenų centrą?
Nr. Šiuo metu „WireGuard“ neturi daugybės svarbių funkcijų, kad galėtų atlikti kažką panašaus. Pavyzdžiui, jis negali naudoti dinaminių IP adresų tunelinio serverio pusėje, o vien tai sulaužo visą tokio produkto naudojimo scenarijų.
IPFire dažnai naudojamas pigiems interneto saitams, pvz., DSL arba kabeliniam ryšiui. Tai prasminga mažoms ar vidutinėms įmonėms, kurioms nereikia greito pluošto. [Pastaba iš vertėjo: nepamirškite, kad komunikacijos prasme Rusija ir kai kurios NVS šalys toli lenkia Europą ir JAV, nes savo tinklus pradėjome kurti daug vėliau ir atsiradus Ethernet ir šviesolaidiniams tinklams. standartą, mums buvo lengviau atstatyti. Tose pačiose ES ar JAV šalyse 3-5 Mbps sparta xDSL plačiajuosčio ryšio prieiga vis dar yra įprasta norma, o šviesolaidinis ryšys kainuoja mūsų standartais nerealius pinigus. Todėl straipsnio autorius apie DSL arba kabelinį ryšį kalba kaip apie normą, o ne apie senus laikus.] Tačiau DSL, kabelinė, LTE (ir kiti belaidžio ryšio prieigos būdai) turi dinaminius IP adresus. Žinoma, kartais jie keičiasi ne dažnai, bet keičiasi.
Yra subprojektas, vadinamas , kuris prideda vartotojo erdvės demoną, kad pašalintų šį trūkumą. Didžiulė aukščiau aprašyto vartotojo scenarijaus problema yra dinaminio IPv6 adresavimo pablogėjimas.
Platintojo požiūriu visa tai irgi neatrodo labai gerai. Vienas iš projektavimo tikslų buvo, kad protokolas būtų paprastas ir švarus.
Deja, visa tai iš tikrųjų tapo pernelyg paprasta ir primityvu, todėl turime naudoti papildomą programinę įrangą, kad visas šis dizainas būtų gyvybingas realiai.
Ar „WireGuard“ taip lengva naudotis?
Dar ne. Nesakau, kad „WireGuard“ niekada nebus gera alternatyva tuneliavimui tarp dviejų taškų, tačiau kol kas tai tik produkto, kuris turėtų būti, alfa versija.
Bet ką jis iš tikrųjų daro tada? Ar tikrai „IPsec“ daug sunkiau prižiūrėti?
Akivaizdu, kad ne. IPsec pardavėjas pagalvojo apie tai ir pristato savo produktą kartu su sąsaja, pvz., su IPFire.
Norėdami nustatyti VPN tunelį per IPsec, jums reikės penkių duomenų rinkinių, kuriuos turėsite įvesti į konfigūraciją: jūsų viešasis IP adresas, viešasis priimančios šalies IP adresas, potinkliai, kuriuos norite paskelbti viešai. šį VPN ryšį ir iš anksto bendrinamą raktą. Taigi VPN nustatomas per kelias minutes ir yra suderinamas su bet kuriuo pardavėju.
Deja, šioje istorijoje yra keletas išimčių. Kiekvienas, kuris bandė tuneliuoti per IPsec į OpenBSD mašiną, žino, apie ką aš kalbu. Yra dar keli skaudūs pavyzdžiai, bet iš tikrųjų yra daug daugiau gerų IPsec naudojimo praktikų.
Apie protokolo sudėtingumą
Galutiniam vartotojui nereikia jaudintis dėl protokolo sudėtingumo.
Jei gyventume pasaulyje, kuriame tai būtų tikras vartotojo rūpestis, jau seniai būtume atsikratę SIP, H.323, FTP ir kitų daugiau nei prieš dešimt metų sukurtų protokolų, kurie neveikia gerai su NAT.
Yra priežasčių, kodėl „IPsec“ yra sudėtingesnis nei „WireGuard“: jis atlieka daug daugiau dalykų. Pavyzdžiui, vartotojo autentifikavimas naudojant prisijungimo vardą / slaptažodį arba SIM kortelę su EAP. Jis turi išplėstą galimybę pridėti naujų .
Ir WireGuard to neturi.
O tai reiškia, kad „WireGuard“ kažkada suges, nes vienas iš kriptografinių primityvų susilpnės arba bus visiškai pažeistas. Techninės dokumentacijos autorius sako taip:
Verta paminėti, kad „WireGuard“ turi kriptografinę nuomonę. Sąmoningai trūksta šifrų ir protokolų lankstumo. Jei pagrindiniuose primityvuose randama rimtų skylių, reikės atnaujinti visus galutinius taškus. Kaip matote iš nuolatinio SLL/TLS pažeidžiamumų srauto, šifravimo lankstumas dabar nepaprastai išaugo.
Paskutinis sakinys visiškai teisingas.
Pasiekus sutarimą, kokį šifravimą naudoti, sukuriami tokie protokolai kaip IKE ir TLS daugiau kompleksas. Per daug komplikuota? Taip, TLS/SSL pažeidžiamumai yra gana dažni ir jiems nėra alternatyvos.
Apie tikrų problemų ignoravimą
Įsivaizduokite, kad kažkur pasaulyje turite VPN serverį su 200 kovinių klientų. Tai gana standartinis naudojimo atvejis. Jei turite pakeisti šifravimą, turite pateikti naujinimą į visas WireGuard kopijas šiuose nešiojamuosiuose kompiuteriuose, išmaniuosiuose telefonuose ir pan. Tuo pačiu metu pristatyti. Tai tiesiogine prasme neįmanoma. Administratoriai, bandantys tai padaryti, užtruks mėnesius, kol įdiegs reikiamas konfigūracijas, o vidutinei įmonei prireiks metų, kad surengtų tokį įvykį.
IPsec ir OpenVPN siūlo šifravimo derybų funkciją. Todėl kurį laiką, po kurio įjungsite naują šifravimą, senasis taip pat veiks. Tai leis esamiems klientams atnaujinti į naują versiją. Išleidę naujinimą, tiesiog išjunkite pažeidžiamą šifravimą. Štai ir viskas! Pasiruošę! tu nuostabus! Klientai to net nepastebės.
Tai iš tikrųjų yra labai dažnas didelių diegimų atvejis, ir net „OpenVPN“ turi tam tikrų sunkumų. Atgalinis suderinamumas yra svarbus, ir net jei naudojate silpnesnį šifravimą, daugeliui tai nėra priežastis uždaryti verslą. Nes tai paralyžiuos šimtų klientų darbą dėl nesugebėjimo atlikti savo darbo.
„WireGuard“ komanda padarė savo protokolą paprastesnį, bet visiškai netinkamą naudoti žmonėms, kurie nuolat nekontroliuoja abiejų savo tunelyje esančių bendraamžių. Mano patirtis rodo, kad tai yra labiausiai paplitęs scenarijus.
Kriptografija!
Bet kas yra šis įdomus naujas šifravimas, kurį naudoja „WireGuard“?
„WireGuard“ naudoja „Curve25519“ raktų mainams, „ChaCha20“ šifravimui ir „Poly1305“ duomenų autentifikavimui. Jis taip pat veikia su SipHash maišos raktams ir BLAKE2 maišai.
ChaCha20-Poly1305 yra standartizuotas IPsec ir OpenVPN (per TLS).
Akivaizdu, kad Danielio Bernsteino kūrinys naudojamas labai dažnai. BLAKE2 yra BLAKE įpėdinis, SHA-3 finalininkas, kuris nelaimėjo dėl savo panašumo į SHA-2. Jei SHA-2 būtų sugadintas, yra didelė tikimybė, kad BLAKE taip pat bus pažeista.
Dėl jų dizaino „IPsec“ ir „OpenVPN“ nereikia „SipHash“. Taigi vienintelis dalykas, kurio šiuo metu su jais negalima naudoti, yra BLAKE2, ir tai tik tol, kol jis nebus standartizuotas. Tai nėra didelis trūkumas, nes VPN naudoja HMAC, kad sukurtų vientisumą, kuris laikomas stipriu sprendimu net ir kartu su MD5.
Taigi padariau išvadą, kad beveik tas pats kriptografinių įrankių rinkinys naudojamas visuose VPN. Todėl „WireGuard“ yra ne daugiau ar mažiau saugus nei bet kuris kitas dabartinis produktas, kai kalbama apie šifravimą ar perduodamų duomenų vientisumą.
Tačiau net ir tai nėra svarbiausias dalykas, į kurį pagal oficialią projekto dokumentaciją verta atkreipti dėmesį. Juk svarbiausia – greitis.
Ar „WireGuard“ yra greitesnis nei kiti VPN sprendimai?
Trumpai: ne, ne greičiau.
ChaCha20 yra srauto šifras, kurį lengviau įdiegti programinėje įrangoje. Jis šifruoja po vieną bitą. Blokų protokolai, tokie kaip AES, vienu metu užšifruoja bloką 128 bitais. Norint įdiegti aparatūros palaikymą, reikia daug daugiau tranzistorių, todėl didesni procesoriai yra su AES-NI – instrukcijų rinkinio plėtiniu, kuris atlieka kai kurias šifravimo proceso užduotis, kad jį pagreitintų.
Buvo tikimasi, kad AES-NI niekada nepateks į išmaniuosius telefonus [bet tai padarė – apytiksliai. per.]. Tam ChaCha20 buvo sukurtas kaip lengva, akumuliatorių taupanti alternatyva. Todėl jums gali būti naujiena, kad kiekvienas išmanusis telefonas, kurį galite įsigyti šiandien, turi tam tikrą AES pagreitį ir veikia greičiau bei sunaudoja mažiau energijos su šiuo šifravimu nei su ChaCha20.
Akivaizdu, kad beveik kiekvienas stalinio kompiuterio / serverio procesorius, pirktas per pastaruosius porą metų, turi AES-NI.
Todėl tikiuosi, kad AES pranoks ChaCha20 kiekviename scenarijuje. Oficialioje „WireGuard“ dokumentacijoje minima, kad naudojant AVX512 „ChaCha20-Poly1305“ pranoks AES-NI, tačiau šis instrukcijų rinkinio plėtinys bus pasiekiamas tik didesniuose procesoriuose, o tai vėlgi nepadės naudojant mažesnę ir mobilesnę aparatinę įrangą, kuri visada bus greitesnė naudojant AES. - N.I.
Nesu tikras, ar tai buvo galima numatyti kuriant WireGuard, tačiau šiandien tai, kad jis prikaltas vien prie šifravimo, jau yra trūkumas, kuris gali nelabai paveikti jo veikimą.
IPsec leidžia laisvai pasirinkti, kuris šifravimas geriausiai tinka jūsų atveju. Ir, žinoma, tai būtina, jei, pavyzdžiui, norite per VPN ryšį perkelti 10 ar daugiau gigabaitų duomenų.
„Linux“ integravimo problemos
Nors WireGuard pasirinko modernų šifravimo protokolą, tai jau sukelia daug problemų. Taigi, užuot naudoję tai, ką palaiko branduolys, WireGuard integravimas buvo atidėtas daugelį metų, nes Linux sistemoje trūksta šių primityvų.
Nesu visiškai tikras, kokia padėtis yra kitose operacinėse sistemose, bet tikriausiai ji nelabai skiriasi nuo Linux.
Kaip atrodo realybė?
Deja, kiekvieną kartą, kai klientas prašo manęs nustatyti jiems VPN ryšį, susiduriu su problema, kad jie naudoja pasenusius kredencialus ir šifravimą. 3DES kartu su MD5 vis dar yra įprasta praktika, kaip ir AES-256 ir SHA1. Ir nors pastarasis yra šiek tiek geresnis, tai nėra kažkas, ko reikėtų naudoti 2020 m.
Dėl raktų keitimo visada Naudojama RSA – lėta, bet pakankamai saugi priemonė.
Mano klientai yra susiję su muitinėmis ir kitomis vyriausybinėmis organizacijomis bei institucijomis, taip pat su didelėmis korporacijomis, kurių pavadinimai žinomi visame pasaulyje. Jie visi naudoja užklausos formą, kuri buvo sukurta prieš dešimtmečius, o galimybė naudoti SHA-512 tiesiog nebuvo pridėta. Negaliu teigti, kad tai kažkaip aiškiai veikia technologinę pažangą, bet akivaizdu, kad tai lėtina įmonės procesą.
Man skaudu tai matyti, nes IPsec nuo 2005 m. palaiko elipsines kreives. Curve25519 taip pat yra naujesnė ir galima naudoti. Taip pat yra AES alternatyvų, tokių kaip Camellia ir ChaCha20, tačiau akivaizdu, kad ne visas jas palaiko pagrindiniai pardavėjai, tokie kaip Cisco ir kiti.
Ir žmonės tuo naudojasi. Yra daug Cisco rinkinių, yra daug rinkinių, skirtų dirbti su Cisco. Jie yra šio segmento rinkos lyderiai ir nėra labai suinteresuoti jokiomis naujovėmis.
Taip, situacija [įmonių segmente] yra baisi, bet dėl „WireGuard“ pokyčių nepamatysime. Pardavėjai tikriausiai niekada nepastebės jokių našumo problemų dėl jau naudojamų įrankių ir šifravimo, nematys problemų su IKEv2, todėl jie neieško alternatyvų.
Apskritai, ar kada nors galvojote apie „Cisco“ atsisakymą?
Etalonai
O dabar pereikime prie „WireGuard“ dokumentacijos etalonų. Nors ši [dokumentacija] nėra mokslinis straipsnis, aš vis tiek tikėjausi, kad kūrėjai imsis moksliškesnio požiūrio arba naudos mokslinį požiūrį kaip nuorodą. Bet kokie etalonai yra nenaudingi, jei jų negalima atkurti, ir dar nenaudingesni, kai jie gaunami laboratorijoje.
„Linux“ versijoje „WireGuard“ naudoja GSO – bendro segmentavimo iškrovimo pranašumus. Jo dėka klientas sukuria didžiulį 64 kilobaitų paketą ir vienu ypu užšifruoja / iššifruoja. Taigi sumažėja kriptografinių operacijų iškvietimo ir įgyvendinimo išlaidos. Jei norite maksimaliai padidinti VPN ryšio pralaidumą, tai yra gera idėja.
Tačiau, kaip įprasta, realybė nėra tokia paprasta. Norint siųsti tokį didelį paketą į tinklo adapterį, jį reikia supjaustyti į daug mažesnių paketų. Įprastas siuntimo dydis yra 1500 baitų. Tai yra, mūsų 64 kilobaitų milžinas bus padalintas į 45 paketus (1240 baitų informacijos ir 20 baitų IP antraštės). Tada kurį laiką jie visiškai blokuos tinklo adapterio darbą, nes jie turi būti siunčiami kartu ir iš karto. Dėl to tai sukels prioritetinį šuolį, o paketai, pvz., VoIP, bus įrašyti į eilę.
Taigi didelis pralaidumas, apie kurį taip drąsiai teigia „WireGuard“, pasiekiamas sulėtėjus kitų programų tinklų kūrimui. Ir WireGuard komanda jau yra tokia mano išvada.
Bet eikime toliau.
Remiantis techninėje dokumentacijoje esančiais etalonais, ryšio pralaidumas yra 1011 Mbps.
Įspūdingas.
Tai ypač įspūdinga dėl to, kad didžiausias teorinis vieno Gigabit Ethernet ryšio pralaidumas yra 966 Mbps, kai paketo dydis yra 1500 baitų, atėmus 20 baitų IP antraštei, 8 baitai UDP antraštei ir 16 baitų antraštei pats WireGuard. Inkapsuliuotame pakete yra dar viena IP antraštė, o TCP - dar viena 20 baitų. Taigi iš kur atsirado šis papildomas pralaidumas?
Turint didžiulius kadrus ir GSO pranašumus, apie kuriuos kalbėjome aukščiau, teorinis maksimalus 9000 baitų kadro dydis būtų 1014 Mbps. Paprastai toks pralaidumas realybėje nepasiekiamas, nes susijęs su dideliais sunkumais. Taigi, galiu tik daryti prielaidą, kad testas buvo atliktas naudojant dar riebesnius per didelius 64 kilobaitų kadrus su teoriniu maksimumu 1023 Mbps, kurį palaiko tik kai kurie tinklo adapteriai. Tačiau tai visiškai netaikoma realiomis sąlygomis arba gali būti naudojama tik tarp dviejų tiesiogiai sujungtų stočių, išskirtinai tik bandymų stende.
Bet kadangi VPN tunelis yra persiunčiamas tarp dviejų kompiuterių, naudojant interneto ryšį, kuris visiškai nepalaiko „jumbo“ kadrų, rezultatas, pasiektas stende, negali būti laikomas etalonu. Tai tiesiog nerealus laboratorinis pasiekimas, kuris neįmanomas ir nepritaikomas realiomis kovos sąlygomis.
Net sėdėdamas duomenų centre negalėjau perkelti didesnių nei 9000 baitų kadrų.
Pritaikomumo realiame gyvenime kriterijus yra absoliučiai pažeistas ir, kaip manau, atlikto „matavimo“ autorius dėl akivaizdžių priežasčių rimtai diskreditavo save.
Paskutinė vilties blykstė
WireGuard svetainėje daug kalbama apie konteinerius ir tampa aišku, kam jis iš tikrųjų skirtas.
Paprastas ir greitas VPN, kuriam nereikia konfigūracijos ir kurį galima įdiegti ir sukonfigūruoti naudojant didžiulius orkestravimo įrankius, tokius kaip „Amazon“ debesyje. Tiksliau, „Amazon“ naudoja naujausias aparatinės įrangos funkcijas, kurias minėjau anksčiau, pvz., AVX512. Tai daroma siekiant pagreitinti darbą ir neprisirišti prie x86 ar kitos architektūros.
Jie optimizuoja pralaidumą ir didesnius nei 9000 baitų paketus – tai bus didžiuliai įkapsuliuoti kadrai, skirti konteineriams bendrauti tarpusavyje, arba atsarginėms operacijoms, kuriant momentines nuotraukas ar diegiant tuos pačius konteinerius. Netgi dinaminiai IP adresai niekaip neturės įtakos WireGuard veikimui mano aprašyto scenarijaus atveju.
Gerai sužaista. Puikus įgyvendinimas ir labai plonas, beveik etaloninis protokolas.
Tačiau jis tiesiog netelpa pasaulyje, esančiame už duomenų centro ribų, kurį visiškai kontroliuojate. Jei surizikuosite ir pradėsite naudoti „WireGuard“, turėsite nuolat leistis į kompromisus kuriant ir įgyvendinant šifravimo protokolą.
Produkcija
Man lengva padaryti išvadą, kad „WireGuard“ dar neparengta.
Jis buvo sumanytas kaip lengvas ir greitas daugelio esamų sprendimų problemų sprendimas. Deja, dėl šių sprendimų jis paaukojo daugybę funkcijų, kurios bus aktualios daugumai vartotojų. Štai kodėl jis negali pakeisti „IPsec“ ar „OpenVPN“.
Kad „WireGuard“ taptų konkurencinga, jai reikia pridėti bent IP adreso nustatymą ir maršruto parinkimo bei DNS konfigūraciją. Akivaizdu, kad tam yra skirti užšifruoti kanalai.
Saugumas yra mano svarbiausias prioritetas, ir šiuo metu neturiu pagrindo manyti, kad IKE ar TLS yra kaip nors pažeisti ar sugadinti. Šiuolaikinis šifravimas palaikomas abiejose, o jų veikimas buvo įrodytas dešimtmečiais. Tai, kad kažkas yra naujesnio, nereiškia, kad jis geresnis.
Sąveika yra nepaprastai svarbi, kai bendraujate su trečiosiomis šalimis, kurių stočių nevaldote. IPsec yra de facto standartas ir palaikomas beveik visur. Ir jis dirba. Ir kad ir kaip atrodytų, teoriškai „WireGuard“ ateityje gali būti nesuderinamas net su skirtingomis savo versijomis.
Bet kokia kriptografinė apsauga anksčiau ar vėliau sugenda ir atitinkamai turi būti pakeista arba atnaujinta.
Visų šių faktų neigimas ir aklas noras naudoti „WireGuard“ savo iPhone prijungti prie namų darbo vietos yra tik meistriškumo klasė, kaip kišti galvą į smėlį.
Šaltinis: www.habr.com