В последно време 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 Мбит/с — все още е обща норма, а оптично свързване струва невероятни суми по нашите мерки. Затова авторът на статията говори за 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 — 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
