Az utóbbi időben a WireGuard nagy figyelmet kapott, gyakorlatilag ez az új „csillag” a VPN. De tényleg olyan jó, amilyennek tűnik? Szeretném megvitatni néhány észrevételt, és megvizsgálni a WireGuard megvalósítását, hogy elmondjam, miért nem helyettesíti az IPsec-et vagy az OpenVPN-t.
Ebben a cikkben szeretném megdönteni néhány mítoszt [a WireGuard körül]. Igen, hosszú olvasmány vár ránk, tehát ha még nem főztél magadnak egy csésze teát vagy kávét, most jött el az idő. Ezenkívül szeretnék köszönetet mondani Peternek a kaotikusan megfogalmazott gondolataim korrektúrájáért.
Nem az a célom, hogy diszkreditáljam a WireGuard fejlesztőit, vagy hogy leértékeljem az ő erőfeszítéseiket vagy ötleteiket. A termékük működőképes, de személy szerint úgy vélem, hogy teljesen másként van bemutatva, mint amilyen valójában — mint az IPsec és az OpenVPN helyettesítője, ami valójában jelenleg egyszerűen nem létezik.
Megjegyzésként szeretném hozzátenni, hogy a WireGuard ilyen pozicionálásáért a média a felelős, akik beszámoltak róla, és nem magának a projektnek vagy alkotóinak.
Az utóbbi időben nem sok jó hír érkezett a Linux kernelt illetően. Elmondták nekünk a borzalmas processzorhibákról, amelyeket szoftveresen orvosoltak, Linus Torvalds pedig erről túl durván és unalmasan, a fejlesztők nyelvén beszéltek. A nulladik szintű ütemező vagy hálózati stack szintén nem túl érthető téma a csillogó magazinok számára. Itt jön a WireGuard.
Papíron minden jól hangzik: lenyűgöző új technológia.
A WireGuard technikai dokumentációja
Ez a cikk a WireGuard hivatalos dokumentációja, amelyet Jason Donenfeld írt. Ott elmagyarázza a [WireGuard] koncepcióját, célját és technikai megvalósítását a Linux kernelben.
Az első mondat így szól:
A WireGuard […] arra törekszik, hogy a legtöbb alkalmazási esetben helyettesítse az IPsec-et és más népszerű megoldásokat, amelyek felhasználói térben és/vagy TLS-alapúak, mint például az OpenVPN, miközben biztonságosabb, teljesítményorientáltabb és egyszerűbben használható [eszköz].
Természetesen az összes új technológia fő előnye a egyszerűség [az elődeivel összehasonlítva]. De a VPN-nek szintén hatékonynak és biztonságosnak kell lennie..
Mi következik most?
Ha azt mondod, hogy neked [VPN-től] nem ez kell, akkor itt be is fejezhetjük az olvasást. Azonban megjegyzem, hogy az ilyen feladatok bármely más alagút-technológiával szemben is felmerülnek.
A fent idézett mondat legérdekesebb része az a kifejezés, hogy 'a legtöbb esetben', amit természetesen a sajtó figyelmen kívül hagyott. És itt vagyunk, ahol a gondatlanság miatt létrejött káosz miatt eljutottunk — ebben a cikkben.
Helyettesíti-e a WireGuard a [IPsec] VPN-kapcsolatomat a webhelyek között?
Nem. Itt egyszerűen nincs esély arra, hogy a nagy szolgáltatók, mint például a Cisco, Juniper és mások, megvásárolják a WireGuard-ot a termékeikhez. Nem 'ugranak bele a mozgó vonatokba' csak úgy, ha nincs rá nagy szükség. Később mesélek néhány okról, amiért valószínűleg nem tudják integrálni a WireGuard-ot a termékeikbe, még ha akarnák is.
Áthelyezi-e a WireGuard a RoadWarrior-t a laptopomról az adatközpontba?
Nem. Jelenleg a WireGuard-ban hiányzik számos fontos funkció ahhoz, hogy ilyesmit megtegyen. Például nem tud dinamikus IP-címet használni az alagút szerveroldalán, és már ez is összezúzza az ilyen típusú termékhasználat minden forgatókönyvét.
Az IPFire-t gyakran használják olcsó internetes csatornákhoz, például DSL vagy kábelcsatlakozáshoz. Ez értelmes egy kis vagy közepes vállalkozás számára, amelynek nincs szüksége gyors optikai kábelre. [Fordítói megjegyzés: ne feledjük, hogy a kommunikációs területen Oroszország és néhány poszt-szovjet ország messze megelőzi Európát és az Egyesült Államokat, mivel sokkal később kezdtük el építeni a hálózatainkat, és az Ethernet és az optikai szálas hálózatok standardként való megjelenésével könnyebben átszervezhettük magunkat. Az EU vagy az Egyesült Államok hasonló országaiban a 3-5 Mbps sebességű xDSL széles sávú hozzáférés még mindig általános norma, míg az optikai csatlakozás elképesztően magas költségeket jelent a mi mércénkkel. Ezért az írás szerzője a DSL vagy kábelcsatlakozást normának nevezi, nem pedig régimódi dolognak.] A DSL, kábel, LTE (és más vezeték nélküli hozzáférési módszerek) azonban dinamikus IP-címekkel rendelkeznek. Természetesen időnként nem változnak túl gyakran, de azért változnak.
Van egy alprojektről van szó, amelynek neve «wg-dynamic», amely hozzáad egy felhasználói teret, hogy áthidalja ezt a hiányosságot. A fent leírt felhasználói forgatókönyv egyik nagy problémája a dinamikus IPv6-címekkel való súlyosbítás.
A disztribútor szempontjából mindez nem tűnik túl jónak. A fejlesztés egyik célja az volt, hogy megőrizzük a protokoll egyszerűségét és tisztaságát.
Sajnos mindez tényleg túl egyszerű és primitív lett, ezért kiegészítő szoftvert kell használnunk ahhoz, hogy ez az egész konstrukció életképes legyen a valós használat során.
Annyira egyszerű a WireGuard használata?
Még nem. Nem mondom, hogy a WireGuard sosem lesz jó alternatíva a két pont közötti alagút létrehozására, de jelenleg csak a termék alfa verziója, aminek lennie kellene.
De hát akkor mit csinál valójában? Tényleg annyira bonyolultabb az IPsec üzemeltetése?
Nyilvánvalóan nem. Az IPsec szolgáltató átgondolta ezt a kérdést, és a termékét egy felülettel, például az IPFire-ral szállítja.
VPN-alagút létrehozásához IPsec-en keresztül öt adathalmazon kell végigmenni, amelyeket be kell vezetni a konfigurációba: a saját nyilvános IP-cím, a fogadó fél nyilvános IP-címe, azok az alhálózatok, amelyeket nyilvánossá szeretne tenni ezen a VPN-kapcsolaton keresztül, és a pre-shared kulcs. Így a VPN néhány perc alatt beállítható és bármely gyártóval kompatibilis.
Sajnos van néhány kivétel ebben a történetben. Mindenki, aki próbálta IPsec-en keresztül VPN-alagutat létrehozni egy OpenBSD géphez, tudja, miről beszélek. Van még néhány fájdalmas példa, de valójában az IPsec használatával kapcsolatos pozitív tapasztalatokból sokkal több van.
A protokoll bonyolultságáról
A végfelhasználónak nem kell aggódnia a protokoll bonyolultsága miatt.
Ha olyan világban élnénk, ahol ez valódi aggály lenne a felhasználók számára, akkor már rég megszabadultunk volna a SIP-től, H.323-tól, FTP-től és más, több mint tíz éve létrehozott protokolloktól, amelyek rosszul működnek a NAT-tal.
Vannak okai annak, hogy az IPsec bonyolultabb, mint a WireGuard: sokkal több dolgot csinál. Például felhasználói azonosítás jelszóval / SIM-kártyával EAP-val. Kiterjesztett lehetőséget biztosít új kriptográfiai primitívek.
A WireGuard viszont nem rendelkezik ezzel.
És ez azt jelenti, hogy a WireGuard valamikor meghibásodik, mert az egyik kriptográfiai primitív gyengül vagy teljesen kompromittálódik. A műszaki dokumentáció szerzője így fogalmaz erről:
Érdemes megjegyezni, hogy a WireGuard kriptográfiailag önbizalommal bír. Szándékosan hiányzik a titkosítások és protokollok rugalmassága. Ha az alacsonyabb szintű primitívekben komoly hiányosságokat találnak, az összes végpontot frissíteni kell. Ahogy az SSL/TLS folyamatosan jelentkező sebezhetőségei is mutatják, a titkosítás rugalmassága most hatalmas mértékben megnőtt.
Az utolsó állítás abszolút helyes.
A konszenzus elérése arról, hogy milyen titkosítást használjunk, bonyolulttá teszi az IKE és TLS típusú protokollokat. több mint Túl bonyolultak? Igen, az SSL/TLS sebezhetőségek meglehetősen gyakran fordulnak elő, és nincs rájuk alternatíva.
A valós problémák figyelmen kívül hagyása.
Képzelje el, hogy van egy VPN-szervere 200 aktív klienssel, szerte a világban. Ez egy meglehetősen szokásos használati forgatókönyv. Ha meg kellene változtatnia a titkosítást, akkor frissítést kellene zavarnia az összes WireGuard másolatra ezeken a laptopokon, okostelefonokon stb. Egyidejűleg Ez szó szerint lehetetlen. Az adminisztrátorok, akik megpróbálják ezt megtenni, hónapokra lesznek szükségesek ahhoz, hogy a megfelelő konfigurációkat telepítsék, és a közepes méretű cégeknek szó szerint évekbe telhet egy ilyen esemény lebonyolítása.
Az IPsec és az OpenVPN kínálja a titkosítások egyeztetésének funkcióját. Ezért egy ideig, amikor bekapcsolja az új titkosítást, a régi is működni fog. Ennek köszönhetően a jelenlegi kliensek frissülni tudnak az új verzióra. Miután a frissítést végrehajtották, egyszerűen lekapcsolja a sebezhető titkosítást. És kész! Kész! Csodás vagy! A kliensek ezt még észre sem veszik.
Valójában ez egy nagyon gyakori eset nagy telepítések során, és még az OpenVPN is tapasztal némi nehézséget ezzel. A visszamenőleges kompatibilitás fontos, és bár gyengébb titkosítást használ, sokak számára ez nem ok a vállalkozásuk bezárására. Mert ez számos kliens munkájának megbénulását eredményezheti a munkájuk végrehajtásának képtelensége miatt.
A WireGuard csapata egyszerűsítette a protokollját, de teljesen használhatatlanná tette az olyan emberek számára, akik nem rendelkeznek folyamatos irányítással mindkét alagútjuk fölött. Tapasztalataim szerint ez a forgatókönyv a leggyakoribb.
Kriptográfia!
De mi ez az érdekes új titkosítás, amit a WireGuard használ?
A WireGuard a Curve25519-et használja kulcscserére, a ChaCha20-at titkosításra, és a Poly1305-öt az adatok hitelesítésére. Emellett a SipHash-t is használja a hash-kulcsokhoz, és a BLAKE2-t a hash-eléshez.
A ChaCha20-Poly1305 szabványosított az IPsec és az OpenVPN számára (TLS-en keresztül).
Nyilvánvaló, hogy Daniel Bernstein fejlesztése nagyon gyakran használják. A BLAKE2 a BLAKE utódja, ami a SHA-3 döntős volt, de nem nyert, mivel hasonlít a SHA-2-höz. Ha a SHA-2-t feltörik, akkor nagy a valószínűsége, hogy a BLAKE is kompromittálódik.
Az IPsec és az OpenVPN nem igényel SipHash-ot a tervezésük miatt. Így jelenleg az egyetlen, ami nem használható velük, az a BLAKE2, és az is csak addig, amíg nem szabványosítják. Ez nem nagy hátrány, mert a VPN-ek HMAC-ot használnak az integritás biztosítására, ami erős megoldásnak számít még az MD5-tel együtt is.
Tehát arra a következtetésre jutottam, hogy szinte ugyanazt a kriptográfiai eszközkészletet használják minden VPN esetében. Így a WireGuard nem biztonságosabb vagy kevésbé biztonságos, mint bármely más, aktuális termék, amikor az adatok titkosítása vagy integritása a téma.
De még ez sem a legfontosabb dolog, amire az olyan hivatalos dokumentáció szerint figyelni kell. A legfontosabb a sebesség.
Gyorsabb-e a WireGuard, mint a többi VPN megoldás?
Röviden: nem, nem gyorsabb.
A ChaCha20 egy folyamatos titkosító, amely könnyebben implementálható szoftverben. Egy bitet titkosít egyszerre. A blokkalapú protokollok, mint az AES, 128 bitet titkosítanak egyszerre. A hardvertámogatás megvalósításához sokkal több tranzisztorra van szükség, ezért a nagyobb processzorok AES-NI-t kínálnak – egy utasításkészlet kiterjesztést, amely bizonyos titkosítási folyamatokat gyorsít.
Várták, hogy az AES-NI soha nem kerül be okostelefonokba [pedig bekerült, a fordító megjegyzése]. Erre fejlesztették ki a ChaCha20-ot, mint egy könnyű és gazdaságos alternatívát, amely kíméli az akkumulátor töltését. Ezért talán meglepetés, hogy minden okostelefon, amelyet ma megvásárolhat, rendelkezik valamilyen AES gyorsítással, és gyorsabban működik ezzel a titkosítással, mint a ChaCha20-tel.
Nyilvánvaló, hogy szinte minden asztali PC- vagy szerverprocesszor, amelyet az utóbbi pár évben vásároltak, rendelkezik AES-NI-val.
Ennek következtében arra számítok, hogy az AES minden egyes szcenárióban felülmúlja a ChaCha20-t. A WireGuard hivatalos dokumentációjában említést nyer, hogy az AVX512 révén a ChaCha20-Poly1305 felülmúlja az AES-NI-t, de ez a parancsérték bővítés csak nagyobb processzorokon érhető el, ami újból nem segít a kisebb és mobil hardvereken, amelyek mindig is gyorsabban működnek az AES-NI-vel.
Nem vagyok biztos benne, hogy ezt előre látták-e a WireGuard fejlesztésekor, de ma az a tény, hogy egyetlen titkosításhoz véglegesen kötve van, már hátrány, amely nem biztos, hogy jótékonyan hat a teljesítményére.
Az IPsec szabad választást biztosít az Önnek legmegfelelőbb titkosításhoz. Ez nyilvánvalóan szükséges, ha például 10 gigabájtnál nagyobb adatot szeretne átkonvertálni VPN-kapcsolaton keresztül.
Integrációs problémák Linuxban
Bár a WireGuard modern titkosítási protokollt választott, ez máris számos problémát felvetett. Így, ahelyett, hogy azt használnák, amit a kernel dobozból támogat, a WireGuard integrációját évek óta halasztják a Linuxban lévő primitívek hiánya miatt.
Nem vagyok teljesen tisztában a többi operációs rendszer helyzetével, de valószínűleg nem különbözik túlságosan a Linux helyzetétől.
Hogyan néz ki a valóság?
Sajnos minden alkalommal, amikor az ügyfél megkér, hogy állítsak be neki VPN-kapcsolatot, szembesülök azzal, hogy elavult hitelesítő adatokat és titkosítást használnak. A 3DES és az MD5 kombinációja még mindig elterjedt gyakorlat, akárcsak az AES-256 és a SHA1. Bár az utóbbi kicsit jobb – ez nem az, amit 2020-ban használni kellene.
Kulcsok cseréjéhez kíméletlenek voltak RSA-t használnak – lassú, de elég biztonságos eszköz.
Ügyfeleim kapcsolatban állnak a vámhatóságokkal és egyéb állami szervekkel, valamint világszerte ismert nagyvállalatokkal. Mindannyian egy évtizedekkel ezelőtt létrehozott kérdőívet használnak, és a SHA-512 használatának lehetősége soha nem került hozzáadásra. Nem mondhatom, hogy ez kifejezetten befolyásolja a technológiai fejlődést, de nyilvánvaló, hogy lassítja a vállalati folyamatokat.
Fáj látni, mert az IPsec már 2005 óta támogatja az elliptikus görbéket. A Curve25519 szintén újszerű és használható. Vannak alternatívák az AES-hez, mint a Camellia és a ChaCha20, de nyilvánvaló, hogy nem mindegyiküket támogatják a nagyobb szolgáltatók, mint például a Cisco és mások.
És az emberek ezt használják. Számos Cisco készlet érhető el, és sok készlet készült, hogy a Cisco-val működjön. Ők a piacon vezető szerepet játszanak ebben a szegmensben, és nem nagyon érdeklik őket az innovációk.
Igen, a helyzet [a vállalati szegmensben] borzalmas, de nem fogunk látni változásokat a WireGuard miatt. A gyártók valószínűleg soha nem fognak felfedezni teljesítményproblémákat a már használt eszközökkel és titkosítással kapcsolatban, nem fognak észlelni problémákat az IKEv2 használatakor — és ezért nem keresnek alternatívákat.
Gondolkodott már valaha a Cisco elhagyásán?
Benchmarkok
Most áttérünk a WireGuard dokumentációjából származó benchmarkokra. Bár ez a [dokumentáció] nem tudományos cikk, mégis többet vártam el a fejlesztőktől tudományos megközelítést vagy tudományos alapként való használatot. Bármilyen benchmark haszontalan, ha azokat nem lehet reprodukálni, és még inkább haszontalan, ha laboratóriumi körülmények között nyerik.
A WireGuard Linux verziójában előnyt nyer a GSO — Generic Segmentation Offloading használatával. Ennek köszönhetően a kliens egy hatalmas 64 kilobájtos csomagot hoz létre, amelyet egy lépésben titkosít/dekódol. Így csökken a hívások és a kriptográfiai műveletek végrehajtásának költsége. Ha szeretné maximalizálni a VPN kapcsolatának sávszélességét — ez egy jó ötlet.
De, ahogy lenni szokott, a valóságban nem minden olyan egyszerű. Egy ilyen nagy csomag hálózati adapterre történő küldése megköveteli, hogy azt sok kisebb csomagra bontsák. Az átlagos küldési méret 1500 byte. Tehát a 64 kilobájtunk 45 csomagra lesz bontva (1240 byte információ és 20 byte IP-fejléc). Ezután egy időre teljesen blokkolják a hálózati adapter működését, mivel ezeket egyszerre kell elküldeni. Ennek következtében prioritásugrás fog bekövetkezni, és olyan csomagok, mint például a VoIP, várakozási sorba kerülnek.
Így a WireGuard által olyan magabiztosan hangoztatott magas sávszélesség a más alkalmazások hálózati működésének lelassításának árán valósul meg. A WireGuard csapata már megerősítette ez az én következtetésem.
De haladjunk tovább.
A technikai dokumentáció benchmarkjai szerint a csatlakozás 1011 Mbit/s sávszélességet mutat.
Impozáns.
Ez különösen lenyűgöző, mivel egy gigabites Ethernet-összeköttetés maximális elméleti sávszélessége 966 Mbit/s 1500 byte-os csomagméret mellett, ami mínusz 20 byte az IP-fejléc, 8 byte az UDP-fejléc és 16 byte a WireGuard saját fejlécében. Van egy IP-fejléc a kapszulázott csomagban és még egy TCP fejléc 20 byte. Honnan származik tehát ez a plusz sávszélesség?
A fent említett nagy keretekkel és GSO előnyökkel a keretméret 9000 byte esetén az elméleti maximum 1014 Mbit/s-ra nő. Általában ez a sávszélesség a valóságban elérhetetlen, mert nagy nehézségekkel jár. Így csak azt feltételezhetem, hogy a tesztet felső korlátú keretekkel hajtották végre, 64 kilobájt méretet meghaladóan, az elméleti maximum 1023 Mbit/s, ami csak bizonyos hálózati adapterekkel támogatott. De ez a valós körülmények között teljesen alkalmazhatatlan, vagy csak közvetlenül összekapcsolt állomások között, kizárólag tesztkörnyezet keretein belül használható.
Mivel a VPN-alagút két gazda között internetkapcsolaton keresztül működik, amely általában nem támogatja a nagy kereteket, a laboratóriumi körülmények között elért eredményt nem lehet etalonként elfogadni. Ez csupán egy irreális laboratóriumi teljesítmény, amely a valós harci körülmények között lehetetlen és alkalmazhatatlan.
Még egy adatközpontban sem tudnék 9000 bájtnál nagyobb kereteket átkonvertálni.
A valós életben alkalmazhatóság kritériuma teljes mértékben sérült, és szerintem a végrehajtott 'mérés' szerzője súlyosan diszkreditálta magát nyilvánvaló okok miatt.
Az utolsó reménysugár.
A WireGuard weboldalán sokat beszélnek a tárolókról, és világossá válik, hogy valójában mire is készült.
Egyszerű és gyors VPN, amely nem igényel konfigurálást, és tömeges orchestrációs eszközökkel telepíthető és beállítható, mint például az Amazon felhőszolgáltatásában. Az Amazon konkrétan a legújabb hardveres funkciókat használja, amikről korábban már beszéltem, például az AVX512-t. Ezt azért tesszük, hogy felgyorsítsuk a működést, és ne ragaszkodjunk az x86-hoz vagy bármilyen más architektúrához.
Optimalizálják a sávszélességet és a 9000 bájtot meghaladó csomagokat — ezek hatalmas beágyazott kereteket eredményeznek a tárolók közötti kommunikációhoz, vagy a biztonsági mentések, pillanatfelvételek készítéséhez, vagy ezeknek a tárolóknak a telepítéséhez. Még a dinamikus IP-címek sem befolyásolják a WireGuard működését az általam leírt forgatókönyvben.
Jól játszott. Kiváló megvalósítás és nagyon finom, szinte etalon protokoll.
De egyszerűen nem alkalmas a teljes mértékben Ön által ellenőrzött adatközponton kívüli világ számára. Ha mégis kockára teszi és elkezdi használni a WireGuardot, folyamatos kompromisszumokat kell kötnie a titkosítási protokoll fejlesztése és megvalósítása során.
Következtetés
Nem nehéz arra a következtetésre jutni, hogy a WireGuard még nem készült el.
Úgy tervezték, mint egy könnyített és gyors megoldást a meglévő megoldások egy sor problémájára. Sajnos ezeknek a megoldásoknak a megvalósítása számos funkciót feláldozott, amelyek a legtöbb felhasználó számára relevánsak. Ezért nem tudja helyettesíteni az IPsec-et vagy az OpenVPN-t.
Ahhoz, hogy a WireGuard versenyképes legyen, legalább egy IP-cím beállítást és a forgalomirányítást, valamint a DNS-konfigurációt kellene hozzáadnia. Nyilvánvaló, hogy pontosan ezért szükségesek a titkosított csatornák.
A biztonság a legfontosabb prioritásom, és jelenleg nincs okom arra, hogy feltételezzem, hogy az IKE vagy a TLS bármilyen módon kompromittálva vagy megszakítva lenne. A modern titkosítás mindkettőnél támogatott, és évtizedek használatával tesztelték őket. Csak mert valami újabb, még nem jelenti azt, hogy az jobb is.
A funkcionális kompatibilitás rendkívül fontos, amikor harmadik felekkel lépünk kapcsolatba, akiknek a forgalmát nem ellenőrizzük. Az IPsec de facto szabvány, és gyakorlatilag mindenhol támogatott. És működik. Bármennyire is tűnik elméletinek, a WireGuard a jövőben inkompatibilis lehet még önmagának különböző verzióival is.
Bármely kriptográfiai védelem előbb-utóbb feltörhető, ezért ki kell cserélni vagy frissíteni kell.
Ezeknek a tényeknek a tagadása és a vak vágy, hogy a WireGuardot használjuk az iPhone-unk otthoni munkaállomáshoz való csatlakoztatásához, egyszerűen csak egy mesterkurzus a fej a homokba dugásában.
Forrás: habr.com
