A WireGuard az utóbbi időben nagy figyelmet kapott, valójában ez az új sztár a VPN-ek között. De vajon olyan jó, mint amilyennek látszik? Szeretnék néhány észrevételt megvitatni és áttekinteni a WireGuard megvalósítását, hogy elmagyarázzam, miért nem megoldás az IPsec vagy az OpenVPN lecserélése.
Ebben a cikkben szeretnék megcáfolni néhány mítoszt [a WireGuard körül]. Igen, sokáig fog tartani az olvasás, tehát ha még nem főzött magának egy csésze teát vagy kávét, akkor itt az ideje, hogy megcsinálja. Ezúton is szeretném megköszönni Péternek, hogy kijavította kaotikus gondolataimat.
Nem azt a célt tűzöm ki magam elé, hogy lejáratjam a WireGuard fejlesztőit, leértékeljem erőfeszítéseiket vagy elképzeléseiket. A termékük működik, de személy szerint úgy gondolom, hogy teljesen másként mutatják be, mint amilyen valójában - az IPsec és az OpenVPN helyettesítőjeként mutatják be, amelyek valójában egyszerűen nem léteznek.
Megjegyzésként szeretném hozzátenni, hogy a WireGuard ilyen elhelyezéséért a felelősség a médiát terheli, amely beszélt róla, és nem magát a projektet vagy annak alkotóit.
Az utóbbi időben nem sok jó hír érkezett a Linux kernellel. Tehát a processzor szörnyű sebezhetőségeiről meséltek nekünk, amelyeket szoftverrel simított ki, Linus Torvalds pedig túl durván és unalmasan, a fejlesztő haszonelvű nyelvén. Az ütemező vagy a nulla szintű hálózati stack szintén nem túl egyértelmű téma a fényes magazinok számára. És itt jön a WireGuard.
Papíron mindez nagyszerűen hangzik: egy izgalmas új technológia.
De nézzük meg egy kicsit alaposabban.
WireGuard fehér papír
Ez a cikk a írta Jason Donenfeld. Itt 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 […] célja, hogy mind az IPsec-et, mind az egyéb népszerű felhasználói terület- és/vagy TLS-alapú megoldásokat, például az OpenVPN-t lecserélje a legtöbb használati esetben, miközben biztonságosabb, hatékonyabb és könnyebben használható [eszköz].
Természetesen minden új technológia fő előnye az nyugalom [az elődökhöz képest]. De VPN-nek is kell lennie hatékony és biztonságos.
Szóval, mi lesz ezután?
Ha azt mondja, hogy nem erre van szüksége [VPN-ből], akkor itt befejezheti az olvasást. Megjegyzem azonban, hogy ilyen feladatok minden más alagútépítési technológiára vonatkoznak.
A fenti idézet közül a legérdekesebb a "legtöbb esetben" szavakban rejlik, amelyeket a sajtó természetesen figyelmen kívül hagyott. Így hát ott tartunk, ahol a hanyagságból eredő káosz miatt kerültünk – ebben a cikkben.
A WireGuard lecseréli az [IPsec] helyek közötti VPN-t?
Nem. Egyszerűen nincs esély arra, hogy olyan nagy gyártók, mint a Cisco, a Juniper és mások megvásárolják a WireGuard-ot termékeikhez. Nem "ugranak fel az elhaladó vonatokra" menet közben, hacsak nincs rá nagy szükség. Később áttekintek néhány okot, amiért valószínűleg még akkor sem tudják bevinni a WireGuard termékeiket a fedélzetre, ha akarnák.
A WireGuard elviszi a RoadWarrioromat a laptopomról az adatközpontba?
Nem. Jelenleg a WireGuard nem rendelkezik túl sok fontos funkcióval ahhoz, hogy képes legyen ilyesmire. Például nem tud dinamikus IP-címeket használni az alagútkiszolgáló oldalán, és ez önmagában megtöri a termék ilyen használatának teljes forgatókönyvét.
Az IPFire-t gyakran használják olcsó internetes kapcsolatokhoz, például DSL- vagy kábelkapcsolatokhoz. Ez logikus a kis- és középvállalkozások számára, amelyeknek nincs szükségük gyorsszálas szálra. [Megjegyzés a fordítótól: ne felejtsd el, hogy kommunikációs szempontból Oroszország és néhány FÁK-ország messze megelőzi Európát és az Egyesült Államokat, mivel hálózatainkat jóval később kezdtük építeni, és az Ethernet és az optikai hálózatok megjelenésével. szabványnak, könnyebb volt újjáépíteni. Az EU vagy az USA ugyanazon országaiban továbbra is általános a 3-5 Mbps sebességű xDSL szélessávú hozzáférés, és egy száloptikai kapcsolat a mi szabványunk szerint irreális pénzbe kerül. Ezért a cikk szerzője a DSL-ről vagy a kábeles kapcsolatról beszél, mint normáról, és nem az ókorról.] A DSL, a kábel, az LTE (és más vezeték nélküli hozzáférési módok) azonban dinamikus IP-címmel rendelkeznek. Persze néha nem gyakran változnak, de változnak.
Van egy alprojekt, az úgynevezett , amely egy userspace démont ad hozzá ennek a hiányosságnak a kiküszöbölésére. A fent leírt felhasználói forgatókönyv óriási problémája a dinamikus IPv6-címzés súlyosbodása.
A forgalmazó szemszögéből mindez sem tűnik túl jól. Az egyik tervezési cél az volt, hogy a protokoll egyszerű és tiszta legyen.
Sajnos mindez túlságosan egyszerűvé és primitívé vált, így további szoftvereket kell használnunk ahhoz, hogy ez az egész design életképes legyen a valós használatban.
A WireGuard olyan könnyen használható?
Még nem. Nem mondom, hogy a WireGuard soha nem lesz jó alternatíva a két pont közötti alagútra, de egyelőre ez csak a termék alfa verziója, aminek lennie kellene.
De akkor mit csinál valójában? Az IPsec karbantartása valóban sokkal nehezebb?
Nyilvánvalóan nem. Az IPsec-szállító gondolt erre, és termékét interfésszel, például IPFire-rel együtt szállítja.
VPN-alagút IPsec feletti beállításához öt adatkészletre lesz szüksége, amelyeket meg kell adnia a konfigurációban: saját nyilvános IP-címe, a fogadó fél nyilvános IP-címe, az alhálózatok, amelyeken keresztül nyilvánossá kíván tenni. ezt a VPN-kapcsolatot és az előre megosztott kulcsot. Így a VPN percek alatt beállítható, és bármely szállítóval kompatibilis.
Sajnos van néhány kivétel ez alól a történet alól. Aki próbált már IPsec-en keresztül OpenBSD-s gépre alagutat építeni, tudja, miről beszélek. Van még egy-két fájdalmas példa, de valójában még sok-sok jó gyakorlat létezik az IPsec használatára.
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óban a felhasználó gondja lenne, akkor 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 nem működnek jól a NAT-tal.
Vannak okai annak, hogy az IPsec bonyolultabb, mint a WireGuard: sokkal több dolgot végez. Például felhasználó hitelesítés bejelentkezési/jelszó vagy EAP-s SIM-kártya használatával. Kibővített új hozzáadási képességgel rendelkezik .
A WireGuardnak pedig nincs ilyen.
Ez pedig azt jelenti, hogy a WireGuard valamikor meg fog törni, mert az egyik kriptográfiai primitív meggyengül vagy teljesen kompromittálódik. A műszaki dokumentáció szerzője ezt írja:
Érdemes megjegyezni, hogy a WireGuard kriptográfiailag véleményes. Szándékosan hiányzik a titkosítások és a protokollok rugalmassága. Ha komoly lyukakat találnak az alapul szolgáló primitívekben, akkor az összes végpontot frissíteni kell. Amint az az SLL/TLS sebezhetőségeinek folyamatos folyamából látható, a titkosítás rugalmassága mostanra rendkívül megnőtt.
Az utolsó mondat teljesen helyes.
Ha konszenzusra jutunk a használandó titkosítást illetően, olyan protokollok jönnek létre, mint az IKE és a TLS több összetett. Túl bonyolult? Igen, a sérülékenységek meglehetősen gyakoriak a TLS/SSL-ben, és nincs alternatíva.
A valódi problémák figyelmen kívül hagyásáról
Képzelje el, hogy van egy VPN-kiszolgálója 200 harci klienssel valahol a világon. Ez egy meglehetősen szokásos használati eset. Ha módosítania kell a titkosítást, a frissítést el kell küldenie a WireGuard összes példányára ezeken a laptopokon, okostelefonokon stb. Egyidejűleg szállít. Szó szerint lehetetlen. Az erre törekvő adminisztrátoroknak hónapokig tartanak a szükséges konfigurációk telepítése, egy közepes méretű cégnek pedig szó szerint évekbe fog telni egy ilyen esemény lebonyolítása.
Az IPsec és az OpenVPN titkosítási egyeztetési funkciót kínál. Ezért egy ideig, ami után bekapcsolja az új titkosítást, a régi is működni fog. Ez lehetővé teszi a jelenlegi ügyfelek számára, hogy frissítsenek az új verzióra. A frissítés bevezetése után egyszerűen kikapcsolja a sebezhető titkosítást. És ez az! Kész! Ön gyönyörű! Az ügyfelek észre sem veszik.
Ez valójában nagyon gyakori eset nagy telepítéseknél, és még az OpenVPN-nek is vannak nehézségei ezzel kapcsolatban. A visszamenőleges kompatibilitás fontos, és bár gyengébb titkosítást használsz, sokak számára ez nem ok a vállalkozás bezárására. Mert több száz ügyfél munkáját fogja megbénítani a munkájuk képtelensége miatt.
A WireGuard csapata leegyszerűsítette protokollját, de teljesen használhatatlanná tette azokat az embereket, akiknek nincs állandó ellenőrzésük mindkét társuk felett az alagútjukban. Tapasztalataim szerint ez a leggyakoribb forgatókönyv.
Kriptográfia!
De mi ez az érdekes új titkosítás, amelyet a WireGuard használ?
A WireGuard a Curve25519-et használja a kulcscseréhez, a ChaCha20-at a titkosításhoz és a Poly1305-öt az adatok hitelesítéséhez. Működik a SipHash-sel is a hash kulcsokhoz és a BLAKE2-vel a kivonatoláshoz.
A ChaCha20-Poly1305 szabványosítva van az IPsec és az OpenVPN számára (TLS felett).
Nyilvánvaló, hogy Daniel Bernstein fejlesztését nagyon gyakran használják. A BLAKE2 a BLAKE utódja, egy SHA-3 döntős, amely az SHA-2-vel való hasonlósága miatt nem nyert. Ha az SHA-2 megszakadna, jó eséllyel a BLAKE is veszélybe kerülne.
Az IPsecnek és az OpenVPN-nek a kialakításuk miatt nincs szüksége SipHash-re. Tehát az egyetlen dolog, ami jelenleg nem használható velük, az a BLAKE2, és ez csak addig van, amíg nem szabványosítják. Ez nem nagy hátrány, mert a VPN-ek HMAC-t használnak az integritás létrehozására, ami még az MD5-tel együtt is erős megoldásnak számít.
Tehát arra a következtetésre jutottam, hogy majdnem ugyanazt a kriptográfiai eszközkészletet használják minden VPN-ben. Ezért a WireGuard sem biztonságosabb, sem kevésbé biztonságos, mint bármely más jelenlegi termék, ami a titkosítást vagy a továbbított adatok integritását illeti.
De még ez sem a legfontosabb, amire a projekt hivatalos dokumentációja szerint érdemes odafigyelni. Végül is a sebesség a lényeg.
A WireGuard gyorsabb, mint a többi VPN-megoldás?
Röviden: nem, nem gyorsabb.
A ChaCha20 egy adatfolyam-rejtjel, amelyet könnyebben megvalósítható szoftverben. Egyszerre egy bitet titkosít. Az olyan blokkprotokollok, mint az AES, egyszerre 128 bitre titkosítanak egy blokkot. Sokkal több tranzisztor szükséges a hardvertámogatás megvalósításához, ezért a nagyobb processzorokhoz AES-NI tartozik, egy utasításkészlet-bővítmény, amely elvégzi a titkosítási folyamat egyes feladatait a gyorsítás érdekében.
Várható volt, hogy az AES-NI soha nem fog bekerülni az okostelefonokba [de sikerült – kb. per.]. Ehhez a ChaCha20-at könnyű, akkumulátorkímélő alternatívaként fejlesztették ki. Ezért újdonság lehet számodra, hogy minden ma megvásárolható okostelefon rendelkezik valamilyen AES-gyorsítással, és gyorsabban és alacsonyabb fogyasztás mellett fut ezzel a titkosítással, mint a ChaCha20-al.
Nyilvánvaló, hogy szinte minden asztali/szerver processzor, amelyet az elmúlt néhány évben vásároltak, rendelkezik AES-NI-vel.
Ezért azt várom, hogy az AES minden esetben felülmúlja a ChaCha20-at. A WireGuard hivatalos dokumentációja megemlíti, hogy az AVX512-vel a ChaCha20-Poly1305 felülmúlja az AES-NI-t, de ez az utasításkészlet-kiterjesztés csak nagyobb CPU-kon lesz elérhető, ami megint nem segít a kisebb és mobilabb hardvereknél, amelyek AES-sel mindig gyorsabbak lesznek. - N.I.
Nem vagyok benne biztos, hogy ezt előre lehetett látni a WireGuard fejlesztése során, de ma már az a tény, hogy önmagában a titkosításhoz van szegezve, már olyan hátrány, ami nem nagyon befolyásolja a működését.
Az IPsec lehetővé teszi, hogy szabadon kiválaszthassa, melyik titkosítás a legjobb az Ön esetéhez. És persze erre akkor van szükség, ha például 10 vagy több gigabájt adatot szeretne átvinni VPN-kapcsolaton keresztül.
Integrációs problémák a Linuxban
Bár a WireGuard egy modern titkosítási protokollt választott, ez már sok problémát okoz. Így ahelyett, hogy a kernel által támogatott elemeket használnánk, a WireGuard integrációja évekig késik, mert hiányoznak ezek a primitívek a Linuxban.
Nem vagyok teljesen biztos benne, hogy mi a helyzet más operációs rendszereken, de valószínűleg nem sokban különbözik a Linuxtól.
Hogy néz ki a valóság?
Sajnos minden alkalommal, amikor egy ügyfél arra kér, hogy állítsak be egy VPN-kapcsolatot, azzal a problémával találkozom, hogy elavult hitelesítő adatokat és titkosítást használnak. A 3DES az MD5-tel együtt még mindig általános gyakorlat, csakúgy, mint az AES-256 és az SHA1. És bár ez utóbbi valamivel jobb, ezt nem érdemes 2020-ban használni.
Kulcscseréhez mindig RSA-t használnak - egy lassú, de meglehetősen biztonságos eszközt.
Ügyfeleim kapcsolatban állnak a vámhatóságokkal és más kormányzati szervezetekkel és intézményekkel, valamint olyan nagyvállalatokkal, amelyek nevét világszerte ismerik. Mindegyikük egy évtizedekkel ezelőtt létrehozott kérőűrlapot használ, és az SHA-512 használatának lehetőségét egyszerűen soha nem adták hozzá. Nem mondhatom, hogy ez valahogy egyértelműen befolyásolja a technológiai fejlődést, de nyilván lassítja a vállalati folyamatokat.
Fáj ezt látni, mert az IPsec 2005 óta támogatja az elliptikus görbéket. A Curve25519 is újabb és használható. Az AES-nek is vannak alternatívái, például a Camellia és a ChaCha20, de nyilvánvalóan nem mindegyiket támogatják olyan nagy gyártók, mint a Cisco és mások.
És az emberek kihasználják. Sok Cisco készlet létezik, sok olyan készlet létezik, amelyeket a Ciscoval való együttműködésre terveztek. Ebben a szegmensben piacvezetők, és nem nagyon érdeklődnek semmiféle innováció iránt.
Igen, a helyzet [a vállalati szegmensben] szörnyű, de a WireGuard miatt nem fogunk változást látni. A gyártók valószínűleg soha nem látnak teljesítményproblémákat a már használt szerszámokkal és titkosítással, nem fognak problémát látni az IKEv2-vel, ezért nem keresnek alternatívákat.
Általában véve gondolt már arra, hogy elhagyja a Ciscót?
Benchmarkok
És most térjünk át a WireGuard dokumentációjában található referenciaértékekre. Bár ez a [dokumentáció] nem tudományos cikk, mégis azt vártam a fejlesztőktől, hogy tudományosabb megközelítést alkalmazzanak, vagy egy tudományos megközelítést használjanak referenciaként. Minden referenciaérték haszontalan, ha nem reprodukálható, és még haszontalanabb, ha laboratóriumban szerzik be.
A WireGuard linuxos buildjében a GSO – Általános szegmentációs tehermentesítés előnyeit használja ki. Neki köszönhetően az ügyfél egy hatalmas, 64 kilobájtos csomagot hoz létre, és egy mozdulattal titkosítja / visszafejti. Így a kriptográfiai műveletek meghívásának és végrehajtásának költsége csökken. Ha maximalizálni szeretné VPN-kapcsolatának átviteli sebességét, ez egy jó ötlet.
De mint általában, a valóság nem ilyen egyszerű. Egy ilyen nagy csomag hálózati adapterre küldéséhez sok kisebb csomagra kell vágni. A normál küldési méret 1500 bájt. Vagyis 64 kilobájtos óriásunk 45 csomagra lesz felosztva (1240 bájt információ és 20 bájt IP-fejléc). Aztán egy ideig teljesen blokkolják a hálózati adapter munkáját, mert együtt és egyszerre kell elküldeni. Ennek eredményeként ez prioritásugráshoz vezet, és az olyan csomagok, mint például a VoIP, sorba kerülnek.
Így a WireGuard által oly merészen állított nagy áteresztőképességet más alkalmazások hálózatba kapcsolásának lelassítása árán érik el. A WireGuard csapata pedig már ez az én következtetésem.
De menjünk tovább.
A műszaki dokumentációban szereplő benchmarkok szerint a kapcsolat 1011 Mbps átviteli sebességet mutat.
Hatásos.
Ez különösen annak köszönhető, hogy egyetlen Gigabit Ethernet kapcsolat maximális elméleti átviteli sebessége 966 Mbps 1500 bájt csomagméret mínusz 20 bájt az IP fejléc, 8 bájt az UDP fejléc és 16 bájt a fejléc esetében. maga a WireGuard. Van még egy IP-fejléc a beágyazott csomagban és egy másik a TCP-ben 20 bájtig. Szóval honnan jött ez a plusz sávszélesség?
Hatalmas keretekkel és a GSO előnyeivel, amelyekről fentebb beszéltünk, az elméleti maximum 9000 bájtos keretméret esetén 1014 Mbps lenne. Általában az ilyen áteresztőképesség a valóságban elérhetetlen, mert nagy nehézségekkel jár. Így csak azt tudom feltételezni, hogy a tesztet még kövérebb, 64 kilobájtos túlméretezett keretek felhasználásával végezték el, 1023 Mbps elméleti maximummal, amit csak néhány hálózati adapter támogat. De ez valós körülmények között abszolút nem alkalmazható, vagy csak két közvetlenül összefüggő állomás között használható, kizárólag a próbapadon belül.
Ám mivel a VPN-alagút két gazdagép között továbbítódik olyan internetkapcsolat segítségével, amely egyáltalán nem támogatja a jumbo frame-eket, a padon elért eredményt nem lehet viszonyítási alapnak tekinteni. Ez egyszerűen egy irreális laboratóriumi eredmény, amely lehetetlen és nem alkalmazható valós harci körülmények között.
Még az adatközpontban ülve sem tudtam 9000 bájtnál nagyobb képkockákat átvinni.
A való életben való alkalmazhatóság kritériuma abszolút sérül, és szerintem az elvégzett "mérés" szerzője nyilvánvaló okokból súlyosan lejáratta magát.
Az utolsó reménysugár
A WireGuard weboldala sokat beszél a konténerekről, és kiderül, hogy valójában mire is szánják.
Egyszerű és gyors VPN, amely nem igényel konfigurálást, és olyan hatalmas hangszerelési eszközökkel telepíthető és konfigurálható, mint az Amazon felhőjében. Pontosabban, az Amazon a legújabb hardverfunkciókat használja, amelyeket korábban említettem, például az AVX512-t. Ez a munka felgyorsítása érdekében történik, és nem kötődik x86-hoz vagy más architektúrához.
Optimalizálják az átviteli sebességet és a 9000 bájtnál nagyobb csomagokat – ezek hatalmas beágyazott keretek lesznek a konténerek egymás közötti kommunikációjához, vagy biztonsági mentési műveletekhez, pillanatképek készítéséhez vagy ugyanezen konténerek telepítéséhez. Még a dinamikus IP-címek sem befolyásolják semmilyen módon a WireGuard működését az általam leírt forgatókönyv esetén.
Jól játszott. Zseniális megvalósítás és nagyon vékony, szinte referencia protokoll.
De egyszerűen nem illik bele egy olyan adatközponton kívüli világba, amelyet teljesen Ön irányít. Ha vállalja a kockázatot, és elkezdi használni a WireGuard-ot, állandó kompromisszumokat kell kötnie a titkosítási protokoll kialakítása és megvalósítása terén.
Teljesítmény
Könnyű arra a következtetésre jutnom, hogy a WireGuard még nincs készen.
Könnyű és gyors megoldásként készült számos meglévő megoldással kapcsolatos probléma megoldására. Sajnos ezekért a megoldásokért sok olyan funkciót feláldozott, amelyek a legtöbb felhasználó számára relevánsak lesznek. Ezért nem helyettesítheti az IPsec-et vagy az OpenVPN-t.
Ahhoz, hogy a WireGuard versenyképessé váljon, hozzá kell adnia legalább egy IP-cím beállítást, valamint egy útválasztási és DNS-konfigurációt. Nyilvánvalóan erre valók a titkosított csatornák.
A biztonság a legfontosabb prioritásom, és jelenleg nincs okom azt hinni, hogy az IKE vagy a TLS valamilyen módon veszélybe került vagy meghibásodott. A modern titkosítást mindkettő támogatja, és több évtizedes működés bizonyítja. Attól, hogy valami újabb, még nem biztos, hogy jobb.
Az interoperabilitás rendkívül fontos, ha olyan harmadik felekkel kommunikál, amelyek állomásait nem Ön irányítja. Az IPsec a de facto szabvány, és szinte mindenhol támogatott. És dolgozik. És bárhogyan is néz ki, elméletileg a WireGuard a jövőben nem biztos, hogy kompatibilis lesz saját különböző verzióival sem.
Bármilyen kriptográfiai védelem előbb-utóbb megszakad, és ennek megfelelően ki kell cserélni vagy frissíteni kell.
Mindezen tények tagadása, és vakon a WireGuard használata az iPhone és az otthoni munkaállomás összekapcsolására csak egy mesterkurzus a homokba dugáshoz.
Forrás: will.com