WireGuard zadnje čase vzbuja veliko pozornosti, pravzaprav je nova zvezda med VPN-ji. Toda ali je tako dober, kot se zdi? Rad bi razpravljal o nekaterih opažanjih in pregledal implementacijo WireGuarda, da bi pojasnil, zakaj ni rešitev za zamenjavo IPsec ali OpenVPN.
V tem članku bi rad razkril nekatere mite [o WireGuardu]. Da, branje bo trajalo veliko časa, tako da, če si še niste skuhali skodelice čaja ali kave, je čas, da to storite. Prav tako bi se rada zahvalila Petru, ker je popravil moje kaotične misli.
Ne postavljam si za cilj diskreditirati razvijalce WireGuarda, razvrednotiti njihova prizadevanja ali ideje. Njihov produkt sicer deluje, a osebno menim, da je predstavljen popolnoma drugače kot v resnici - predstavljen je kot zamenjava za IPsec in OpenVPN, ki pa v resnici zdaj preprosto ne obstajata.
Kot opombo bi rad dodal, da so za takšno pozicioniranje WireGuarda odgovorni mediji, ki so o tem govorili, in ne projekt sam ali njegovi ustvarjalci.
Zadnje čase ni veliko dobrih novic o jedru Linuxa. Tako so nam povedali o pošastnih ranljivostih procesorja, ki jih je izravnala programska oprema, Linus Torvalds pa je o tem govoril preveč nesramno in dolgočasno, v utilitarističnem jeziku razvijalca. Razporejevalnik ali omrežni sklad ničelne ravni prav tako nista zelo jasni temi za sijajne revije. In prihaja WireGuard.
Na papirju se vse sliši odlično: vznemirljiva nova tehnologija.
A poglejmo ga malo bolj natančno.
Beli papir WireGuard
Ta članek temelji na napisal Jason Donenfeld. Tam pojasnjuje koncept, namen in tehnično izvedbo [WireGuard] v jedru Linuxa.
Prvi stavek se glasi:
WireGuard […] želi nadomestiti IPsec v večini primerov uporabe in druge priljubljene rešitve, ki temeljijo na uporabniškem prostoru in/ali TLS, kot je OpenVPN, hkrati pa je bolj varno, zmogljivo in enostavnejše za uporabo [orodje].
Seveda je glavna prednost vseh novih tehnologij njihov preprostost [v primerjavi s predhodniki]. Vendar bi moral biti tudi VPN učinkovito in varno.
Torej, kaj je naslednje?
Če rečete, da to ni tisto, kar potrebujete [od VPN], potem lahko tukaj končate branje. Vendar bom omenil, da so takšne naloge določene za katero koli drugo tehnologijo tuneliranja.
Najbolj zanimivo v zgornjem citatu so besede "v večini primerov", ki jih je tisk seveda prezrl. In tako smo tam, kjer smo pristali zaradi kaosa, ki ga je ustvarila ta malomarnost – v tem članku.
Ali bo WireGuard nadomestil moj [IPsec] VPN od mesta do mesta?
št. Preprosto ni možnosti, da bi veliki prodajalci, kot so Cisco, Juniper in drugi, kupili WireGuard za svoje izdelke. Na poti ne "skočijo na mimoidoče vlake", razen če je to resna potreba. Kasneje bom preučil nekaj razlogov, zakaj verjetno ne bodo mogli vključiti svojih izdelkov WireGuard, tudi če bi to želeli.
Ali bo WireGuard prenesel moj RoadWarrior iz prenosnika v podatkovni center?
št. Trenutno WireGuard nima implementiranih ogromnih pomembnih funkcij, da bi lahko naredil kaj takega. Na primer, ne more uporabljati dinamičnih naslovov IP na strani tunelskega strežnika in samo to prekine celoten scenarij takšne uporabe izdelka.
IPFire se pogosto uporablja za poceni internetne povezave, kot so DSL ali kabelske povezave. To je smiselno za mala ali srednje velika podjetja, ki ne potrebujejo hitrih vlaken. [Opomba prevajalca: ne pozabite, da so Rusija in nekatere države CIS v komunikaciji daleč pred Evropo in Združenimi državami, saj smo svoja omrežja začeli graditi veliko pozneje in s prihodom Etherneta in optičnih omrežij kot standard, nam je bilo lažje obnoviti. V istih državah EU ali ZDA je širokopasovni dostop xDSL s hitrostjo 3-5 Mbps še vedno splošna norma, optična povezava pa stane nekaj nerealnih denarjev za naše standarde. Zato avtor članka govori o DSL ali kabelski povezavi kot normi in ne o starih časih.] Vendar imajo DSL, kabel, LTE (in drugi načini brezžičnega dostopa) dinamične naslove IP. Seveda se včasih ne spreminjajo pogosto, vendar se spreminjajo.
Obstaja podprojekt, imenovan , ki dodaja demon uporabniškega prostora za odpravo te pomanjkljivosti. Velika težava zgoraj opisanega uporabniškega scenarija je poslabšanje dinamičnega naslavljanja IPv6.
Tudi z vidika distributerja vse to ne izgleda preveč dobro. Eden od ciljev oblikovanja je bil ohraniti protokol preprost in čist.
Na žalost je vse to dejansko postalo preveč preprosto in primitivno, tako da moramo uporabljati dodatno programsko opremo, da bi ta celotna zasnova sploh delovala v realni uporabi.
Je WireGuard tako enostaven za uporabo?
Ne še. Ne trdim, da WireGuard nikoli ne bo dobra alternativa za tuneliranje med dvema točkama, a za zdaj je le alfa različica izdelka, ki naj bi bil.
Toda kaj potem pravzaprav počne? Je IPsec res toliko težje vzdrževati?
Očitno ne. Prodajalec IPsec je pomislil na to in pošilja svoj izdelek skupaj z vmesnikom, na primer z IPFire.
Za nastavitev tunela VPN prek IPsec boste potrebovali pet nizov podatkov, ki jih boste morali vnesti v konfiguracijo: svoj javni naslov IP, javni naslov IP prejemne strani, podomrežja, ki jih želite objaviti prek ta povezava VPN in ključ v vnaprejšnji skupni rabi. Tako je VPN nastavljen v nekaj minutah in je združljiv s katerim koli ponudnikom.
Na žalost je v tej zgodbi nekaj izjem. Vsakdo, ki je poskušal vzpostaviti tunel prek IPsec do stroja OpenBSD, ve, o čem govorim. Obstaja še nekaj bolečih primerov, v resnici pa obstaja veliko, veliko več dobrih praks za uporabo IPsec.
O kompleksnosti protokola
Končnemu uporabniku ni treba skrbeti za kompleksnost protokola.
Če bi živeli v svetu, kjer bi bila to prava skrb uporabnika, bi se že zdavnaj znebili SIP, H.323, FTP in drugih pred več kot desetimi leti ustvarjenih protokolov, ki ne delujejo dobro z NAT.
Obstajajo razlogi, zakaj je IPsec bolj zapleten kot WireGuard: počne veliko več stvari. Na primer, preverjanje pristnosti uporabnika z uporabo prijave / gesla ali kartice SIM z EAP. Ima razširjeno možnost dodajanja novega .
In WireGuard tega nima.
In to pomeni, da se bo WireGuard na neki točki zlomil, ker bo ena od kriptografskih primitiv oslabela ali popolnoma ogrožena. Avtor tehnične dokumentacije pravi takole:
Omeniti velja, da je WireGuard kriptografsko prepričan. Namerno mu primanjkuje prilagodljivosti šifer in protokolov. Če se najdejo resne luknje v temeljnih primitivih, bo treba posodobiti vse končne točke. Kot lahko vidite iz nenehnega toka ranljivosti SLL/TLS, se je prilagodljivost šifriranja zdaj izjemno povečala.
Zadnji stavek je popolnoma pravilen.
Doseganje soglasja o tem, katero šifriranje uporabiti, naredi protokole, kot sta IKE in TLS bolj kompleksen. Preveč zapleteno? Da, ranljivosti so v TLS/SSL precej pogoste in zanje ni druge alternative.
O ignoriranju resničnih problemov
Predstavljajte si, da imate strežnik VPN z 200 bojnimi odjemalci nekje po svetu. To je precej standarden primer uporabe. Če morate spremeniti šifriranje, morate posodobitev dostaviti vsem kopijam WireGuarda na teh prenosnikih, pametnih telefonih itd. Hkrati dostaviti. To je dobesedno nemogoče. Skrbniki, ki to poskušajo narediti, bodo potrebovali mesece, da uvedejo zahtevane konfiguracije, srednje velika podjetja pa bodo dobesedno potrebovala leta, da bodo izvedla tak dogodek.
IPsec in OpenVPN ponujata funkcijo šifriranja. Zato bo nekaj časa, po katerem vklopite novo šifriranje, delovalo tudi staro. To bo trenutnim strankam omogočilo nadgradnjo na novo različico. Ko je posodobitev uvedena, preprosto izklopite ranljivo šifriranje. In to je to! pripravljena! ti si čudovit! Stranke ne bodo niti opazile.
To je pravzaprav zelo pogost primer pri velikih uvajanjih in celo OpenVPN ima nekaj težav s tem. Združljivost s prejšnjimi različicami je pomembna in čeprav uporabljate šibkejše šifriranje, za mnoge to ni razlog za zaprtje podjetja. Ker bo zaradi nezmožnosti opravljanja svojega dela ohromil delo na stotine strank.
Ekipa WireGuard je naredila svoj protokol enostavnejši, vendar popolnoma neuporaben za ljudi, ki nimajo stalnega nadzora nad obema vrstnikoma v svojem tunelu. Po mojih izkušnjah je to najpogostejši scenarij.
Kriptografija!
Toda kaj je to zanimivo novo šifriranje, ki ga uporablja WireGuard?
WireGuard uporablja Curve25519 za izmenjavo ključev, ChaCha20 za šifriranje in Poly1305 za avtentikacijo podatkov. Deluje tudi s SipHash za zgoščevalne ključe in BLAKE2 za zgoščevanje.
ChaCha20-Poly1305 je standardiziran za IPsec in OpenVPN (preko TLS).
Očitno je, da se razvoj Daniela Bernsteina uporablja zelo pogosto. BLAKE2 je naslednik BLAKE-a, finalista SHA-3, ki ni zmagal zaradi podobnosti s SHA-2. Če bi SHA-2 zlomil, obstaja velika verjetnost, da bi bil ogrožen tudi BLAKE.
IPsec in OpenVPN zaradi svoje zasnove ne potrebujeta SipHash. Torej edina stvar, ki je trenutno ni mogoče uporabljati z njimi, je BLAKE2, in to samo dokler ni standardiziran. To ni velika pomanjkljivost, saj VPN-ji uporabljajo HMAC za ustvarjanje integritete, kar velja za močno rešitev tudi v povezavi z MD5.
Tako sem prišel do zaključka, da se v vseh VPN-jih uporablja skoraj enak nabor kriptografskih orodij. Zato WireGuard ni nič bolj ali manj varen kot kateri koli drug trenutni izdelek, ko gre za šifriranje ali celovitost prenesenih podatkov.
A tudi to ni najpomembnejše, na kar je po uradni dokumentaciji projekta vredno biti pozoren. Navsezadnje je glavna stvar hitrost.
Je WireGuard hitrejši od drugih rešitev VPN?
Na kratko: ne, ne hitreje.
ChaCha20 je tokovna šifra, ki jo je lažje implementirati v programsko opremo. Šifrira en bit naenkrat. Protokoli blokov, kot je AES, šifrirajo blok 128 bitov naenkrat. Za izvajanje podpore za strojno opremo je potrebnih veliko več tranzistorjev, zato večji procesorji prihajajo z AES-NI, razširitvijo nabora navodil, ki opravlja nekatere naloge postopka šifriranja, da ga pospeši.
Pričakovano je bilo, da AES-NI nikoli ne bo prišel v pametne telefone [vendar se je — pribl. per.]. Za to je bil ChaCha20 razvit kot lahka alternativa, ki varčuje z baterijo. Zato vam bo morda novica, da ima vsak pametni telefon, ki ga lahko kupite danes, nekakšen pospešek AES in s tem šifriranjem deluje hitreje ter z manjšo porabo energije kot s ChaCha20.
Očitno ima skoraj vsak namizni/strežniški procesor, kupljen v zadnjih nekaj letih, AES-NI.
Zato pričakujem, da bo AES v vsakem posameznem scenariju presegel ChaCha20. Uradna dokumentacija WireGuarda omenja, da bo z AVX512 ChaCha20-Poly1305 prekašal AES-NI, vendar bo ta razširitev nabora navodil na voljo le na večjih procesorjih, kar spet ne bo pomagalo pri manjši in bolj mobilni strojni opremi, ki bo vedno hitrejša z AES - N.I.
Nisem prepričan, ali je bilo to mogoče predvideti med razvojem WireGuarda, a danes je dejstvo, da je prikovan samo na šifriranje, že pomanjkljivost, ki morda ne bo najbolje vplivala na njegovo delovanje.
IPsec vam omogoča, da prosto izberete, katero šifriranje je najboljše za vaš primer. In seveda, to je potrebno, če na primer želite prenesti 10 ali več gigabajtov podatkov prek povezave VPN.
Težave z integracijo v Linuxu
Čeprav je WireGuard izbral sodoben šifrirni protokol, že to povzroča nemalo težav. In tako je bila integracija WireGuarda več let odložena zaradi pomanjkanja teh primitivov v Linuxu, namesto da bi uporabljali tisto, kar podpira že pripravljeno jedro.
Nisem povsem prepričan, kakšna je situacija v drugih operacijskih sistemih, vendar verjetno ni veliko drugačna kot v Linuxu.
Kako izgleda realnost?
Na žalost vsakič, ko me stranka prosi, da zanjo vzpostavim povezavo VPN, naletim na težavo, da uporablja zastarele poverilnice in šifriranje. 3DES v povezavi z MD5 je še vedno običajna praksa, tako kot AES-256 in SHA1. In čeprav je slednji nekoliko boljši, to ni nekaj, kar bi veljalo uporabljati leta 2020.
Za menjavo ključev vedno Uporablja se RSA - počasno, a dokaj varno orodje.
Moje stranke so povezane s carinskimi organi in drugimi vladnimi organizacijami in institucijami, pa tudi z velikimi korporacijami, katerih imena so znana po vsem svetu. Vsi uporabljajo obrazec za zahtevo, ki je bil ustvarjen pred desetletji, možnost uporabe SHA-512 pa preprosto ni bila nikoli dodana. Ne morem reči, da nekako jasno vpliva na tehnološki napredek, očitno pa upočasnjuje korporativni proces.
Boli me, ko to vidim, ker IPsec že od leta 2005 podpira eliptične krivulje. Curve25519 je tudi novejši in na voljo za uporabo. Obstajajo tudi alternative za AES, kot sta Camellia in ChaCha20, vendar očitno ne podpirajo vseh glavni prodajalci, kot so Cisco in drugi.
In ljudje to izkoriščajo. Obstaja veliko kompletov Cisco, veliko kompletov je zasnovanih za delo s Ciscom. V tem segmentu so vodilni na trgu in jih kakršne koli novosti ne zanimajo preveč.
Da, stanje [v podjetniškem segmentu] je grozno, vendar zaradi WireGuarda ne bomo videli nobenih sprememb. Prodajalci verjetno nikoli ne bodo opazili nobenih težav z zmogljivostjo z orodji in šifriranjem, ki jih že uporabljajo, ne bodo opazili nobenih težav z IKEv2 in zato ne iščejo alternativ.
Ste na splošno kdaj razmišljali, da bi opustili Cisco?
Merila uspešnosti
Zdaj pa preidimo na merila uspešnosti iz dokumentacije WireGuard. Čeprav ta [dokumentacija] ni znanstveni članek, sem vseeno pričakoval, da bodo razvijalci ubrali bolj znanstveni pristop ali uporabili znanstveni pristop kot referenco. Kakršna koli merila so neuporabna, če jih ni mogoče reproducirati, še bolj pa so neuporabna, če so pridobljena v laboratoriju.
V različici WireGuard za Linux izkorišča prednosti uporabe GSO – Generic Segmentation Offloading. Zahvaljujoč njemu odjemalec ustvari ogromen paket 64 kilobajtov in ga šifrira / dešifrira v enem zamahu. Tako se zmanjšajo stroški priklica in izvajanja kriptografskih operacij. Če želite povečati prepustnost vaše povezave VPN, je to dobra ideja.
Toda, kot ponavadi, resničnost ni tako preprosta. Pošiljanje tako velikega paketa omrežnemu adapterju zahteva, da se razreže na veliko manjših paketov. Običajna velikost pošiljanja je 1500 bajtov. To pomeni, da bo naš velikan 64 kilobajtov razdeljen na 45 paketov (1240 bajtov informacij in 20 bajtov glave IP). Nato bodo za nekaj časa popolnoma blokirali delo omrežne kartice, ker jih je treba poslati skupaj in hkrati. Posledično bo to povzročilo prednostni skok in paketi, kot je na primer VoIP, bodo postavljeni v čakalno vrsto.
Tako je visoka prepustnost, ki jo tako pogumno trdi WireGuard, dosežena za ceno upočasnitve omrežnega povezovanja drugih aplikacij. In ekipa WireGuard je že to je moj zaključek.
Ampak pojdimo naprej.
Glede na merila v tehnični dokumentaciji povezava kaže prepustnost 1011 Mbps.
Impresivno.
To je še posebej impresivno zaradi dejstva, da je največja teoretična prepustnost ene same povezave Gigabit Ethernet 966 Mbps z velikostjo paketa 1500 bajtov minus 20 bajtov za glavo IP, 8 bajtov za glavo UDP in 16 bajtov za glavo sam WireGuard. V enkapsuliranem paketu je še ena glava IP in še ena v TCP za 20 bajtov. Od kod torej ta dodatna pasovna širina?
Z ogromnimi okvirji in prednostmi GSO, o katerih smo govorili zgoraj, bi bil teoretični maksimum za velikost okvirja 9000 bajtov 1014 Mbps. Ponavadi je takšna prepustnost v resnici nedosegljiva, ker je povezana z velikimi težavami. Tako lahko samo domnevam, da je bil test izveden s še debelimi predimenzioniranimi okvirji 64 kilobajtov s teoretično največjo hitrostjo 1023 Mbps, ki jo podpirajo le nekateri omrežni adapterji. Toda to je absolutno neuporabno v realnih pogojih oziroma se lahko uporablja le med dvema neposredno povezanima postajama, izključno znotraj testne naprave.
Toda ker se tunel VPN posreduje med dvema gostiteljema prek internetne povezave, ki sploh ne podpira jumbo okvirjev, rezultata, doseženega na klopi, ni mogoče vzeti kot merilo. To je preprosto nerealen laboratorijski dosežek, ki je nemogoč in neuporaben v realnih bojnih razmerah.
Tudi ko sem sedel v podatkovnem centru, nisem mogel prenesti okvirjev, večjih od 9000 bajtov.
Merilo uporabnosti v resničnem življenju je absolutno porušeno in po mojem mnenju se je avtor opravljene "meritve" hudo diskreditiral iz očitnih razlogov.
Zadnji kanček upanja
Spletna stran WireGuard veliko govori o posodah in postane jasno, čemu je pravzaprav namenjena.
Preprost in hiter VPN, ki ne zahteva konfiguracije in ga je mogoče uvesti in konfigurirati z obsežnimi orodji za orkestracijo, kot jih ima Amazon v svojem oblaku. Natančneje, Amazon uporablja najnovejše funkcije strojne opreme, ki sem jih omenil prej, kot je AVX512. To se naredi, da bi pospešili delo in ne bili vezani na x86 ali katero koli drugo arhitekturo.
Optimizirajo prepustnost in pakete, večje od 9000 bajtov – to bodo ogromni inkapsulirani okvirji za medsebojno komunikacijo vsebnikov ali za operacije varnostnega kopiranja, ustvarjanje posnetkov ali uvajanje teh istih vsebnikov. Tudi dinamični naslovi IP ne bodo na noben način vplivali na delovanje WireGuarda v primeru scenarija, ki sem ga opisal.
Dobro odigrano. Briljantna izvedba in zelo tanek, skoraj referenčni protokol.
Toda preprosto ne sodi v svet zunaj podatkovnega centra, ki ga popolnoma nadzorujete. Če tvegate in začnete uporabljati WireGuard, boste morali delati nenehne kompromise pri načrtovanju in implementaciji šifrirnega protokola.
Izhod
Zlahka sklepam, da WireGuard še ni pripravljen.
Zasnovan je bil kot lahka in hitra rešitev številnih težav z obstoječimi rešitvami. Na žalost je zaradi teh rešitev žrtvoval številne funkcije, ki bodo pomembne za večino uporabnikov. Zato ne more nadomestiti IPsec ali OpenVPN.
Da bi WireGuard postal konkurenčen, mora dodati vsaj nastavitev naslova IP ter konfiguracijo usmerjanja in DNS. Očitno so temu namenjeni šifrirani kanali.
Varnost je moja glavna prednostna naloga in trenutno nimam razloga, da bi verjel, da sta IKE ali TLS nekako ogrožena ali pokvarjena. Oba podpirata sodobno šifriranje, preverjeno z desetletji delovanja. Samo zato, ker je nekaj novejše, še ne pomeni, da je boljše.
Interoperabilnost je izjemno pomembna, ko komunicirate s tretjimi osebami, katerih postaj ne nadzorujete. IPsec je de facto standard in je podprt skoraj povsod. In dela. In ne glede na to, kako izgleda, v teoriji WireGuard v prihodnosti morda ne bo združljiv niti z različnimi različicami samega sebe.
Vsaka kriptografska zaščita se prej ali slej pokvari in jo je zato treba zamenjati ali posodobiti.
Zanikanje vseh teh dejstev in na slepo želja po uporabi WireGuarda za povezavo vašega iPhone-a z vašo domačo delovno postajo je le mojstrski tečaj tiščanja glave v pesek.
Vir: www.habr.com