В последно време WireGuard привлича голямо внимание, всъщност — това е новата „звезда“ сред VPN. Но наистина ли е толкова добър, колкото изглежда? Бих искал да обсъдим някои наблюдения и да разгледаме имплементацията на WireGuard, за да разкажа защо той не е решение, което да замени IPsec или OpenVPN.
В тази статия бих искал да разоблича някои митове [около WireGuard]. Да, ще трябва да четете дълго, така че ако все още не сте си приготвили чаша чай или кафе, сега е моментът да го направите. Искам също да благодаря на Питър за корекцията на моите хаотични мисли.
Не си поставям за цел да дискредитирам разработчиците на WireGuard, да подценявам усилията им или идеите им. Продуктът им е работещ, но лично аз смятам, че той е представен съвсем различно от това, което всъщност представлява — представен е като замяна на IPsec и OpenVPN, което в момента всъщност просто не съществува.
Като забележка искам да добавя, че отговорността за такова позициониране на WireGuard носят медиите, които разказваха за него, а не самият проект или неговите създатели.
В последно време по темата за ядрото на Linux не е имало твърде много добри новини. По този начин, ни информираха за чудовищни уязвимости на процесора, които бяха неутрализирани по софтуерен начин, а Линус Торвалдс говореше за това прекалено грубо и скучно, утилитарен език на разработчика. Планиращият или мрежовият стек на нулево ниво — също не са много ясни теми за гланцевите списания. И тук се появява WireGuard.
На хартия всичко звучи чудесно: вълнуваща нова технология.
Но нека да я разгледаме по-внимателно.
Техническа документация на 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 Mbps все още е общопризната норма, а оптичното свързване струва невъзможни суми за нашите рамки. Затова авторът на статията говори за DSL или кабелно свързване като за норма, а не като за дремуча старина.] Обаче DSL, кабелни, LTE (и други безжични методи на достъп) имат динамични IP адреси. Разбира се, понякога те не се променят често, но все пак се променят.
Съществува подпроект на име „wg-dynamic“, който добавя демона на потребителското пространство, за да преодолее този недостатък. Огромен проблем на потребителската ситуация, описана по-горе, е влошаването на условията за динамична IPv6 адресация.
От гледна точка на дистрибутора всичко това също не изглежда много добре. Една от целите на разработката беше да се запази простотата и чистотата на протокола.
За съжаление, всичко това всъщност стана твърде просто и примитивно, така че трябва да използваме допълнителен софтуер, за да направим цялата тази конструкция жизнеспособна в условията на реална експлоатация.
Толкова ли е лесно да се използва WireGuard?
Все още не. Не казвам, че WireGuard никога няма да бъде добра алтернатива за прокарване на тунел между две точки, но в момента той е просто альфа-версия на продукта, който трябва да стане.
Но какво всъщност прави той? Дали наистина IPsec е толкова сложен за експлоатация?
Очевидно не. Доставчикът на IPsec се е замислил за този момент и предлага своя продукт с интерфейс, например с IPFire.
За да настроите VPN тунел през IPsec, ще ви трябва пет комплекта данни, които трябва да включите в конфигурацията: ваш собствен публичен IP адрес, публичния IP адрес на приемащата страна, подмрежите, които искате да направите публични чрез това VPN съединение, и предварително споделен ключ. По този начин, 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 — Общo Офloading на сегментиране. Благодарение на него, клиентът създава огромен пакет размер 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
