WireGuard on viimasel ajal palju tähelepanu pälvinud, tegelikult on see VPN-ide seas uus täht. Aga kas ta on nii hea, kui tundub? Tahaksin arutada mõningaid tähelepanekuid ja vaadata üle WireGuardi rakendamine, et selgitada, miks IPseci või OpenVPN-i asendamine ei ole lahendus.
Selles artiklis tahaksin ümber lükata mõned müüdid [WireGuardi kohta]. Jah, selle lugemine võtab kaua aega, nii et kui te pole endale tassi teed või kohvi valmistanud, siis on aeg seda teha. Samuti tahan tänada Peetrit minu kaootiliste mõtete parandamise eest.
Ma ei sea endale eesmärgiks diskrediteerida WireGuardi arendajaid, devalveerida nende pingutusi või ideid. Nende toode töötab, kuid isiklikult arvan, et seda esitletakse täiesti erinevalt sellest, mis see tegelikult on - seda esitletakse IPseci ja OpenVPN-i asendajana, mida tegelikult praegu lihtsalt pole.
Märkusena lisan, et vastutus WireGuardi sellise positsioneerimise eest lasub sellest rääkinud meedial, mitte projektil endal või selle loojatel.
Viimasel ajal pole Linuxi kerneli kohta eriti häid uudiseid olnud. Niisiis, meile räägiti protsessori koletutest haavatavustest, mida tarkvara tasandas, ja Linus Torvalds rääkis sellest liiga ebaviisakalt ja igavalt, arendaja utilitaarses keeles. Ka ajakava või nulltaseme võrgupinn pole läikivate ajakirjade jaoks väga selged teemad. Ja siit tuleb WireGuard.
Paberil kõlab see kõik suurepäraselt: uus põnev tehnoloogia.
Aga vaatame seda veidi lähemalt.
WireGuard valge paber
See artikkel põhineb kirjutas Jason Donenfeld. Seal selgitab ta [WireGuardi] kontseptsiooni, eesmärki ja tehnilist teostust Linuxi tuumas.
Esimene lause kõlab:
WireGuard […] eesmärk on asendada nii IPseci enamikul kasutusjuhtudel kui ka teisi populaarseid kasutajaruumi ja/või TLS-ipõhiseid lahendusi, nagu OpenVPN, olles samal ajal turvalisem, tõhusam ja hõlpsamini kasutatav [tööriist].
Loomulikult on kõigi uute tehnoloogiate peamine eelis nende lihtsus [võrreldes eelkäijatega]. Kuid VPN peaks ka olema tõhus ja ohutu.
Mis saab edasi?
Kui ütlete, et see pole see, mida te vajate [VPN-ist], saate lugemise siin lõpetada. Siiski märgin, et sellised ülesanded on seatud igale muule tunnelitehnoloogiale.
Kõige huvitavam ülaltoodud tsitaadist peitub sõnades "enamasti", mida ajakirjandus muidugi ignoreeris. Ja nii, me oleme selle hooletuse tekitatud kaose tõttu sinna, kuhu me sattusime – selles artiklis.
Kas WireGuard asendab minu [IPsec] saitidevahelise VPN-i?
Ei. Pole lihtsalt mingit võimalust, et suured müüjad, nagu Cisco, Juniper ja teised, ostavad oma toodete jaoks WireGuardi. Nad ei "hüppa möödasõitvatele rongidele" liikvel olles, välja arvatud juhul, kui selleks on suur vajadus. Hiljem käsitlen mõningaid põhjuseid, miks nad tõenäoliselt ei saa oma WireGuardi tooteid pardale isegi siis, kui nad seda tahaksid.
Kas WireGuard viib mu RoadWarriori sülearvutist andmekeskusesse?
Ei. Praegu pole WireGuardil tohutult palju olulisi funktsioone, et see saaks midagi sellist teha. Näiteks ei saa see tunneliserveri poolel kasutada dünaamilisi IP-aadresse ja ainuüksi see rikub kogu toote sellise kasutamise stsenaariumi.
IPFire'i kasutatakse sageli odavate Interneti-linkide jaoks, näiteks DSL- või kaabelühenduste jaoks. See on mõistlik väikeste või keskmise suurusega ettevõtete jaoks, kes ei vaja kiiret kiudaineid. [Märkus tõlkijalt: ärge unustage, et suhtluse osas on Venemaa ja mõned SRÜ riigid Euroopast ja USA-st kaugel ees, kuna alustasime võrkude ehitamist palju hiljem ning Etherneti ja fiiberoptiliste võrkude tulekuga. standard, oli meil lihtsam ümber ehitada. Samades EL-i või USA riikides on xDSL-lairibajuurdepääs kiirusega 3-5 Mbps endiselt üldnorm ja fiiberoptiline ühendus maksab meie standardite järgi ebareaalset raha. Seetõttu räägib artikli autor DSL-ist ehk kaabelühendusest kui normist, mitte iidsetest aegadest.] DSL-il, kaablil, LTE-l (ja muudel traadita juurdepääsu meetoditel) on aga dünaamilised IP-aadressid. Muidugi mõnikord ei muutu need sageli, kuid muutuvad.
Seal on alamprojekt nimega , mis lisab selle puuduse ületamiseks kasutajaruumi deemoni. Ülalkirjeldatud kasutajastsenaariumi suur probleem on dünaamilise IPv6-aadressi süvenemine.
Turustaja seisukohalt ei paista see kõik samuti kuigi hea välja. Üks disainieesmärke oli hoida protokoll lihtne ja puhas.
Kahjuks on see kõik muutunud tegelikult liiga lihtsaks ja primitiivseks, nii et peame kasutama lisatarkvara, et kogu see disain oleks reaalses kasutuses elujõuline.
Kas WireGuard on nii lihtne kasutada?
Mitte veel. Ma ei väida, et WireGuard ei ole kunagi hea alternatiiv kahe punkti vahel tunneldamiseks, kuid praegu on see lihtsalt selle toote alfaversioon, mis see peaks olema.
Aga mida ta siis tegelikult teeb? Kas IPseci hooldamine on tõesti nii palju raskem?
Ilmselgelt mitte. IPseci müüja on sellele mõelnud ja saadab oma toote koos liidesega, näiteks IPFire'iga.
IPseci kaudu VPN-tunneli seadistamiseks vajate viit andmekomplekti, mille peate konfiguratsiooni sisestama: teie enda avalik IP-aadress, vastuvõtva osapoole avalik IP-aadress, alamvõrgud, mille kaudu soovite avalikustada. see VPN-ühendus ja eeljagatud võti. Seega seadistatakse VPN mõne minutiga ja ühildub kõigi müüjatega.
Kahjuks on sellel lool mõned erandid. Kõik, kes on proovinud IPseci kaudu OpenBSD masinasse tunneldada, teavad, millest ma räägin. On paar valusamat näidet, aga tegelikult on IPseci kasutamiseks palju-palju rohkem häid tavasid.
Protokolli keerukusest
Lõppkasutaja ei pea muretsema protokolli keerukuse pärast.
Kui me elaksime maailmas, kus see oli kasutaja jaoks tõsine mure, siis oleksime vabanenud SIP-st, H.323-st, FTP-st ja muudest enam kui kümme aastat tagasi loodud protokollidest, mis NAT-iga hästi ei tööta.
On põhjuseid, miks IPsec on keerulisem kui WireGuard: see teeb palju rohkem asju. Näiteks kasutaja autentimine sisselogimise / parooli või EAP-iga SIM-kaardi abil. Sellel on laiendatud võimalus lisada uusi .
Ja WireGuardil seda pole.
Ja see tähendab, et WireGuard läheb ühel hetkel katki, sest üks krüptoprimitiiv nõrgeneb või on täielikult ohustatud. Tehnilise dokumentatsiooni autor ütleb järgmist:
Väärib märkimist, et WireGuardil on krüptograafiline arvamus. Sellel puudub teadlikult šifrite ja protokollide paindlikkus. Kui aluspõhistes primitiivides leitakse tõsiseid auke, tuleb kõiki lõpp-punkte värskendada. Nagu näete pidevast SLL/TLS-i haavatavuste voost, on krüptimise paindlikkus nüüd tohutult suurenenud.
Viimane lause on täiesti õige.
Konsensuse saavutamine selles, millist krüptimist kasutada, loob sellised protokollid nagu IKE ja TLS rohkem keeruline. Liiga keeruline? Jah, haavatavused on TLS/SSL-is üsna tavalised ja neile pole alternatiivi.
Tõeliste probleemide ignoreerimisest
Kujutage ette, et teil on VPN-server 200 võitluskliendiga kusagil üle maailma. See on üsna tavaline kasutusjuht. Kui peate krüptimist muutma, peate värskenduse edastama kõikidele WireGuardi koopiatele nendes sülearvutites, nutitelefonides ja nii edasi. Samaaegselt toimetama. See on sõna otseses mõttes võimatu. Administraatoritel, kes üritavad seda teha, kulub vajalike konfiguratsioonide juurutamiseks kuid ja keskmise suurusega ettevõttel kulub sellise sündmuse korraldamiseks sõna otseses mõttes aastaid.
IPsec ja OpenVPN pakuvad šifri läbirääkimiste funktsiooni. Seetõttu töötab mõnda aega, pärast mida lülitate uue krüptimise sisse, ka vana. See võimaldab praegustel klientidel uuele versioonile üle minna. Pärast värskenduse väljalaskmist lülitate lihtsalt haavatava krüptimise välja. Ja see ongi kõik! Valmis! sa oled imeilus! Kliendid ei pane seda isegi tähele.
See on tegelikult väga levinud juhtum suurte juurutuste puhul ja isegi OpenVPN-il on sellega probleeme. Tagasiühilduvus on oluline ja kuigi kasutate nõrgemat krüptimist, ei ole see paljude jaoks põhjus ettevõtte sulgemiseks. Sest see halvab sadade klientide töö suutmatuse tõttu oma tööd teha.
WireGuardi meeskond on muutnud oma protokolli lihtsamaks, kuid täiesti kasutuskõlbmatuks inimestele, kellel pole pidevat kontrolli mõlema tunnelis oleva kaaslase üle. Minu kogemuse järgi on see kõige levinum stsenaarium.
Krüptograafia!
Aga mis on see huvitav uus krüptimine, mida WireGuard kasutab?
WireGuard kasutab võtme vahetamiseks Curve25519, krüptimiseks ChaCha20 ja andmete autentimiseks Poly1305. Samuti töötab see koos SipHashiga räsivõtmete jaoks ja BLAKE2-ga räsimiseks.
ChaCha20-Poly1305 on standardiseeritud IPseci ja OpenVPN jaoks (üle TLS-i).
On ilmne, et Daniel Bernsteini arendust kasutatakse väga sageli. BLAKE2 on BLAKE järglane, SHA-3 finalist, kes ei võitnud oma sarnasuse tõttu SHA-2-ga. Kui SHA-2 peaks purunema, on suur tõenäosus, et ka BLAKE satub ohtu.
IPsec ja OpenVPN ei vaja oma disaini tõttu SipHashi. Seega ainus asi, mida nendega praegu kasutada ei saa, on BLAKE2 ja seda ainult seni, kuni see on standarditud. See pole suur puudus, sest VPN-id kasutavad terviklikkuse loomiseks HMAC-i, mida peetakse tugevaks lahenduseks isegi koos MD5-ga.
Seega jõudsin järeldusele, et kõigis VPN-ides kasutatakse peaaegu sama krüptotööriistade komplekti. Seetõttu pole WireGuard krüptimise või edastatavate andmete terviklikkuse osas enam ega vähem turvaline kui ükski teine praegune toode.
Kuid ka see pole kõige olulisem, millele tasub projekti ametliku dokumentatsiooni järgi tähelepanu pöörata. Peaasi on ju kiirus.
Kas WireGuard on teistest VPN-lahendustest kiirem?
Lühidalt: ei, mitte kiiremini.
ChaCha20 on voošifr, mida on tarkvaras lihtsam rakendada. See krüpteerib üks bitt korraga. Plokiprotokollid nagu AES krüpteerivad ploki korraga 128 bitti. Riistvaratoe rakendamiseks on vaja palju rohkem transistore, nii et suurematel protsessoritel on AES-NI, käsukomplekti laiendus, mis täidab krüpteerimisprotsessi kiirendamiseks mõningaid ülesandeid.
Eeldati, et AES-NI ei satu kunagi nutitelefonidesse [aga see juhtus - u. per.]. Selleks töötati ChaCha20 välja kerge ja akut säästva alternatiivina. Seetõttu võib teile uudisena tulla, et igal nutitelefonil, mida täna osta saate, on mingi AES-kiirendus ja see töötab selle krüptimisega kiiremini ja väiksema energiatarbimisega kui ChaCha20-ga.
Ilmselgelt on peaaegu igal viimase paari aasta jooksul ostetud lauaarvuti/serveri protsessoril AES-NI.
Seetõttu eeldan, et AES ületab ChaCha20 igas stsenaariumis. WireGuardi ametlik dokumentatsioon mainib, et AVX512 puhul ületab ChaCha20-Poly1305 AES-NI, kuid see juhiste komplekti laiendus on saadaval ainult suurematel protsessoritel, mis jällegi ei aita väiksema ja mobiilsema riistvara puhul, mis on AES-iga alati kiirem. - N.I.
Ma ei ole kindel, kas seda võis WireGuardi arendamise käigus ette näha, kuid tänapäeval on juba ainuüksi krüpteerimise külge naelutatud tõsiasi, mis ei pruugi selle toimimist kuigi hästi mõjutada.
IPsec võimaldab teil vabalt valida, milline krüptimine teie juhtumi jaoks kõige paremini sobib. Ja loomulikult on see vajalik, kui soovite näiteks VPN-ühenduse kaudu edastada 10 gigabaiti või rohkem andmeid.
Integratsiooniprobleemid Linuxis
Kuigi WireGuard on valinud moodsa krüpteerimisprotokolli, tekitab see juba praegu palju probleeme. Ja nii, selle asemel, et kasutada seda, mida tuum karbist väljas toetab, on WireGuardi integreerimine nende primitiivide puudumise tõttu Linuxis aastaid viibinud.
Ma ei ole täiesti kindel, milline on olukord teistes operatsioonisüsteemides, kuid tõenäoliselt ei erine see palju Linuxi omast.
Kuidas reaalsus välja näeb?
Kahjuks tekib mul iga kord, kui klient palub mul enda jaoks VPN-ühenduse seadistada, probleem, et nad kasutavad aegunud mandaate ja krüptimist. 3DES koos MD5-ga on endiselt levinud praktika, nagu ka AES-256 ja SHA1. Ja kuigi viimane on veidi parem, ei tohiks seda 2020. aastal kasutada.
Võtmevahetuseks alati Kasutatakse RSA-d – aeglast, kuid üsna ohutut vahendit.
Minu kliendid on seotud tolliasutuste ja teiste valitsusasutuste ja -asutustega, samuti suurkorporatsioonidega, mille nimed on tuntud üle maailma. Kõik nad kasutavad aastakümneid tagasi loodud päringuvormi ja SHA-512 kasutamise võimalust lihtsalt ei lisatud. Ma ei saa öelda, et see kuidagi selgelt tehnoloogilist progressi mõjutaks, aga ilmselgelt pidurdab see ettevõtte protsessi.
Mul on seda valus näha, sest IPsec on elliptilisi kõveraid toetanud alates aastast 2005. Curve25519 on ka uuem ja kasutamiseks saadaval. AES-ile on ka alternatiive, nagu Camellia ja ChaCha20, kuid ilmselt ei toeta neid kõiki suuremad müüjad, nagu Cisco ja teised.
Ja inimesed kasutavad seda ära. Cisco komplekte on palju, palju on Ciscoga töötamiseks mõeldud komplekte. Nad on selles segmendis turuliidrid ega ole eriti huvitatud mingitest uuendustest.
Jah, olukord [ettevõtete segmendis] on kohutav, kuid me ei näe WireGuardi tõttu mingeid muudatusi. Tõenäoliselt ei näe müüjad kunagi juba kasutatavate tööriistade ja krüptimisega probleeme, ei näe probleeme IKEv2-ga ja seega ei otsi nad alternatiive.
Kas olete üldiselt mõelnud Ciscost loobumisele?
Võrdlusnäitajad
Ja nüüd liigume edasi WireGuardi dokumentatsiooni võrdlusaluste juurde. Kuigi see [dokumentatsioon] ei ole teadusartikkel, eeldasin siiski, et arendajad võtavad rohkem teaduslikku lähenemist või kasutavad viitena teaduslikku lähenemist. Kõik võrdlusnäitajad on kasutud, kui neid ei saa reprodutseerida, ja veelgi kasutumad, kui need saadakse laboris.
WireGuardi Linuxi järgus kasutab see ära GSO – üldise segmenteerimise mahalaadimise. Tänu temale loob klient tohutu 64 kilobaidise paketi ja krüpteerib / dekrüpteerib selle ühe korraga. Seega vähenevad krüptograafiliste toimingute kutsumise ja rakendamise kulud. Kui soovite oma VPN-ühenduse läbilaskevõimet maksimeerida, on see hea mõte.
Kuid nagu tavaliselt, pole tegelikkus nii lihtne. Nii suure paketi saatmine võrguadapterisse nõuab selle lõikamist paljudeks väiksemateks pakettideks. Tavaline saatmismaht on 1500 baiti. See tähendab, et meie 64 kilobaidine hiiglane jagatakse 45 paketiks (1240 baiti teavet ja 20 baiti IP-päist). Siis blokeerivad nad mõneks ajaks täielikult võrguadapteri töö, sest need tuleb saata koos ja korraga. Selle tulemusena toob see kaasa prioriteedihüppe ja paketid, nagu näiteks VoIP, pannakse järjekorda.
Seega saavutatakse WireGuardi uljalt väidetav suur läbilaskevõime teiste rakenduste võrkude loomise aeglustamise hinnaga. Ja WireGuardi meeskond juba on see on minu järeldus.
Aga lähme edasi.
Vastavalt tehnilises dokumentatsioonis toodud võrdlusalustele näitab ühendus läbilaskevõimet 1011 Mbps.
Muljetavaldav.
See on eriti muljetavaldav seetõttu, et ühe Gigabit Etherneti ühenduse maksimaalne teoreetiline läbilaskevõime on 966 Mbps paketi suurusega 1500 baiti miinus 20 baiti IP päise jaoks, 8 baiti UDP päise jaoks ja 16 baiti päise jaoks. WireGuard ise. Kapseldatud paketis on veel üks IP-päis ja TCP-s veel üks 20 baidi jaoks. Kust see täiendav ribalaius siis tuli?
Tohutute kaadrite ja GSO eeliste korral, millest me eespool rääkisime, oleks 9000 baidise kaadri suuruse teoreetiline maksimum 1014 Mbps. Tavaliselt on selline läbilaskevõime tegelikkuses saavutamatu, kuna see on seotud suurte raskustega. Seega võin vaid oletada, et testi läbiviimiseks kasutati veelgi paksemaid 64 kilobaidiseid ülisuureid kaadreid, mille teoreetiline maksimum on 1023 Mbps, mida toetavad vaid mõned võrguadapterid. Kuid see pole reaalsetes tingimustes absoluutselt rakendatav või seda saab kasutada ainult kahe otse ühendatud jaama vahel, ainult katsestendi sees.
Aga kuna VPN-tunnel suunatakse edasi kahe hosti vahel, kasutades Interneti-ühendust, mis jumbo-kaadreid üldse ei toeta, siis pingil saavutatud tulemust etaloniks võtta ei saa. See on lihtsalt ebareaalne labori saavutus, mis on reaalsetes lahingutingimustes võimatu ja rakendamatu.
Isegi andmekeskuses istudes ei saanud ma üle 9000 baidi suuremaid kaadreid üle kanda.
Reaalses elus rakendatavuse kriteerium on absoluutselt rikutud ja, nagu ma arvan, diskrediteeris läbiviidud "mõõtmise" autor ennast arusaadavatel põhjustel tõsiselt.
Viimane lootusekiir
WireGuardi kodulehel räägitakse palju konteineritest ja saab selgeks, milleks see tegelikult mõeldud on.
Lihtne ja kiire VPN, mis ei vaja konfigureerimist ning mida saab juurutada ja konfigureerida tohutute orkestreerimistööriistadega, nagu Amazonil oma pilves on. Täpsemalt kasutab Amazon uusimaid riistvarafunktsioone, mida ma varem mainisin, näiteks AVX512. Seda tehakse selleks, et kiirendada tööd ja mitte olla seotud x86 või mõne muu arhitektuuriga.
Need optimeerivad läbilaskevõimet ja pakette, mis on suuremad kui 9000 baiti – need on tohutud kapseldatud kaadrid konteinerite omavaheliseks suhtlemiseks või varundustoiminguteks, hetktõmmiste loomiseks või samade konteinerite juurutamiseks. Isegi dünaamilised IP-aadressid ei mõjuta minu kirjeldatud stsenaariumi puhul kuidagi WireGuardi tööd.
Hästi mängitud. Hiilgav teostus ja väga õhuke, peaaegu etalonprotokoll.
Kuid see lihtsalt ei sobi maailma väljaspool andmekeskust, mida te täielikult kontrollite. Kui võtate riski ja hakkate WireGuardi kasutama, peate tegema pidevaid kompromisse krüpteerimisprotokolli kujundamisel ja rakendamisel.
Väljund
Mul on lihtne järeldada, et WireGuard pole veel valmis.
See loodi kerge ja kiire lahendusena paljudele olemasolevate lahendustega seotud probleemidele. Kahjuks ohverdas ta nende lahenduste nimel palju funktsioone, mis on enamiku kasutajate jaoks asjakohased. Seetõttu ei saa see asendada IPseci ega OpenVPN-i.
Selleks, et WireGuard muutuks konkurentsivõimeliseks, peab see lisama vähemalt IP-aadressi sätte ning marsruutimise ja DNS-i konfiguratsiooni. Ilmselgelt on krüpteeritud kanalid selleks mõeldud.
Turvalisus on minu prioriteet ja praegu pole mul põhjust arvata, et IKE või TLS on kuidagi ohus või katki. Mõlemad toetavad kaasaegset krüptimist ja seda on tõestanud aastakümnete pikkune tegevus. See, et miski on uuem, ei tähenda, et see on parem.
Koostalitlusvõime on äärmiselt oluline, kui suhtlete kolmandate osapooltega, kelle jaamu te ei kontrolli. IPsec on de facto standard ja seda toetatakse peaaegu kõikjal. Ja ta töötab. Ja hoolimata sellest, kuidas see välja näeb, ei pruugi WireGuard tulevikus teoreetiliselt ühilduda isegi enda erinevate versioonidega.
Igasugune krüptograafiline kaitse on varem või hiljem katki ja seetõttu tuleb see välja vahetada või värskendada.
Kõigi nende faktide eitamine ja pimesi tahtmine WireGuardi abil oma iPhone'i koduse tööjaamaga ühendada on lihtsalt meistriklass pea liiva alla pistamiseks.
Allikas: www.habr.com