Ang WireGuard ay nakakakuha ng maraming pansin kamakailan, sa katunayan ito ang bagong bituin sa mga VPN. Ngunit siya ba ay kasing galing niya? Gusto kong talakayin ang ilang mga obserbasyon at suriin ang pagpapatupad ng WireGuard upang ipaliwanag kung bakit hindi solusyon ang pagpapalit ng IPsec o OpenVPN.
Sa artikulong ito, gusto kong i-debunk ang ilan sa mga alamat [sa paligid ng WireGuard]. Oo, magtatagal ang pagbabasa, kaya kung hindi mo pa nagagawa ang iyong sarili ng isang tasa ng tsaa o kape, oras na para gawin ito. Gusto ko ring magpasalamat kay Peter sa pagwawasto sa aking magulong pag-iisip.
Hindi ko itinakda ang aking sarili ng layunin na siraan ang mga developer ng WireGuard, na sirain ang kanilang mga pagsisikap o ideya. Gumagana ang kanilang produkto, ngunit sa palagay ko personal na ito ay ipinakita na ganap na naiiba sa kung ano talaga ito - ipinakita ito bilang isang kapalit para sa IPsec at OpenVPN, na sa katunayan ay wala na ngayon.
Bilang isang tala, nais kong idagdag na ang responsibilidad para sa naturang pagpoposisyon ng WireGuard ay nakasalalay sa media na nagsalita tungkol dito, at hindi ang proyekto mismo o ang mga tagalikha nito.
Walang gaanong magandang balita tungkol sa Linux kernel kamakailan. Kaya, sinabi sa amin ang tungkol sa napakalaking kahinaan ng processor, na na-level ng software, at binanggit ito ni Linus Torvalds nang masyadong bastos at nakakainip, sa utilitarian na wika ng developer. Ang isang scheduler o isang zero-level na networking stack ay hindi rin masyadong malinaw na mga paksa para sa mga makintab na magazine. At narito ang WireGuard.
Sa papel, ang lahat ay maganda: isang kapana-panabik na bagong teknolohiya.
Ngunit tingnan natin ito nang mas malapitan.
WireGuard puting papel
Ang artikulong ito ay batay sa isinulat ni Jason Donenfeld. Doon ay ipinaliwanag niya ang konsepto, layunin at teknikal na pagpapatupad ng [WireGuard] sa Linux kernel.
Ang unang pangungusap ay nagbabasa:
Nilalayon ng WireGuard [β¦] na palitan ang parehong IPsec sa karamihan ng mga kaso ng paggamit at iba pang sikat na espasyo ng gumagamit at/o mga solusyon na nakabatay sa TLS gaya ng OpenVPN habang mas secure, gumaganap at mas madaling gamitin [tool].
Siyempre, ang pangunahing bentahe ng lahat ng mga bagong teknolohiya ay ang kanilang simple [kumpara sa mga nauna]. Ngunit ang isang VPN ay dapat din mahusay at ligtas.
Kaya, ano ang susunod?
Kung sasabihin mo na hindi ito ang kailangan mo [mula sa isang VPN], maaari mong tapusin ang pagbabasa dito. Gayunpaman, papansinin ko na ang mga naturang gawain ay nakatakda para sa anumang iba pang teknolohiya sa pag-tunnel.
Ang pinaka-kawili-wili sa itaas na quote ay namamalagi sa mga salitang "sa karamihan ng mga kaso", na, siyempre, ay hindi pinansin ng press. At kaya, kami ay kung saan kami natapos dahil sa kaguluhan na nilikha ng kapabayaan na ito - sa artikulong ito.
Papalitan ba ng WireGuard ang aking [IPsec] site-to-site na VPN?
Hindi. Walang pagkakataon na ang malalaking vendor tulad ng Cisco, Juniper at iba pa ay bibili ng WireGuard para sa kanilang mga produkto. Hindi sila "tumalon sa mga dumaraan na tren" habang gumagalaw maliban kung may malaking pangangailangan na gawin ito. Mamaya, tatalakayin ko ang ilan sa mga dahilan kung bakit malamang na hindi nila maisakay ang kanilang mga produkto ng WireGuard kahit na gusto nila.
Dadalhin ba ng WireGuard ang aking RoadWarrior mula sa aking laptop patungo sa data center?
Hindi. Sa ngayon, ang WireGuard ay walang malaking bilang ng mahahalagang feature na ipinatupad para magawa nito ang isang bagay na tulad nito. Halimbawa, hindi nito magagamit ang mga dynamic na IP address sa gilid ng tunnel server, at ito lamang ang sumisira sa buong senaryo ng naturang paggamit ng produkto.
Ang IPFire ay kadalasang ginagamit para sa murang mga link sa Internet, tulad ng DSL o mga koneksyon sa cable. Makatuwiran ito para sa mga maliliit o katamtamang negosyo na hindi nangangailangan ng mabilis na hibla. [Tandaan mula sa tagasalin: huwag kalimutan na sa mga tuntunin ng komunikasyon, ang Russia at ilang mga bansa ng CIS ay malayong nauuna sa Europa at USA, dahil sinimulan namin ang pagbuo ng aming mga network sa ibang pagkakataon at sa pagdating ng Ethernet at fiber optic network bilang isang pamantayan. , mas madali para sa amin ang muling pagtatayo. Sa parehong mga bansa ng EU o USA, ang xDSL broadband access sa bilis na 3-5 Mbps ay karaniwan pa rin, at ang isang fiber optic na koneksyon ay nagkakahalaga ng hindi makatotohanang pera ayon sa aming mga pamantayan. Samakatuwid, ang may-akda ng artikulo ay nagsasalita ng DSL o koneksyon sa cable bilang pamantayan, at hindi sinaunang panahon.] Gayunpaman, ang DSL, cable, LTE (at iba pang paraan ng wireless access) ay may mga dynamic na IP address. Siyempre, kung minsan hindi sila madalas na nagbabago, ngunit nagbabago sila.
May tinatawag na subproject , na nagdadagdag ng userspace daemon para malampasan ang pagkukulang na ito. Ang isang malaking problema sa senaryo ng gumagamit na inilarawan sa itaas ay ang paglala ng dynamic na IPv6 addressing.
Mula sa punto ng view ng distributor, ang lahat ng ito ay hindi masyadong maganda. Isa sa mga layunin sa disenyo ay panatilihing simple at malinis ang protocol.
Sa kasamaang palad, ang lahat ng ito ay talagang naging napakasimple at primitive, kaya kailangan nating gumamit ng karagdagang software upang ang buong disenyo na ito ay maging mabubuhay sa tunay na paggamit.
Napakadali bang gamitin ang WireGuard?
Hindi pa. Hindi ko sinasabi na ang WireGuard ay hindi kailanman magiging isang mahusay na alternatibo para sa pag-tunnel sa pagitan ng dalawang punto, ngunit sa ngayon ito ay isang alpha na bersyon lamang ng produktong ito ay dapat na maging.
Pero ano ba talaga ang ginagawa niya? Ang IPsec ba ay talagang mas mahirap i-maintain?
Halatang hindi. Naisip ito ng vendor ng IPsec at ipinapadala ang kanilang produkto kasama ng isang interface, tulad ng sa IPFire.
Upang mag-set up ng VPN tunnel sa IPsec, kakailanganin mo ng limang set ng data na kakailanganin mong ipasok sa configuration: ang iyong sariling pampublikong IP address, ang pampublikong IP address ng tumatanggap na partido, ang mga subnet na gusto mong isapubliko sa pamamagitan ng itong koneksyon sa VPN at pre-shared na key. Kaya, ang VPN ay naka-set up sa loob ng ilang minuto at tugma sa anumang vendor.
Sa kasamaang palad, may ilang mga pagbubukod sa kuwentong ito. Alam ng sinumang sumubok na mag-tunnel sa IPsec sa isang makinang OpenBSD kung ano ang pinag-uusapan ko. Mayroong ilang mas masakit na mga halimbawa, ngunit sa katunayan, marami, mas maraming magagandang kasanayan para sa paggamit ng IPsec.
Tungkol sa pagiging kumplikado ng protocol
Ang end user ay hindi kailangang mag-alala tungkol sa pagiging kumplikado ng protocol.
Kung nabuhay tayo sa isang mundo kung saan ito ay isang tunay na pag-aalala ng gumagamit, kung gayon ay aalisin na sana natin ang SIP, H.323, FTP at iba pang mga protocol na nilikha higit sa sampung taon na ang nakalipas na hindi gumagana nang maayos sa NAT.
May mga dahilan kung bakit mas kumplikado ang IPsec kaysa sa WireGuard: mas marami itong ginagawa. Halimbawa, ang pagpapatunay ng user gamit ang isang login / password o isang SIM card na may EAP. Mayroon itong pinahabang kakayahan na magdagdag ng bago .
At walang ganoon ang WireGuard.
At nangangahulugan ito na ang WireGuard ay masisira sa isang punto, dahil ang isa sa mga cryptographic primitives ay hihina o ganap na makompromiso. Sinabi ito ng may-akda ng teknikal na dokumentasyon:
Ito ay nagkakahalaga ng pagpuna na ang WireGuard ay cryptographically opinionated. Ito ay sadyang kulang sa flexibility ng mga cipher at protocol. Kung ang mga seryosong butas ay makikita sa pinagbabatayan ng mga primitive, ang lahat ng mga endpoint ay kailangang i-update. Tulad ng nakikita mo mula sa patuloy na pag-stream ng mga kahinaan sa SLL/TLS, ang flexibility ng encryption ay tumaas nang husto.
Ang huling pangungusap ay ganap na tama.
Ang pag-abot sa consensus sa kung anong encryption ang gagamitin ay gumagawa ng mga protocol tulad ng IKE at TLS pa kumplikado. Masyadong kumplikado? Oo, ang mga kahinaan ay karaniwan sa TLS/SSL, at walang alternatibo sa mga ito.
Sa hindi pagpansin sa mga tunay na problema
Isipin na mayroon kang isang VPN server na may 200 mga kliyente ng labanan sa isang lugar sa buong mundo. Ito ay isang medyo karaniwang kaso ng paggamit. Kung kailangan mong baguhin ang encryption, kailangan mong ihatid ang update sa lahat ng kopya ng WireGuard sa mga laptop, smartphone, at iba pa na ito. Sabay-sabay ihatid. Ito ay literal na imposible. Ang mga administrator na sumusubok na gawin ito ay aabutin ng ilang buwan upang i-deploy ang mga kinakailangang configuration, at literal na aabutin ng isang medium-sized na taon ng kumpanya upang maisagawa ang naturang kaganapan.
Nag-aalok ang IPsec at OpenVPN ng tampok na negosasyon ng cipher. Samakatuwid, sa ilang oras pagkatapos mong i-on ang bagong pag-encrypt, gagana rin ang luma. Papayagan nito ang mga kasalukuyang customer na mag-upgrade sa bagong bersyon. Pagkatapos mailunsad ang update, i-off mo lang ang vulnerable encryption. At ayun na nga! handa na! ikaw ay maganda! Hindi ito mapapansin ng mga kliyente.
Ito ay talagang isang pangkaraniwang kaso para sa malalaking pag-deploy, at kahit na ang OpenVPN ay nahihirapan dito. Mahalaga ang backward compatibility, at kahit na gumagamit ka ng weaker encryption, para sa marami, hindi ito dahilan para isara ang isang negosyo. Dahil ito ay maparalisa ang trabaho ng daan-daang mga customer dahil sa kawalan ng kakayahan upang gawin ang kanilang trabaho.
Ginawa ng WireGuard team na mas simple ang kanilang protocol, ngunit ganap na hindi magagamit para sa mga taong walang patuloy na kontrol sa parehong mga kapantay sa kanilang tunnel. Sa aking karanasan, ito ang pinakakaraniwang senaryo.
Cryptography!
Ngunit ano itong kawili-wiling bagong encryption na ginagamit ng WireGuard?
Gumagamit ang WireGuard ng Curve25519 para sa pagpapalit ng susi, ChaCha20 para sa pag-encrypt at Poly1305 para sa pagpapatunay ng data. Gumagana rin ito sa SipHash para sa mga hash key at BLAKE2 para sa pag-hash.
Ang ChaCha20-Poly1305 ay na-standardize para sa IPsec at OpenVPN (sa TLS).
Malinaw na ang pag-unlad ni Daniel Bernstein ay madalas na ginagamit. Ang BLAKE2 ang pumalit sa BLAKE, isang SHA-3 finalist na hindi nanalo dahil sa pagkakatulad nito sa SHA-2. Kung masisira ang SHA-2, malaki ang posibilidad na makompromiso rin si BLAKE.
Hindi kailangan ng IPsec at OpenVPN ang SipHash dahil sa kanilang disenyo. Kaya ang tanging bagay na kasalukuyang hindi magagamit sa kanila ay BLAKE2, at iyon ay hanggang sa ito ay na-standardize lamang. Ito ay hindi isang malaking sagabal, dahil ang mga VPN ay gumagamit ng HMAC upang lumikha ng integridad, na itinuturing na isang malakas na solusyon kahit na kasabay ng MD5.
Kaya't dumating ako sa konklusyon na halos parehong hanay ng mga tool sa cryptographic ang ginagamit sa lahat ng VPN. Samakatuwid, ang WireGuard ay hindi hihigit o mas ligtas kaysa sa anumang iba pang kasalukuyang produkto pagdating sa pag-encrypt o integridad ng ipinadalang data.
Ngunit kahit na ito ay hindi ang pinakamahalagang bagay, na kung saan ay nagkakahalaga ng pagbibigay pansin ayon sa opisyal na dokumentasyon ng proyekto. Pagkatapos ng lahat, ang pangunahing bagay ay bilis.
Mas mabilis ba ang WireGuard kaysa sa iba pang mga solusyon sa VPN?
Sa madaling salita: hindi, hindi mas mabilis.
Ang ChaCha20 ay isang stream cipher na mas madaling ipatupad sa software. Naka-encrypt ito nang paisa-isa. I-block ang mga protocol tulad ng AES na naka-encrypt ng isang block na 128 bits sa isang pagkakataon. Higit pang mga transistor ang kinakailangan upang ipatupad ang suporta sa hardware, kaya ang mga malalaking processor ay may kasamang AES-NI, isang extension ng set ng pagtuturo na gumaganap ng ilan sa mga gawain ng proseso ng pag-encrypt upang mapabilis ito.
Inaasahan na ang AES-NI ay hindi kailanman makapasok sa mga smartphone [ngunit nangyari ito β humigit-kumulang. bawat.]. Para dito, ang ChaCha20 ay binuo bilang isang magaan, nakakatipid ng baterya na alternatibo. Samakatuwid, maaaring dumating bilang balita sa iyo na ang bawat smartphone na mabibili mo ngayon ay may ilang uri ng AES acceleration at tumatakbo nang mas mabilis at may mas mababang paggamit ng kuryente sa pag-encrypt na ito kaysa sa ChaCha20.
Malinaw, halos lahat ng desktop/server processor na binili sa nakalipas na ilang taon ay may AES-NI.
Kaya naman, inaasahan kong hihigitan ng AES ang ChaCha20 sa bawat solong senaryo. Binanggit ng opisyal na dokumentasyon ng WireGuard na sa AVX512, ang ChaCha20-Poly1305 ay hihigit sa pagganap ng AES-NI, ngunit ang extension ng set ng pagtuturo na ito ay magagamit lamang sa mas malalaking CPU, na muli ay hindi makakatulong sa mas maliit at mas maraming mobile na hardware, na palaging magiging mas mabilis sa AES - N.I.
Hindi ako sigurado kung ito ay maaaring foreseen sa panahon ng pagbuo ng WireGuard, ngunit ngayon ang katotohanan na ito ay ipinako sa pag-encrypt lamang ay isa nang disbentaha na maaaring hindi masyadong makaapekto sa operasyon nito.
Binibigyang-daan ka ng IPsec na malayang pumili kung aling pag-encrypt ang pinakamainam para sa iyong kaso. At siyempre, kinakailangan ito kung, halimbawa, nais mong maglipat ng 10 o higit pang gigabytes ng data sa pamamagitan ng koneksyon sa VPN.
Mga isyu sa pagsasama sa Linux
Bagama't pumili ang WireGuard ng modernong protocol ng pag-encrypt, nagdudulot na ito ng maraming problema. At kaya, sa halip na gamitin kung ano ang sinusuportahan ng kernel sa labas ng kahon, ang pagsasama ng WireGuard ay naantala ng maraming taon dahil sa kakulangan ng mga primitive na ito sa Linux.
Hindi ako lubos na sigurado kung ano ang sitwasyon sa ibang mga operating system, ngunit malamang na hindi ito gaanong naiiba kaysa sa Linux.
Ano ang hitsura ng katotohanan?
Sa kasamaang palad, sa tuwing hihilingin sa akin ng isang kliyente na mag-set up ng isang koneksyon sa VPN para sa kanila, nararanasan ko ang isyu na gumagamit sila ng hindi napapanahong mga kredensyal at pag-encrypt. Ang 3DES kasabay ng MD5 ay karaniwang kasanayan pa rin, tulad ng AES-256 at SHA1. At kahit na ang huli ay bahagyang mas mahusay, ito ay hindi isang bagay na dapat gamitin sa 2020.
Para sa palitan ng susi laging Ginagamit ang RSA - isang mabagal ngunit medyo ligtas na tool.
Ang aking mga kliyente ay nauugnay sa mga awtoridad sa customs at iba pang organisasyon at institusyon ng gobyerno, pati na rin sa malalaking korporasyon na kilala ang mga pangalan sa buong mundo. Gumagamit silang lahat ng form ng kahilingan na nilikha ilang dekada na ang nakalipas, at ang kakayahang gumamit ng SHA-512 ay hindi kailanman naidagdag. Hindi ko masasabi na kahit papaano ay malinaw na nakakaapekto ito sa pag-unlad ng teknolohiya, ngunit malinaw na pinapabagal nito ang proseso ng korporasyon.
Nasasaktan akong makita ito, dahil sinuportahan ng IPsec ang mga elliptic curve mula noong taong 2005. Ang Curve25519 ay mas bago at magagamit para magamit. Mayroon ding mga alternatibo sa AES tulad ng Camellia at ChaCha20, ngunit malinaw na hindi lahat ng mga ito ay suportado ng mga pangunahing vendor tulad ng Cisco at iba pa.
At sinasamantala ito ng mga tao. Maraming Cisco kit, maraming kit na idinisenyo upang gumana sa Cisco. Sila ay mga pinuno ng merkado sa segment na ito at hindi masyadong interesado sa anumang uri ng pagbabago.
Oo, ang sitwasyon [sa corporate segment] ay kakila-kilabot, ngunit wala kaming makikitang anumang pagbabago dahil sa WireGuard. Malamang na hindi kailanman makikita ng mga vendor ang anumang mga isyu sa pagganap sa tooling at encryption na ginagamit na nila, hindi makakakita ng anumang mga problema sa IKEv2, at kaya hindi sila naghahanap ng mga alternatibo.
Sa pangkalahatan, naisip mo na bang iwanan ang Cisco?
Mga benchmark
At ngayon lumipat tayo sa mga benchmark mula sa dokumentasyon ng WireGuard. Bagama't ang [dokumentasyon] na ito ay hindi isang siyentipikong artikulo, inaasahan ko pa rin na ang mga developer ay gagawa ng mas siyentipikong diskarte, o gumamit ng siyentipikong diskarte bilang isang sanggunian. Ang anumang mga benchmark ay walang silbi kung hindi ito maaaring kopyahin, at mas walang silbi kapag nakuha ito sa laboratoryo.
Sa Linux build ng WireGuard, sinasamantala nito ang paggamit ng GSO - Generic Segmentation Offloading. Salamat sa kanya, ang kliyente ay lumilikha ng isang malaking packet ng 64 kilobytes at i-encrypt / i-decrypt ito nang sabay-sabay. Kaya, ang halaga ng pag-invoke at pagpapatupad ng mga cryptographic na operasyon ay nababawasan. Kung nais mong i-maximize ang throughput ng iyong koneksyon sa VPN, ito ay isang magandang ideya.
Ngunit, gaya ng dati, ang katotohanan ay hindi gaanong simple. Ang pagpapadala ng ganoong kalaking packet sa isang network adapter ay nangangailangan na ito ay i-cut sa maraming mas maliliit na packet. Ang normal na laki ng pagpapadala ay 1500 bytes. Ibig sabihin, ang aming higanteng 64 kilobytes ay mahahati sa 45 packet (1240 bytes ng impormasyon at 20 bytes ng IP header). Pagkatapos, sa ilang sandali, ganap nilang harangan ang gawain ng adapter ng network, dahil dapat silang ipadala nang magkasama at sabay-sabay. Bilang resulta, hahantong ito sa isang priority jump, at ang mga packet tulad ng VoIP, halimbawa, ay ipipila.
Kaya, ang mataas na throughput na matapang na inaangkin ng WireGuard ay nakakamit sa halaga ng pagpapabagal sa networking ng iba pang mga application. At ang koponan ng WireGuard ay na ito ang aking konklusyon.
Ngunit magpatuloy tayo.
Ayon sa mga benchmark sa teknikal na dokumentasyon, ang koneksyon ay nagpapakita ng throughput na 1011 Mbps.
Kahanga-hanga.
Ito ay lalo na kahanga-hanga dahil sa ang katunayan na ang maximum na theoretical throughput ng isang solong Gigabit Ethernet na koneksyon ay 966 Mbps na may laki ng packet na 1500 bytes minus 20 bytes para sa IP header, 8 bytes para sa UDP header at 16 bytes para sa header ng ang WireGuard mismo. May isa pang IP header sa encapsulated packet at isa pa sa TCP para sa 20 bytes. Kaya saan nagmula ang sobrang bandwidth na ito?
Sa malalaking frame at mga benepisyo ng GSO na napag-usapan natin sa itaas, ang maximum na teoretikal para sa laki ng frame na 9000 bytes ay magiging 1014 Mbps. Karaniwan ang ganitong throughput ay hindi matamo sa katotohanan, dahil ito ay nauugnay sa malalaking paghihirap. Kaya, maaari ko lamang ipagpalagay na ang pagsubok ay isinagawa gamit ang mas mataba na malalaking frame na 64 kilobytes na may maximum na teoretikal na 1023 Mbps, na sinusuportahan lamang ng ilang mga adapter ng network. Ngunit ito ay ganap na hindi naaangkop sa mga tunay na kondisyon, o maaari lamang gamitin sa pagitan ng dalawang direktang konektadong istasyon, eksklusibo sa loob ng test bench.
Ngunit dahil ang VPN tunnel ay ipinapasa sa pagitan ng dalawang host gamit ang isang koneksyon sa Internet na hindi sumusuporta sa mga jumbo frame, ang resulta na nakamit sa bench ay hindi maaaring kunin bilang isang benchmark. Isa lamang itong hindi makatotohanang tagumpay sa laboratoryo na imposible at hindi naaangkop sa totoong mga kondisyon ng labanan.
Kahit na nakaupo sa data center, hindi ako makapaglipat ng mga frame na mas malaki sa 9000 bytes.
Ang criterion ng applicability sa totoong buhay ay ganap na nilalabag at, tulad ng sa tingin ko, ang may-akda ng "pagsukat" na isinagawa ay seryosong sinisiraan ang kanyang sarili para sa mga malinaw na dahilan.
Huling kislap ng pag-asa
Ang website ng WireGuard ay maraming pinag-uusapan tungkol sa mga lalagyan at nagiging malinaw kung ano talaga ang nilalayon nito.
Isang simple at mabilis na VPN na hindi nangangailangan ng configuration at maaaring i-deploy at i-configure gamit ang napakalaking tool sa orkestra tulad ng Amazon sa kanilang cloud. Sa partikular, ginagamit ng Amazon ang pinakabagong mga tampok ng hardware na nabanggit ko kanina, tulad ng AVX512. Ginagawa ito upang mapabilis ang gawain at hindi matali sa x86 o anumang iba pang arkitektura.
Ino-optimize nila ang throughput at mga packet na mas malaki sa 9000 bytes - ito ay magiging malalaking encapsulated frame para sa mga container na makipag-ugnayan sa isa't isa, o para sa mga backup na operasyon, paggawa ng mga snapshot o pag-deploy ng parehong mga container. Kahit na ang mga dynamic na IP address ay hindi makakaapekto sa pagpapatakbo ng WireGuard sa anumang paraan sa kaso ng senaryo na inilarawan ko.
Mahusay na nilalaro. Napakahusay na pagpapatupad at napakanipis, halos reference na protocol.
Ngunit hindi ito akma sa isang mundo sa labas ng isang data center na ganap mong kinokontrol. Kung magsasaalang-alang ka at magsisimulang gumamit ng WireGuard, kakailanganin mong gumawa ng patuloy na mga kompromiso sa disenyo at pagpapatupad ng protocol ng pag-encrypt.
Pagbubuhos
Madali para sa akin na maghinuha na ang WireGuard ay hindi pa handa.
Ito ay naisip bilang isang magaan at mabilis na solusyon sa ilang mga problema sa mga kasalukuyang solusyon. Sa kasamaang palad, para sa kapakanan ng mga solusyong ito, isinakripisyo niya ang maraming mga tampok na magiging may-katuturan para sa karamihan ng mga gumagamit. Kaya naman hindi nito mapapalitan ang IPsec o OpenVPN.
Upang maging mapagkumpitensya ang WireGuard, kailangan nitong magdagdag ng hindi bababa sa isang setting ng IP address at isang pagruruta at configuration ng DNS. Malinaw, ito ay para sa mga naka-encrypt na channel.
Ang seguridad ang aking pangunahing priyoridad, at sa ngayon ay wala akong dahilan upang maniwala na ang IKE o TLS ay kahit papaano ay nakompromiso o nasira. Ang modernong pag-encrypt ay suportado sa pareho ng mga ito, at napatunayan na sila ng mga dekada ng operasyon. Dahil lang sa isang bagay na mas bago ay hindi nangangahulugan na ito ay mas mahusay.
Napakahalaga ng interoperability kapag nakikipag-usap ka sa mga third party na ang mga istasyon ay hindi mo kontrolado. Ang IPsec ay ang de facto na pamantayan at sinusuportahan halos lahat ng dako. At nagtatrabaho siya. At gaano man ito hitsura, sa teorya, ang WireGuard sa hinaharap ay maaaring hindi tugma kahit na sa iba't ibang mga bersyon ng sarili nito.
Ang anumang cryptographic na proteksyon ay nasira sa madaling panahon at, nang naaayon, ay dapat palitan o i-update.
Ang pagtanggi sa lahat ng mga katotohanang ito at walang taros na pagnanais na gamitin ang WireGuard upang ikonekta ang iyong iPhone sa iyong home workstation ay isang master class lamang sa pagdikit ng iyong ulo sa buhangin.
Pinagmulan: www.habr.com