WireGuard on saanut paljon huomiota viime aikoina, itse asiassa se on uusi tähti VPN-verkkojen joukossa. Mutta onko hän niin hyvä kuin miltä näyttää? Haluaisin keskustella joistakin havainnoista ja tarkastella WireGuardin toteutusta selittääkseni, miksi IPsecin tai OpenVPN:n korvaaminen ei ole ratkaisu.
Tässä artikkelissa haluaisin kumota joitain myyttejä [WireGuardin ympärillä]. Kyllä, sen lukeminen kestää kauan, joten jos et ole keittänyt itsellesi kuppia teetä tai kahvia, on aika tehdä se. Haluan myös kiittää Peteriä kaoottisten ajatusteni korjaamisesta.
En aseta itselleni tavoitteeksi diskreditoida WireGuardin kehittäjiä, heikentää heidän pyrkimyksiään tai ideoitaan. Heidän tuotteensa toimii, mutta henkilökohtaisesti mielestäni se esitetään täysin eri tavalla kuin se todellisuudessa on - se esitetään korvaavana IPsecille ja OpenVPN:lle, joita itse asiassa ei yksinkertaisesti ole nyt olemassa.
Huomiona haluaisin lisätä, että vastuu WireGuardin sijoittamisesta on siitä puhuneella medialla, ei itse projektilla tai sen tekijöillä.
Linux-ytimestä ei ole viime aikoina ollut juurikaan hyviä uutisia. Joten meille kerrottiin prosessorin hirviömäisistä haavoittuvuuksista, joita ohjelmisto tasoitti, ja Linus Torvalds puhui siitä liian töykeästi ja tylsästi, kehittäjän utilitaristisella kielellä. Aikataulu tai nollatason verkkopino eivät myöskään ole kovin selkeitä aiheita kiiltävälle aikakauslehdelle. Ja tässä tulee WireGuard.
Paperilla kaikki kuulostaa hyvältä: jännittävä uusi tekniikka.
Mutta katsotaanpa sitä hieman tarkemmin.
WireGuard valkoinen paperi
Tämä artikkeli perustuu kirjoittanut Jason Donenfeld. Siellä hän selittää [WireGuardin] käsitteen, tarkoituksen ja teknisen toteutuksen Linux-ytimessä.
Ensimmäinen lause kuuluu:
WireGuard […] pyrkii korvaamaan sekä IPsecin useimmissa käyttötapauksissa että muut suositut käyttäjätila- ja/tai TLS-pohjaiset ratkaisut, kuten OpenVPN, samalla kun ne ovat turvallisempia, tehokkaampia ja helpompia käyttää [työkalu].
Tietenkin kaikkien uusien teknologioiden tärkein etu on niiden helppous [verrattuna edeltäjiin]. Mutta VPN:n pitäisi myös olla tehokas ja turvallinen.
Mitä seuraavaksi?
Jos sanot, että tämä ei ole sitä, mitä tarvitset [VPN:ltä], voit lopettaa lukemisen tähän. Huomautan kuitenkin, että tällaisia tehtäviä on asetettu mille tahansa muulle tunnelointiteknologialle.
Mielenkiintoisin yllä olevasta lainauksesta piilee sanoissa "useimmissa tapauksissa", jotka lehdistö tietysti jätti huomiotta. Ja niin, olemme minne päädyimme tämän huolimattomuuden aiheuttaman kaaoksen vuoksi - tässä artikkelissa.
Korvaako WireGuard [IPsec]-sivustojen välisen VPN:n?
Ei. Ei yksinkertaisesti ole mahdollista, että suuret toimittajat, kuten Cisco, Juniper ja muut, ostaisivat WireGuardin tuotteilleen. He eivät "hyppää ohi kulkeviin juniin" liikkeellä ollessaan, ellei siihen ole suurta tarvetta. Myöhemmin käyn läpi joitakin syitä, miksi he eivät todennäköisesti saa WireGuard-tuotteitaan laivaan, vaikka he haluaisivat.
Viekö WireGuard RoadWarriorini kannettavasta tietokoneestani datakeskukseen?
Ei. Tällä hetkellä WireGuardissa ei ole valtavaa määrää tärkeitä ominaisuuksia toteutettu, jotta se voisi tehdä jotain tällaista. Se ei voi esimerkiksi käyttää dynaamisia IP-osoitteita tunnelipalvelimen puolella, ja tämä yksinään rikkoo tuotteen tällaisen käytön koko skenaarion.
IPFireä käytetään usein halpojen Internet-linkkien, kuten DSL- tai kaapeliyhteyksien, luomiseen. Tämä on järkevää pienille tai keskisuurille yrityksille, jotka eivät tarvitse nopeaa kuitua. [Kääntäjän huomautus: älä unohda, että Venäjä ja jotkin IVY-maat ovat viestinnässä paljon edellä Eurooppaa ja Yhdysvaltoja, koska aloimme rakentaa verkkojamme paljon myöhemmin ja Ethernet- ja valokuituverkkojen myötä. standardia, meidän oli helpompi rakentaa uudelleen. Samoissa EU- tai USA-maissa xDSL-laajakaistayhteys nopeudella 3-5 Mbps on edelleen yleinen normi, ja valokuituyhteys maksaa meidän standardimme mukaan epärealistista rahaa. Siksi artikkelin kirjoittaja puhuu DSL- tai kaapeliyhteydestä normina, ei muinaisista ajoista.] DSL:llä, kaapelilla, LTE:llä (ja muilla langattomilla yhteystavoilla) on kuitenkin dynaamiset IP-osoitteet. Tietenkin joskus ne eivät muutu usein, mutta ne muuttuvat.
Siellä on aliprojekti nimeltä , joka lisää userspace-daemonin tämän puutteen korjaamiseksi. Valtava ongelma yllä kuvatussa käyttäjäskenaariossa on dynaamisen IPv6-osoitteiden paheneminen.
Jakelijan näkökulmasta tämäkään ei näytä kovin hyvältä. Yksi suunnittelutavoitteista oli pitää protokolla yksinkertaisena ja puhtaana.
Valitettavasti tästä kaikesta on itse asiassa tullut liian yksinkertaista ja primitiivistä, joten joudumme käyttämään lisäohjelmistoja, jotta tämä koko suunnittelu olisi elinkelpoinen todellisessa käytössä.
Onko WireGuard niin helppokäyttöinen?
Ei vielä. En väitä, että WireGuard ei koskaan olisi hyvä vaihtoehto tunnelointiin kahden pisteen välillä, mutta toistaiseksi se on vain alfaversio tuotteesta, jonka sen oletetaan olevan.
Mutta mitä hän sitten oikeasti tekee? Onko IPsec todella niin paljon vaikeampi ylläpitää?
Ilmiselvästi ei. IPsec-toimittaja on ajatellut tätä ja toimittaa tuotteensa käyttöliittymän, kuten IPFiren, kanssa.
VPN-tunnelin määrittämiseksi IPsecin kautta tarvitset viisi tietojoukkoa, jotka sinun on syötettävä määritykseen: oma julkinen IP-osoite, vastaanottavan osapuolen julkinen IP-osoite, aliverkot, jotka haluat tehdä julkisiksi. tämä VPN-yhteys ja esijaettu avain. Siten VPN määritetään muutamassa minuutissa ja on yhteensopiva minkä tahansa toimittajan kanssa.
Valitettavasti tässä tarinassa on muutamia poikkeuksia. Jokainen, joka on yrittänyt tunneloida IPsecin kautta OpenBSD-koneeseen, tietää mistä puhun. On olemassa pari kipeämpää esimerkkiä, mutta itse asiassa IPsecin käyttöön on monia, monia muita hyviä käytäntöjä.
Tietoja protokollan monimutkaisuudesta
Loppukäyttäjän ei tarvitse huolehtia protokollan monimutkaisuudesta.
Jos eläisimme maailmassa, jossa tämä oli todellinen huolenaihe käyttäjälle, olisimme päässeet eroon SIP:stä, H.323:sta, FTP:stä ja muista yli kymmenen vuotta sitten luoduista protokollista, jotka eivät toimi hyvin NAT:n kanssa.
On syitä, miksi IPsec on monimutkaisempi kuin WireGuard: se tekee paljon enemmän asioita. Esimerkiksi käyttäjän todennus sisäänkirjautumisella/salasanalla tai SIM-kortilla EAP:lla. Siinä on laajennettu kyky lisätä uutta .
Ja WireGuardilla ei ole sitä.
Ja tämä tarkoittaa, että WireGuard hajoaa jossain vaiheessa, koska yksi kryptografisista primitiiveistä heikkenee tai vaarantuu kokonaan. Teknisen dokumentaation kirjoittaja sanoo näin:
On syytä huomata, että WireGuardilla on kryptografinen mielipide. Siitä puuttuu tietoisesti salausten ja protokollien joustavuus. Jos taustalla olevista primitiiveistä löytyy vakavia reikiä, kaikki päätepisteet on päivitettävä. Kuten näet jatkuvasta SLL/TLS-haavoittuvuuksista, salauksen joustavuus on nyt lisääntynyt valtavasti.
Viimeinen lause on täysin oikea.
Konsensuksen saavuttaminen käytettävästä salauksesta tekee protokollista, kuten IKE:n ja TLS:n lisää monimutkainen. Liian monimutkainen? Kyllä, haavoittuvuudet ovat melko yleisiä TLS/SSL:ssä, eikä niille ole vaihtoehtoa.
Todellisten ongelmien huomioimatta jättämisestä
Kuvittele, että sinulla on VPN-palvelin, jossa on 200 taisteluasiakasta jossain päin maailmaa. Tämä on melko tavallinen käyttötapaus. Jos sinun on vaihdettava salausta, sinun on toimitettava päivitys kaikkiin WireGuard-kopioihin näissä kannettavissa tietokoneissa, älypuhelimissa ja niin edelleen. Samanaikaisesti toimittaa. Se on kirjaimellisesti mahdotonta. Ylläpitäjillä, jotka yrittävät tehdä tätä, vaadittujen kokoonpanojen käyttöönotto vie kuukausia, ja keskisuurelta yritykseltä kestää kirjaimellisesti vuosia saada tällainen tapahtuma.
IPsec ja OpenVPN tarjoavat salausneuvotteluominaisuuden. Siksi jonkin aikaa, jonka jälkeen otat uuden salauksen käyttöön, myös vanha toimii. Näin nykyiset asiakkaat voivat päivittää uuteen versioon. Kun päivitys on julkaistu, poistat vain haavoittuvan salauksen käytöstä. Ja siinä se! Valmis! sinä olet upea! Asiakkaat eivät edes huomaa.
Tämä on itse asiassa hyvin yleinen tapaus suurille käyttöönotuksille, ja jopa OpenVPN:llä on vaikeuksia tämän kanssa. Taaksepäin yhteensopivuus on tärkeää, ja vaikka käytät heikompaa salausta, monille tämä ei ole syy yrityksen sulkemiseen. Koska se lamauttaa satojen asiakkaiden työn kyvyttömyyden vuoksi tehdä työtään.
WireGuard-tiimi on tehnyt protokollansa yksinkertaisemmiksi, mutta täysin käyttökelvottomaksi ihmisille, joilla ei ole jatkuvaa hallintaa molempiin tunneliinsa. Kokemukseni mukaan tämä on yleisin skenaario.
Kryptografia!
Mutta mikä on tämä mielenkiintoinen uusi salaus, jota WireGuard käyttää?
WireGuard käyttää Curve25519:ää avainten vaihtoon, ChaCha20:tä salaukseen ja Poly1305:tä tietojen todentamiseen. Se toimii myös SipHashin kanssa hajautusavaimia varten ja BLAKE2:n kanssa hajautusavaimia varten.
ChaCha20-Poly1305 on standardoitu IPsecille ja OpenVPN:lle (TLS:n yli).
On selvää, että Daniel Bernsteinin kehitystä käytetään hyvin usein. BLAKE2 on BLAKEn seuraaja, SHA-3-finalisti, joka ei voittanut, koska se on samankaltainen kuin SHA-2. Jos SHA-2 rikkoutuisi, oli hyvä mahdollisuus, että myös BLAKE vaarantuisi.
IPsec ja OpenVPN eivät tarvitse SipHashia suunnittelunsa vuoksi. Joten ainoa asia, jota ei voi tällä hetkellä käyttää niiden kanssa, on BLAKE2, ja se on vain kunnes se on standardoitu. Tämä ei ole suuri haitta, koska VPN:t käyttävät HMAC:ia luomaan eheyttä, jota pidetään vahvana ratkaisuna myös MD5:n yhteydessä.
Joten tulin siihen tulokseen, että lähes samoja salaustyökaluja käytetään kaikissa VPN:issä. Siksi WireGuard ei ole enemmän tai vähemmän turvallinen kuin mikään muu nykyinen tuote, mitä tulee salaukseen tai lähetettyjen tietojen eheyteen.
Mutta tämäkään ei ole tärkein asia, johon kannattaa kiinnittää huomiota projektin virallisen dokumentaation mukaan. Loppujen lopuksi pääasia on nopeus.
Onko WireGuard nopeampi kuin muut VPN-ratkaisut?
Lyhyesti: ei, ei nopeammin.
ChaCha20 on stream-salaus, joka on helpompi toteuttaa ohjelmistossa. Se salaa bitin kerrallaan. Lohkoprotokollat, kuten AES, salaavat lohkon 128 bittiä kerrallaan. Laitteistotuen toteuttamiseen tarvitaan paljon enemmän transistoreita, joten suuremmissa prosessoreissa on AES-NI, käskysarjalaajennus, joka suorittaa joitakin salausprosessin tehtäviä sen nopeuttamiseksi.
Odotettiin, että AES-NI ei koskaan pääsisi älypuhelimiin [mutta se tapahtui - noin. per.]. Tätä varten ChaCha20 kehitettiin kevyeksi, akkua säästäväksi vaihtoehdoksi. Siksi voi olla uutinen sinulle, että jokaisessa älypuhelimessa, jonka voit ostaa tänään, on jonkinlainen AES-kiihtyvyys ja se toimii nopeammin ja pienemmällä virrankulutuksella tällä salauksella kuin ChaCha20:lla.
Ilmeisesti lähes jokaisessa parin viime vuoden aikana ostetussa työpöytä-/palvelinprosessorissa on AES-NI.
Siksi odotan AES:n ylittävän ChaCha20:n kaikissa skenaarioissa. WireGuardin virallisessa dokumentaatiossa mainitaan, että AVX512:lla ChaCha20-Poly1305 ylittää AES-NI:n, mutta tämä ohjesarjalaajennus on saatavilla vain suuremmissa prosessoreissa, mikä ei taaskaan auta pienemmille ja mobiililaitteille, jotka ovat aina nopeampia AES:n kanssa. - N.I.
En ole varma, olisiko tämä voitu ennakoida WireGuardin kehittämisen aikana, mutta nykyään se, että se on naulattu yksinomaan salaukseen, on jo haittapuoli, joka ei välttämättä vaikuta sen toimintaan kovin hyvin.
IPsec antaa sinun valita vapaasti, mikä salaus sopii parhaiten sinun tapauksellesi. Ja tietysti tämä on välttämätöntä, jos esimerkiksi haluat siirtää 10 gigatavua tai enemmän dataa VPN-yhteyden kautta.
Integrointiongelmat Linuxissa
Vaikka WireGuard on valinnut modernin salausprotokollan, tämä aiheuttaa jo paljon ongelmia. Ja niin sen sijaan, että käytettäisiin ytimen tukemaa järjestelmää, WireGuardin integrointi on viivästynyt vuosia näiden primitiivien puutteen vuoksi Linuxissa.
En ole täysin varma, mikä tilanne on muissa käyttöjärjestelmissä, mutta se ei luultavasti ole paljon erilainen kuin Linuxissa.
Miltä todellisuus näyttää?
Valitettavasti joka kerta kun asiakas pyytää minua luomaan VPN-yhteyden heille, törmään ongelmaan, että he käyttävät vanhentuneita tunnistetietoja ja salausta. 3DES yhdessä MD5:n kanssa on edelleen yleinen käytäntö, samoin kuin AES-256 ja SHA1. Ja vaikka jälkimmäinen on hieman parempi, tätä ei pitäisi käyttää vuonna 2020.
Avainten vaihtoon aina Käytetään RSA:ta - hidasta mutta melko turvallista työkalua.
Asiakkaani ovat yhteydessä tulliviranomaisiin ja muihin valtion organisaatioihin ja instituutioihin sekä suuriin yrityksiin, joiden nimet tunnetaan kaikkialla maailmassa. He kaikki käyttävät vuosikymmeniä sitten luotua pyyntölomaketta, eikä mahdollisuutta käyttää SHA-512:ta yksinkertaisesti lisätty. En voi sanoa, että se jotenkin selvästi vaikuttaisi tekniseen kehitykseen, mutta ilmeisesti se hidastaa yritysprosessia.
Minua harmittaa nähdä tämä, koska IPsec on tukenut elliptisiä käyriä suoraan vuodesta 2005 lähtien. Curve25519 on myös uudempi ja käytettävissä. AES:lle on myös vaihtoehtoja, kuten Camellia ja ChaCha20, mutta kaikki eivät tietenkään tue suuret toimittajat, kuten Cisco ja muut.
Ja ihmiset käyttävät sitä hyväkseen. On olemassa monia Cisco-sarjoja, monia sarjoja, jotka on suunniteltu toimimaan Ciscon kanssa. He ovat markkinajohtajia tässä segmentissä eivätkä ole kovin kiinnostuneita minkäänlaisesta innovaatiosta.
Kyllä, tilanne [yrityssegmentissä] on kauhea, mutta emme näe mitään muutoksia WireGuardin takia. Toimittajat eivät todennäköisesti koskaan näe suorituskykyongelmia jo käyttämiensä työkalujen ja salauksen kanssa, eivät näe ongelmia IKEv2:n kanssa, joten he eivät etsi vaihtoehtoja.
Oletko yleensä koskaan ajatellut Ciscon luopumista?
Vertailuarvot
Ja nyt siirrytään WireGuard-dokumentaation vertailuarvoihin. Vaikka tämä [dokumentaatio] ei ole tieteellinen artikkeli, odotin silti kehittäjien ottavan tieteellisemmän lähestymistavan tai käyttävän tieteellistä lähestymistapaa viitteenä. Vertailuarvot ovat hyödyttömiä, jos niitä ei voida toistaa, ja vielä hyödyttömiä, kun ne hankitaan laboratoriossa.
WireGuardin Linux-koontiversiossa se hyödyntää GSO:n - Generic Segmentation Offloading -käyttöä. Hänen ansiosta asiakas luo valtavan 64 kilotavun paketin ja salaa / purkaa sen yhdellä kertaa. Näin ollen salaustoimintojen kutsumisen ja toteuttamisen kustannukset pienenevät. Jos haluat maksimoida VPN-yhteytesi suorituskyvyn, tämä on hyvä idea.
Mutta kuten tavallista, todellisuus ei ole niin yksinkertainen. Näin suuren paketin lähettäminen verkkosovittimeen vaatii sen leikkaamisen useiksi pienemmiksi paketeiksi. Normaali lähetyskoko on 1500 tavua. Eli 64 kilotavun jättiläisemme jaetaan 45 pakettiin (1240 tavua tietoa ja 20 tavua IP-otsikkoa). Sitten ne estävät jonkin aikaa kokonaan verkkosovittimen toiminnan, koska ne on lähetettävä yhdessä ja kerralla. Seurauksena on, että tämä johtaa prioriteettihypyyn, ja paketit, kuten esimerkiksi VoIP, joutuvat jonoon.
Näin ollen WireGuardin niin rohkeasti väittämä korkea suorituskyky saavutetaan muiden sovellusten verkottumisen hidastumisella. Ja WireGuard-tiimi on jo tämä on minun päätelmäni.
Mutta mennään eteenpäin.
Teknisen dokumentaation vertailuarvojen mukaan yhteyden suorituskyky on 1011 Mbps.
Vaikuttava.
Tämä on erityisen vaikuttavaa johtuen siitä, että yhden Gigabit Ethernet -yhteyden teoreettinen enimmäiskapasiteetti on 966 Mbps pakettikoon ollessa 1500 tavua miinus 20 tavua IP-otsikolle, 8 tavua UDP-otsikolle ja 16 tavua itse WireGuard. Kapseloidussa paketissa on vielä yksi IP-otsikko ja toinen TCP:ssä 20 tavua varten. Mistä tämä ylimääräinen kaistanleveys sitten tuli?
Valtavilla kehyksillä ja GSO:n eduilla, joista puhuimme edellä, teoreettinen maksimi 9000 tavun kehyskoon olisi 1014 Mbps. Yleensä tällaista läpimenoa ei voida saavuttaa todellisuudessa, koska siihen liittyy suuria vaikeuksia. Näin ollen voin vain olettaa, että testi tehtiin käyttämällä vieläkin paksumpia ylisuuria, 64 kilotavuisia kehyksiä teoreettisella maksiminopeudella 1023 Mbps, jota tukevat vain jotkut verkkosovittimet. Mutta tämä on täysin soveltumaton todellisissa olosuhteissa tai sitä voidaan käyttää vain kahden suoraan yhdistetyn aseman välillä, yksinomaan testipenkissä.
Mutta koska VPN-tunneli välitetään kahden isännän välillä käyttäen Internet-yhteyttä, joka ei tue jumbo-kehyksiä ollenkaan, benkillä saavutettua tulosta ei voida ottaa vertailukohtana. Tämä on yksinkertaisesti epärealistinen laboratorion saavutus, joka on mahdotonta ja käyttökelvoton todellisissa taisteluolosuhteissa.
En pystynyt siirtämään yli 9000 tavua suurempia kehyksiä edes konesalissa istuessani.
Todellisessa elämässä sovellettavuuskriteeriä rikotaan ehdottomasti ja, kuten uskon, suoritetun "mittauksen" kirjoittaja huononsi itsensä vakavasti ilmeisistä syistä.
Viimeinen toivon pilkahdus
WireGuard-verkkosivustolla puhutaan paljon konteista ja käy selväksi, mihin se todella on tarkoitettu.
Yksinkertainen ja nopea VPN, joka ei vaadi konfigurointia ja joka voidaan ottaa käyttöön ja määrittää massiivisilla orkestrointityökaluilla, kuten Amazonilla on pilvessä. Erityisesti Amazon käyttää viimeisimpiä aiemmin mainitsemiani laitteisto-ominaisuuksia, kuten AVX512. Tämä tehdään työn nopeuttamiseksi, eikä se ole sidottu x86:een tai mihinkään muuhun arkkitehtuuriin.
Ne optimoivat suorituskyvyn ja yli 9000 tavua suuremmat paketit – nämä ovat valtavia kapseloituja kehyksiä säiliöiden toistensa kanssa kommunikointiin tai varmuuskopiointiin, tilannekuvien luomiseen tai samojen säiliöiden käyttöönottoon. Edes dynaamiset IP-osoitteet eivät vaikuta WireGuardin toimintaan millään tavalla kuvaamassani tilanteessa.
Hyvin pelattu. Loistava toteutus ja erittäin ohut, melkein referenssiprotokolla.
Mutta se ei vain sovi täysin hallitsemaasi datakeskuksen ulkopuolelle. Jos otat riskin ja aloitat WireGuardin käytön, joudut jatkuvasti tekemään kompromisseja salausprotokollan suunnittelussa ja toteutuksessa.
johtopäätös
Minun on helppo päätellä, että WireGuard ei ole vielä valmis.
Se suunniteltiin kevyeksi ja nopeaksi ratkaisuksi useisiin olemassa olevien ratkaisujen ongelmiin. Valitettavasti hän uhrasi näiden ratkaisujen vuoksi monia ominaisuuksia, jotka ovat tärkeitä useimmille käyttäjille. Siksi se ei voi korvata IPsecia tai OpenVPN:ää.
Jotta WireGuardista tulee kilpailukykyinen, sen on lisättävä vähintään IP-osoiteasetus sekä reititys- ja DNS-kokoonpano. On selvää, että salatut kanavat ovat tätä varten.
Turvallisuus on tärkein prioriteettini, eikä minulla tällä hetkellä ole mitään syytä uskoa, että IKE tai TLS olisi jotenkin vaarantunut tai rikki. Molemmissa tuetaan modernia salausta, ja ne on todistettu vuosikymmenten toiminnalla. Se, että jokin on uudempaa, ei tarkoita, että se olisi parempi.
Yhteentoimivuus on erittäin tärkeää, kun kommunikoit kolmansien osapuolten kanssa, joiden asemia et hallitse. IPsec on de facto -standardi, ja sitä tuetaan melkein kaikkialla. Ja hän työskentelee. Ja riippumatta siitä, miltä se näyttää, teoriassa WireGuard ei ehkä tulevaisuudessa ole yhteensopiva edes eri versioiden kanssa.
Mikä tahansa kryptografinen suojaus rikkoutuu ennemmin tai myöhemmin ja on vastaavasti vaihdettava tai päivitettävä.
Kaikkien näiden tosiasioiden kieltäminen ja sokea halu käyttää WireGuardia iPhonen liittämiseen kotityöasemaan on vain mestarikurssi pään hiekkaan pistämisessä.
Lähde: will.com