Lately WireGuard trek baie aandag, trouens, dit is 'n nuwe "ster" onder SkynprivaatnetwerkMaar is dit so goed soos dit lyk? Ek wil graag 'n paar waarnemings bespreek en die implementering hersien. WireGuard, om te verduidelik waarom dit nie 'n oplossing is wat IPsec sal vervang nie, of OpenVPN.
In hierdie artikel wil ek graag 'n paar mites ontmasker [rondom WireGuardJa, dis 'n lang leesstuk, so as jy nog nie vir jou 'n koppie tee of koffie gemaak het nie, is dit nou die tyd. Ek wil ook vir Peter bedank vir die proeflees van my chaotiese gedagtes.
Dit is nie my doel om die ontwikkelaars in diskrediet te bring nie. WireGuard, devalueer hul pogings of idees. Hul produk werk, maar ek glo persoonlik dat dit aangebied word as iets heeltemal anders as wat dit werklik is - aangebied as 'n plaasvervanger vir IPsec en OpenVPN, wat eintlik nou eenvoudig nie bestaan nie.
Terloops, ek wil byvoeg dat die verantwoordelikheid vir sodanige posisionering WireGuard word gedra deur die media wat daaroor berig het, en nie die projek self of die skeppers daarvan nie.
Onlangs oor die onderwerp van die kern Linux Daar was nie veel goeie nuus nie. Ons is vertel van monsteragtige verwerkerkwesbaarhede wat deur sagteware gemitigeer is, en Linus Torvalds se weergawe daarvan was te kru en vervelig, in die utilitaristiese taal van 'n ontwikkelaar. Die skeduleerder of die vlak-0-netwerkstapel is ook nie juis duidelike onderwerpe vir glanstydskrifte nie. En toe kom daar... WireGuard.
Op papier klink dit alles wonderlik: 'n opwindende nuwe tegnologie.
Maar kom ons kyk bietjie nader daarna.
Tegniese dokumentasie WireGuard
Hierdie artikel is gebaseer op amptelike dokumentasie WireGuard, geskryf deur Jason Donenfeld, waar hy die konsep, doel en tegniese implementering verduidelik [WireGuard] in die kern Linux.
Die eerste sin lui:
WireGuard […] beoog om beide IPsec in die meeste gebruiksgevalle te vervang, sowel as ander gewilde gebruikersruimte- en/of TLS-gebaseerde oplossings soos OpenVPN, terwyl dit veiliger, meer produktief en makliker is om te gebruik [gereedskap].
Natuurlik, die grootste voordeel van alle nuwe tegnologie is hul eenvoud [in vergelyking met voorgangers]. Maar 'n VPN moet ook wees doeltreffend en veilig.
So, wat is volgende?
As jy sê dat dit nie is wat jy nodig het nie [van 'n VPN], dan kan jy die lees hier beëindig. Ek sal egter daarop let dat sulke take vir enige ander tonneltegnologie gestel word.
Die interessantste van bogenoemde aanhaling lê in die woorde "in die meeste gevalle", wat natuurlik deur die pers geïgnoreer is. En so, ons is waar ons beland het weens die chaos wat deur hierdie nalatigheid geskep is – in hierdie artikel.
Sal dit gebeur? WireGuard vervanging van my [IPsec] webwerf-tot-werf VPN?
Nee. Daar is eenvoudig geen kans dat groot verskaffers soos Cisco, Juniper en ander dit vir hul produkte sal bekom nie. WireGuardHulle "spring nie op verbygaande treine" tensy daar 'n dringende behoefte is nie. Later sal ek sommige van die redes bespreek waarom hulle waarskynlik nie hul produkte aan boord sal kan installeer nie. WireGuard, selfs al wou hulle.
Sal dit oorleef? WireGuard my RoadWarrior van 'n skootrekenaar na 'n datasentrum?
Nee. Tans in WireGuard 'n Groot aantal belangrike kenmerke ontbreek om so iets moontlik te maak. Dit kan byvoorbeeld nie dinamiese IP-adresse aan die tonnelbedienerkant gebruik nie, en dit alleen breek die hele gebruiksgeval vir hierdie produk.
IPFire word dikwels gebruik vir goedkoop internetverbindings, soos DSL- of kabelverbindings. Dit maak sin vir klein of medium ondernemings wat nie vinnige vesel nodig het nie. [Nota van die vertaler: moenie vergeet dat Rusland en sommige GOS-lande wat kommunikasie betref, ver voor Europa en die Verenigde State is nie, want ons het heelwat later begin bou aan ons netwerke en met die koms van Ethernet en optieseveselnetwerke as 'n standaard was dit vir ons makliker om te herbou. In dieselfde lande van die EU of die VSA is xDSL-breëbandtoegang teen 'n spoed van 3-5 Mbps steeds die algemene norm, en 'n optieseveselverbinding kos 'n bietjie onrealistiese geld volgens ons standaarde. Daarom praat die skrywer van die artikel van DSL of kabelverbinding as die norm, en nie antieke tye nie.] DSL, kabel, LTE (en ander draadlose toegangsmetodes) het egter dinamiese IP-adresse. Natuurlik verander hulle soms nie gereeld nie, maar hulle verander wel.
Daar is 'n subprojek genaamd "wg-dinamiese", wat 'n gebruikersruimte-demoon byvoeg om hierdie tekortkoming te oorkom. 'n Groot probleem met die gebruikersscenario wat hierbo beskryf word, is die verergering van dinamiese IPv6-adressering.
Uit die oogpunt van die verspreider lyk dit alles ook nie baie goed nie. Een van die ontwerpdoelwitte was om die protokol eenvoudig en skoon te hou.
Ongelukkig het dit alles eintlik te eenvoudig en primitief geword, sodat ons addisionele sagteware moet gebruik sodat hierdie hele ontwerp in werklike gebruik lewensvatbaar kan wees.
WireGuard Is dit so maklik om te gebruik?
Nog nie. Ek sê dit nie. WireGuard Dit sal nooit 'n goeie alternatief wees vir tonnelwerk tussen twee punte nie, maar vir nou is dit net 'n alfa-weergawe van die produk wat dit veronderstel is om te word.
Maar wat doen hy dan eintlik? Is IPsec regtig soveel moeiliker om te onderhou?
Duidelik nie. Die IPsec-verskaffer het hieraan gedink en stuur hul produk saam met 'n koppelvlak, soos met IPFire.
Om 'n VPN-tonnel oor IPsec op te stel, sal jy vyf stelle data nodig hê wat jy in die konfigurasie sal moet invoer: jou eie openbare IP-adres, die publieke IP-adres van die ontvangende party, die subnette waardeur jy publiek wil maak hierdie VPN-verbinding en vooraf-gedeelde sleutel. Die VPN word dus binne minute opgestel en is versoenbaar met enige verskaffer.
Ongelukkig is daar 'n paar uitsonderings op hierdie storie. Enigiemand wat probeer het om oor IPsec na 'n OpenBSD-masjien te tonnel, weet waarvan ek praat. Daar is nog 'n paar pynlike voorbeelde, maar in werklikheid is daar baie, baie meer goeie praktyke vir die gebruik van IPsec.
Oor protokol kompleksiteit
Die eindgebruiker hoef nie bekommerd te wees oor die kompleksiteit van die protokol nie.
As ons in 'n wêreld geleef het waar dit 'n werklike bekommernis van die gebruiker was, dan sou ons ontslae geraak het van SIP, H.323, FTP en ander protokolle wat meer as tien jaar gelede geskep is wat nie goed met NAT werk nie.
Daar is redes waarom IPsec meer kompleks is as WireGuardDit doen baie meer. Dit verifieer byvoorbeeld gebruikers met behulp van aanmelding/wagwoord of 'n SIM-kaart met EAP. Dit het 'n uitgebreide vermoë om nuwes by te voeg. kriptografiese primitiewe.
En by WireGuard dit bestaan nie.
En dit beteken dat WireGuard Op 'n stadium sal dit misluk omdat een van die kriptografiese primitiewe elemente verswak of heeltemal gekompromitteer sal word. Die outeur van die tegniese dokumentasie stel dit so:
Daar moet op gelet word dat WireGuard Kriptografies oorvol selfversekerd. Dit het doelbewus 'n gebrek aan buigsaamheid in sy kodes en protokolle. Indien ernstige gate in die onderliggende primitiewe elemente ontdek word, sal alle eindpunte opgedateer moet word. Soos die voortdurende vloed van SSL/TLS-kwesbaarhede demonstreer, het enkripsiebuigsaamheid nou dramaties toegeneem.
Die laaste sin is absoluut korrek.
Om konsensus te bereik oor watter enkripsie om te gebruik, maak protokolle soos IKE en TLS meer kompleks. Te ingewikkeld? Ja, kwesbaarhede is redelik algemeen in TLS/SSL, en daar is geen alternatief daarvoor nie.
Om werklike probleme te ignoreer
Stel jou voor jy het 'n VPN-bediener met 200 produksiekliënte, êrens regoor die wêreld. Dit is 'n redelik standaard gebruiksgeval. As jy die enkripsie moet verander, moet jy die opdatering na alle kopieë stoot. WireGuard op hierdie skootrekenaars, slimfone, ensovoorts. Terselfdertyd lewer. Dit is letterlik onmoontlik. Administrateurs wat dit probeer doen, sal maande neem om die vereiste konfigurasies te ontplooi, en dit sal letterlik 'n mediumgrootte maatskappy jare neem om so 'n gebeurtenis af te handel.
IPsec en OpenVPN bied 'n syferonderhandelingsfunksie. So, vir 'n kort tydjie, nadat jy die nuwe enkripsie geaktiveer het, sal die oue ook werk. Dit laat huidige kliënte toe om op te gradeer na die nuwe weergawe. Sodra die opdatering uitgerol is, deaktiveer eenvoudig die kwesbare enkripsie. En dis dit! Klaar! Jy is wonderlik! En jou kliënte sal dit nie eers agterkom nie.
Dit is eintlik 'n baie algemene geval vir groot ontplooiings, en selfs OpenVPN Dit ondervind probleme hiermee. Agterwaartse versoenbaarheid is belangrik, en al gebruik jy swakker enkripsie, is dit vir baie nie 'n rede om hul besigheid te sluit nie. Want dit sou honderde kliënte verlam as gevolg van hul onvermoë om hul werk te doen.
Span WireGuard het sy protokol eenvoudiger gemaak, maar heeltemal ongeskik vir mense wat nie konstante beheer oor beide eweknieë van hul tonnel het nie. In my ervaring is dit die mees algemene scenario.
Kriptografie!
Maar wat is hierdie interessante nuwe enkripsie wat gebruik word? WireGuard?
WireGuard Dit gebruik Curve25519 vir sleuteluitruiling, ChaCha20 vir enkripsie en Poly1305 vir data-verifikasie. Dit ondersteun ook SipHash vir sleutel-hashes en BLAKE2 vir hashing.
ChaCha20-Poly1305 is gestandaardiseer vir IPsec en OpenVPN (via TLS).
Dit is duidelik dat die ontwikkeling van Daniel Bernstein baie gereeld gebruik word. BLAKE2 is die opvolger van BLAKE, 'n SHA-3-finalis wat nie gewen het nie weens sy ooreenkoms met SHA-2. As SHA-2 gebreek sou word, was daar 'n goeie kans dat BLAKE ook gekompromitteer sou word.
IPsec en OpenVPN SipHash word nie vereis as gevolg van sy ontwerp nie. Daarom is die enigste ding wat tans nie saam met hulle gebruik kan word nie, BLAKE2, en slegs totdat dit gestandaardiseer is. Dit is nie 'n groot nadeel nie, aangesien VPN's HMAC vir integriteit gebruik, wat as 'n sterk oplossing beskou word selfs wanneer dit met MD5 gepaar word.
So het ek tot die gevolgtrekking gekom dat alle VPN'e amper dieselfde stel kriptografiese gereedskap gebruik. Daarom WireGuard nie meer of minder veilig as enige ander huidige produk wat enkripsie of integriteit van oorgedraagde data betref nie.
Maar selfs dit is nie die belangrikste ding wat die moeite werd is om aandag te gee volgens die amptelike dokumentasie van die projek nie. Die belangrikste ding is immers spoed.
WireGuard vinniger as ander VPN-oplossings?
Kortom: nee, nie vinniger nie.
ChaCha20 is 'n stroomsyfer wat makliker is om in sagteware te implementeer. Dit enkripteer een bietjie op 'n slag. Blokprotokolle soos AES enkripteer 'n blok 128 bisse op 'n slag. Baie meer transistors word benodig om hardeware-ondersteuning te implementeer, so groter verwerkers kom met AES-NI, 'n instruksiestel-uitbreiding wat sommige van die take van die enkripsieproses uitvoer om dit te bespoedig.
Daar is verwag dat AES-NI nooit in slimfone sou kom nie [maar dit het - ongeveer. per.]. Hiervoor is die ChaCha20 ontwikkel as 'n liggewig, batterybesparende alternatief. Daarom kan dit vir jou as nuus kom dat elke slimfoon wat jy vandag kan koop een of ander AES-versnelling het en vinniger en met laer kragverbruik met hierdie enkripsie werk as met ChaCha20.
Natuurlik het omtrent elke rekenaar-/bedienerverwerker wat die afgelope paar jaar gekoop is, AES-NI.
Daarom verwag ek dat AES ChaCha20 in elke enkele scenario sal oortref. Die amptelike dokumentasie WireGuard Daar word genoem dat ChaCha20-Poly1305 danksy AVX512 beter sal presteer as AES-NI, maar hierdie instruksiestel-uitbreiding sal slegs op groter verwerkers beskikbaar wees, wat weer nie sal help met kleiner en mobiele hardeware nie, wat altyd vinniger sal wees met AES-NI.
Ek is nie seker of dit tydens ontwikkeling voorsien kon word nie. WireGuard, maar vandag is die feit dat dit aan een vasgespyker is enkripsie reeds 'n nadeel wat dalk nie 'n baie goeie uitwerking op die werking daarvan het nie.
Met IPsec kan u vrylik kies watter enkripsie die beste vir u geval is. En dit is natuurlik nodig as u byvoorbeeld 10 of meer gigagrepe data deur 'n VPN-verbinding wil oordra.
Probleme van integrasie in Linux
Alhoewel WireGuard Ek het 'n moderne enkripsieprotokol gekies, wat reeds baie probleme veroorsaak. En so, in plaas daarvan om te gebruik wat die kern outomaties ondersteun, die integrasie WireGuard is jare lank uitgestel weens die gebrek aan hierdie primitiewe elemente in Linux.
Ek is nie heeltemal seker wat die situasie op ander bedryfstelsels is nie, maar dit is waarskynlik nie veel anders as Linux.
Hoe lyk die werklikheid?
Ongelukkig, elke keer as 'n kliënt my vra om 'n VPN-verbinding vir hulle op te stel, kry ek die probleem dat hulle verouderde geloofsbriewe en enkripsie gebruik. 3DES in samewerking met MD5 is steeds algemene praktyk, net soos AES-256 en SHA1. En hoewel laasgenoemde effens beter is, is dit nie iets wat in 2020 gebruik behoort te word nie.
Vir sleutelruil altyd RSA word gebruik - 'n stadige maar redelik veilige hulpmiddel.
My kliënte word geassosieer met doeane-owerhede en ander regeringsorganisasies en -instellings, asook met groot korporasies wie se name oor die hele wêreld bekend is. Hulle gebruik almal 'n versoekvorm wat dekades gelede geskep is, en die vermoë om SHA-512 te gebruik is eenvoudig nooit bygevoeg nie. Ek kan nie sê dat dit op een of ander manier duidelik tegnologiese vooruitgang beïnvloed nie, maar natuurlik vertraag dit die korporatiewe proses.
Dit maak my seer om dit te sien, want IPsec ondersteun al sedert 2005 elliptiese kurwes. Curve25519 is ook nuwer en beskikbaar vir gebruik. Daar is ook alternatiewe vir AES soos Camellia en ChaCha20, maar natuurlik word nie almal deur groot verskaffers soos Cisco en ander ondersteun nie.
En mense trek voordeel daaruit. Daar is baie Cisco-stelle, daar is baie kits wat ontwerp is om met Cisco te werk. Hulle is markleiers in hierdie segment en stel nie baie belang in enige soort innovasie nie.
Ja, die situasie [in die korporatiewe segment] is verskriklik, maar ons sal geen veranderinge sien nie as gevolg van die WireGuardVervaardigers sal waarskynlik nooit enige prestasieprobleme met die gereedskap en enkripsie wat hulle reeds gebruik, ontdek nie, en hulle sal ook geen probleme met IKEv2 sien nie – en daarom soek hulle nie na alternatiewe nie.
In die algemeen, het jy al ooit daaraan gedink om Cisco te laat vaar?
Maatstawwe
Kom ons gaan nou oor na die maatstawwe uit die dokumentasie. WireGuardAlhoewel hierdie [dokumentasie] nie 'n wetenskaplike artikel is nie, het ek steeds verwag dat die ontwikkelaars 'n meer wetenskaplike benadering sou volg, of 'n wetenskaplike benadering as 'n maatstaf sou gebruik. Maatstawwe is nutteloos as hulle nie gereproduseer kan word nie, en hulle is selfs meer nutteloos wanneer hulle in 'n laboratoriumomgewing verkry word.
In samestelling WireGuard vir Linux Dit verkry 'n voordeel deur GSO (Generic Segmentation Offloading) te gebruik. Dit laat die kliënt toe om 'n enorme 64-kilogreep-pakket te skep en dit in 'n enkele deurgang te enkripteer/dekripteer. Dit verminder die koste van die uitvoering van die kriptografiese bewerkings en oproepe. As jy jou VPN-verbinding se deurset wil maksimeer, is dit 'n goeie idee.
Maar soos gewoonlik is die werklikheid nie so eenvoudig nie. Om so 'n groot pakkie na 'n netwerkadapter te stuur, vereis dat dit in baie kleiner pakkies gesny word. Die normale stuurgrootte is 1500 grepe. Dit wil sê, ons reus van 64 kilogrepe sal verdeel word in 45 pakkies (1240 grepe inligting en 20 grepe van die IP-kopskrif). Dan sal hulle vir 'n rukkie die werk van die netwerkadapter heeltemal blokkeer, want hulle moet saam en dadelik gestuur word. As gevolg hiervan sal dit lei tot 'n prioriteitsprong, en pakkies soos VoIP, byvoorbeeld, sal in 'n tou staan.
Dus, die hoë deurset wat so vrymoediglik beweer word WireGuard, word bereik deur die netwerkprestasie van ander toepassings te vertraag. En die span WireGuard reeds bevestig dit is my gevolgtrekking.
Maar kom ons gaan aan.
Volgens die maatstawwe in die tegniese dokumentasie toon die verbinding 'n deurset van 1011 Mbps.
Indrukwekkend.
Dit is veral indrukwekkend omdat die maksimum teoretiese deurset van 'n enkele Gigabit Ethernet-verbinding 966 Mbps is met 'n pakkiegrootte van 1500 grepe minus 20 grepe vir die IP-koptekst, 8 grepe vir die UDP-koptekst en 16 grepe vir die koptekst self. WireGuardDaar is nog 'n IP-koptekst in die ingekapselde pakket en nog een in TCP, 20 grepe lank. So waar kom hierdie ekstra bandwydte vandaan?
Met groot rame en die voordele van GSO waaroor ons hierbo gepraat het, sou die teoretiese maksimum vir 'n raamgrootte van 9000 grepe 1014 Mbps wees. Gewoonlik is sulke deurset in werklikheid onbereikbaar, omdat dit met groot probleme gepaard gaan. Ek kan dus net aanneem dat die toets uitgevoer is met nog vetter oorgrootte rame van 64 kilogrepe met 'n teoretiese maksimum van 1023 Mbps, wat slegs deur sommige netwerkadapters ondersteun word. Maar dit is absoluut ontoepasbaar in werklike toestande, of kan slegs tussen twee direk gekoppelde stasies gebruik word, uitsluitlik binne die toetsbank.
Maar aangesien die VPN-tonnel tussen twee gashere aangestuur word deur 'n internetverbinding te gebruik wat glad nie jumbo-rame ondersteun nie, kan die resultaat wat op die bank behaal word, nie as 'n maatstaf geneem word nie. Dit is bloot 'n onrealistiese laboratoriumprestasie wat onmoontlik en ontoepasbaar is in werklike gevegstoestande.
Selfs as ek in die datasentrum gesit het, kon ek nie rame groter as 9000 grepe oordra nie.
Die kriterium van toepaslikheid in die werklike lewe word absoluut geskend en, soos ek dink, het die skrywer van die "meting" wat uitgevoer is, homself ernstig gediskrediteer om ooglopende redes.
Laaste sprankie hoop
Die webwerf WireGuard Daar word baie gepraat oor houers en dit word duidelik waarvoor hulle eintlik bedoel is.
'N Eenvoudige en vinnige VPN wat geen konfigurasie vereis nie en kan ontplooi en gekonfigureer word met massiewe orkestrasie-instrumente soos Amazon in hul wolk het. Spesifiek, Amazon gebruik die nuutste hardeware-kenmerke wat ek vroeër genoem het, soos die AVX512. Dit word gedoen om die werk te bespoedig en nie aan x86 of enige ander argitektuur gekoppel te wees nie.
Hulle optimaliseer deurset en pakkiegroottes van meer as 9 000 grepe – dit lei tot enorme ingekapselde rame vir houerkommunikasie, rugsteunbedrywighede, momentopname-skepping of houerontplooiing. Selfs dinamiese IP-adresse sal nie die werkverrigting beïnvloed nie. WireGuard in die geval van die scenario wat ek beskryf het.
Goed gespeel. Briljante implementering en baie dun, amper verwysingsprotokol.
Maar dit is eenvoudig nie geskik vir die wêreld buite 'n datasentrum wat jy ten volle beheer nie. As jy die risiko neem en begin gebruik WireGuard, sal jy voortdurend kompromieë moet maak wanneer jy 'n enkripsieprotokol ontwerp en implementeer.
Output
Dit is nie moeilik vir my om tot die gevolgtrekking te kom dat WireGuard nog nie gereed nie.
Dit was bedoel as 'n liggewig en vinnige oplossing vir 'n aantal probleme met bestaande oplossings. Ongelukkig het dit baie funksies opgeoffer wat vir die meeste gebruikers relevant sou wees om hierdie oplossings te bereik. Daarom kan dit nie IPsec of ... vervang nie. OpenVPN.
Ten einde te WireGuard Om mededingend te word, moet dit ten minste IP-adreskonfigurasie, roetering en DNS-konfigurasie byvoeg. Dit is duidelik dat geënkripteerde kanale hiervoor nodig is.
Sekuriteit is my topprioriteit, en op die oomblik het ek geen rede om te glo dat IKE of TLS op een of ander manier gekompromitteer of gebreek is nie. Moderne enkripsie word in albei ondersteun, en dit is deur dekades se werking bewys. Net omdat iets nuwer is, beteken dit nie dat dit beter is nie.
Interoperabiliteit is van kardinale belang wanneer jy met derde partye kommunikeer wie se stasies jy nie beheer nie. IPsec is die de facto-standaard en word amper oral ondersteun. En dit werk. En hoe dit ook al lyk, in teorie, WireGuard in die toekoms mag dit selfs met verskillende weergawes van homself onversoenbaar wees.
Enige kriptografiese beskerming word vroeër of later verbreek en moet dienooreenkomstig vervang of bygewerk word.
Ontkenning van al hierdie feite en 'n blinde begeerte om te gebruik WireGuard om jou te verbind iPhone na 'n tuiswerkstasie is 'n meesterklas in om jou kop in die sand te steek.
Bron: will.com
