Останнім часом 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