Koha sĂ« fundmi WireGuard po tĂ«rheq vĂ«mendjen e madhe, nĂ« fakt â Ă«shtĂ« njĂ« 'yje' e re nĂ« mesin e VPN. Por a Ă«shtĂ« aq i mirĂ« sa duket? Do doja tĂ« diskutonin disa vĂ«zhgime dhe tĂ« shqyrtoj implementimin e WireGuard pĂ«r tĂ« treguar pse ai nuk Ă«shtĂ« njĂ« zgjidhje qĂ« do tĂ« zĂ«vendĂ«sojĂ« IPsec ose OpenVPN.
Në këtë artikull do doja të demaskoja disa mite [rreth WireGuard]. Po, do të duhet të lexoni gjatë, kështu që nëse nuk keni bërë akoma një filxhan çaji ose kafeje, tani është koha ta bëni. Gjithashtu, do doja të falënderoj Piterin për korrekturimin e mendimeve të mia kaotike.
Nuk e kam si qĂ«llim tĂ« diskreditoj zhvilluesit e WireGuard, tĂ« devalvoj pĂ«rpjekjet ose idetĂ« e tyre. Produkti i tyre Ă«shtĂ« funksional, por personalisht mendoj se ai paraqitet krejt ndryshe nga çfarĂ« Ă«shtĂ« nĂ« tĂ« vĂ«rtetĂ« â paraqitet si njĂ« zĂ«vendĂ«sim pĂ«r IPsec dhe OpenVPN, tĂ« cilat aktualisht thjesht nuk ekzistojnĂ«.
Si një shënim, do të doja të theksoj se përgjegjësia për këtë pozicionimin e WireGuard e mbajnë mediat që flisnin për të, e jo projekti vetë ose krijuesit e tij.
Koha e fundit nuk kishte shumĂ« lajme tĂ« mira pĂ«r bĂ«rthamĂ«n Linux. KĂ«shtu, na u raportua pĂ«r dobĂ«sitĂ« e tmerrshme tĂ« procesorit, tĂ« cilat u neutralizuan nĂ« mĂ«nyrĂ« programore, dhe Linus Torvalds fliste pĂ«r kĂ«tĂ« paksa ashpĂ«r dhe mĂ«rzitur, nĂ« njĂ« gjuhĂ« utilitare tĂ« zhvilluesit. Planifikuesi ose staku rrjet nĂ« zero â gjithashtu nuk janĂ« tema tĂ« lehta pĂ«r revista tĂ« shkĂ«lqyera. Dhe kĂ«tu shfaqet WireGuard.
Në letër gjithçka tingëllon shkëlqyeshëm: një teknologji e re që ndizet imagjinatën.
Por le të shohim pak më nga afër.
Dokumentacioni teknik i WireGuard
Ky artikull bazohet në dokumenti zyrtar i WireGuard, i shkruar nga Jason Donenfeld. Aty ai shpjegon konceptin, qëllimin dhe realizimin teknik [WireGuard] në bërthamën Linux.
Fjalinë e parë thotë:
WireGuard [âŠ] synon tĂ« zĂ«vendĂ«sojĂ« si IPsec nĂ« shumicĂ«n e rasteve tĂ« pĂ«rdorimit, ashtu dhe zgjidhje tĂ« tjera popullore tĂ« bazuara nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit dhe/ose TLS, si OpenVPN, duke qenĂ« njĂ« [mjet] mĂ« tĂ« sigurt, mĂ« tĂ« performueshĂ«m dhe mĂ« tĂ« lehtĂ« pĂ«r t'u pĂ«rdorur.
Sigurisht, përfitimi kryesor i të gjitha teknologjive të reja është thjeshtësia [në krahasim me paraardhësit]. Por VPN gjithashtu duhet të jetë efektiv dhe i sigurt.
Dhe tani, çfarë?
Nëse thoni se ju nevojitet ndryshe nga [VPN], atëherë mund të përfundojmë këtu leximin. Megjithatë, do të theksoj se këto detyra përjetohen nga çdo teknologji tjetër tunelimi.
MĂ« interesante nga citati i lartpĂ«rmendur qĂ«ndron nĂ« fjalĂ«t "nĂ« shumicĂ«n e rasteve", tĂ« cilat, natyrisht, janĂ« injoruar nga median. Dhe ja, jemi aty ku jemi pĂ«r shkak tĂ« kĂ«tyre kaoseve tĂ« krijuara nga neglizhenca â nĂ« kĂ«tĂ« artikull.
A do të jetë WireGuard një zëvendësim për lidhjen time [IPsec] VPN ndërmjet vendeve?
Jo. Nuk ka asnjë mundësi që furnizues të mëdhenj si Cisco, Juniper dhe të tjerë të adoptim WireGuard për produktet e tyre. Ata nuk 'hipin në trenat që kalojnë' në levizje, nëse nuk ka ndonjë nevojë të madhe për këtë. Më vonë do të flas për disa arsye se pse ata ndoshta nuk do të jenë në gjendje ta integrokë WireGuard në produktet e tyre, edhe sikur të dëshironin.
A do ta transferojë WireGuard RoadWarrior tim nga laptopi në qendrën e të dhënave?
Jo. Aktualisht, WireGuard nuk ka implementuar shumë funksione të rëndësishme që t'i mundësojnë të bëjë diçka të tillë. Për shembull, ai nuk mund të përdorë adresa IP dinamike nga ana e serverit të tunelit, dhe vetëm kjo e prish të gjithë skenarin e përdorimit të këtij produkti.
IPFire shpesh përdoret për kanale të lira interneti, për shembull, për DSL ose lidhje kabllore. Kjo ka kuptim për biznese të vogla ose të mesme që nuk kanë nevojë për fibra optike të shpejta. [Shënim nga përkthyesi: mos harroni se sa i përket lidhjeve, Rusia dhe disa vende të CIS janë shumë përpara Europës dhe SHBA-së, sepse ne filluam të ndërtojmë rrjetet tona shumë më vonë dhe me ardhjen e Ethernet dhe rrjeteve optike si standard, na ishte më e lehtë të riorganizohemi. Në të njëjtat vende të BE ose SHBA, qasja xDSL me shpejtësi 3-5 Mbps është ende norma e zakonshme, ndërsa lidhja me fibra optike kushton ndonjëherë para që për ne duket joreale. Prandaj, autori i artikullit flet për lidhjet DSL ose kabllore si norma dhe jo si gjë të vjetëruar.] Megjithatë, lidhjet DSL, kabllorët, LTE (dhe metoda të tjera wireless) kanë adresa IP dinamike. Natyrisht, ndonjëherë ato ndryshojnë jo shpesh, por gjithsesi ndryshojnë.
Ekziston një titull nënshtesë që quhet «wg-dynamic», i cili shton një demonstrim të hapësirës së përdoruesit për të tejkaluar këtë mangësi. Një problem i madh me skenarin e përdoruesit të përshkruar më sipër është përkeqësimi i situatës nga adresimi dinamik IPv6.
Nga këndvështrimi i shpërndarësit, gjithçka duket gjithashtu jo shumë mirë. Një nga qëllimet e zhvillimit ishte të ruhej thjeshtësia dhe pastërtia e protokollit.
Fatkeqësisht, gjithçka është bërë në fakt shumë e thjeshtë dhe primitive, saqë na duhet të përdorim software shtesë për ta bërë gjithë këtë strukturë të jetë e jetueshme në kushte reale.
A është aq e lehtë të përdoret WireGuard?
Jo akoma. Nuk thashë që WireGuard kurrë nuk do të jetë një alternativë e mirë për kalimin e tunelit mes dy pikave, por për momentin, ai është thjesht një version alfa i produktit që duhet të bëhet.
Por çfarë bën ai në të vërtetë? A është vërtet IPsec më e komplikuar për t'u përdorur?
Qartë, jo. Ofruesi i IPsec e ka menduar këtë çështje dhe ofron produktin e tij së bashku me një ndërfaqe, për shembull, me IPFire.
Për të konfiguruar një tunel VPN përmes IPsec, do t'ju nevojiten pesë grupe të dhënash që duhet të futen në konfigurim: adresa juaj publike IP, adresa publike IP e palës pritëse, subnetet që dëshironi t'i bëni të dukshme përmes kësaj lidhjeje VPN dhe çelësi i ndarë më parë. Kështu, VPN konfigurimi ndodh brenda disa minutash dhe është në përputhje me çdo shitës.
Fatkeqësisht, në këtë histori ka disa përjashtime. Secili që ka provuar të kalojë një tunel VPN përmes IPsec në një makinë në OpenBSD e kupton se për çfarë po flas. Ka edhe disa shembuj të dhimbshëm, por në fakt ka shumë më tepër praktika pozitive në përdorimin e IPsec.
Rreth kompleksitetit të protokollit
Konsumatori final nuk duhet të shqetësohet për kompleksitetin e protokollit.
Nëse do të jetonim në një botë ku kjo do të ishte një shqetësim real i përdoruesit, ne do të ishim ndarë prej kohësh nga SIP, H.323, FTP dhe protokolle të tjera, të krijuara mbi dhjetë vjet më parë që funksionojnë keq me NAT.
Ka arsye se pse IPsec është më e komplikuar se WireGuard: ai bën shumë më shumë gjëra. Për shembull, autentifikimi i përdoruesit duke përdorur emrin e përdoruesit/faqja ose SIM me EAP. Ai ka një mundësi të zgjeruar për të shtuar të reja elementë kriptografikë.
Ndërsa WireGuard nuk e ka këtë.
Dhe kjo do të thotë se WireGuard në një moment do të dështojë, sepse një nga primitet e kriptografisë do të dobësohet ose do të komprometohen plotësisht. Autori i dokumentacionit teknik e thotë këtë:
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se WireGuard Ă«shtĂ« kriptografikisht i sigurt. Atij i mungon qĂ«llimisht fleksibiliteti i algoritmeve tĂ« enkriptimit dhe protokolleve. NĂ«se do tĂ« gjejmĂ« krisje tĂ« mĂ«dha nĂ« primitet e poshtme, do tĂ« jetĂ« e nevojshme tĂ« pĂ«rditĂ«sohen tĂ« gjitha pikĂ«t pĂ«rfundimtare. Siç e tregon fluksi i vazhdueshĂ«m i vulnerabiliteteve SSL/TLS, fleksibiliteti i enkriptimit Ă«shtĂ« rritur ndjeshĂ«m tani.
Propozimi i fundit është absolutisht i saktë.
Arritja e konsensusit mbi atë se cilin algoritëm të enkriptimit të përdorim, e bën protokollin si IKE dhe TLS më shumë se të komplikuar. Përtej kompleksitetit? Po, në TLS/SSL vulnerabilitetet ndodhin mjaft shpesh, dhe nuk ka alternativë ndaj tyre.
Rreth injorimit të problemeve reale
Imagjinoni se keni një server VPN me 200 klientë aktivë, diku në të gjithë botën. Kjo është një skenar mjaft standard i përdorimit. Nëse do t'ju duhej të ndryshonit algoritmin e enkriptimit, do t'ju duhet të dorëzoni përditësimin në të gjitha kopjet e WireGuard në këto laptopë, smartphone dhe kaq. Në të njëjtën kohë dorëzoni. Kjo është praktikisht e pamundur. Administratorët që do të përpiqen ta bëjnë këtë do të kenë nevojë për muaj të tërë për të zbatuar konfigurimet e nevojshme, dhe kompanitë e zakonshme do t'u duhen vërtet vite për ta realizuar një aktivitet të tillë.
IPsec dhe OpenVPN ofrojnë një funksion për të negociuar algoritmet e enkriptimit. Prandaj, një periudhë kohe, pas së cilës aktivizoni enkriptimin e ri, do të funksionojë edhe ai i vjetër. Falë kësaj, klientët aktualë do të jenë në gjendje të azhurnojnë versionin e ri. Pas përditësimit, thjesht do të çaktivizoni enkriptimin e dobët. Dhe gjithçka! E keni bërë! Ju jeni të mrekullueshëm! Klientët as që do ta vënë re.
Në të vërtetë, ky është një rast shumë i zakonshëm për shpërndarjet e mëdha, dhe edhe OpenVPN ndodhet përballë disa vështirësive në këtë. Kompatibiliteti pasues është i rëndësishëm, dhe ndonëse po përdorni një enkriptim më të dobët, për shumë kjo nuk përbën një arsyetim për të mbyllur biznesin. Sepse kjo do të çojë në paralizimin e qindra klientëve për shkak të pamundësisë për të kryer punën e tyre.
Ekipi i WireGuard e ka thjeshtuar protokollin e tij, por e ka bërë krejtësisht të papërshtatshëm për ata që nuk kanë kontroll të vazhdueshëm mbi të dy pirat e tunelit të tyre. Sipas përvojës sime, ky skenar është më i zakonshmi.
Kriptografia!
Por çfarë është kjo enkriptim i ri interesante që përdor WireGuard?
WireGuard përdor Curve25519 për shkëmbimin e çelësave, ChaCha20 për enkriptimin dhe Poly1305 për autentifikimin e të dhënave. Ai gjithashtu punon me SipHash për çelësat hash dhe BLAKE2 për hashing.
ChaCha20-Poly1305 është standardizuar për IPsec dhe OpenVPN (përmes TLS).
Padyshim, zhvillimi i Daniel Bernstein përdoret shumë shpesh. BLAKE2 është pasardhës i BLAKE, finalist i SHA-3, i cili nuk fitoi për shkak të ngjashmërisë së tij me SHA-2. Nëse SHA-2 do të ishte sulmuar, do të kishte një mundësi të madhe që edhe BLAKE të ishte i komprometuar.
IPsec dhe OpenVPN nuk kanë nevojë për SipHash për shkak të dizajnit të tyre. Kështu, e vetmja gjë që aktualisht nuk mund të përdoret me to është BLAKE2, dhe madje atëherë vetëm derisa të standardizohet. Kjo nuk është një mangësi e madhe, sepse VPN-të përdorin HMAC për të krijuar integritetin, i cili konsiderohet një zgjidhje e fortë edhe në kombinim me MD5.
Prandaj arrita në përfundimin se të gjitha VPN-të përdorin një praktikisht të njëjtin grup të mjeteve kriptografike. Prandaj, WireGuard nuk është më i sigurt ose më pak i sigurt se çdo produkt tjetër aktual, kur bëhet fjalë për enkriptimin ose integritetin e të dhënave të transmetuara.
Por as kjo nuk është më e rëndësishmja, për të cilën duhet të kushtojmë vëmendje sipas dokumentacionit zyrtar të projektit. E rëndësishmja është shpejtësia.
A është WireGuard më i shpejtë se zgjidhjet e tjera VPN?
Nëse e thjeshtojmë: jo, nuk është më i shpejtë.
ChaCha20 Ă«shtĂ« njĂ« algoritĂ«m enkriptues nĂ« rrjedhĂ«, i cili Ă«shtĂ« mĂ« i lehtĂ« pĂ«r t'u integruar nĂ« softuer. Ai enkripton njĂ« bit nĂ« tĂ« njĂ«jtĂ«n kohĂ«. Protokollet blok janĂ« si AES, qĂ« enkriptojnĂ« blloqe 128 bit nĂ« tĂ« njĂ«jtĂ«n kohĂ«. PĂ«r tĂ« realizuar mbĂ«shtetje harduerike kĂ«rkohet shumĂ« mĂ« tepĂ«r transistorĂ«, prandaj procesorĂ«t mĂ« tĂ« mĂ«dhenj vijnĂ« me AES-NI â njĂ« zgjerim tĂ« setit tĂ« komandave qĂ« realizon disa detyra tĂ« procesit tĂ« enkriptimit pĂ«r ta pĂ«rshpejtuar atĂ«.
Pritejtohej qĂ« AES-NI kurrĂ« nuk do tĂ« arrijĂ« nĂ« smartphone [por ja ku Ă«shtĂ«, â shĂ«n. pĂ«rk.]. PĂ«r kĂ«tĂ«, u zhvillua ChaCha20 â si njĂ« alternativĂ« e lehtĂ« dhe ekonomike, qĂ« kursen energjinĂ« e baterisĂ«. Prandaj, mund t'ju befasojĂ« qĂ« çdo smartphone qĂ« mund tĂ« blini sot ka njĂ« formĂ« tĂ« acelerimit pĂ«r AES dhe punon me kĂ«tĂ« enkriptim mĂ« shpejt dhe me mĂ« pak konsum energjie se me ChaCha20.
ĂshtĂ« e qartĂ« se pothuajse çdo procesor pĂ«r PC desktopĂ« / serverĂ«, i blerĂ« nĂ« dy vitet e fundit, ka AES-NI.
Prandaj, pres që AES të tejkalojë ChaCha20 në çdo skenar specifik. Në dokumentacionin zyrtar të WireGuard përmendet se falë AVX512, ChaCha20-Poly1305 do të tejkalojë AES-NI, por kjo zgjerim të komandave do të jetë i disponueshëm vetëm në procesorë më të mëdhenj, e cila përsëri nuk do të ndihmojë me pajisjet më të vogla dhe mobile, të cilat gjithmonë do të punojnë më shpejt me AES-NI.
Nuk jam i sigurt nĂ«se kjo mund tĂ« ishte parashikuar gjatĂ« zhvillimit tĂ« WireGuard, por sot fakti qĂ« ai Ă«shtĂ« i lidhur ngushtĂ« me njĂ« enkriptim â Ă«shtĂ« njĂ« mangĂ«si qĂ« mund tĂ« mos ketĂ« njĂ« efekt shumĂ« tĂ« mirĂ« nĂ« performancĂ«n e tij.
IPsec lejon zgjedhjen e lirë të cilës enkriptim i përshtatet më së miri rastit tuaj. Natyrisht, kjo është e nevojshme, nëse, për shembull, dëshironi të transferoni 10 ose më shumë gigabajt të dhënash përmes një lidhjeje VPN.
Problemet e integrimit në Linux
Megjithëse WireGuard zgjodhi një protokoll modern të enkriptimit, kjo tashmë po shkakton një sërë problemesh. Dhe kështu, në vend që të përdorim atë që mbështetet nga bërthama nga kutia, integrimi i WireGuard është vonuar për vite për shkak të mungesës së këtyre primitiveve në Linux.
Nuk jam plotësisht i informuar për situatën në sistemet e tjera operative, por ndoshta nuk ndryshon shumë nga situata në Linux.
Si duket realiteti?
FatkeqĂ«sisht, çdo herĂ« qĂ« njĂ« klient mĂ« kĂ«rkon tĂ« konfiguroj njĂ« lidhje VPN, pĂ«rballĂ«m me faktin se ata pĂ«rdorin kredenciale dhe enkriptim tĂ« skaduar. 3DES nĂ« kombinim me MD5 â Ă«shtĂ« ende njĂ« praktikĂ« e zakonshme, ashtu si AES-256 dhe SHA1. Dhe ndonĂ«se e fundit Ă«shtĂ« pak mĂ« e mirĂ« â nuk Ă«shtĂ« diçka qĂ« duhet tĂ« pĂ«rdoret nĂ« vitin 2020.
PĂ«r shkĂ«mbimin e çelĂ«save tĂ« ashpĂ«r nĂ« pĂ«rdoret RSA â njĂ« mjet i ngadalshĂ«m, por mjaft i sigurt.
Klientët e mi lidhen me organet doganore dhe institucionet shtetërore, si dhe me korporata të mëdha që njihen në të gjithë botën. Të gjithë ata përdorin një formular kërkese që është krijuar dekada më parë, dhe mundësia e përdorimit të SHA-512 thjesht nuk është shtuar kurrë. Nuk mund të them se kjo ndikon dukshëm në përparimin teknologjik, por është e qartë se ngadalëson proceset korporative.
Më dhemb ta shoh këtë, sepse IPsec mbështet kurbat eliptike që nga viti 2005. Curve25519 gjithashtu është më i ri dhe i disponueshëm për t'u përdorur. Ka edhe alternativa për AES, si Camellia dhe ChaCha20, por, natyrisht, jo të gjitha mbështeten nga ofrues të mëdhenj, si Cisco dhe të tjerë.
Dhe njerëzit e përdorin këtë. Ka shumë grupe Cisco, ka një sërë grupesh të krijuara për të punuar me Cisco. Ata janë liderë të tregut në këtë sektor dhe nuk janë shumë të interesuar për ndonjë inovacion.
Po, situata [në segmentin korporativ] është e tmerrshme, por ne nuk do të shohim ndonjë ndryshim për shkak të WireGuard. Prodhuesit, ndoshta, kurrë nuk do të zbulojnë ndonjë problem me performancën e mjeteve dhe enkriptimit që përdoren tashmë, nuk do të shohin probleme në përdorimin e IKEv2 - dhe për këtë arsyet nuk po kërkojnë alternativa.
A keni menduar ndonjëherë të hiqni dorë nga Cisco?
Benchmark
Tani, le tĂ« kalojmĂ« nĂ« benchmark-et nga dokumentacioni i WireGuard. Edhe pse ky [dokumentacion] nuk Ă«shtĂ« njĂ« artikull shkencor, unĂ« prapĂ« prisja njĂ« qasje mĂ« shkencore nga zhvilluesit, ose pĂ«rdorimin e njĂ« qasjeje shkencore si standart. Ădo benchmark Ă«shtĂ« i padobishĂ«m, nĂ«se nuk mund tĂ« riprodhohen, dhe janĂ« edhe mĂ« tĂ« padobishĂ«m kur janĂ« tĂ« nxjerra nĂ« kushte laboratorike.
Në ndërtimin e WireGuard për Linux, ai merr një avantazh duke përdorur GSO - Generic Segmentation Offloading. Falë këtij, klienti krijon një paketë të madhe prej 64 kilobajtësh dhe e enkripton/dekripton atë me një qasje. Kështu, kostot për thirrjen dhe realizimin e operacioneve kriptografike ulen. Nëse dëshironi të maksimizoni kapacitetin e lidhjes suaj VPN - kjo është një ide e mirë.
Sido, si ashtu si zakonisht, në të vërtetë nuk është gjithmonë kaq e thjeshtë. Dërgimi i një pakete të tillë të madhe në adapterin rrjetë kërkon që ajo të ndahet në shumë paketa më të vogla. Madhësia tipike e dërgesës është 1500 byte. Kështu që gjiganti ynë prej 64 kilobajt do të ndahet në 45 paketa (1240 byte informacion dhe 20 byte për titullin IP). Më pas, për njëfarë kohe, ato do të bllokojnë plotësisht funksionimin e adapterit rrjetë, sepse duhet të dërgohen së bashku dhe menjëherë. Në fund, kjo do të çojë në një rritje të prioriteteve, ndërsa paketat si, për shembull, VoIP, do të vendosen në radhë.
Kështu, kapaciteti i lartë, të cilin e shpall kaq guximshëm WireGuard, arrihet duke ngadalësuar punën e rrjetit të aplikacioneve të tjera. Dhe ekipi i WireGuard tashmë konfirmoi ky është përfundimi im.
Por le të vazhdojmë më tej.
Sipas benchmarkeve në dokumentacionin teknik, lidhja tregon një kapacitet prej 1011 Mbit/s.
Impresionuese.
Kjo është veçanërisht e impresionueshme për shkak se kapaciteti maksimal teorik i një lidhjeje Ethernet 1 gigabit arrin 966 Mbit/s me madhësinë e paketës në 1500 byte minus 20 byte për titullin IP, 8 byte për titullin UDP dhe 16 byte për titullin e WireGuard vetë. Ka një titull tjetër IP në paketën e inkapsuluar dhe një tjetër në TCP me 20 byte. Pra, nga erdhi kjo kapacitet i shtuar?
Me korniza të mëdha dhe përfitimet GSO, të cilat diskutuam më lart, maksimumi teorik me madhësinë e kornizës në 9000 byte do të jetë 1014 Mbit/s. Zakonisht, një kapacitet i tillë në realitet është i paarrijshëm, sepse lidhet me vështirësi të mëdha. Prandaj, mund të supozosh vetëm se testi u krye duke përdorur korniza edhe më të mëdha se 64 kilobajt me maksimumin teorik në 1023 Mbit/s, që mbështetet vetëm nga disa adaptera rrjetë. Por kjo është absolutisht e pavlefshme në kushte reale, ose mund të përdoret vetëm midis dy stacioneve të lidhura drejtpërdrejt me njëra-tjetrën, ekskluzivisht në kuadër të një skene testuese.
Por këtë arsye, ndërsa VPN tuneli kalon midis dy hosteve përmes një lidhjeje interneti që nuk mbështet korniza të mëdha, rezultati i arritur në laborator nuk mund të pranohet si referencë. Kjo është thjesht një arritje laboratorike e pamundur dhe e paarritshme në kushte të vërteta operative.
Edhe duke qëndruar në qendër të të dhënave, nuk do të mund t'i kaloj kornizat më të mëdha se 9000 byte.
Kriteri i përdorshmërisë në të vërtetë është absolutisht i shkelur, dhe siç mendoj, autori i 'masës' së kryer do të diskreditohet rëndë për arsye të qarta.
Shpresë e fundit
Na sitin WireGuard flitet shumë për kontejnerët dhe bëhet e qartë për çfarë është në të vërtetë menduar.
Një VPN e thjeshtë dhe e shpejtë, e cila nuk kërkon konfigurim dhe mund të vendoset dhe konfigurohet me mjete masive orkestrimi, siç është për shembull në Amazon në cloud-in e tyre. Konkretisht, Amazon përdor funksionet më të fundit harduerike, për të cilat kam përmendur më herët, si AVX512. Kjo bëhet për të përshpejtuar punën dhe për të mos u lidhur me x86 apo ndonjë arkitekturë tjetër.
Ata optimizojnë kapacitetin dhe paketat që tejkalojnë 9000 byte - kështu që, do të kemi korniza të mëdha të inkapsuluara për komunikimin midis kontejnerëve, ose për operacione rezervimi, krijimit të snapshot-eve ose për angazhimin e këtyre kontejnerëve. Edhe adresat IP dinamike nuk do të ndikojnë në funksionimin e WireGuard në skenarin që përshkruaj.
Luajtur mirë. Një implementim brilant dhe një protokoll shumë i sofistikuar, pothuajse ideal.
Por thjesht nuk është i përshtatshëm për botën jashtë qendrës së të dhënave plotësisht të kontrolluar nga ju. Nëse guxoni dhe filloni të përdorni WireGuard, do t'ju duhet të bëni kompromise të përhershme në zhvillimin dhe realizimin e protokollit të enkriptimit.
PĂ«rfundimi
Nuk është e vështirë për mua të arrij në përfundimin se WireGuard ende nuk është gati.
Ai është menduar si një zgjidhje e lehtë dhe e shpejtë për disa probleme që ekzistojnë tashmë në zgjidhje. Fatkeqësisht, për të arritur këto zgjidhje, ai ka sakrifikuar shumë funksione që do të jenë të rëndësishme për shumicën e përdoruesve. Kjo është arsyeja pse ai nuk mund të zëvendësojë IPsec apo OpenVPN.
PĂ«r tĂ« qenĂ« konkurruese, WireGuard duhet tĂ« shtojĂ« tĂ« paktĂ«n konfigurimin e IP adresĂ«s dhe konfigurimin e rrugĂ«zimit dhe DNS. ĂshtĂ« e qartĂ« se ky Ă«shtĂ« saktĂ«sisht arsyetimi pĂ«r tĂ« cilin nevojiten kanale tĂ« enkriptuara.
Siguria është prioriteti im kryesor, dhe aktualisht nuk kam arsye për të besuar se IKE ose TLS janë ndonjëherë të komprometuar ose të prishura. Kriptimi modern mbështetet në të dyja dhe ato janë verifikuar për dekada të tëra eksploatimi. Nëse diçka më e re nuk do të thotë se është më e mirë.
Kompaktibiliteti funksional është ekstremisht i rëndësishëm kur lidhemi me palë të treta, stacionet e të cilave nuk i kontrollojmë. IPsec është de facto standardi dhe mbështetet gjerësisht. Dhe funksionon. Edhe pse mund të duket, në teori, WireGuard në të ardhmen mund të jetë i papajtueshëm edhe me versione të ndryshme të vetvetes.
Ădo mbrojtje kriptografike, nĂ« njĂ« moment, do tĂ« thyehet dhe, pĂ«r rrjedhojĂ«, duhet tĂ« zĂ«vendĂ«sohet ose pĂ«rditĂ«sohet.
Mohojja e të gjitha këtyre fakteve dhe dëshira verbale për të përdorur WireGuard për të lidhur iPhone tuaj me stacionin e punës në shtëpi është thjesht një masterclass mbi futjen e kokës në rërë.
Burimi: habr.com
