Mae WireGuard wedi bod yn ennill llawer o sylw yn ddiweddar, mewn gwirionedd dyma'r seren newydd ymhlith VPNs. Ond a yw cystal ag y mae'n ymddangos? Hoffwn drafod rhai arsylwadau ac adolygu gweithrediad WireGuard i egluro pam nad yw'n ateb i ddisodli IPsec neu OpenVPN.
Yn yr erthygl hon, hoffwn chwalu rhai o'r mythau [o amgylch WireGuard]. Bydd, bydd yn cymryd amser hir i ddarllen, felly os nad ydych wedi gwneud paned o de neu goffi i chi'ch hun, yna mae'n bryd ei wneud. Hoffwn hefyd ddiolch i Peter am gywiro fy meddyliau anhrefnus.
Nid wyf yn gosod y nod i mi fy hun o ddifrïo datblygwyr WireGuard, gan ddibrisio eu hymdrechion neu eu syniadau. Mae eu cynnyrch yn gweithio, ond yn bersonol credaf ei fod yn cael ei gyflwyno'n hollol wahanol i'r hyn ydyw mewn gwirionedd - fe'i cyflwynir yn lle IPsec ac OpenVPN, nad yw mewn gwirionedd yn bodoli nawr.
Fel nodyn, hoffwn ychwanegu mai'r cyfryngau a siaradodd amdano, ac nid y prosiect ei hun na'i grewyr, sy'n gyfrifol am leoli WireGuard o'r fath.
Ni fu llawer o newyddion da am y cnewyllyn Linux yn ddiweddar. Felly, dywedwyd wrthym am wendidau gwrthun y prosesydd, a gafodd eu lefelu gan feddalwedd, a siaradodd Linus Torvalds amdano yn rhy ddigywilydd a diflas, yn iaith iwtilitaraidd y datblygwr. Nid yw amserlennydd neu bentwr rhwydweithio lefel sero ychwaith yn bynciau clir iawn ar gyfer cylchgronau sgleiniog. A dyma WireGuard yn dod.
Ar bapur, mae'r cyfan yn swnio'n wych: technoleg newydd gyffrous.
Ond gadewch i ni edrych arno ychydig yn agosach.
Papur gwyn WireGuard
Mae'r erthygl hon yn seiliedig ar ysgrifennwyd gan Jason Donenfeld. Yno mae'n esbonio cysyniad, pwrpas a gweithrediad technegol [WireGuard] yn y cnewyllyn Linux.
Mae'r frawddeg gyntaf yn darllen:
Nod WireGuard […] yw disodli IPsec yn y rhan fwyaf o achosion defnydd a gofod defnyddwyr poblogaidd eraill a / neu atebion sy'n seiliedig ar TLS fel OpenVPN tra'n bod yn fwy diogel, perfformiwr ac yn haws [offeryn].
Wrth gwrs, prif fantais pob technoleg newydd yw eu symlrwydd [o'i gymharu â'r rhagflaenwyr]. Ond dylai VPN fod hefyd effeithlon a diogel.
Felly, beth sydd nesaf?
Os dywedwch nad dyma sydd ei angen arnoch chi [gan VPN], yna gallwch chi ddod â'r darlleniad i ben yma. Fodd bynnag, nodaf fod tasgau o’r fath yn cael eu gosod ar gyfer unrhyw dechnoleg twnelu arall.
Mae'r mwyaf diddorol o'r dyfyniad uchod yn gorwedd yn y geiriau "yn y rhan fwyaf o achosion", a anwybyddwyd, wrth gwrs, gan y wasg. Ac felly, dyma ni lle daethon ni i ben oherwydd yr anhrefn a grëwyd gan yr esgeulustod hwn - yn yr erthygl hon.
A fydd WireGuard yn disodli fy VPN safle-i-safle [IPsec]?
Nac ydw. Yn syml, nid oes unrhyw siawns y bydd gwerthwyr mawr fel Cisco, Juniper ac eraill yn prynu WireGuard ar gyfer eu cynhyrchion. Nid ydynt yn "neidio ar drenau sy'n mynd heibio" wrth symud oni bai bod angen mawr i wneud hynny. Yn ddiweddarach, af dros rai o'r rhesymau pam mae'n debyg na fyddant yn gallu cael eu cynhyrchion WireGuard ar fwrdd hyd yn oed os oeddent am wneud hynny.
A fydd WireGuard yn mynd â'm RoadWarrior o'm gliniadur i'r ganolfan ddata?
Nac ydw. Ar hyn o bryd, nid oes gan WireGuard nifer fawr o nodweddion pwysig ar waith er mwyn iddo allu gwneud rhywbeth fel hyn. Er enghraifft, ni all ddefnyddio cyfeiriadau IP deinamig ar ochr y gweinydd twnnel, ac mae hyn yn unig yn torri'r senario cyfan o ddefnydd o'r fath o'r cynnyrch.
Defnyddir IPFire yn aml ar gyfer cysylltiadau Rhyngrwyd rhad, fel cysylltiadau DSL neu gebl. Mae hyn yn gwneud synnwyr i fusnesau bach neu ganolig nad oes angen ffibr cyflym arnynt. [Nodyn gan y cyfieithydd: peidiwch ag anghofio, o ran cyfathrebu, bod Rwsia a rhai gwledydd CIS ymhell ar y blaen i Ewrop a'r Unol Daleithiau, oherwydd fe wnaethom ddechrau adeiladu ein rhwydweithiau yn ddiweddarach o lawer a chyda dyfodiad Ethernet a rhwydweithiau ffibr optig fel safonol, roedd yn haws i ni ailadeiladu. Yn yr un gwledydd yr UE neu UDA, mynediad band eang xDSL ar gyflymder o 3-5 Mbps yw’r norm cyffredinol o hyd, ac mae cysylltiad ffibr optig yn costio rhywfaint o arian afrealistig yn ôl ein safonau. Felly, mae awdur yr erthygl yn sôn am DSL neu gysylltiad cebl fel y norm, ac nid yr hen amser.] Fodd bynnag, mae gan DSL, cebl, LTE (a dulliau mynediad diwifr eraill) gyfeiriadau IP deinamig. Wrth gwrs, weithiau nid ydynt yn newid yn aml, ond maent yn newid.
Mae yna is-brosiect o'r enw , sy'n ychwanegu daemon userspace i oresgyn y diffyg hwn. Problem enfawr gyda'r senario defnyddiwr a ddisgrifir uchod yw gwaethygu cyfeiriadau IPv6 deinamig.
O safbwynt y dosbarthwr, nid yw hyn i gyd yn edrych yn dda iawn chwaith. Un o'r nodau dylunio oedd cadw'r protocol yn syml ac yn lân.
Yn anffodus, mae hyn i gyd mewn gwirionedd wedi dod yn rhy syml a chyntefig, felly mae'n rhaid i ni ddefnyddio meddalwedd ychwanegol er mwyn i'r dyluniad cyfan hwn fod yn ymarferol mewn defnydd go iawn.
A yw WireGuard mor hawdd i'w ddefnyddio?
Ddim eto. Dydw i ddim yn dweud na fydd WireGuard byth yn ddewis arall da ar gyfer twnelu rhwng dau bwynt, ond am y tro dim ond fersiwn alffa o'r cynnyrch y mae i fod i fod.
Ond wedyn beth mae'n ei wneud mewn gwirionedd? A yw IPsec yn llawer anoddach i'w gynnal mewn gwirionedd?
Yn amlwg ddim. Mae'r gwerthwr IPsec wedi meddwl am hyn ac yn cludo eu cynnyrch ynghyd â rhyngwyneb, fel gydag IPFire.
I sefydlu twnnel VPN dros IPsec, bydd angen pum set o ddata y bydd angen i chi eu nodi yn y ffurfweddiad: eich cyfeiriad IP cyhoeddus eich hun, cyfeiriad IP cyhoeddus y parti sy'n derbyn, yr is-rwydweithiau rydych chi am eu gwneud yn gyhoeddus drwyddynt. y cysylltiad VPN hwn a'r allwedd a rennir ymlaen llaw. Felly, mae'r VPN wedi'i sefydlu o fewn munudau ac mae'n gydnaws ag unrhyw werthwr.
Yn anffodus, mae yna ychydig o eithriadau i'r stori hon. Mae unrhyw un sydd wedi ceisio twnelu dros IPsec i beiriant OpenBSD yn gwybod am beth rwy'n siarad. Mae yna ychydig o enghreifftiau mwy poenus, ond mewn gwirionedd, mae yna lawer, llawer mwy o arferion da ar gyfer defnyddio IPsec.
Ynglŷn â chymhlethdod protocol
Nid oes rhaid i'r defnyddiwr terfynol boeni am gymhlethdod y protocol.
Pe baem yn byw mewn byd lle roedd hyn yn bryder gwirioneddol i'r defnyddiwr, yna byddem wedi cael gwared ar SIP, H.323, FTP a phrotocolau eraill a grëwyd fwy na deng mlynedd yn ôl nad ydynt yn gweithio'n dda gyda NAT ers talwm.
Mae yna resymau pam mae IPsec yn fwy cymhleth na WireGuard: mae'n gwneud llawer mwy o bethau. Er enghraifft, dilysu defnyddwyr gan ddefnyddio mewngofnodi / cyfrinair neu gerdyn SIM gydag EAP. Mae ganddo allu estynedig i ychwanegu newydd .
Ac nid oes gan WireGuard hynny.
Ac mae hyn yn golygu y bydd WireGuard yn torri ar ryw adeg, oherwydd bydd un o'r cyntefig cryptograffig yn gwanhau neu'n cael ei beryglu'n llwyr. Mae awdur y ddogfennaeth dechnegol yn dweud hyn:
Mae'n werth nodi bod WireGuard â barn cryptograffig. Mae'n fwriadol yn brin o hyblygrwydd seiffrau a phrotocolau. Os canfyddir tyllau difrifol mewn cyntefigau gwaelodol, bydd angen diweddaru pob pwynt terfyn. Fel y gallwch weld o'r llif parhaus o wendidau SLL / TLS, mae hyblygrwydd amgryptio bellach wedi cynyddu'n aruthrol.
Mae'r frawddeg olaf yn hollol gywir.
Mae dod i gonsensws ar ba amgryptio i'w ddefnyddio yn gwneud protocolau fel IKE a TLS mwy cymhleth. Rhy gymhleth? Ydy, mae gwendidau yn eithaf cyffredin yn TLS/SSL, ac nid oes dewis arall yn eu lle.
Ar anwybyddu problemau go iawn
Dychmygwch fod gennych weinydd VPN gyda 200 o gleientiaid ymladd rhywle ledled y byd. Mae hwn yn achos defnydd eithaf safonol. Os oes rhaid i chi newid yr amgryptio, mae angen i chi gyflwyno'r diweddariad i bob copi o WireGuard ar y gliniaduron hyn, ffonau smart, ac ati. Ar yr un pryd cyflwyno. Mae'n llythrennol amhosibl. Bydd gweinyddwyr sy'n ceisio gwneud hyn yn cymryd misoedd i ddefnyddio'r ffurfweddiadau gofynnol, a bydd yn llythrennol yn cymryd blynyddoedd cwmni canolig i ddileu digwyddiad o'r fath.
Mae IPsec ac OpenVPN yn cynnig nodwedd negodi seiffr. Felly, am beth amser ar ôl hynny rydych chi'n troi'r amgryptio newydd ymlaen, bydd yr hen un hefyd yn gweithio. Bydd hyn yn galluogi cwsmeriaid presennol i uwchraddio i'r fersiwn newydd. Ar ôl i'r diweddariad gael ei gyflwyno, rydych chi'n diffodd yr amgryptio bregus. A dyna i gyd! Barod! rwyt ti'n brydferth! Ni fydd cleientiaid hyd yn oed yn sylwi.
Mae hwn mewn gwirionedd yn achos cyffredin iawn ar gyfer gosodiadau mawr, ac mae hyd yn oed OpenVPN yn cael rhywfaint o anhawster gyda hyn. Mae cydnawsedd yn ôl yn bwysig, ac er eich bod yn defnyddio amgryptio gwannach, i lawer, nid yw hyn yn rheswm i gau busnes. Oherwydd bydd yn parlysu gwaith cannoedd o gwsmeriaid oherwydd yr anallu i wneud eu gwaith.
Mae tîm WireGuard wedi gwneud eu protocol yn symlach, ond yn gwbl annefnyddiadwy i bobl nad oes ganddynt reolaeth gyson dros y ddau gyfoed yn eu twnnel. Yn fy mhrofiad i, dyma'r senario mwyaf cyffredin.
Cryptograffi!
Ond beth yw'r amgryptio newydd diddorol hwn y mae WireGuard yn ei ddefnyddio?
Mae WireGuard yn defnyddio Curve25519 ar gyfer cyfnewid allweddi, ChaCha20 ar gyfer amgryptio a Poly1305 ar gyfer dilysu data. Mae hefyd yn gweithio gyda SipHash ar gyfer allweddi hash a BLAKE2 ar gyfer stwnsio.
Mae ChaCha20-Poly1305 wedi'i safoni ar gyfer IPsec ac OpenVPN (dros TLS).
Mae'n amlwg bod datblygiad Daniel Bernstein yn cael ei ddefnyddio'n aml iawn. BLAKE2 yw olynydd BLAKE, a gyrhaeddodd rownd derfynol SHA-3 na enillodd oherwydd ei debygrwydd i SHA-2. Pe bai SHA-2 yn cael ei dorri, roedd siawns dda y byddai BLAKE yn cael ei beryglu hefyd.
Nid oes angen SipHash ar IPsec ac OpenVPN oherwydd eu dyluniad. Felly yr unig beth na ellir ei ddefnyddio gyda nhw ar hyn o bryd yw BLAKE2, a dim ond nes ei fod wedi'i safoni y mae hynny. Nid yw hyn yn anfantais fawr, oherwydd mae VPNs yn defnyddio HMAC i greu uniondeb, a ystyrir yn ddatrysiad cryf hyd yn oed ar y cyd â MD5.
Felly deuthum i'r casgliad bod bron yr un set o offer cryptograffig yn cael ei ddefnyddio ym mhob VPN. Felly, nid yw WireGuard yn fwy neu'n llai diogel nag unrhyw gynnyrch cyfredol arall o ran amgryptio neu gyfanrwydd data a drosglwyddir.
Ond hyd yn oed nid dyma'r peth pwysicaf, sy'n werth talu sylw iddo yn ôl dogfennaeth swyddogol y prosiect. Wedi'r cyfan, y prif beth yw cyflymder.
A yw WireGuard yn gyflymach nag atebion VPN eraill?
Yn fyr: na, nid yn gyflymach.
Mae ChaCha20 yn seiffr nant sy'n haws ei weithredu mewn meddalwedd. Mae'n amgryptio un darn ar y tro. Mae protocolau bloc fel AES yn amgryptio bloc 128 did ar y tro. Mae angen llawer mwy o transistorau i weithredu cefnogaeth caledwedd, felly mae proseswyr mwy yn dod ag AES-NI, estyniad set gyfarwyddiadau sy'n cyflawni rhai o dasgau'r broses amgryptio i'w gyflymu.
Roedd disgwyl na fyddai AES-NI byth yn mynd i mewn i ffonau smart [ond fe wnaeth - tua. per.]. Ar gyfer hyn, datblygwyd y ChaCha20 fel dewis arall ysgafn, arbed batri. Felly, efallai y daw'n newyddion i chi fod gan bob ffôn clyfar y gallwch ei brynu heddiw ryw fath o gyflymiad AES a'i fod yn rhedeg yn gyflymach a chyda defnydd pŵer is gyda'r amgryptio hwn na gyda ChaCha20.
Yn amlwg, mae gan bron bob prosesydd bwrdd gwaith / gweinydd a brynwyd yn ystod yr ychydig flynyddoedd diwethaf AES-NI.
Felly, disgwyliaf i AES berfformio'n well na ChaCha20 ym mhob un senario. Mae dogfennaeth swyddogol WireGuard yn sôn y bydd ChaCha512-Poly20, gydag AVX1305, yn perfformio'n well na AES-NI, ond dim ond ar CPUs mwy y bydd yr estyniad set cyfarwyddiadau hwn ar gael, na fydd eto'n helpu gyda chaledwedd llai a mwy symudol, a fydd bob amser yn gyflymach gydag AES - N.I.
Nid wyf yn siŵr a ellid bod wedi rhagweld hyn yn ystod datblygiad WireGuard, ond heddiw mae'r ffaith ei fod wedi'i hoelio ar amgryptio yn unig eisoes yn anfantais efallai na fydd yn effeithio ar ei weithrediad yn dda iawn.
Mae IPsec yn caniatáu ichi ddewis yn rhydd pa amgryptio sydd orau i'ch achos chi. Ac wrth gwrs, mae hyn yn angenrheidiol, er enghraifft, os ydych chi am drosglwyddo 10 gigabeit neu fwy o ddata trwy gysylltiad VPN.
Materion integreiddio yn Linux
Er bod WireGuard wedi dewis protocol amgryptio modern, mae hyn eisoes yn achosi llawer o broblemau. Ac felly, yn lle defnyddio'r hyn a gefnogir gan y cnewyllyn allan o'r bocs, mae integreiddio WireGuard wedi'i ohirio ers blynyddoedd oherwydd diffyg y cyntefigau hyn yn Linux.
Dydw i ddim yn hollol siŵr beth yw'r sefyllfa ar systemau gweithredu eraill, ond mae'n debyg nad yw'n llawer gwahanol nag ar Linux.
Sut olwg sydd ar realiti?
Yn anffodus, bob tro y bydd cleient yn gofyn i mi sefydlu cysylltiad VPN ar eu cyfer, rwy'n rhedeg i mewn i'r mater eu bod yn defnyddio tystlythyrau ac amgryptio hen ffasiwn. Mae 3DES ar y cyd â MD5 yn dal i fod yn arfer cyffredin, fel y mae AES-256 a SHA1. Ac er bod yr olaf ychydig yn well, nid yw hyn yn rhywbeth y dylid ei ddefnyddio yn 2020.
Ar gyfer cyfnewid allweddol bob amser Defnyddir RSA - offeryn araf ond gweddol ddiogel.
Mae fy nghleientiaid yn gysylltiedig ag awdurdodau tollau a sefydliadau a sefydliadau eraill y llywodraeth, yn ogystal â chorfforaethau mawr y mae eu henwau'n hysbys ledled y byd. Maent i gyd yn defnyddio ffurflen gais a grëwyd ddegawdau yn ôl, ac yn syml iawn ni ychwanegwyd y gallu i ddefnyddio SHA-512. Ni allaf ddweud ei fod rywsut yn amlwg yn effeithio ar gynnydd technolegol, ond yn amlwg mae'n arafu'r broses gorfforaethol.
Mae'n boen imi weld hyn oherwydd mae IPsec wedi bod yn cefnogi cromliniau eliptig oddi ar y llaw arall ers 2005. Mae Curve25519 hefyd yn fwy newydd ac ar gael i'w ddefnyddio. Mae yna hefyd ddewisiadau amgen i AES fel Camellia a ChaCha20, ond yn amlwg nid yw pob un ohonynt yn cael eu cefnogi gan werthwyr mawr fel Cisco ac eraill.
Ac mae pobl yn manteisio arno. Mae yna lawer o gitiau Cisco, mae yna lawer o gitiau wedi'u cynllunio i weithio gyda Cisco. Maent yn arweinwyr marchnad yn y gylchran hon ac nid oes ganddynt ddiddordeb mawr mewn unrhyw fath o arloesi.
Ydy, mae'r sefyllfa [yn y segment corfforaethol] yn ofnadwy, ond ni welwn unrhyw newidiadau oherwydd WireGuard. Mae'n debyg na fydd gwerthwyr byth yn gweld unrhyw broblemau perfformiad gyda'r offer a'r amgryptio y maent eisoes yn eu defnyddio, ni fyddant yn gweld unrhyw broblemau gydag IKEv2, ac felly nid ydynt yn chwilio am ddewisiadau eraill.
Yn gyffredinol, ydych chi erioed wedi meddwl am roi'r gorau i Cisco?
Meincnodau
A nawr gadewch i ni symud ymlaen at y meincnodau o ddogfennaeth WireGuard. Er nad yw'r [dogfennaeth] hon yn erthygl wyddonol, roeddwn i'n dal i ddisgwyl i'r datblygwyr gymryd agwedd fwy gwyddonol, neu ddefnyddio dull gwyddonol fel cyfeiriad. Mae unrhyw feincnodau yn ddiwerth os na ellir eu hatgynhyrchu, a hyd yn oed yn fwy diwerth pan gânt eu cael yn y labordy.
Yn adeilad Linux WireGuard, mae'n manteisio ar ddefnyddio GSO - Generic Segmentation Offloading. Diolch iddo, mae'r cleient yn creu pecyn enfawr o 64 kilobytes ac yn ei amgryptio / dadgryptio ar yr un pryd. Felly, mae cost galw a gweithredu gweithrediadau cryptograffig yn cael ei leihau. Os ydych chi am wneud y mwyaf o fewnbwn eich cysylltiad VPN, mae hwn yn syniad da.
Ond, yn ôl yr arfer, nid yw'r realiti mor syml. Mae anfon pecyn mor fawr i addasydd rhwydwaith yn ei gwneud yn ofynnol iddo gael ei dorri'n llawer o becynnau llai. Y maint anfon arferol yw 1500 beit. Hynny yw, bydd ein cawr o 64 kilobytes yn cael ei rannu'n 45 pecyn (1240 beit o wybodaeth ac 20 beit o'r pennawd IP). Yna, am ychydig, byddant yn rhwystro gwaith yr addasydd rhwydwaith yn llwyr, oherwydd rhaid eu hanfon gyda'i gilydd ac ar unwaith. O ganlyniad, bydd hyn yn arwain at naid flaenoriaeth, a bydd pecynnau fel VoIP, er enghraifft, yn cael eu ciwio.
Felly, mae'r trwybwn uchel y mae WireGuard yn ei hawlio mor feiddgar yn cael ei gyflawni ar gost arafu rhwydweithio cymwysiadau eraill. Ac mae tîm WireGuard eisoes dyma fy nghasgliad.
Ond gadewch i ni symud ymlaen.
Yn ôl y meincnodau yn y ddogfennaeth dechnegol, mae'r cysylltiad yn dangos trwygyrch o 1011 Mbps.
Yn drawiadol.
Mae hyn yn arbennig o drawiadol oherwydd y ffaith mai trwybwn damcaniaethol uchaf un cysylltiad Gigabit Ethernet yw 966 Mbps gyda maint pecyn o 1500 beit llai 20 beit ar gyfer y pennawd IP, 8 beit ar gyfer pennawd y CDU ac 16 beit ar gyfer pennyn y CDU. y WireGuard ei hun . Mae un pennawd IP arall yn y pecyn wedi'i amgáu ac un arall yn TCP ar gyfer 20 beit. Felly o ble daeth y lled band ychwanegol hwn?
Gyda fframiau enfawr a manteision GSO y buom yn siarad amdanynt uchod, yr uchafswm damcaniaethol ar gyfer maint ffrâm o 9000 beit fyddai 1014 Mbps. Fel arfer mae trwybwn o'r fath yn anghyraeddadwy mewn gwirionedd, oherwydd ei fod yn gysylltiedig ag anawsterau mawr. Felly, ni allaf ond tybio bod y prawf wedi'i berfformio gan ddefnyddio fframiau mwy tewach fyth o 64 kilobytes gydag uchafswm damcaniaethol o 1023 Mbps, a gefnogir gan rai addaswyr rhwydwaith yn unig. Ond mae hyn yn gwbl amherthnasol mewn amodau real, neu dim ond rhwng dwy orsaf sydd â chysylltiad uniongyrchol y gellir ei ddefnyddio, yn gyfan gwbl o fewn y fainc brawf.
Ond gan fod y twnnel VPN yn cael ei anfon ymlaen rhwng dau westeiwr gan ddefnyddio cysylltiad Rhyngrwyd nad yw'n cefnogi fframiau jumbo o gwbl, ni ellir cymryd y canlyniad a gyflawnwyd ar y fainc fel meincnod. Yn syml, mae hwn yn gyflawniad labordy afrealistig sy'n amhosibl ac yn amherthnasol mewn amodau ymladd go iawn.
Hyd yn oed yn eistedd yn y ganolfan ddata, ni allwn drosglwyddo fframiau mwy na 9000 beit.
Mae'r maen prawf o gymhwysedd mewn bywyd go iawn yn cael ei dorri'n llwyr ac, fel rwy'n meddwl, roedd awdur y "mesur" a gynhaliwyd wedi anfri arno'i hun yn ddifrifol am resymau amlwg.
Llygedyn olaf o obaith
Mae gwefan WireGuard yn siarad llawer am gynwysyddion ac mae'n dod yn amlwg at yr hyn y mae wedi'i fwriadu mewn gwirionedd.
VPN syml a chyflym nad oes angen unrhyw gyfluniad arno a gellir ei ddefnyddio a'i ffurfweddu gydag offer cerddorfaol enfawr fel sydd gan Amazon yn eu cwmwl. Yn benodol, mae Amazon yn defnyddio'r nodweddion caledwedd diweddaraf y soniais amdanynt yn gynharach, fel yr AVX512. Gwneir hyn er mwyn cyflymu'r gwaith a pheidio â'i glymu i x86 nac unrhyw bensaernïaeth arall.
Maent yn gwneud y gorau o fewnbwn a phecynnau sy'n fwy na 9000 beit - bydd y rhain yn fframiau wedi'u hamgáu enfawr i gynwysyddion gyfathrebu â'i gilydd, neu ar gyfer gweithrediadau wrth gefn, gan greu cipluniau neu ddefnyddio'r un cynwysyddion hyn. Ni fydd hyd yn oed cyfeiriadau IP deinamig yn effeithio ar weithrediad WireGuard mewn unrhyw ffordd yn achos y senario a ddisgrifiais.
Chwarae da. Gweithredu gwych a phrotocol cyfeiriol tenau iawn, bron.
Ond nid yw'n ffitio mewn byd y tu allan i ganolfan ddata rydych chi'n ei reoli'n llwyr. Os cymerwch y risg a dechrau defnyddio WireGuard, bydd yn rhaid i chi wneud cyfaddawdau cyson wrth ddylunio a gweithredu'r protocol amgryptio.
Allbwn
Mae'n hawdd i mi ddod i'r casgliad nad yw WireGuard yn barod eto.
Fe'i lluniwyd fel ateb ysgafn a chyflym i nifer o broblemau gydag atebion presennol. Yn anffodus, er mwyn yr atebion hyn, aberthodd lawer o nodweddion a fydd yn berthnasol i'r mwyafrif o ddefnyddwyr. Dyna pam na all ddisodli IPsec neu OpenVPN.
Er mwyn i WireGuard ddod yn gystadleuol, mae angen iddo ychwanegu o leiaf gosodiad cyfeiriad IP a chyfluniad llwybro a DNS. Yn amlwg, dyma beth yw pwrpas sianeli wedi'u hamgryptio.
Diogelwch yw fy mhrif flaenoriaeth, ac ar hyn o bryd nid oes gennyf unrhyw reswm i gredu bod IKE neu TLS yn cael ei beryglu neu ei dorri rywsut. Cefnogir amgryptio modern yn y ddau ohonynt, ac maent wedi'u profi gan ddegawdau o weithredu. Nid yw'r ffaith bod rhywbeth yn fwy newydd yn golygu ei fod yn well.
Mae rhyngweithredu yn hynod bwysig pan fyddwch yn cyfathrebu â thrydydd partïon nad ydych yn rheoli eu gorsafoedd. IPsec yw'r safon de facto ac fe'i cefnogir bron ym mhobman. Ac mae'n gweithio. Ac ni waeth sut mae'n edrych, mewn theori, efallai na fydd WireGuard yn y dyfodol yn gydnaws hyd yn oed â gwahanol fersiynau ohono'i hun.
Mae unrhyw amddiffyniad cryptograffig yn cael ei dorri'n hwyr neu'n hwyrach ac, yn unol â hynny, rhaid ei ddisodli neu ei ddiweddaru.
Mae gwadu'r holl ffeithiau hyn a bod eisiau defnyddio WireGuard i gysylltu'ch iPhone â'ch gweithfan gartref yn ddim ond dosbarth meistr mewn glynu'ch pen yn y tywod.
Ffynhonnell: hab.com