Viimase aja jooksul on WireGuard tõmmanud suurt tähelepanu, olles tõeliselt uus "täht" VPN. Kuid kas ta on tõepoolest nii hea, nagu tundub? Soovin arutada mõningaid tähelepanekuid ja vaadata WireGuardi rakendust, et selgitada, miks see ei ole lahendus, mis asendab IPsec-i või OpenVPN-i.
Selles artiklis soovin suure lahkamisega käsitleda mõningaid müüte [WireGuardi] ümber. Jah, lugemine võtab aega, nii et kui te pole veel tasse teed või kohvi keetnud, siis on nüüd õige aeg seda teha. Samuti tahan tänada Peetrit, et ta toetas mu segaseid mõtteid.
Ma ei sea endale eesmärki WireGuardi arendajaid diskrediteerida, nende pingutusi või ideid devalueerida. Nende toode on funktsionaalne, kuid isiklikult arvan, et see on esitatud täiesti vale mulje järgi — nagu IPsec-i ja OpenVPN-i asendaja, mida tegelikult praegu ei eksisteeri.
Märkusena tahan lisada, et WireGuardi sellise positsioneerimise eest kannavad vastutust meedia, kes sellest rääkinud, mitte projekt või selle loojaid.
Viimasel ajal on Linuxi tuuma teemal olnud vähe häid uudiseid. Meile on räägitud kohutavatest protsessorite haavatavustest, mida on tarkvaraliselt silutud, ja Linus Torvalds rääkis sellest liiga karmilt ja igavalt, arendaja keeles. Ajastiks või nulli taseme võrgu stack ei ole ka just parimad teemad sädelevate ajakirjade jaoks. Siis astub sisse WireGuard.
Paberil kõlab kõik suurepäraselt: kujutlusvõimet sütitav uus tehnoloogia.
Kuid vaatame seda veidi lähemalt.
WireGuardi tehniline dokumentatsioon
See artikkel põhineb WireGuardi ametlikul dokumentatsioonil, mille on kirjutanud Jason Donenfeld. Seal selgitab ta [WireGuardi] kontseptsiooni, eesmärke ja tehnilist rakendust Linuxi tuumas.
Esimene lause ütleb:
WireGuard […] püüab asendada enamiku kasutusjuhtude puhul nii IPsec'i kui ka teised populaarsed kasutusruumi ja/või TLS-i lahendused, nagu OpenVPN, olles samas turvalisem, efektiivsem ja lihtsam kasutada [tööriist].
Muidugi, kõigi uute tehnoloogiate peamine eelis on nende lihtsus [võrreldes eelkäijatega]. Kuid VPN peab olema ka tõhus ja turvaline.
Ja mis edasi?
Kui ütlete, et teile [VPN] ei ole seda vaja, siis võib lugemise lõpetada. Siiski mainin, et selliseid ülesandeid seavad ette kõik teised tunnelitehnoloogiad.
Mainitud tsitaadi kõige huvitavam osa peitub sõnades „enamikul juhtudel”, mida ajakirjandus muidugi tähelepanuta jättis. Ja siin me oleme, kus oleme selle hooletuse põhjustatud kaose tõttu — selles artiklis.
Kas WireGuard asendab minu [IPsec] VPN-ühenduse site'ide vahel?
Ei. Siin pole lihtsalt mingit võimalust, et suured müüjad, nagu Cisco, Juniper ja teised, omandavad WireGuardi oma toodete jaoks. Nad ei „hüppa mööduvatesse rongidesse” jooksvalt, kui selleks pole mingit suurt vajadust. Hiljem räägin mõnest põhjusest, miks nad tõenäoliselt ei suudaks WireGuardi oma toodetesse integreerida, isegi kui nad tahaksid.
Kas WireGuard viib mu RoadWarrior'i sülearvesti andmekeskusesse?
Ei. WireGuard ei sisalda praegu paljusid olulisi funktsioone, et see saaks midagi sarnast teha. Näiteks ei saa see kasutada dünaamilisi IP-aadresse tunneliserveri küljest, ja ainult see rikub kogu toote kasutamise stsenaariumi.
IPFire't kasutatakse sageli odavate internetiühenduste, nagu DSL või kaabliühenduse, jaoks. See on mõistlik väikestele või keskmise suurusega ettevõtetele, kellel ei ole vaja kiiret kiudoptilist internetti. [Примечание от переводчика: не стоит забывать, что в плане связи Россия и некоторые страны СНГ находятся далеко впереди Европы и США, потому что мы начали строить свои сети намного позже и с приходом Ethernet и оптоволоконных сетей в качестве стандарта, нам было проще перестроиться. В тех же странах ЕС или США, xDSL широкополосный доступ на скорости 3-5 Мбит/с — до сих пор всеобщая норма, а оптоволоконное подключение стоит каких-то нереальных по нашим меркам денег. Поэтому автор статьи и говорит о DSL или кабельном подключении, как о норме, а не дремучей старине.] Kuid DSL, kaabel-, LTE (ja muud traadita juurdepääsud) kasutavad dünaamilisi IP-aadresse. Loomulikult ei muutu need alati sageli, kuid siiski muutuvad.
On alamprojekt nimega „wg-dynamic“, mis lisab kasutajaruumi deemon, et see puudus ületada. Suur probleem ülaltoodud kasutusskeemi puhul on dünaamilise IPv6-aadressimise olukorra halvenemine.
Jaotajana näeb kõik see samuti väga kehva välja. Üks arenduse eesmärke oli säilitada protokolli lihtsus ja puhtus.
Kahjuks on kõik see tegelikult muutunud liiga lihtsaks ja primitiivseks, nii et me peame kasutama täiendavat tarkvara, et kogu see struktuur oleks reaalses kasutuses elujõuline.
Kas WireGuard on tõesti nii lihtne kasutada?
Hetkel mitte. Ma ei ütle, et WireGuard ei saa kunagi olema hea alternatiiv tunnelite edastamiseks kahe punkti vahel, kuid praegu on see vaid toote alfa-versioon, milleks ta peaks saama.
Aga mis siis tegelikult toimub? Kas IPsec on tõesti keerulisemini hallatav?
Ilmselt mitte. IPsec-i teenusepakkuja on selle aspekti hoolikalt läbi mõelnud ja pakub oma toodet koos kasutajaliidesega, näiteks IPFire'iga.
VPN-tunneli seadistamiseks IPsec-i kaudu vajate viit andmestikku, mis tuleb konfigureerimisse sisestada: teie enda avalik IP-aadress, vastuvõtva poole avalik IP-aadress, alamvõrgud, mille soovite selle VPN-ühenduse kaudu avalikuks teha, ja eelnevalt jagatud võti. Nii saab VPN-i seadistada vaid mõne minutiga ja see on ühilduv igasuguste müüjatega.
Kahjuks on selles loos mõned erandid. Igaüks, kes on proovinud seadistada VPN-tunneli IPsec-i kaudu OpenBSD masinaga, teab, millest ma räägin. On veel paar valusat näidet, kuid tegelikult on IPsec-i kasutamise positiivseid praktikaid palju ja palju rohkem.
Protokolli keerukusest
Lõppkasutaja ei pea protokolli keerukuse pärast muretsema.
Kui me elaksime maailmas, kus see oleks kasutaja jaoks tõeline mure, oleksime juba ammu loobunud SIP-ist, H.323-st, FTP-st ja muudest protokollidest, mis on loodud rohkem kui kümme aastat tagasi ja töötavad kahjuks halvasti NAT-iga.
On põhjuseid, miks IPsec on keerulisem kui WireGuard: see teeb oluliselt rohkem asju. Näiteks kasutaja autentimine sisselogimise/parooli või SIM-kaardi kaudu EAP abil. Sellel on laiem võimalus lisada uusi krüptograafilisi primitiive.
WireGuardil seda ei ole.
Ja see tähendab, et WireGuard murdub mingil hetkel, sest üks krüptograafilistest primitiividest nõrgeneb või on täielikult kompromiteeritud. Tehnilise dokumentatsiooni autor ütleb sellest nii:
Oluline on märkida, et WireGuard on krüptograafiliselt enesekehtestav. Tal on teadlikult puudulik šifrite ja protokollide paindlikkus. Kui aluse primitiivides avastatakse tõsiseid auke, tuleb kõik lõpp-punktid uuendada. Nagu näha jätkuvast SSL/TLS haavatavuste voost, on šifrite paindlikkus praegu tohutult suurenenud.
Viimane lause on täiesti õige.
Konsensuse saavutamine selle üle, millist šifreerimist kasutada, muudab protokollid, nagu IKE ja TLS, üle keeruliseks. Liigselt keeruliseks? Jah, TLS/SSL haavatavusi esineb piisavalt sageli ja alternatiive pole.
Tegelike probleemide ignoreerimine
Kujutage ette, et teil on VPN-server 200 aktiivse kliendiga, kes asuvad eri paigus üle maailma. See on täiesti tavaline kasutusstsenaarium. Kui peate krüpteeringut muutma, tuleb teil uuendus edastada kõikidele WireGuardi koopiaile nende sülearvutites, nutitelefonides ja muudes seadmetes. Samuti edastamine. See on sõna otseses mõttes võimatu. Administratorid, kes üritavad seda teha, vajavad vajalike konfiguratsioonide juurutamiseks kuid, ja keskmiste ettevõtete jaoks kulub sellise ettevõtmise elluviimiseks lausa aastaid.
IPsec ja OpenVPN pakuvad šifrite kooskõlastamise funktsiooni. Seetõttu töötab mõnda aega, pärast seda kui aktiveerite uue krüpteeringu, ka eelmine. Nii saavad olemasolevad kliendid uuendusele üle minna. Pärast uuenduse rakendamist lülitate lihtsalt välja haavatava krüpteeringu. Ja kõik on! Valmis! Te olete suurepärased! Ja kliendid ei pane seda isegi tähele.
Tegelikult on see väga levinud juhtum suurte kasutusjuhtumite korral, ning isegi OpenVPN kogeb siinkohal teatavaid raskusi. Tagasipööratavuse säilitamine on oluline ning kuigi te kasutate nõrgemat krüptimist, ei tähenda see paljude jaoks, et nad oma äri sulgeksid. Sest see tooks kaasa sadade klientide töö seiskumise, kuna nad ei suuda oma tööd teha.
WireGuardi meeskond on teinud oma protokolli lihtsamaks, kuid täiesti sobimatuks inimestele, kes ei oma pidevat ülevaadet oma tunnelite mõlema peeri üle. Minu kogemuse põhjal on just selline stsenaarium kõige levinum.
Krüptograafia!
Aga mis see huvitav uus krüptimine on, mida WireGuard kasutab?
WireGuard kasutab Curve25519 võtme vahetamiseks, ChaCha20 krüptimiseks ja Poly1305 andmete autentimiseks. Samuti töötab see SipHashiga võtmehaskimiseks ja BLAKE2 hashimiseks.
ChaCha20-Poly1305 on standardiseeritud IPsec'i ja OpenVPN'i (TLS kaudu) jaoks.
On selge, et Daniel Bernstein'i välja töötatud tehnoloogiat kasutatakse väga sageli. BLAKE2 on BLAKE järeltulija, mis oli SHA-3 finalist, kuid ei võitnud oma sarnasuse tõttu SHA-2-ga. Kui SHA-2 oleks rikutud, oleks suur tõenäosus, et ka BLAKE on kompromiteeritud.
IPsec ja OpenVPN ei vaja SipHash'i nende kujunduse tõttu. Seega on ainus, mida praegu ei saa nende jaoks kasutada, BLAKE2, ning see kehtib ainult seni, kuni see ei ole standardiseeritud. See ei ole suur puudus, kuna VPN-id kasutavad integriteedi loomiseks HMAC-i, mis on isegi MD5-ga koos arvestades tugev lahendus.
Nii jõudsin järeldusele, et peaaegu kõikides VPN-ides kasutatakse praktiliselt sama krüptograafilist tööriistade komplekti. Seetõttu ei ole WireGuard mitte rohkem ega vähem turvaline kui kõik muud aktuaalsed tooted, kui teema on andmete krüptimine või edastatava sisu terviklikkus.
Aga isegi see ei ole kõige olulisem, millele projektis ametlikus dokumentatsioonis tähelepanu pöörata. Lõppude lõpuks on peamine — kiirus.
Kas WireGuard on kiirem kui teised VPN lahendused?
Lühidalt öeldes: ei, mitte kiiremini.
ChaCha20 on voolukrüpto, mille rakendamine tarkvaras on lihtsam. See krüpteerib ühe bitiga korraga. Blokaadiprotokollid, nagu AES, krüpteerivad 128 bitti korraga. Riistvaratoe rakendamiseks on vaja palju rohkem transistore, seega on suuremad protsessorid varustatud AES-NI-ga — käskude komplekti laiendusega, mis täidab osa krüpteerimisprotsessi ülesannetest selle kiirendamiseks.
Ootused olid, et AES-NI ei jõua kunagi nutitelefonidesse [aga see jõudis, — tõlkija märkus]. Selle asemel töötati välja ChaCha20 — kerge ja ökonoomne alternatiiv, mis säästab aku energiat. Seetõttu võib teid üllatada, et igas nutitelefoni, mille täna ostate, on mingisugune kiirus AES-i jaoks ja see töötab selle krüpteerimisega kiiremini ning väiksema energiatarbimisega kui ChaCha20.
Ilmselgelt on peaaegu igas lauaarvuti / serveri protsessoris, mis on viimase paari aasta jooksul ostetud, AES-NI olemas.
Seega ootan, et AES ületab ChaCha20 igas eraldi stsenaariumis. WireGuardi ametlikus dokumentatsioonis mainitakse, et tänu AVX512-le ületab ChaCha20-Poly1305 AES-NI-d, kuid see käskude laiendamine on saadaval ainult suuremates protsessorites, mis ei aita väike- ja mobiilseadmel, mis töötab alati AES-NI-ga kiiremini.
Ma ei ole kindel, kas seda oli võimalik WireGuardi arendamise ajal ette näha, kuid tänane fakt, et see on tugevalt seotud ühe krüptimisega, on juba puuduseks, mis võib halvasti mõjutada selle toimimist.
IPsec võimaldab vabalt valida, milline krüptimine sobib teie olukorraga kõige paremini. Ja see on iseenesest mõistetav, kui soovite näiteks edastada 10 ja rohkem gigabyte andmeid VPN-ühenduse kaudu.
Integreerimisprobleemid Linuxis
Kuigi WireGuard valis kaasaegse krüptimisprotokolli, toob see endaga kaasa palju probleeme. Ja selle asemel, et kasutada seda, mida tuum kohe toetab, on WireGuardi integreerimine veninud aastaid, kuna neid primitiive ei ole Linuxis.
Ma ei ole täielikult kindel, mis toimub teiste operatsioonisüsteemide puhul, kuid tõenäoliselt ei erine see Linuxist palju.
Kuidas näeb reaalsus välja?
Kahjuks, iga kord, kui klient palub mul seadistada VPN-ühenduse, kohtan teemat, et nad kasutavad aegunud kasutusandmeid ja krüpteerimist. 3DES koos MD5-ga on endiselt levinud praktika, nagu ka AES-256 ja SHA1. Ja kuigi viimane on pisut parem, ei ole see midagi, mida peaksite 2020. aastal kasutama.
Ahnitsemiseks võtmete vahetamiseks alati kasutatakse RSA-d — aeglane, kuid piisavalt ohutu tööriist.
Minu kliendid on seotud tolliorganite ja teiste riigiasutustega, samuti suurte korporatsioonidega, mille nimesid tuntakse üle kogu maailma. Kõik nad kasutavad taotlusvormi, mis loodi juba aastakümneid tagasi, ja võimalust SHA-512 kasutamiseks pole kunagi lisatud. Ma ei saa öelda, et see mõjutab tehnoloogilist arengut, kuid on selge, et see aeglustab ettevõtte protsesse.
On kahju seda näha, kuna IPsec toetab elliptilisi kõveraid peaaegu alates 2005. aastast. Curve25519 on samuti uuem ja saadaval kasutamiseks. On ka alternatiive AES-ile, nagu Camellia ja ChaCha20, kuid ilmselt ei toeta neid kõik suured teenusepakkujad, näiteks Cisco ja teised.
Ja inimesed kasutavad neid. Cisco komplekte on palju, samuti on palju komplekte, mis on loodud töötama koos Cisco-ga. Nad on selle segmendi turuliidrid ja ei ole väga huvitatud uuendustest.
Jah, olukord [korporatiivses segmentis] on kohutav, kuid me ei näe mingeid muutusi WireGuard'i tõttu. Tootjad ei avasta tõenäoliselt kunagi mingeid jõudlusprobleeme juba kasutatavast tööriistast ja krüptimisest ega näe probleeme IKEv2 kasutamisel — ja seetõttu nad ei otsi alternatiive.
Kas olete kunagi kaalunud loobuda Cisco-st?
Benkmarker
Nüüd liigume üle WireGuardi dokumentatsiooni benchmarkide juurde. Kuigi see [dokumentatsioon] ei ole teaduslik artikkel, ootasin siiski arendajatelt teaduslikumat lähenemist või teadusliku lähenemise kasutamist kui näidet. Igaühed benchmarkid on kasutud, kui neid ei saa korrata, ja nad on veelgi kasutud, kui need saadakse laboritingimustes.
WireGuardi Linuxi koostises on tal eelis, kasutades GSO-d — Generic Segmentation Offloading. Tänu sellele loob klient tohutu paketi suurusega 64 kilobaiti ja krüpteerib/dekrüpteerib selle ühe katsega. Seeläbi väheneb krüptograafiliste operatsioonide kutsete ja rakenduste kulud. Kui soovite maksimeerida oma VPN-ühenduse läbilaskevõimet — on see hea idee.
Kuid nagu öeldakse, ei ole kõik nii lihtne. Suure paketi saatmine võrknupukesi nõuab, et see oleks jagatud paljudeks väiksemateks pakettideks. Tavaline saatmise suurus on 1500 baiti. See tähendab, et meie 64 kilobaiti suurune hiiglane jaguneb 45 paketiks (1240 baiti teavet ja 20 baiti IP-päist). Seejärel blokeerivad nad mõneks ajaks võrknupuke täielikult, kuna need peavad olema saadetud koos ja kohe. Lõpuks põhjustab see prioriteedi hüpet, ja sellised paketid nagu VoIP pannakse ootejärjekorda.
Nii saavutatakse kõrge ribalaius, millest WireGuard nii julgesti räägib, aeglustades teiste rakenduste võrgutööd. Ja WireGuardi meeskond on juba kinnitanud see on minu järeldus.
Aga läheme edasi.
Vastavalt tehnilistele dokumendile näitab ühendus ribalaiust 1011 Mbit/s.
Muljetavaldav.
See, et on eriti muljetavaldav, et ühe gigabitise Etherneti ühenduse maksimaalne teoreetiline läbilaskevõime on 966 Mbit/s, kui paketisuurus on 1500 baiti, miinus 20 baiti IP-päises, 8 baiti UDP-päises ja 16 baiti WireGuardi enda päises. Inkatud pakettides on veel üks IP-päis ja TCP-s 20 baiti. Kust see täiendav läbilaskevõime siis tuli?
Suuremate raamide ja eelistega GSO, millest oleme varem rääkinud, on teoreetiline maksimum paketi suurusega 9000 baiti 1014 Mbit/s. Tüüpiliselt on selline läbilaskevõime reaalsuses saavutamatu, kuna sellega on seotud suurte raskustega. Seega võin vaid oletada, et test viidi läbi veelgi suuremate raamidega, mille ülekatte suurus on 64 kilobaiti ja teoreetiline maksimum 1023 Mbit/s, mida toetavad ainult mõned võrgukaardid. Kuid see pole absoluutselt rakendatav reaalses elus või saab seda kasutada ainult kahe vahetult omavahel ühendatud jaama vahel, rangelt testimise jaoks.
Kuna VPN-tunnel loodi kahe hosti vahel internetiühenduse kaudu, mis ei toeta suuri raame, ei saa saavutatud tulemust pidada standardiks. See on lihtsalt ebareaalne laboratoorne saavutus, mida ei saa ja ei ole võimalik rakendada tõelistes tingimustes.
Isegi olles andmekeskuses, ei saaks ma edastada raame, mis on suuremad kui 9000 baiti.
Tõelisuse rakendamise kriteerium on täiesti rikutud ja, nagu ma arvan, on autori läbiviidud 'mõõtmine' tõsiselt diskrediteerinud teda ise mõistetavatel põhjustel.
Viimane lootusekiir
WireGuardi lehel räägitakse palju konteineritest ja on selge, milleks see tegelikult mõeldud on.
Lihtne ja kiire VPN, mis ei vaja seadistamist ja saab rakendada ja seadistada massiliste orkestreerimisriistadega, nagu näiteks Amazon oma pilves. Konkreetne Amazon kasutab uusimaid riistvarafunktsioone, millest olen varem rääkinud, nagu AVX512. Seda tehakse, et kiirendada tööd ja mitte siduda end x86 või mõne muu arhitektuuriga.
Need to optimize bandwidth and packets larger than 9000 bytes — this results in massive encapsulated frames for communication between containers or for backup operations, snapshot creation, or deployment of those containers. Even dynamic IP addresses will not affect WireGuard's performance in the scenario I described.
Well played. A brilliant implementation and a very sleek, almost quintessential protocol.
But it simply does not suit a world outside a fully controlled data center. If you dare to start using WireGuard, you'll have to make constant compromises in the development and implementation of the encryption protocol.
Kokkuvõte
I have no difficulty concluding that WireGuard is not yet ready.
It was conceived as a lightweight and fast solution for a number of issues with existing solutions. Unfortunately, in pursuit of these solutions, it sacrificed many features that would be relevant to most users. That is why it cannot replace IPsec or OpenVPN.
Kuna WireGuard oleks konkurentsivõimeline, peab see lisama vähemalt IP-aadressi ja marsruutimise ning DNS-i seadistamise. Ilmselgelt on selleks vajalikud krüpteeritud kanalid.
Turvalisus on minu peamine prioriteet ja mul ei ole hetkeseisuga põhjuseid uskuda, et IKE või TLS oleksid kuidagi kompromiteeritud või rikutud. Kaasaegne krüptimine on mõlemas toetatud ja nad on läbi testitud aastakümnete jooksul. Kui midagi on uuem, ei tähenda, et see on parem.
Funktsionaalne ühilduvus on äärmiselt oluline, kui te suhtlete kolmandate osapooltega, kelle jaamad ei ole teie kontrolli all. IPsec on de facto standard ja seda toetatakse peaaegu kõikjal. Ja see töötab. Ja nagu kummaline kui see ei kõlaks, võib WireGuard tulevikus olla isegi iseendaga erinevate versioonide osas ühilduvuse probleemidega.
Iga krüptograafiline kaitse on varem või hiljem sisse murdetud ja seega peab olema asendatud või uuendatud.
Küsimine nende faktide eitamisest ja pime soov kasutada WireGuard'i oma iPhone'i ühendamiseks kodu tööjaamaga on lihtsalt klassikaline näide pea liiva alla peitmisest.
Allikas: habr.com
