У апошні час WireGuard прыцягвае да сябе вялікую ўвагу, фактычна – гэта новая "зорка" сярод VPN. Але ці такі ён добры, як здаецца? Я хацеў бы абмеркаваць некаторыя назіранні і разгледзець рэалізацыю WireGuard, каб расказаць, чаму ён не з'яўляецца рашэннем, якое заменіць IPsec або OpenVPN.
У гэтым артыкуле я хацеў бы развянчаць некаторыя міфы [вакол WireGuard]. Так, чытаць давядзецца доўга, так што калі вы яшчэ не заварылі сабе кубачак гарбаты ці кава, той самы час гэта зрабіць. Яшчэ я б хацеў сказаць дзякуй Піцеру за карэктуру маіх хаатычных думак.
Я не стаўлю сабе мэту дыскрэдытаваць распрацоўшчыкаў WireGuard, абясцэніць іх намаганні або ідэі. Іх прадукт – працоўны, але асабіста я лічу, што ён прадстаўлены зусім не тым, чым з'яўляецца насамрэч – прадстаўлены як замена IPsec і OpenVPN, якой насамрэч цяпер проста не існуе.
У якасці заўвагі хочацца дадаць, што адказнасць за такое пазіцыянаванне WireGuard нясуць СМІ, якія пра яго расказвалі, а не сам праект або яго стваральнікі.
У апошні час на тэму ядра Linux было не занадта шмат добрых навін. Так, нам распавялі пра жахлівыя ўразлівасці працэсара, якія былі нівеляваныя праграмным спосабам, а Лінус Торвальдс распавядаў пра гэта занадта груба і сумна, утылітарнай мовай распрацоўніка. Планавальнік або сеткавы стэк нулявога ўзроўню - таксама не занадта зразумелыя тэмы для глянцавых часопісаў. І тут з'яўляецца WireGuard.
На паперы ўсё гучыць выдатна: захапляльная ўяўленне новая тэхналогія.
Але давайце паглядзім на яе крыху больш уважліва.
Тэхнічная дакументацыя WireGuard
Гэты артыкул заснавана на , якую напісаў Джэйсан Даненфельд. Там ён тлумачыць канцэпцыю, мэту і тэхнічную рэалізацыю [WireGuard] у ядры Linux.
Першы сказ абвяшчае:
WireGuard […] імкнецца замяніць як IPsec у большасці кейсаў яго выкарыстання, так іншыя папулярныя рашэнні на аснове карыстацкай прасторы і/ці TLS, такія як OpenVPN, пры гэтым з'яўляючыся больш бяспечным, прадукцыйным і простым у выкарыстанні [інструментам].
Вядома, галоўная добрая якасць усіх новых тэхналогій - гэта іх прастата [у параўнанні з папярэднікамі]. Але VPN таксама павінен быць эфектыўным і бяспечным.
І што далей?
Калі вы скажаце, што вам [ад VPN] трэба не гэта, то на гэтым чытанне можна сканчаць. Аднак я заўважу, што такія задачы ставяцца перад любой іншай тэхналогіяй тунэлявання.
Самае цікавае з прыведзенай вышэй цытаты крыецца ў словах "у большасці выпадкаў", якія, само сабой, прэсай былі праігнараваныя. І вось, мы там, дзе апынуліся з-за створанага гэтай нядбайнасцю хаосу - у гэтым артыкуле.
Ці стане WireGuard заменай маёй [IPsec] VPN-сувязі паміж сайтамі?
Не. Тут проста няма шанцаў, што буйныя вендары, такія як Cisco, Juniper і іншыя набудуць для сваіх прадуктаў WireGuard. Яны не «заскокваюць у міма якія праходзяць цягнікі» на хаду, калі на гэта няма нейкай вялікай неабходнасці. Пазней я раскажу аб некаторых прычынах, па якіх яны, верагодна, не змогуць усталяваць на борт сваіх прадуктаў WireGuard, нават калі б захацелі.
Ці перанясе WireGuard мой RoadWarrior з ноўтбука ў дата-цэнтр?
Не. Прама зараз у WireGuard не рэалізавана велізарная колькасць важных функцый, каб ён змог зрабіць нешта падобнае. Напрыклад, ён не можа выкарыстоўваць дынамічныя IP-адрас на боку сервера тунэля, і ўжо толькі гэта ламае ўвесь сцэнар падобнага выкарыстання прадукта.
IPFire часта выкарыстоўваецца для танных інтэрнэт-каналаў, напрыклад, для DSL ці кабельнага злучэння. Гэта мае сэнс для малога ці сярэдняга бізнэсу, якому не трэба хуткае оптавалакно. [Заўвага ад перакладчыка: не варта забываць, што ў плане сувязі Расія і некаторыя краіны СНД знаходзяцца далёка наперадзе Еўропы і ЗША, таму што мы пачалі будаваць свае сеткі нашмат пазней і з прыходам Ethernet і оптавалакновых сетак у якасці стандарту, нам было прасцей перабудавацца. У тых жа краінах ЕС ці ЗША, xDSL шырокапалосны доступ на хуткасці 3-5 Мбіт / с – да гэтага часу ўсеагульная норма, а оптавалакновае падключэнне варта нейкіх нерэальных па нашых мерках грошай. Таму аўтар артыкула і кажа аб DSL або кабельным падключэнні, як аб норме, а не дрымучай даўніне.] Аднак DSL, кабельныя, LTE (і іншыя бесправадныя метады доступу) маюць дынамічныя IP-адрасы. Вядома, часам яны мяняюцца не часта, але ўсё ж мяняюцца.
Існуе падпраект пад назвай , Які дадае дэман карыстацкай прасторы для пераадолення гэтага недахопу. Велізарная праблема карыстацкага сцэнара, апісанага вышэй - гэта пагаршэнне сітуацыі дынамічнай IPv6-адрасацыяй.
З пункта гледжання дыстрыбутара ўсё гэта таксама выглядае не вельмі. Адна з мэт распрацоўкі была захаваць прастату і чысціню пратакола.
Нажаль, усё гэта насамрэч стала занадта простым і прымітыўным, так што нам прыходзіцца выкарыстаць дадатковае ПА, каб уся гэтая канструкцыя была жыццяздольнай ва ўмовах рэальнай эксплуатацыі.
WireGuard так проста карыстацца?
Пакуль няма. Я не кажу, што WireGuard ніколі не будзе добрай альтэрнатывай для пракіду тунэля паміж двума кропкамі, але пакуль ён – усяго толькі альфа-версія прадукта, якім павінен стаць.
Але што тады насамрэч ён робіць? Ці сапраўды IPsec настолькі складаней у эксплуатацыі?
Відавочна, што не. Пастаўшчык IPsec прадумаў гэты момант і пастаўляе свой прадукт разам з інтэрфейсам, напрыклад, з IPFire.
Для настройкі VPN-тунэля праз IPsec вам спатрэбіцца пяць набораў дадзеных, якія трэба будзе ўнесці ў канфігурацыю: ваш уласны публічны IP-адрас, публічны IP-адрас прымаючага боку, падсеткі, якія вы хочаце зрабіць агульнадаступнымі праз гэта VPN-злучэнне і pre-shared ключ. Такім чынам, VPN наладжваецца на працягу некалькіх хвілін і ён сумяшчальны з любым вендарам.
Нажаль, у гэтай гісторыі ёсць некалькі выключэнняў. Кожны, хто спрабаваў пракінуць VPN-тунэль праз IPsec да машыны на OpenBSD, разумее, пра што я кажу. Ёсць яшчэ пара балючых прыкладаў, але на самой справе станоўчай практыкі выкарыстання IPsec нашмат і нашмат больш.
Аб складанасці пратакола
Канчатковы спажывец не павінен турбавацца аб складанасці пратакола.
Калі б мы жылі ў свеце, дзе гэта было рэальным клопатам юзэра, то мы ўжо даўно пазбавіліся б ад SIP, H.323, FTP і іншых, створаных больш за дзесяць гадоў таму пратаколаў, якія дрэнна працуюць з NAT.
Ёсць чыннікі, па якіх IPsec складаней, чым WireGuard: ён робіць нашмат больш рэчаў. Напрыклад, аўтэнтыфікацыя карыстальніка з выкарыстаннем лагіна/пароля ці SIM-карты з EAP. У яго пашыраная магчымасць дадання новых .
А ў WireGuard гэтага няма.
І гэта азначае, што WireGuard у нейкі момант зламаецца, таму што адзін з крыптаграфічных прымітываў саслабне ці будзе цалкам скампраметаваны. Аўтар тэхдакументацыі кажа пра гэта так:
Варта адзначыць, што WireGuard крыптаграфічна самаўпэўнены. Яму наўмысна не хапае гнуткасці шыфраў і пратаколаў. Калі ў найнізкіх прымітывах будуць выяўленыя сур'ёзныя дзюры, усе канчатковыя кропкі запатрабуецца абнавіць. Як відаць з які працягваецца струменя ўразлівасцяў SLL/TLS, гнуткасць шыфравання цяпер каласальна павялічылася.
Апошняя прапанова абсалютна дакладна.
Дасягненне кансэнсусу на тэму таго, якое шыфраванне выкарыстоўваць, робіць пратаколы тыпу IKE і TLS больш складанымі. Занадта складанымі? Так, у TLS/SSL уразлівасці сустракаюцца досыць часта, і альтэрнатывы ім няма.
Аб ігнараванні рэальных праблем
Уявіце, што ў вас ёсць VPN-сервер з 200 баявымі кліентамі, недзе па ўсім свеце. Гэта суцэль стандартны сцэнар выкарыстання. Калі вам давядзецца мяняць шыфраванне, вам трэба даставіць абнаўленне на ўсе копіі WireGuard на гэтых наўтбуках, смартфонах і гэтак далей. адначасова даставіць. Гэта літаральна немагчыма. Адміністратарам, якія паспрабуюць гэта зрабіць, спатрэбяцца месяцы для разгортвання неабходных канфігурацый, а сярэднім кампаніям літаральна спатрэбяцца гады на правядзенне падобнага мерапрыемства.
IPsec і OpenVPN прапануюць функцыю ўзгаднення шыфраў. Таму некаторы час, пасля якога вы ўключыце новае шыфраванне, будзе працаваць і стары. Дзякуючы гэтаму бягучыя кліенты змогуць абнавіцца да новай версіі. Пасля таго, як абнаўленне будзе раскочана, вы проста выключыце ўразлівае шыфраванне. І ўсё! Гатова! вы цудоўныя! А кліенты гэтага нават не заўважаць.
Насамрэч гэта вельмі распаўсюджаны кейс для вялікіх разгортванняў, і нават OpenVPN адчувае ў гэтым некаторыя цяжкасці. Зваротная сумяшчальнасць важная, і хоць вы карыстаецеся слабейшае шыфраванне, для шматлікіх гэта не становіцца чыннікам зачынення бізнэсу. Таму што гэта прывядзе да паралічу працы сотняў кліентаў з прычыны няздольнасці выконваць сваю працу.
Каманда WireGuard зрабіла свой пратакол прасцей, але зусім непрыдатным для людзей, якія не маюць пастаяннага кантролю над абодвума банкетамі свайго тунэля. На маю вопыту менавіта такі сцэнар - найбольш распаўсюджаны.
Крыптаграфія!
Але што гэта за цікавае новае шыфраванне, якое выкарыстоўвае WireGuard?
WireGuard выкарыстоўвае Curve25519 для абмену ключамі, ChaCha20 для шыфравання і Poly1305 для аўтэнтыфікацыі дадзеных. Таксама ён працуе з SipHash для хэш-ключоў і BLAKE2 для хэшавання.
ChaCha20-Poly1305 стандартызаваны для IPsec і OpenVPN (праз TLS).
Відавочна, што распрацоўка Даніэля Бернштэйна выкарыстоўваецца вельмі часта. BLAKE2 з'яўляецца пераемнікам BLAKE, фіналіста SHA-3, які не выйграў з-за свайго падабенства з SHA-2. Калі б SHA-2 быў узламаны, была вялікая верагоднасць, што і BLAKE апынецца скампраметаваны.
IPsec і OpenVPN не маюць патрэбы ў SipHash з-за іх дызайну. Такім чынам, адзінае, што ў цяперашні час не можа выкарыстоўвацца з імі, гэта BLAKE2, і тое, толькі пакуль ён не будзе стандартызаваны. Гэта не ёсць вялікі недахоп, таму што VPN выкарыстоўваюць HMAC для стварэння цэласнасці, якая лічыцца моцным рашэннем нават у звязку з MD5.
Так я прыйшоў да высновы, што ва ўсіх VPN выкарыстоўваецца практычна адзін і той жа набор крыптаграфічных прылад. Таму WireGuard не больш і не менш бяспечны, чым любыя іншыя актуальныя прадукты, калі справа даходзіць да шыфравання або цэласнасці перадаюцца дадзеных.
Але нават не гэта самае галоўнае, на што варта звярнуць увагу паводле афіцыйнай дакументацыі праекту. Бо галоўнае - гэта хуткасць.
WireGuard хутчэй за іншых рашэнняў VPN?
Калі коратка: не, не хутчэй.
ChaCha20 – гэта струменевы шыфр, які лягчэй укараніць у праграмнае забеспячэнне. Ён шыфруе адзін біт за раз. Блокавыя пратаколы, такія як AES, шыфруюць блок па 128 біт за раз. Для рэалізацыі апаратнай падтрымкі запатрабуецца значна больш транзістараў, таму буйнейшыя працэсары пастаўляюцца з AES-NI – пашырэннем набору каманд, якое выконвае некаторыя задачы працэсу шыфравання для яго паскарэння.
Чакалася, што AES-NI ніколі не патрапіць у смартфоны [а яно патрапіла, - заўв. зав.]. Для гэтага быў распрацаваны ChaCha20 – у якасці лёгкай і эканамічнай альтэрнатывы, зберагалай зарад батарэі. Таму для вас можа стаць навіной, што кожны смартфон, які вы можаце сёння набыць, мае тое ці іншае паскарэнне для AES і працуе з гэтым шыфраваннем хутчэй і з меншым энергаспажываннем, чым з ChaCha20.
Відавочна, што практычна кожны працэсар для настольных ПК/сервераў, набыты за апошнія пару гадоў, мае AES-NI.
Такім чынам, я чакаю, што AES перасягне ChaCha20 у кожным асобна ўзятым сцэнары. У афіцыйнай дакументацыі WireGuard згадваецца, што дзякуючы AVX512 ChaCha20-Poly1305 будзе пераўзыходзіць AES-NI, але гэтае пашырэнне набору каманд будзе даступна толькі на вялікіх працэсарах, што ізноў-ткі не дапаможа з малодшым і мабільным абсталяваннем, якое заўсёды будзе хутчэй працаваць з AES- NI.
Я не ўпэўнены, ці можна было прадбачыць гэта пры распрацоўцы WireGuard, але сёння факт таго, што ён цвікамі прыбіты да аднаго шыфравання – ужо з'яўляецца недахопам, які можа не вельмі добра паўплываць на яго працу.
IPsec дазваляе свабодна выбіраць, якое шыфраванне лепш за ўсё падыходзіць для вашага выпадку. І само сабой, гэта неабходна, калі вы, напрыклад, жадаеце перадаць 10 і больш гігабайт дадзеных праз VPN-злучэнне.
Праблемы інтэграцыі ў Linux
Хоць WireGuard абраў сучасны пратакол шыфравання, гэта ўжо выклікае шмат праблем. І вось, замест таго, каб выкарыстоўваць тое, што падтрымліваецца ядром са скрынкі, інтэграцыя WireGuard адкладалася гадамі з-за адсутнасці гэтых прымітываў у Linux.
Я не да канца ў курсе, якая сітуацыя ў іншых аперацыйных сістэмах, але верагодна, яна не моцна адрозніваецца ад сітуацыі з Linux.
Як выглядае рэальнасць?
На жаль, кожны раз, калі кліент просіць мяне наладзіць яму VPN-злучэнне, я сутыкаюся з тым, што яны выкарыстоўваюць састарэлыя уліковыя дадзеныя і шыфраванне. 3DES у звязку з MD5 – усё яшчэ распаўсюджаная практыка, таксама як AES-256 і SHA1. І хоць апошні крыху лепш — гэта не тое, чым варта карыстацца ў 2020 годзе.
Для абмену ключамі заўсёды выкарыстоўваецца RSA - павольны, але досыць бяспечны інструмент.
Мае кліенты звязаны з мытнымі органамі і іншымі дзяржарганізацыямі і ўстановамі, а таксама з буйнымі карпарацыямі, назвы якіх ведаюць па ўсім свеце. Усе яны выкарыстоўваюць форму запыту, якая была створана дзесяцігоддзі таму, а магчымасць выкарыстання SHA-512 проста ніколі не дадавалася. Я не магу сказаць, што гэта неяк відавочна ўплывае на тэхналагічны прагрэс, але відавочна, гэта запавольвае карпаратыўны працэс.
Мне балюча гэта бачыць, таму што IPsec падтрымлівае эліптычныя крывыя на ўскідку так з года 2005. Curve25519 таксама навей і даступны для выкарыстання. Яшчэ ёсць альтэрнатывы AES, такія як Camellia і ChaCha20, але, відавочна, не ўсе з іх падтрымліваюцца буйнымі пастаўшчыкамі, такімі як Cisco і іншымі.
І людзі гэтым карыстаюцца. Ёсць шмат камплектаў Cisco, ёсць мноства камплектаў, створаных для працы з Cisco. Яны з'яўляюцца лідэрамі рынку ў гэтым сегменце і не вельмі зацікаўлены ў якіх-небудзь інавацыях.
Так, сітуацыя [у карпаратыўным сегменце] жудасная, але мы не ўбачым якія-небудзь змен з-за WireGuard. Вытворцы, верагодна, ніколі не выявяць якія-небудзь праблем з прадукцыйнасцю ўжо выкарыстоўванага інструментара і шыфраванні, не ўбачаць праблем пры выкарыстанні IKEv2 – і таму яны не шукаюць альтэрнатыў.
Наогул, вы задумляліся калі-небудзь аб адмове ад Cisco?
Арыенціры
А зараз пяройдзем да бенчмаркаў з дакументацыі WireGuard. Хоць гэта [дакументацыя] не навуковы артыкул, я ўсё ж чакаў ад распрацоўшчыкаў больш навуковага падыходу, або выкарыстання навуковага падыходу ў якасці эталона. Любыя бенчмаркі бескарысныя, калі іх нельга прайграць, і яшчэ больш яны бескарысныя, калі атрыманы ў лабараторных умовах.
У зборцы WireGuard для Linux ён атрымлівае перавагу, выкарыстоўваючы GSO – Generic Segmentation Offloading. Дзякуючы яму, кліент стварае велізарны пакет памерам 64 кілабайта і шыфруе/расшыфроўвае яго за адзін падыход. Такім чынам, выдаткі на выклік і рэалізацыю крыптаграфічных аперацый зніжаюцца. Калі вы жадаеце максымізаваць прапускную здольнасць вашага VPN-злучэнні - гэта добрая ідэя.
Але, як гэта водзіцца, у рэальнасці не ўсё так проста. Адпраўка такога вялікага пакета на сеткавы адаптар патрабуе, каб ён бы быў нарэзаны на мноства малодшых пакетаў. Звычайны памер адпраўлення складае 1500 байт. Гэта значыць наш гігант у 64 кілабайта будзе падзелены на 45 пакетаў (1240 байт інфармацыі і 20 байт IP-загалоўка). Затым, на некаторы час яны поўнасцю заблакуюць працу сеткавага адаптара, таму што яны павінны быць адпраўленыя разам і адразу. У выніку гэта прывядзе да скачка прыярытэту, а такія пакеты, як, напрыклад, VoIP, будуць пастаўлены ў чаргу чаканні.
Такім чынам, высокая прапускная здольнасць, аб якой так смела заяўляе WireGuard, дасягаецца за кошт запаволення сеткавай працы іншых прыкладанняў. І каманда WireGuard ужо гэта мая выснова.
Але давайце рухацца далей.
Згодна з бенчмаркам у тэхдакументацыі, злучэнне паказвае прапускную здольнасць у 1011 Мбіт/с.
Уражвае.
Асабліва гэта ўражвае з-за таго, што максімальная тэарэтычная прапускная здольнасць аднаго гігабітнага Ethernet-падлучэння складае 966 Мбіт/з пры памеры пакета ў 1500 байт мінус 20 байт на IP-загаловак, 8 байт на UDP-загаловак і 16 байт на загаловак самога WireGuard . Ёсць яшчэ адзін загаловак IP у інкапсуляваным пакеце і іншы – у TCP на 20 байт. Дык адкуль з'явілася гэтая дадатковая прапускная здольнасць?
З велізарнымі фрэймамі і перавагамі GSO, аб якіх мы казалі вышэй, тэарэтычны максімум пры памеры фрэйма ў 9000 байт будзе роўны 1014 Мбіт/з. Звычайна такая прапускная здольнасць у рэальнасці недасяжная, таму што звязана з вялікімі цяжкасцямі. Такім чынам, я магу толькі выказаць здагадку, што тэст быў выкананы з выкарыстаннем яшчэ больш тоўстых фрэймаў з перавышэннем памеру ў 64 кілабайта з тэарэтычным максімумам у 1023 Мбіт/з, што падтрымліваецца толькі некаторымі сеткавымі адаптарамі. Але гэта абсалютна непрымяняльна ў рэальных умовах, альбо можа выкарыстоўвацца толькі паміж двума напрамую злучанымі паміж сабой станцыямі, выключна ў рамках тэставага стэнда.
Але так як VPN-тунэль пракідваецца паміж двума хастамі з дапамогай інтэрнэт-злучэння, якое ўвогуле не падтрымлівае вялікія фрэймы, дасягнуты на стэндзе вынік не можа быць прыняты за эталон. Гэта проста нерэальнае лабараторнае дасягненне, якое немагчыма і непрымяняльна ў рэальных баявых умовах.
Нават седзячы ў дата-цэнтры я не змог бы перакідваць фрэймы памерам больш за 9000 байт.
Крытэрый дастасавальнасці ў рэальным жыцці абсалютна парушаны і, як я думаю, аўтар праведзенага "вымярэння" сур'ёзна дыскрэдытаваў сам сябе па зразумелых прычынах.
Апошні пробліск надзеі
На сайце WireGuard шмат гаворыцца аб кантэйнерах і становіцца зразумела, для чаго ён насамрэч прызначаны.
Просты і хуткі VPN, які не патрабуе наладкі і можа быць разгорнуты і настроены масіўнымі інструментамі аркестроўкі, як, напрыклад, у Amazon у іх воблаку. Менавіта Amazon выкарыстоўвае найноўшыя апаратныя функцыі, пра якія я згадваў раней, напрыклад – AVX512. Робіцца гэта для таго, каб паскорыць працу і не прывязвацца да x86 ці любой іншай архітэктуры.
Яны аптымізуюць прапускную здольнасць і пакеты, памер якіх перавышае 9000 байт - гэта атрымаюцца велізарныя інкапсуляванага фрэймы для зносін кантэйнераў паміж сабой, або для аперацый рэзервовага капіявання, стварэння снапшотаў або разгортваючы гэтых самых кантэйнераў. Нават дынамічныя IP-адрасы ніяк не паўплываюць на працу WireGuard у выпадку апісанага мною сцэнара.
Нядрэнна згуляна. Бліскучая рэалізацыя і вельмі тонкі, амаль эталонны пратакол.
Але ён проста не падыходзіць для міру за межамі цалкам кантраляванага вамі дата-цэнтра. Калі ж вы рызыкнеце і пачнеце выкарыстоўваць WireGuard, вам давядзецца ісці на пастаянныя кампрамісы пры распрацоўцы і рэалізацыі пратакола шыфравання.
Выснова
Мне нескладана зрабіць выснову аб тым, што WireGuard пакуль не готаў.
Ён задумваўся як аблегчанае і хуткае вырашэнне шэрагу праблем ва ўжо існуючых рашэнняў. Нажаль, дзеля гэтых рашэнняў ён ахвяраваў шматлікімі функцыямі, якія будуць актуальныя для большасці карыстачоў. Менавіта таму ён не можа замяніць IPsec ці OpenVPN.
Для таго, каб WireGuard стаў канкурэнтным, яму трэба дадаць хаця б настройку IP-адрасы і канфігурацыю маршрутызацыі і DNS. Відавочна, што менавіта для гэтага патрэбны зашыфраваныя каналы.
Бяспека - мой галоўны прыярытэт, і цяпер у мяне няма падстаў меркаваць, што IKE або TLS неяк скампраметаваныя або паламаныя. Сучаснае шыфраванне падтрымліваецца ў іх абодвух, і яны былі правераны дзесяцігоддзямі эксплуатацыі. Калі нешта навейшае не значыць, што гэта нешта — лепш.
Функцыянальная сумяшчальнасць вельмі важная, калі вы звязваецеся з трэцімі асобамі, станцыі якіх вы не кантралюеце. IPsec дэ-факта з'яўляецца стандартам і падтрымліваецца практычна паўсюдна. І ён працуе. І як бы гэта не выглядала, у тэорыі, WireGuard у будучыні можа быць несумяшчальны нават з рознымі версіямі самога сябе.
Любая крыптаграфічная абарона рана ці позна ўзломваецца і, адпаведна, павінна быць заменена ці абноўлена.
Адмаўленне ўсіх гэтых фактаў і сляпое жаданне выкарыстоўваць WireGuard для падлучэння вашага iPhone да хатняй працоўнай станцыі - гэта проста майстар-клас па засоўванні галавы ў пясок.
Крыніца: habr.com