Зошто не треба да користите WireGuard

WireGuard во последно време привлекува големо внимание, всушност тоа е новата ѕвезда меѓу VPN. Но, дали е толку добар како што изгледа? Би сакал да разговарам за некои набљудувања и да ја прегледам имплементацијата на WireGuard за да објаснам зошто не е решение да се замени IPsec или OpenVPN.

Во оваа статија, би сакал да отфрлам некои од митовите [околу WireGuard]. Да, ќе биде потребно многу време за читање, па ако не сте направиле чај или кафе, тогаш време е да го направите тоа. Би сакал да му се заблагодарам и на Петар што ги исправи моите хаотични мисли.

Не си поставувам за цел да ги дискредитирам развивачите на WireGuard, да ги обезвреднувам нивните напори или идеи. Нивниот производ работи, но лично мислам дека е претставен сосема поинаков од она што навистина е - претставен е како замена за IPsec и OpenVPN, кои всушност сега едноставно не постојат.

Како забелешка, би сакал да додадам дека одговорноста за ваквото позиционирање на WireGuard е на медиумите кои зборуваа за тоа, а не на самиот проект или неговите креатори.

Во последно време нема многу добри вести за кернелот на Linux. Така, ни беше кажано за монструозните пропусти на процесорот, кои беа израмнети со софтвер, а Линус Торвалдс зборуваше за тоа премногу грубо и досадно, на утилитарниот јазик на развивачот. Распоредувачот или мрежниот оџак на нула ниво исто така не се многу јасни теми за сјајни списанија. И тука доаѓа WireGuard.

На хартија, сето тоа звучи одлично: возбудлива нова технологија.

Но, ајде да погледнеме малку поблиску.

Бела хартија WireGuard

Оваа статија се заснова на официјална документација на WireGuardнапишана од Џејсон Доненфелд. Таму тој го објаснува концептот, целта и техничката имплементација на [WireGuard] во кернелот Линукс.

Првата реченица гласи:

WireGuard […] има за цел да ги замени и IPsec во повеќето случаи на употреба и други популарни решенија базирани на кориснички простор и/или TLS, како што е OpenVPN, додека е посигурен, поперформативен и полесен за користење [алатка].

Се разбира, главната предност на сите нови технологии е нивната едноставност [во споредба со претходниците]. Но, VPN исто така треба да биде ефективни и безбедни.

Значи, што е следно?

Ако кажете дека тоа не е она што ви треба [од VPN], тогаш можете да го завршите читањето овде. Сепак, ќе забележам дека таквите задачи се поставени за која било друга технологија за тунелирање.

Најинтересниот од горенаведениот цитат лежи во зборовите „во повеќето случаи“, кои, се разбира, беа игнорирани од печатот. И така, ние сме таму каде што завршивме поради хаосот создаден од оваа негрижа - во оваа статија.

Дали WireGuard ќе го замени мојот [IPsec] VPN од локација до локација?

бр. Едноставно нема шанси големите продавачи како што се Cisco, Juniper и други да купат WireGuard за нивните производи. Тие не „скокаат на возови што поминуваат“ во движење, освен ако има некоја голема потреба да го сторат тоа. Подоцна, ќе разгледам некои од причините зошто тие веројатно нема да можат да ги преземат своите производи од WireGuard дури и да сакаат.

Дали WireGuard ќе го однесе мојот RoadWarrior од мојот лаптоп до центарот за податоци?

бр. Во моментов, WireGuard нема огромен број важни функции имплементирани за да може да направи вакво нешто. На пример, не може да користи динамични IP-адреси на страната на серверот на тунелот, и само тоа го прекинува целото сценарио за таква употреба на производот.

IPFire често се користи за евтини интернет врски, како што се DSL или кабелски конекции. Ова има смисла за мали или средни бизниси на кои не им требаат брзи влакна. [Забелешка од преведувачот: не заборавајте дека во однос на комуникацијата, Русија и некои земји од ЗНД се далеку пред Европа и САД, бидејќи почнавме да ги градиме нашите мрежи многу подоцна и со доаѓањето на етернет и оптичките мрежи како стандард, ни беше полесно да се обновиме. Во истите земји од ЕУ или САД, широкопојасен пристап xDSL со брзина од 3-5 Mbps сè уште е општа норма, а поврзувањето со оптички влакна чини некои нереални пари според нашите стандарди. Затоа, авторот на статијата зборува за DSL или кабелска врска како норма, а не за античко време.] Сепак, DSL, кабелски, LTE (и други методи за безжичен пристап) имаат динамични IP адреси. Се разбира, понекогаш тие не се менуваат често, но се менуваат.

Има подпроект наречен "wg-динамична", кој додава демон на корисничкиот простор за да се надмине овој недостаток. Огромен проблем со корисничкото сценарио опишано погоре е влошувањето на динамичкото IPv6 адресирање.

Од гледна точка на дистрибутерот, сето ова не изгледа многу добро. Една од целите на дизајнот беше протоколот да биде едноставен и чист.

За жал, сето ова всушност стана премногу едноставно и примитивно, така што мораме да користиме дополнителен софтвер за целиот овој дизајн да биде остварлив во вистинска употреба.

Дали WireGuard е толку лесен за користење?

Не сеуште. Не велам дека WireGuard никогаш нема да биде добра алтернатива за тунелирање помеѓу две точки, но засега тоа е само алфа верзија на производот што треба да биде.

Но, тогаш што всушност прави тој? Дали IPsec навистина е многу потешко да се одржува?

Очигледно не. Продавачот IPsec го смислил ова и го испорачува својот производ со интерфејс, како на пример со IPFire.

За да поставите VPN тунел преку IPsec, ќе ви требаат пет групи на податоци што ќе треба да ги внесете во конфигурацијата: вашата јавна IP адреса, јавната IP адреса на страната што прима, подмрежите што сакате да ги објавите во јавноста преку оваа 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, имаше големи шанси и БЛЕК да биде компромитиран.

На 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 - Н.И.

Не сум сигурен дали ова можеше да се предвиди за време на развојот на 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, тој ги користи предностите на користењето на GSO - Оптоварување на генерички сегменти. Благодарение на него, клиентот создава огромен пакет од 64 килобајти и го шифрира / дешифрира со едно движење. Така, трошоците за повикување и спроведување на криптографски операции се намалуваат. Ако сакате да ја максимизирате пропусната моќ на вашата VPN конекција, ова е добра идеја.

Но, како и обично, реалноста не е толку едноставна. Испраќањето на толку голем пакет до мрежен адаптер бара тој да се исече на многу помали пакети. Нормалната големина на испраќање е 1500 бајти. Односно, нашиот гигант од 64 килобајти ќе биде поделен на 45 пакети (1240 бајти информации и 20 бајти од насловот на IP). Потоа, за некое време, тие целосно ќе ја блокираат работата на мрежниот адаптер, бидејќи мора да се испратат заедно и одеднаш. Како резултат на тоа, ова ќе доведе до скок на приоритет, а пакетите како VoIP, на пример, ќе бидат во редица.

Така, високата пропусност за која WireGuard толку смело тврди се постигнува по цена на забавување на вмрежувањето на другите апликации. И тимот на WireGuard е веќе потврдено ова е мојот заклучок.

Но, да продолжиме понатаму.

Според одредниците во техничката документација, врската покажува пропусност од 1011 Mbps.

Импресивно.

Ова е особено импресивно поради фактот што максималната теоретска пропусност на една гигабитна етернет конекција е 966 Mbps со големина на пакет од 1500 бајти минус 20 бајти за заглавието IP, 8 бајти за заглавието UDP и 16 бајти за заглавието на самиот WireGuard. Има уште еден IP наслов во инкапсулираниот пакет и уште еден во TCP за 20 бајти. Значи, од каде дојде овој дополнителен пропусен опсег?

Со огромни рамки и придобивките од GSO за кои зборувавме погоре, теоретскиот максимум за големина на рамка од 9000 бајти би бил 1014 Mbps. Обично таквата пропусност е недостижна во реалноста, бидејќи е поврзана со големи тешкотии. Така, можам само да претпоставам дека тестот е направен со користење на уште подебели преголеми рамки од 64 килобајти со теоретски максимум од 1023 Mbps, што е поддржано само од некои мрежни адаптери. Но, ова е апсолутно неприменливо во реални услови, или може да се користи само помеѓу две директно поврзани станици, исклучиво во рамките на тест-клупата.

Но, бидејќи тунелот VPN се препраќа помеѓу два домаќини користејќи интернет конекција која воопшто не поддржува џамбо рамки, резултатот постигнат на клупата не може да се земе како репер. Ова е едноставно нереално лабораториско достигнување кое е невозможно и неприменливо во реални борбени услови.

Дури и седејќи во центарот за податоци, не можев да префрлам рамки поголеми од 9000 бајти.

Критериумот на применливост во реалниот живот е апсолутно прекршен и, како што мислам, авторот на спроведеното „мерење“ сериозно се дискредитира од очигледни причини.

Последна трошка надеж

Веб-страницата WireGuard зборува многу за контејнерите и станува јасно за што навистина е наменет.

Едноставен и брз VPN кој не бара конфигурација и може да се распореди и конфигурира со масивни алатки за оркестрација како што има Amazon во нивниот облак. Поточно, Амазон ги користи најновите хардверски карактеристики што ги споменав претходно, како што е AVX512. Ова е направено со цел да се забрза работата и да не се врзува за x86 или некоја друга архитектура.

Тие ја оптимизираат пропусната моќ и пакетите поголеми од 9000 бајти - тоа ќе бидат огромни инкапсулирани рамки за контејнерите да комуницираат едни со други, или за операции за резервни копии, создавање снимки или распоредување на истите овие контејнери. Дури и динамичните IP адреси нема да влијаат на работата на WireGuard на кој било начин во случајот со сценариото што го опишав.

Добро одиграно. Брилијантна имплементација и многу тенок, речиси референтен протокол.

Но, едноставно не се вклопува во свет надвор од центарот за податоци што вие целосно го контролирате. Ако го преземете ризикот и почнете да го користите WireGuard, ќе мора да правите постојани компромиси во дизајнот и имплементацијата на протоколот за шифрирање.

Излез

Лесно ми е да заклучам дека WireGuard сè уште не е подготвен.

Беше замислен како лесно и брзо решение за голем број проблеми со постоечките решенија. За жал, за доброто на овие решенија, тој жртвуваше многу функции кои ќе бидат релевантни за повеќето корисници. Затоа не може да ги замени IPsec или OpenVPN.

За да може WireGuard да стане конкурентен, треба да додаде барем поставка за IP адреса и конфигурација за рутирање и DNS. Очигледно, за ова служат шифрираните канали.

Безбедноста е мојот главен приоритет и во моментов немам причина да верувам дека IKE или TLS се некако компромитирани или скршени. Во двата од нив е поддржано модерно шифрирање, а тие се докажани со децении на работа. Само затоа што нешто е поново не значи дека е подобро.

Интероперабилноста е исклучително важна кога комуницирате со трети страни чии станици не ги контролирате. IPsec е де факто стандард и е поддржан речиси насекаде. И тој работи. И без разлика како изгледа, во теорија, WireGuard во иднина можеби нема да биде компатибилен дури и со различни верзии од себе.

Секоја криптографска заштита е скршена порано или подоцна и, соодветно, мора да се замени или ажурира.

Негирањето на сите овие факти и слепо желбата да го користите WireGuard за да го поврзете вашиот iPhone со вашата домашна работна станица е само мастер клас во заглавувањето на главата во песок.

Извор: www.habr.com