WireGuard hat de lêste tiid in soad oandacht krigen, yn feite is it de nije stjer ûnder VPN's. Mar is hy sa goed as hy liket? Ik wol wat observaasjes besprekke en de ymplemintaasje fan WireGuard besjen om út te lizzen wêrom't it gjin oplossing is om IPsec of OpenVPN te ferfangen.
Yn dit artikel soe ik guon fan 'e myten [om WireGuard hinne] wolle debunk. Ja, it sil in lange tiid duorje om te lêzen, dus as jo sels gjin bakje tee of kofje makke hawwe, dan is it tiid om it te dwaan. Ik wol Peter ek tank sizze foar it korrigearjen fan myn chaotyske gedachten.
Ik set mysels net it doel om de ûntwikkelders fan WireGuard te diskreditearjen, har ynspanningen of ideeën te devaluearjen. Har produkt wurket, mar persoanlik tink ik dat it folslein oars wurdt presintearre as wat it echt is - it wurdt presintearre as ferfanging foar IPsec en OpenVPN, dy't no eins gewoan net bestiet.
As notysje soe ik taheakje wolle dat de ferantwurdlikens foar sa'n posisjonearring fan WireGuard leit by de media dy't it deroer hawwe, en net it projekt sels of de makkers dêrfan.
D'r is de lêste tiid net folle goed nijs west oer de Linux-kernel. Dat, wy waarden ferteld oer de meunsterlike kwetsberens fan 'e prosessor, dy't waarden nivellere troch software, en Linus Torvalds praat der te grof en saai oer, yn' e utilitaristyske taal fan 'e ûntwikkelder. In planner as in netwurkstapel op nul nivo binne ek net heul dúdlike ûnderwerpen foar glossy tydskriften. En hjir komt WireGuard.
Op papier klinkt it allegear geweldich: in spannende nije technology.
Mar lit ús it noch efkes neier sjen.
WireGuard wit papier
Dit artikel is basearre op skreaun troch Jason Donenfeld. Dêr ferklearret hy it konsept, doel en technyske ymplemintaasje fan [WireGuard] yn 'e Linux kernel.
De earste sin lêst:
WireGuard […] is fan doel om sawol IPsec te ferfangen yn de measte gebrûksgefallen as oare populêre brûkersromte en/of TLS-basearre oplossingen lykas OpenVPN, wylst se feiliger, performanter en makliker te brûken [ark] binne.
Fansels is it wichtichste foardiel fan alle nije technologyen har ienfâld [ferlike mei foargongers]. Mar in VPN moat ek wêze effisjint en feilich.
Dus, wat is de folgjende?
As jo sizze dat dit net is wat jo nedich binne [fan in VPN], dan kinne jo it lêzen hjir beëinigje. Ik sil lykwols opmerke dat sokke taken binne ynsteld foar elke oare tunnelingtechnology.
De meast nijsgjirrige fan 'e boppesteande sitaat leit yn' e wurden "yn 'e measte gefallen", dy't, fansels, waarden negearre troch de parse. En sa binne wy wêr't wy einigje fanwegen de gaos makke troch dizze negligens - yn dit artikel.
Sil WireGuard myn [IPsec] site-to-site VPN ferfange?
Nee. D'r is gewoan gjin kâns dat grutte leveransiers lykas Cisco, Juniper en oaren WireGuard keapje foar har produkten. Se "springe net op foarbygeane treinen" ûnderweis, útsein as d'r wat grutte need is om dat te dwaan. Letter sil ik guon fan 'e redenen gean wêrom't se wierskynlik har WireGuard-produkten net oan board kinne krije, sels as se dat wolle.
Sil WireGuard myn RoadWarrior fan myn laptop nei it datasintrum nimme?
Nee. Op it stuit hat WireGuard net in enoarm oantal wichtige funksjes ymplementearre om soksawat te dwaan. It kin bygelyks gjin dynamyske IP-adressen brûke oan 'e kant fan' e tunnelserver, en dit allinich brekt it hiele senario fan sa'n gebrûk fan it produkt.
IPFire wurdt faak brûkt foar goedkeape ynternetferbiningen, lykas DSL of kabelferbiningen. Dit makket sin foar lytse as middelgrutte bedriuwen dy't gjin snelle glêstried nedich hawwe. [Opmerking fan 'e oersetter: ferjit net dat op it mêd fan kommunikaasje Ruslân en guon GOS-lannen fier foarút binne op Jeropa en de Feriene Steaten, om't wy folle letter begon te bouwen ús netwurken en mei de komst fan Ethernet en glêstriednetwurken as in standert, it wie makliker foar ús in werbouwen. Yn deselde lannen fan 'e EU as de FS is xDSL breedbân tagong mei in snelheid fan 3-5 Mbps noch altyd de algemiene noarm, en in glêstriedferbining kostet wat ûnrealistysk jild neffens ús noarmen. Dêrom sprekt de skriuwer fan it artikel fan DSL as kabelferbining as de noarm, en net oer âlde tiden.] DSL, kabel, LTE (en oare metoaden foar draadloze tagong) hawwe lykwols dynamyske IP-adressen. Fansels feroarje se soms net faak, mar se feroarje wol.
Der is in subprojekt neamd , dy't in brûkersromte-daemon tafoegje om dizze tekoart te oerwinnen. In enoarm probleem mei it hjirboppe beskreaune brûkerssenario is de fergrutting fan dynamyske IPv6-adressering.
Ut it eachpunt fan de distributeur, dit alles sjocht der ek net hiel goed. Ien fan 'e ûntwerpdoelen wie it protokol ienfâldich en skjin te hâlden.
Spitigernôch is dit alles eins te ienfâldich en primityf wurden, sadat wy ekstra software brûke moatte om dit hiele ûntwerp yn echt gebrûk leefber te wêzen.
Is WireGuard sa maklik te brûken?
Noch net. Ik sis net dat WireGuard nea in goed alternatyf sil wêze foar tunneling tusken twa punten, mar foar no is it gewoan in alfaferzje fan it produkt dat it moat wêze.
Mar wat docht er dan eins? Is IPsec echt sa folle dreger te ûnderhâlden?
Fansels net. De IPsec-ferkeaper hat dit tocht en ferstjoert har produkt tegearre mei in ynterface, lykas mei IPFire.
Om in VPN-tunnel oer IPsec yn te stellen, hawwe jo fiif sets gegevens nedich dy't jo yn 'e konfiguraasje moatte ynfiere: jo eigen iepenbiere IP-adres, it iepenbiere IP-adres fan 'e ûntfangende partij, de subnetten dy't jo iepenbier meitsje wolle. dizze VPN ferbining en pre-dielde kaai. Sa wurdt de VPN binnen minuten ynsteld en is kompatibel mei elke ferkeaper.
Spitigernôch binne d'r in pear útsûnderingen op dit ferhaal. Elkenien dy't hat besocht te tunnel oer IPsec nei in OpenBSD masine wit wêr't ik it oer. D'r binne in pear mear pynlike foarbylden, mar yn feite binne d'r in protte, folle mear goede praktiken foar it brûken fan IPsec.
Oer protokol kompleksiteit
De ein brûker hoecht gjin soargen te meitsjen oer de kompleksiteit fan it protokol.
As wy wenne yn in wrâld dêr't dit wie in echte soarch fan 'e brûker, dan wy soene hawwe lang lyn los fan SIP, H.323, FTP en oare protokollen makke mear as tsien jier lyn dy't net wurkje goed mei NAT.
D'r binne redenen wêrom't IPsec komplekser is dan WireGuard: it docht folle mear dingen. Bygelyks, brûkersautentikaasje mei in oanmelding / wachtwurd of in SIM-kaart mei EAP. It hat in útwreide mooglikheid om nij ta te foegjen .
En WireGuard hat dat net.
En dit betsjut dat WireGuard op in stuit sil brekke, om't ien fan 'e kryptografyske primitiven sil swakke of folslein kompromitteare wurde. De skriuwer fan 'e technyske dokumintaasje seit dit:
It is de muoite wurdich op te merken dat WireGuard kryptografysk miening is. It ûntbrekt bewust de fleksibiliteit fan sifers en protokollen. As serieuze gatten wurde fûn yn ûnderlizzende primitiven, moatte alle einpunten bywurke wurde. Lykas jo kinne sjen fan 'e oanhâldende stream fan SLL / TLS-kwetsberheden, is de fleksibiliteit fan fersifering no enoarm tanommen.
De lêste sin is perfoarst korrekt.
Konsensus berikke oer hokker fersifering te brûken makket protokollen lykas IKE en TLS mear as kompleks. Te yngewikkeld? Ja, kwetsberens binne frij gewoan yn TLS / SSL, en d'r is gjin alternatyf foar har.
Op it negearjen fan echte problemen
Stel jo foar dat jo in VPN-tsjinner hawwe mei 200 fjochtskliïnten earne om 'e wrâld. Dit is in frij standert gebrûk gefal. As jo de fersifering feroarje moatte, moatte jo de fernijing leverje oan alle kopyen fan WireGuard op dizze laptops, smartphones, ensfh. Tagelyk leverje. It is letterlik ûnmooglik. Behearders dy't besykje dit te dwaan, sille moannen duorje om de fereaske konfiguraasjes yn te setten, en it sil letterlik in middelgrutte bedriuw jierren duorje om sa'n evenemint ôf te heljen.
IPsec en OpenVPN biede in funksje foar ûnderhanneling fan sifers. Dêrom, foar in skoft wêrnei't jo de nije fersifering ynskeakelje, sil de âlde ek wurkje. Hjirmei kinne hjoeddeistige klanten opwurdearje nei de nije ferzje. Nei't de fernijing is útrôle, skeakelje jo gewoan de kwetsbere fersifering út. En dat is alles! Klear! Do bist prachtich! Klanten sille it net iens fernimme.
Dit is eins in heul gewoan gefal foar grutte ynset, en sels OpenVPN hat wat muoite mei dit. Efterútkompatibiliteit is wichtich, en ek al brûke jo swakkere fersifering, foar in protte is dit gjin reden om in bedriuw te sluten. Om't it it wurk fan hûnderten klanten ferlamme sil troch it ûnfermogen om har wurk te dwaan.
It WireGuard-team hat har protokol ienfâldiger makke, mar folslein ûnbrûkber foar minsken dy't gjin konstante kontrôle hawwe oer beide peers yn har tunnel. Yn myn ûnderfining is dit it meast foarkommende senario.
Kryptografy!
Mar wat is dizze nijsgjirrige nije fersifering dy't WireGuard brûkt?
WireGuard brûkt Curve25519 foar kaai útwikseling, ChaCha20 foar fersifering en Poly1305 foar gegevens autentikaasje. It wurket ek mei SipHash foar hash-kaaien en BLAKE2 foar hashing.
ChaCha20-Poly1305 is standerdisearre foar IPsec en OpenVPN (oer TLS).
It is fanselssprekkend dat de ûntwikkeling fan Daniel Bernstein tige faak brûkt wurdt. BLAKE2 is de opfolger fan BLAKE, in SHA-3 finalist dy't net wûn fanwegen syn oerienkomst mei SHA-2. As SHA-2 soe wurde brutsen, der wie in goede chance dat BLAKE soe wêze kompromittearre ek.
IPsec en OpenVPN hawwe SipHash net nedich fanwegen har ûntwerp. Dus it ienige ding dat kin net op it stuit brûkt wurde mei harren is BLAKE2, en dat is allinnich oant it is standerdisearre. Dit is net in grut nadeel, om't VPN's HMAC brûke om yntegriteit te meitsjen, dy't sels yn kombinaasje mei MD5 as in sterke oplossing wurdt beskôge.
Dat ik kaam ta de konklúzje dat hast deselde set fan kryptografyske ark wurdt brûkt yn alle VPN's. Dêrom, WireGuard is net mear of minder feilich as hokker oar aktueel produkt as it giet om fersifering of de yntegriteit fan oerdroegen gegevens.
Mar sels dit is net it wichtichste ding, dat is it wurdich omtinken te jaan neffens de offisjele dokumintaasje fan it projekt. Ommers, it wichtichste ding is snelheid.
Is WireGuard rapper dan oare VPN-oplossings?
Koartsein: nee, net flugger.
ChaCha20 is in stream cipher dat is makliker te ymplemintearjen yn software. It fersiferet ien bit op in tiid. Blokkearje protokollen lykas AES fersiferje in blok 128 bits tagelyk. Folle mear transistors binne nedich om hardware-stipe te ymplementearjen, sadat gruttere processors komme mei AES-NI, in ynstruksjeset-útwreiding dy't guon fan 'e taken fan it fersiferingsproses útfiert om it te fersnellen.
It waard ferwachte dat AES-NI noait yn smartphones soe komme [mar it die - sawat. mei.]. Hjirfoar waard de ChaCha20 ûntwikkele as in lichtgewicht, batterijbesparend alternatyf. Dêrom kin it as nijs foar jo komme dat elke smartphone dy't jo hjoed kinne keapje in soarte fan AES-fersnelling hat en rapper rint en mei legere enerzjyferbrûk mei dizze fersifering dan mei ChaCha20.
Fansels hat sawat elke buroblêd / serverprosessor kocht yn 'e lêste pear jier AES-NI.
Dêrom ferwachtsje ik dat AES ChaCha20 yn elk senario sil prestearje. De offisjele dokumintaasje fan WireGuard neamt dat mei AVX512, ChaCha20-Poly1305 AES-NI sil prestearje, mar dizze ynstruksjeset-útwreiding sil allinich beskikber wêze op gruttere CPU's, dy't wer net sille helpe mei lytsere en mear mobile hardware, dy't altyd rapper sil wêze mei AES - N.I.
Ik bin net wis as dit koe wurde foarsjoen tidens de ûntwikkeling fan WireGuard, mar hjoed is it feit dat it allinich oan fersifering spikere is al in neidiel dat miskien net sa goed ynfloed hat op syn wurking.
IPsec lit jo frij kieze hokker fersifering it bêste is foar jo gefal. En fansels is dit nedich as jo bygelyks 10 of mear gigabytes oan gegevens wolle oerdrage fia in VPN-ferbining.
Yntegraasjeproblemen yn Linux
Hoewol WireGuard foar in modern fersiferingsprotokol keazen hat, soarget dat al foar in soad problemen. En dus, ynstee fan te brûken wat wurdt stipe troch de kernel út 'e doaze, is de yntegraasje fan WireGuard jierrenlang fertrage troch it ûntbrekken fan dizze primitives yn Linux.
Ik bin net hielendal wis op wat de situaasje is op oare bestjoeringssystemen, mar it is nei alle gedachten net folle oars as op Linux.
Hoe sjocht de werklikheid derút?
Spitigernôch, elke kear as in kliïnt my freget om in VPN-ferbining foar har op te stellen, kom ik yn 't probleem dat se ferâldere bewiisbrieven en fersifering brûke. 3DES yn gearhing mei MD5 is noch altyd gewoane praktyk, lykas AES-256 en SHA1. En hoewol dat lêste wat better is, is dit net iets dat yn 2020 brûkt wurde moat.
Foar kaai útwikseling altyd RSA wurdt brûkt - in stadich, mar frij feilich ark.
Myn kliïnten binne ferbûn mei dûaneautoriteiten en oare oerheidsorganisaasjes en -ynstellingen, lykas ek mei grutte bedriuwen waans nammen oer de hiele wrâld bekend binne. Se brûke allegear in oanfraachformulier dat tsientallen jierren lyn is makke, en de mooglikheid om SHA-512 te brûken is gewoan nea tafoege. Ik kin net sizze dat it op ien of oare manier dúdlik beynfloedet op technologyske foarútgong, mar fansels fertraget it it bedriuwsproses.
It makket my pynlik om dit te sjen, om't IPsec sûnt 2005 elliptyske krommes stipet. Curve25519 is ek nijer en beskikber foar gebrûk. D'r binne ek alternativen foar AES lykas Camellia en ChaCha20, mar fansels wurde se net allegear stipe troch grutte leveransiers lykas Cisco en oaren.
En minsken profitearje derfan. Der binne in protte Cisco kits, der binne in protte kits ûntwurpen om te wurkjen mei Cisco. Se binne merklieders yn dit segmint en binne net heul ynteressearre yn elke soart ynnovaasje.
Ja, de situaasje [yn it bedriuwssegment] is ferskriklik, mar wy sille gjin feroaringen sjen fanwegen WireGuard. Ferkeapers sille wierskynlik noait gjin prestaasjesproblemen sjen mei it ark en fersifering dat se al brûke, sille gjin problemen sjen mei IKEv2, en dus sykje se net nei alternativen.
Yn it algemien, hawwe jo ea tocht oer in ferlitte Cisco?
Benchmarks
En litte wy no trochgean nei de benchmarks fan 'e WireGuard-dokumintaasje. Hoewol dizze [dokumintaasje] gjin wittenskiplik artikel is, ferwachte ik noch dat de ûntwikkelders in mear wittenskiplike oanpak soene nimme, of in wittenskiplike oanpak as referinsje brûke. Alle benchmarks binne nutteloos as se net kinne wurde reprodusearre, en noch nutteloos as se wurde krigen yn it laboratoarium.
Yn 'e Linux-build fan WireGuard profiteart it fan it brûken fan GSO - Generic Segmentation Offloading. Mei tank oan him makket de kliïnt in enoarm pakket fan 64 kilobytes en fersiferet / ûntsiferet it yn ien kear. Sa wurde de kosten foar it oproppen en útfieren fan kryptografyske operaasjes fermindere. As jo de trochfier fan jo VPN-ferbining maksimalisearje wolle, is dit in goed idee.
Mar, lykas gewoanlik, is de realiteit net sa ienfâldich. It ferstjoeren fan sa'n grut pakket nei in netwurkadapter fereasket dat it yn in protte lytsere pakketten knipt wurdt. De normale ferstjoergrutte is 1500 bytes. Dat is, ús reus fan 64 kilobytes sil wurde ferdield yn 45 pakketten (1240 bytes fan ynformaasje en 20 bytes fan de IP-header). Dan sille se in skoftke it wurk fan 'e netwurkadapter folslein blokkearje, om't se tegearre en tagelyk stjoerd wurde moatte. As gefolch, dit sil liede ta in prioriteit sprong, en pakketten lykas VoIP, bygelyks, wurde wachtrige.
Sa wurdt de hege trochstreaming dy't WireGuard sa frijmoedich beweart, berikt op kosten fan it fertrage fan it netwurkjen fan oare applikaasjes. En it WireGuard-team is al dit is myn konklúzje.
Mar litte wy fierder.
Neffens de benchmarks yn 'e technyske dokumintaasje toant de ferbining in trochfier fan 1011 Mbps.
Ymposant.
Dit is benammen yndrukwekkend troch it feit dat de maksimale teoretyske trochfier fan in inkele Gigabit Ethernet-ferbining 966 Mbps is mei in pakketgrutte fan 1500 bytes min 20 bytes foar de IP-header, 8 bytes foar de UDP-header en 16 bytes foar de header fan de WireGuard sels. D'r is noch ien IP-header yn it ynkapsulearre pakket en in oare yn TCP foar 20 bytes. Dus wêr kaam dizze ekstra bânbreedte wei?
Mei enoarme frames en de foardielen fan GSO dy't wy hjirboppe praat hawwe, soe it teoretyske maksimum foar in framegrutte fan 9000 bytes 1014 Mbps wêze. Meastentiids is sa'n trochslach yn 'e realiteit net te berikken, om't it mei grutte swierrichheden ferbûn is. Sa, ik kin allinnich oannimme dat de test waard útfierd mei help fan noch feter oversized frames fan 64 kilobytes mei in teoretysk maksimum fan 1023 Mbps, dat wurdt stipe allinnich troch guon netwurk adapters. Mar dit is absolút net fan tapassing yn echte omstannichheden, of kin allinnich brûkt wurde tusken twa direkt ferbûn stasjons, allinnich binnen de test bank.
Mar om't de VPN-tunnel trochstjoerd wurdt tusken twa hosts mei in ynternetferbining dy't hielendal gjin jumbo-frames stipet, kin it resultaat dat op 'e bank wurdt berikt net as benchmark wurde nommen. Dit is gewoan in unrealistyske laboratoariumprestaasje dy't ûnmooglik en net fan tapassing is yn echte fjochtsomstannichheden.
Sels sittend yn it datasintrum, koe ik gjin frames oerdrage grutter dan 9000 bytes.
It kritearium fan tapassing yn it echte libben is absolút skeind en, sa't ik tink, de skriuwer fan 'e "mjitting" útfierd serieus diskreditearre himsels foar fanselssprekkende redenen.
Lêste glim fan hope
De webside WireGuard praat in soad oer konteners en it wurdt dúdlik wêr't it echt foar bedoeld is.
In ienfâldige en rappe VPN dy't gjin konfiguraasje fereasket en kin wurde ynset en konfigureare mei massive orkestraasje-ark lykas Amazon yn har wolk hat. Spesifyk brûkt Amazon de lêste hardwarefunksjes dy't ik earder neamde, lykas de AVX512. Dit wurdt dien om it wurk te fersnellen en net bûn te wêzen oan x86 of in oare arsjitektuer.
Se optimalisearje trochfier en pakketten grutter dan 9000 bytes - dit sille enoarme ynkapsulearre frames wêze foar konteners om mei elkoar te kommunisearjen, of foar backupoperaasjes, it meitsjen fan snapshots of it ynsetten fan deselde konteners. Sels dynamyske IP-adressen sille de wurking fan WireGuard op gjin inkelde manier beynfloedzje yn it gefal fan it senario dat ik beskreaun.
Goed spile. Briljante ymplemintaasje en heul tin, hast referinsjeprotokol.
Mar it past gewoan net yn in wrâld bûten in datasintrum dat jo folslein kontrolearje. As jo it risiko nimme en WireGuard begjinne te brûken, moatte jo konstante kompromissen meitsje yn it ûntwerp en ymplemintaasje fan it fersiferingsprotokol.
konklúzje
It is my maklik om te konkludearjen dat WireGuard noch net klear is.
It waard betocht as in lichtgewicht en rappe oplossing foar in oantal problemen mei besteande oplossingen. Spitigernôch hat hy om 'e wille fan dizze oplossingen in protte funksjes opoffere dy't relevant sille wêze foar de measte brûkers. Dêrom kin it IPsec of OpenVPN net ferfange.
Om WireGuard kompetitive te wurden, moat it op syn minst in IP-adresynstelling en in routing- en DNS-konfiguraasje tafoegje. Fansels is dit wêr't fersifere kanalen foar binne.
Feiligens is myn topprioriteit, en op it stuit haw ik gjin reden om te leauwen dat IKE of TLS op ien of oare manier kompromittearre of brutsen is. Moderne fersifering wurdt stipe yn beide, en se binne bewiisd troch desennia fan operaasje. Krekt om't wat nijer is, betsjut net dat it better is.
Ynteroperabiliteit is ekstreem wichtich as jo kommunisearje mei tredden waans stasjons jo net kontrolearje. IPsec is de de facto standert en wurdt hast oeral stipe. En hy wurket. En hoe't it der ek útsjocht, yn teory kin WireGuard yn 'e takomst miskien net kompatibel wêze, sels mei ferskate ferzjes fan himsels.
Elke kryptografyske beskerming wurdt ier of letter brutsen en moat dêrom ferfongen of bywurke wurde.
Al dizze feiten ûntkenne en WireGuard blyn wolle brûke om jo iPhone te ferbinen mei jo thúswurkstasjon is gewoan in masterklasse om jo holle yn it sân te stekken.
Boarne: www.habr.com