Pēdējā laikā WireGuard piesaista lielu uzmanību, faktiski — tas ir jauna "zvaigzne" starp VPN. Bet vai tas tiešām ir tik labs, kā šķiet? Es vēlētos apspriest dažus novērojumus un izskatīt WireGuard īstenošanu, lai pastāstītu, kāpēc tas nav risinājums, kas varētu aizvietot IPsec vai OpenVPN.
Šajā rakstā es vēlētos atspēkot dažus mītus [ap WireGuard]. Jā, būs jālasa ilgi, tāpēc, ja vēl neesat uzvārījis sev tasi tējas vai kafijas, tad ir īstais laiks to izdarīt. Vēlos pateikt paldies Piteram par manu haotisko domu labojumiem.
Es neuzstāju, ka mērķis ir diskreditēt WireGuard izstrādātājus, novērtēt viņu centienus vai idejas. Viņu produkts ir funkcionāls, bet personīgi uzskatu, ka tas tiek pasniegts pilnīgi ne tā, kā tam patiesībā ir jābūt — tas tiek prezentēts kā IPsec un OpenVPN aizvietotājs, kura patiesībā šobrīd vienkārši nepastāv.
Kā piezīmi var mākt piebilst, ka atbildība par šādu WireGuard pozicionēšanu gulstas uz medijiem, kas par to runāja, nevis pašu projektu vai tā veidotājiem.
Pēdējā laikā par Linux kodolu nav bijis pārāk daudz labu ziņu. Tātad mums tika pastāstīts par briesmīgām procesora ievainojamībām, kas tika novērstas programmatiskā veidā, un Linuss Torvalds par to runāja pārāk rupji un garlaicīgi, izmantojot izstrādātāja utilitāro valodu. Plānotājs vai nulles līmeņa tīkla kaudze arī nav pārāk saprotamas tēmas spīguļojošiem žurnāliem. Un te parādās WireGuard.
Papīrā viss izklausās lieliski: pārsteidzoša jauna tehnoloģija.
Bet aplūkosim to nedaudz tuvāk.
WireGuard tehniskā dokumentācija
Šis raksts balstās uz oficiālo WireGuard dokumentāciju, ko uzrakstījis Džeisons Donenfīlds. Tur viņš skaidro koncepciju, mērķi un tehnisko īstenošanu [WireGuard] Linux kodolā.
Pirmais teikums saka:
WireGuard […] mēģina aizvietot gan IPsec lielākajā daļā tā lietojuma gadījumu, gan citus populārus risinājumus, kas balstīti uz lietotāja telpu un/vai TLS, piemēram, OpenVPN, tajā pašā laikā būdams drošāks, ātrāks un vieglāk lietojams [rīks].
Protams, galvenā priekšrocība visām jaunajām tehnoloģijām ir to vienkāršība [salīdzinājumā ar priekšgājējiem]. Bet VPN arī jābūt efektīvs un drošs.
Un kas tālāk?
Ja jūs sakāt, ka jums [no VPN] nav nepieciešams tas, tad šo lasīšanu var beigt. Tomēr es norādīšu, ka šādas problēmas tiek izvirzītas jebkurai citai tunelēšanas tehnoloģijai.
Interesantākais no iepriekš citētā teikuma ir vārdi „lielākajā daļā gadījumu”, kurus, protams, prese ignorēja. Un tā, mēs esam tur, kur nonācām šī neuzmanības radītā haosa dēļ — šajā rakstā.
Vai WireGuard būs aizstājējs manai [IPsec] VPN savienojumam starp vietnēm?
Nē. Šajā gadījumā vienkārši nav izredžu, ka lieli piegādātāji, piemēram, Cisco, Juniper un citi, iegādāsies WireGuard saviem produktiem. Viņi neizlemj „lēkt garām pa ceļam” bez kādas lielas nepieciešamības. Vēlāk es pastāstīšu par dažiem iemesliem, kāpēc viņi, iespējams, nespēs iekļaut WireGuard savos produktos, pat ja vēlētos.
Vai WireGuard pārvietos manu RoadWarrior no klēpjdatora uz datu centru?
Nē. Šobrīd WireGuard nav ieviests liels skaits svarīgu funkciju, lai tas varētu veikt kaut ko līdzīgu. Piemēram, tas nevar izmantot dinamisku IP adresi tunelēšanas servera pusē, un jau tas izjauc visu šāda produkta lietošanas scenāriju.
IPFire bieži izmanto lētiem interneta kanāliem, piemēram, DSL vai kabelim. Tas ir pamatots mazajam vai vidējam biznesam, kam nav nepieciešams ātrs optiskais šķiedras savienojums. [Tulkošanas piezīme: nevajadzētu aizmirst, ka sakaru jomā Krievija un dažas CIS valstis ir tālu priekšā Eiropai un ASV, jo mēs sākām būvēt savas tīklas daudz vēlāk un, nonākot pie Ethernet un optiskās šķiedras tīkliem kā standarta, mums bija vieglāk pārbūvēt. Tajās pašās ES vai ASV valstīs xDSL platjoslas pieslēgums ar ātrumu 3-5 Mbit/s — joprojām ir vispārēja norma, bet optiskās šķiedras pieslēgums maksā nereālas naudas summas pēc mūsu mērogiem. Tāpēc raksta autors runā par DSL vai kabeļa pieslēgumiem kā normu, nevis novecojušu tehnoloģiju.] Tomēr DSL, kabeļu, LTE (un citi bezvadu piekļuves veidi) ir dinamiskas IP adreses. Protams, tās dažreiz nemainās bieži, bet, tomēr, tās mainās.
Ir apakšprojekts ar nosaukumu „wg-dynamic”, kas pievieno lietotāja telpas demonstrušanu, lai pārvarētu šo trūkumu. Liela problēma ar iepriekš aprakstīto lietotāju scenāriju ir situācijas pasliktināšanās, ko izraisa dinamiskā IPv6 adresēšana.
No izplatītāja viedokļa viss tas arī neizskatās ļoti labi. Viens no izstrādes mērķiem bija saglabāt protokola vienkāršību un tīrību.
Diemžēl viss patiešām ir kļuvis pārāk vienkāršs un primitīvs, tāpēc mums jāizmanto papildu programmatūra, lai viss šis veidojums būtu dzīvotspējīgs reālajā ekspluatācijā.
Vai WireGuard ir tik vienkārši lietojams?
Pagājušajā laikā nē. Es nesaku, ka WireGuard nekad nebūs laba alternatīva tuneļa izveidei starp divām punktiem, bet pagaidām tas ir tikai produkta alfa versija, par kuru tam vajadzētu kļūt.
Bet ko tad tas patiesībā dara? Vai IPsec tiešām ir tik daudz sarežģītāka ekspluatācijā?
Acīmredzot nē. IPsec sniedzējs ir padomājis par šo aspektu un piegādā savu produktu kopā ar saskarni, piemēram, ar IPFire.
Lai konfigurētu VPN tuneli caur IPsec, jums būs nepieciešami pieci datu kopumi, kurus jāievada konfigurācijā: jūsu publiskā IP adrese, saņemšanas puses publiskā IP adrese, apakštīkli, kurus vēlaties padarīt publiskus caur šo VPN savienojumu, un iepriekš koplietots atslēgas. Tādējādi VPN tiek iestatīts dažu minūšu laikā, un tas ir saderīgs ar jebkuru piegādātāju.
Diemžēl šajā stāstā ir daži izņēmumi. Ikviens, kurš ir mēģinājis izveidot VPN tuneli caur IPsec uz mašīnu ar OpenBSD, sapratīs, par ko es runāju. Ir vēl pāris sāpīgu piemēru, bet tiešām pozitīvās IPsec lietošanas prakses ir daudz un daudz vairāk.
Par protokola sarežģītību
Pēdējais patērētājs nedrīkst uztraukties par protokola sarežģītību.
Ja mēs dzīvotu pasaulē, kur tas būtu reāls lietotāja uztraukums, mēs jau sen būtu atbrīvojušies no SIP, H.323, FTP un citiem protokoliem, kas radīti vairāk nekā pirms desmit gadiem un kas slikti darbojas ar NAT.
Ir iemesli, kādēļ IPsec ir sarežģītāks nekā WireGuard: tas veic daudz vairāk darbību. Piemēram, lietotāja autentifikācija, izmantojot lietotāja vārdu/paroli vai SIM karti ar EAP. Tam ir paplašināta iespēja pievienot jaunus kriptogrāfiskos primitīvus.
Un WireGuard tam nav.
Un tas nozīmē, ka WireGuard kādā brīdī sabojāsies, jo viens no kriptogrāfiskajiem primitiviem vājinās vai tiks pilnībā apdraudēts. Tehniskās dokumentācijas autors to norāda šādi:
Vērts atzīmēt, ka WireGuard ir pārmērīgi pašpārliecināts no kriptogrāfiskā viedokļa. Tam apzināti trūkst šifrēšanas un protokolu elastības. Ja pamatā esošajos primitivos tiks atrastas nopietnas ievainojamības, visām beigām jāveic atjaunināšana. Kā redzams no nepārtrauktā SLL/TLS ievainojamību plūsmas, šifrēšanas elastība tagad ir ievērojami palielinājusies.
Pēdējais apgalvojums ir absolūti pareizs.
Sasniegt konsensu par to, kādu šifrēšanu lietot, padara IKE un TLS protokolus vairāk nekā grūti. Pārāk grūti? Jā, TLS/SSL ievainojamības tiek konstatētas diezgan bieži, un nav alternatīvu.
Par reālo problēmu ignorēšanu
Iedomājieties, ka jums ir VPN servers ar 200 aktīviem klientiem, kas izkaisīti pa visu pasauli. Tas ir diezgan standarta lietošanas scenārijs. Ja jums nāksies mainīt šifrēšanu, jums būs jānosūta atjauninājums uz visām WireGuard kopijām šajos klēpjdatoros, viedtālruņos utt. Vienlaikus piegādāt. Tas ir burtiski neiespējami. Administratoriem, kuri mēģinās to izdarīt, būs nepieciešami mēneši, lai izvērstu nepieciešamās konfigurācijas, un vidējām uzņēmumiem tieši būs nepieciešami gadi, lai veiktu šādu pasākumu.
IPsec un OpenVPN piedāvā šifrēšanas saskaņošanas funkciju. Tādējādi noteiktu laiku, kamēr jūs aktivizējat jauno šifrēšanu, darbosies arī vecā. Pateicoties tam, esošie klienti varēs atjaunināties uz jauno versiju. Pēc tam, kad atjauninājums tiks izplatīts, jūs vienkārši izslēgsiet ievainojamo šifrēšanu. Un viss! Gatavs! Jūs esat brīnišķīgi! Un klienti to pat nepamanīs.
Patiesībā tas ir ļoti izplatīts gadījums lielos izvēršanas projektos, un pat OpenVPN ar to saskaras ar dažām grūtībām. Atpakaļsaderība ir svarīga, un, lai arī jūs izmantojat vāju šifrēšanu, daudziem tas nenovērš biznesa slēgšanu. Jo tas novedīs pie simtiem klientu darba paralizēšanas, jo viņi nespēs veikt savu darbu.
WireGuard komanda ir padarījusi savu protokolu vienkāršāku, bet pilnībā nepiemērotu cilvēkiem, kuriem nav pastāvīgas kontroles pār abiem savas tunela galiem. Mans pieredze liecina, ka šāds scenārijs ir visizplatītākais.
Kryptogrāfija!
Bet kas tas ir par interesanto jauno šifrēšanu, ko izmanto WireGuard?
WireGuard izmanto Curve25519 atslēgu apmaiņai, ChaCha20 šifrēšanai un Poly1305 datu autentifikācijai. Tas arī strādā ar SipHash atslēgu hašēšanai un BLAKE2 hašēšanai.
ChaCha20-Poly1305 ir standartizēts IPsec un OpenVPN (caur TLS).
Acīmredzami, ka Daniela Bernšteina izstrādājums ir ļoti bieži izmantots. BLAKE2 ir BLAKE pēctecis, kas bija SHA-3 finālists, bet neuzvarēja dēļ līdzības ar SHA-2. Ja SHA-2 tiktu salauzts, pastāvēja liela varbūtība, ka arī BLAKE tiktu kompromitēts.
IPsec un OpenVPN neizmantot SipHash dēļ sava dizaina. Tādējādi vienīgais, kas šobrīd nevar tikt izmantots ar tiem, ir BLAKE2, un tas tikai līdz tam, kamēr tas tiks standartizēts. Tas nav liels trūkums, jo VPN izmanto HMAC, lai nodrošinātu integritāti, kas tiek uzskatīta par spēcīgu risinājumu pat kopā ar MD5.
Tādējādi es nonācu pie secinājuma, ka gandrīz visa VPN izmanto praktiski to pašu kriptogrāfisko rīku komplektu. Tādējādi WireGuard nav drošāks vai mazāk drošs par jebkuriem citiem aktuāliem produktiem, kad runa ir par datu šifrēšanu vai integritāti.
Tomēr pat tas nav galvenais, uz ko jāpievērš uzmanība saskaņā ar projekta oficiālo dokumentāciju. Galvenais ir ātrums.
Vai WireGuard ir ātrāks par citiem VPN risinājumiem?
Ja īsi: nē, tas nav ātrāks.
ChaCha20 ir plūsmas šifrētājs, kas ir vieglāk integrējams programmatūrā. Tas šifrē vienu bitu vienlaikus. Bloku protokoli, piemēram, AES, šifrē 128 bitu blokā vienlaikus. Lai īstenotu aparatūras atbalstu, būs nepieciešams daudz vairāk tranzistoru, tāpēc lielāki procesori tiek piedāvāti ar AES-NI - komandu kopas paplašinājumu, kas veic dažus šifrēšanas procesa uzdevumus, lai to paātrinātu.
Tika bija gaidāms, ka AES-NI nekad nonāks viedtālruņos [bet tas ir noticis, — piezīme tulkotājam]. Tāpēc ChaCha20 tika izstrādāts kā viegla un ekonomiska alternatīva, kas saudzē akumulatoru. Tāpēc jums var būt jaunums, ka katrs viedtālrunis, ko šodien varat iegādāties, ir aprīkots ar kādu AES paātrinājumu un ar šo šifrēšanu strādā ātrāk un ar mazāku enerģijas patēriņu nekā ar ChaCha20.
Acīmredzot praktiski katram galddatoru vai serveru procesoram, ko iegādājāties pēdējo divu gadu laikā, ir AES-NI.
Tādējādi es sagaidu, ka AES katrā atsevišķā scenārijā pārspēs ChaCha20. Oficiālajā WireGuard dokumentācijā minēts, ka, pateicoties AVX512, ChaCha20-Poly1305 pārspēs AES-NI, bet šis komandu kopas paplašinājums būs pieejams tikai uz lieliem procesoriem, kas atkal nepalīdzēs mazākiem un mobilajiem aprīkojumiem, kuri vienmēr darbosies ātrāk ar AES-NI.
Nezinu, vai to varēja paredzēt, izstrādājot WireGuard, bet šodien ir acīmredzams, ka tas ir pieķēries vienai šifrēšanai — tas jau ir trūkums, kas var nelabvēlīgi ietekmēt tā darbību.
IPsec ļauj brīvi izvēlēties, kura šifrēšana vislabāk atbilst jūsu vajadzībām. Un, protams, tas ir nepieciešams, ja, piemēram, vēlaties pārsūtīt 10 un vairāk gigabaitus datu caur VPN savienojumu.
Integrācijas problēmas Linux sistēmās
Lai gan WireGuard izvēlējās mūsdienīgu šifrēšanas protokolu, tas jau rada daudz problēmu. Un tā vietā, lai izmantotu to, kas tiek atbalstīts kodolā no kastes, WireGuard integrācija tika atlikta gadiem ilgi dēļ šo primitīvu trūkuma Linux.
Es neesmu pilnībā informēts par situāciju citās operētājsistēmās, bet iespējams, ka tā būtiski neatšķiras no Linux situācijas.
Kā izskatās realitāte?
Diemžēl katru reizi, kad klients lūdz mani iestatīt viņam VPN savienojumu, es saskaros ar to, ka viņi izmanto novecojušus akreditācijas datus un šifrēšanu. 3DES, apvienojumā ar MD5, joprojām ir izplatīta prakse, tāpat kā AES-256 un SHA1. Un, lai gan pēdējais ir nedaudz labāks — tas nav tas, ar ko vajadzētu izmantot 2020. gadā.
Atslēgu apmaiņai vienmēr tiek izmantots RSA — lēns, bet pietiekami drošs rīks.
Mani klienti ir saistīti ar muitas iestādēm un citām valsts institūcijām, kā arī ar lielām korporācijām, kuru nosaukumi ir pazīstami visā pasaulē. Visi viņi izmanto pieprasījumu veidlapu, kas tika izveidota pirms daudziem gadiem, un iespēja izmantot SHA-512 vienkārši nekad nav pievienota. Es nevaru teikt, ka tas acīmredzami ietekmē tehnoloģisko progresu, bet skaidrs, ka tas kavē korporatīvos procesus.
Man tas sāp redzēt, jo IPsec atbalsta eliptiskās līknes jau kopš 2005. gada. Curve25519 arī ir jaunāka un pieejama izmantošanai. Ir arī AES alternatīvas, piemēram, Camellia un ChaCha20, bet acīmredzot ne visas no tām atbalsta lielie piegādātāji, piemēram, Cisco un citi.
Un cilvēki to izmanto. Ir daudz Cisco komplektu, ir daudz komplektu, kas veidoti darbam ar Cisco. Viņi ir tirgus līderi šajā segmentā un nav ļoti ieinteresēti kādās inovācijās.
Jā, situācija [korporatīvajā segmentā] ir šausmīga, bet mēs neredzēsim nekādas izmaiņas WireGuard dēļ. Ražotāji, visticamāk, nekad neatklās nekādas snieguma problēmas, izmantojot jau esošos rīkus un šifrēšanu, neredzēs problēmas, lietojot IKEv2 — un tāpēc viņi nemeklē alternatīvas.
Vispār, vai jūs kādreiz esat domājuši atteikties no Cisco?
Salīdzinājumi
Tagad pāriesim pie salīdzinājumiem no WireGuard dokumentācijas. Lai gan šī [dokumentācija] nav zinātnisks raksts, es tomēr gaidīju no izstrādātājiem zinātniskāku pieeju vai vismaz zinātniskās pieejas izmantošanu kā standartu. Jebkuri salīdzinājumi ir nederīgi, ja tos nevar reproducēt, un vēl vairāk tie ir nederīgi, ja iegūti laboratorijas apstākļos.
WireGuard izstrādē Linux tas iegūst priekšrocību, izmantojot GSO — Generic Segmentation Offloading. Pateicoties tam, klients izveido milzīgu paketi, kas ir 64 kilobaiti liela, un šifrē/dešifrē to vienā piegājienā. Tādējādi izmaksas kriptogrāfisko operāciju izsaukumam un īstenošanai samazinās. Ja vēlaties optimizēt sava VPN savienojuma caurlaidību — tā ir laba ideja.
Tomēr, kā tas bieži notiek, īstenībā nekas nav tik vienkārši. Šāda liela datu paketa nosūtīšana uz tīkla adapteri prasa, lai tas tiktu sadalīts daudzos mazākos paketiņos. Parastais nosūtīšanas izmērs ir 1500 baitus. Tas nozīmē, ka mūsu milzis 64 kilobaitu apmērā tiks sadalīts 45 paketiņos (1240 baitu informācija un 20 baitu IP virsraksts). Pēc tam, uz kādu laiku, tie pilnībā bloķēs tīkla adaptera darbību, jo tie jānosūta kopā un uzreiz. Rezultātā tas nov leads pie prioritātes pieauguma, un tādi paketi kā, piemēram, VoIP tiks ievietoti gaidīšanas rindā.
Tādējādi augstais caurlaidspēja, par kuru ar lielu pārliecību apgalvo WireGuard, tiek panākta, palēninot citu programmu tīkla darbību. Un WireGuard komanda jau apstiprināja izteica šo manu secinājumu.
Bet pāriesim tālāk.
Saskaņā ar tehniskās dokumentācijas testiem, savienojums rāda caurlaidspēju 1011 Mbit/s.
Iespaidīgi.
Tas ir īpaši iespaidīgi, ņemot vērā, ka maksimālā teorētiskā caurlaidspēja vienai gigabitu Ethernet pieslēgšanai ir 966 Mbit/s, ņemot vērā 1500 baitus paketa izmērā, mīnus 20 baitus IP virsrakstam, 8 baitus UDP virsrakstam un 16 baitus paša WireGuard virsrakstam. Ir arī vēl viens IP virsraksts iekapsulētajā paketē un cits - TCP ar 20 baitiem. No kurienes tad šī papildu caurlaidspēja parādījās?
Ar lieliem datu rāmjiem un iepriekš minēto GSO priekšrocību dēļ teorētiskais maksimālais izmērs 9000 baitus ietvaros būs 1014 Mbit/s. Parasti šāds caurlaidspēja praksē nav sasniedzams, jo tam ir saistīti lielas grūtības. Tādēļ es varu tikai pieņemt, ka tests tika veikts, izmantojot vēl lielākus datus ar pārsniegumu 64 kilobaitu apmērā ar teorētisko maksimālo 1023 Mbit/s, ko atbalsta tikai daži tīkla adapteri. Tomēr tas ir absolūti neieelpojams reālajās situācijās vai var tikt izmantots tikai starp divām tieši savienotām stacijām, izņēmuma kārtā testēšanas ietvaros.
Tomēr, ņemot vērā, ka VPN tunelis tiek veidots starp diviem hostiem, izmantojot interneta savienojumu, kas vispār neatbalsta lielus ietvarus, iegūtais rezultāts nav uztverams kā etalons. Tas ir vienkārši nereāls laboratorijas sasniegums, kas nav realizējams reālajos apstākļos.
Pat atrodoties datu centrā, es nespētu pārsūtīt ietvarus, kuru izmērs pārsniedz 9000 baitus.
Prasība attiecībā uz piemērojamību reālajā dzīvē ir pilnībā pārkāpta, un, manuprāt, veiktā "mērījuma" autora reputācija ir nopietni apdraudēta saprotamu iemeslu dēļ.
Pēdējais cerības mirklis
WireGuard mājaslapā ir daudz runāts par konteineriem, un ir skaidrs, kādam tiešām nolūkam tas ir paredzēts.
Vienkāršs un ātrs VPN, kas neprasa iestatīšanu un var tikt izveidots un konfigurēts ar masu orķestrēšanas rīkiem, piemēram, Amazon viņu mākoņos. Galu galā Amazon izmanto jaunākās aparatūras funkcijas, par kurām es iepriekš minēju, piemēram, AVX512. Tas tiek darīts, lai paātrinātu darbību un nerakstītos pie x86 vai jebkuras citas arhitektūras.
Viņi optimizē joslas platumu un paketes, kuru izmērs pārsniedz 9000 baitus — tas būs milzīgi iepakoti ietvari, lai sazinātos starp konteineriem vai veiktu dublēšanas operācijas, veidojot snapshots vai izvietojot šos pašus konteinerus. Pat dinamiskie IP adreses nekādā veidā neietekmēs WireGuard darbību manā aprakstītajā scenārijā.
Labi nospēlēts. Iespaidīga īstenošana un ļoti smalks, gandrīz etalona protokols.
Tomēr tas vienkārši nav piemērots pasaulei ārpus pilnīgi kontrolēta datu centra. Ja jūs riskējat un sākat izmantot WireGuard, jums būs jādara pastāvīgi kompromisi šifrēšanas protokola izstrādē un īstenošanā.
Izvade
Man nav grūti secināt, ka WireGuard vēl nav gatavs.
Tas tika domāts kā viegls un ātrs risinājums vairāku problēmu dēļ, kas pastāv jau esošajos risinājumos. Diemžēl šo risinājumu dēļ tas ir upurējis daudzus funkcijas, kas būs aktuālas vairumam lietotāju. Tāpēc tas nevar aizstāt IPsec vai OpenVPN.
Lai WireGuard kļūtu konkurētspējīgs, tam ir nepieciešams pievienot vismaz IP adreses iestatījumu un maršrutēšanas un DNS konfigurāciju. Acīmredzami, tieši tam ir nepieciešami šifrētie kanāli.
Drošība ir mana galvenā prioritāte, un šobrīd man nav iemesla domāt, ka IKE vai TLS ir kādā veidā apdraudēti vai uzlauzti. Mūsdienu šifrēšana tiek atbalstīta abos, un tie ir pārbaudīti desmitiem gadu. Ja kaut kas ir jaunāks, tas nenozīmē, ka tas ir labāks.
Funkcionālā saderība ir ārkārtīgi svarīga, sazinoties ar trešām personām, kuru stacijas jūs nekontrolējat. IPsec de facto ir standarts un tiek atbalstīts praktiski visur. Un tas darbojas. Un, lai kā tas izskatītos teorijā, WireGuard nākotnē var nebūt saderīgs pat ar dažādām versijām pašam ar sevi.
Jebkura kriptogrāfiskā aizsardzība agri vai vēlu tiek uzlauzta un attiecīgi jāaizstāj vai jāatjaunina.
Visu šo faktu noliegšana un akls vēlēšanās izmantot WireGuard, lai savienotu jūsu iPhone ar mājas darbvirsmas staciju, ir patiesi meistardarbs galvas ierakšanā smiltīs.
Avots: habr.com
