Почему не стоит пользоваться WireGuard

Original author: Michael Tremer
  • Translation
В последнее время 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-соединение и 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 к домашней рабочей станции — это просто мастер-класс по засовыванию головы в песок.
Дата-центр «Миран»
Решения для аренды и размещения ИТ-инфраструктуры

Comments 43

    0
    Для поднятия туннелей между ДЦ лучше Wireguard пока ничего не нашел. Ipsec на Linux это медленный ужас.
      +1
      Почему? Там медленный только хендшейк, а ESP в теории должен обеспечивать производительность, сравнимую с Wireguard.
      +1
      Таким образом, я могу только предположить, что тест был выполнен с использованием еще более жирных фреймов с превышением размера в 64 килобайта с теоретическим максимумом в 1023 Мбит/с, что поддерживается только некоторыми сетевыми адаптерами. Но это абсолютно неприменимо в реальных условиях
      В реальных условиях на сервере будет 10G интерфейс, и скорость будет ещё выше.
        +3
        и OpenVPN предлагают функцию согласования шифров. Поэтому некоторое время, после которого вы включите новое шифрование, будет работать и старое. Благодаря этому текущие клиенты смогут обновиться до новой версии. После того, как обновление будет раскатано, вы просто выключите уязвимое шифрование. И все! Готово! вы восхитительны! А клиенты этого даже не заметят

        Ахаха, нет.
        У меня как раз недавно был кейс с OpenVPN (на OpenWRT роутере) где в древней версии было сжатие tls, а в новой версии его не было и обновив «сервер» — пришлось ехать к «клиенту» чтоб поправить конфиг, благо он был один и в том же городе.
          0
          Ахаха, нет.
          У меня как раз недавно был кейс с OpenVPN (на OpenWRT роутере) где в древней версии было сжатие tls, а в новой версии его не было и обновив «сервер» — пришлось ехать к «клиенту» чтоб поправить конфиг, благо он был один и в том же городе.


          Ахаха, да. Сорян за прямоту, но мне кажется, что вы OpenWRT-проблемы зачем-то в кучу в OpenVPN-проблемами смешали, и если поверх этого работает что-нибудь реально business-critical, то обновление OpenVPN — одна из наименьших ваших проблем.
            0
            Причем здесь OpenWRT, если это разработчики OpenVPN выкинули comp-lzo из 2.4?

            Бизнес-критикала там нет, но процесс сложился: офису удобнее накладные печатать прямо на принтер производства чем высылать их емейлами, а производству удобнее забирать их с принтера, а не шуршать в почте и распечатывать.
              0
              Причем здесь OpenWRT, если это разработчики OpenVPN выкинули comp-lzo из 2.4?


              При чем здесь OpenVPN, который comp-lzo не выкидывал? Пруф: community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-lzo

              Опция --comp-lzo помечена как deprecated и «Currently not planned for removal», т.е. в OpenVPN она все еще есть, и все еще работает «for backward compatibility».

              А то, что конкретно ваша сборка OpenVPN под конкретно вашу сборку OpenWRT на конкретно вашей железке — это именно OpenWRT-проблема. Поэтому я и говорю, не путайте OpenVPN-проблемы с OpenWRT-проблемами.

              Бизнес-критикала там нет, но процесс сложился: ...


              Ну это просто классическое «что-то к чему-то примотали скотчем, и оно теперь как-то работает». Странно эти проблемы адресовать к OpenVPN.
                0
                Ок, согласен, наверно OpenWRT сэкономили место и собрали без deprecated опций.
                Но ведь от клиента не требовалась магия по поддержке чего-то нового, достаточно было не включать сжатие. Я почему возмутился — автор статьи нам рассказывает что OpenVPN сам по себе дико смышленый и сам все согласовывает, а по факту оказалось что нет, сообразить отключить сжатие он не может.

                Может конечно имелось ввиду что настройки клиентам можно отдавать из ccd, но в статье это не указано явно.

                Честно говоря весь параграф «Об игнорировании реальных проблем» больше похож на маркетинговый буллшит, какие-то абстрактные преимущества и недостатки без единого слова конкретики.
                  0
                  Ок, согласен, наверно OpenWRT сэкономили место и собрали без deprecated опций.


                  Ну, скорее подошла бы формулировка «немного через жопу». Не, не подумайте, это им не то чтобы в обиду. Просто природа самого проекта OpenWRT (и dd-wrt, до кучи) такова, что «немного через жопу» — это нормальное состояние. Задача «собрать некую штуку, которая будет работать на тысячах устройствах, которые не предназначены для запуска этой штуки в условиях отсутствия спецификаций на эти устройства» — она сама по себе достаточно ресурсоемка, нетривиальна и благородна, спору нет. И в какой-то определенной нише смысл от всех этих трудозатрат есть.

                  Просто сама постановка задачи предполагает, что работать это будет «как-то», «немного через жопу» и «ну ведь работает же». А условие «тысячи разных устройств без спецификаций» исключает а) возможность квалифицированной сборки под все конечные устройства б) унифицированное(одинаковое) поведение всей этой системы на разных девайсах.

                  Вот и имеем то, что имеем. Это не плохо, и не хорошо — это просто так есть. Согласно моим личным предпочтениям, я бы предпочел собрать аналогичную схему на том же микротике за примерно такие же деньги. В конкретно вашей же ситуации — выбор за вами, и собиралось оно, видимо, несколько раньше текущего времени, а тогда и имкротики были другие, и стоить могли дороже.

                  Но ведь от клиента не требовалась магия по поддержке чего-то нового, достаточно было не включать сжатие.


                  Там «собака зарыта», видимо, таки в сборке. Т.е. deprecated-сжатие не собирали, а из списка поддерживаемых сервером опций не убрали. Вот и получилось:
                  Клиент: — Слушай, сервер, а ты поддерживаешь comp-lzo?
                  Сервер (на голубом глазу, сверяясь со списком, подсунутым при сборке): — Да.
                  Клиент: — #sl0sdfl(*jsei
                  Сервер:… Нихрена не понял, что ты сказал, но, на всякий случай «сам урод».

                  Я почему возмутился — автор статьи нам рассказывает что OpenVPN сам по себе дико смышленый и сам все согласовывает, а по факту оказалось что нет, сообразить отключить сжатие он не может.


                  Ну, он достаточно смышленный для того, чтобы сопоставить свой список с тем, что ему сервер прислал. Он вообще действительно достаточно смышленный. Просто сервер неправильный список прислал — и это вопрос к сборщику. Я на эти грабли сам наступал, когда один мой товарищ пытался как раз openVPN'ом подружить 2 D-Link'а соседних моделей (на буковку в конце различались) на «одной и той же версии OpenWRT» с «одним и тем же билдом OpenVPN». Я в предыдущем предложении специально кавычки так расставил, потому что дебаг выявил, что эти девайсы с идентичным конфигом отдавали разные списки поддерживаемых опций, и со сжатием так и не завелись.

                  Честно говоря весь параграф «Об игнорировании реальных проблем» больше похож на маркетинговый буллшит, какие-то абстрактные преимущества и недостатки без единого слова конкретики.


                  А вот с маркетинговой сутью всей этой бучи вокруг WG однозначно соглашусь. Собственно, сам продукт достаточно интересен, но а) ему еще расти и расти, б) его пиарят как замену всему, включая те вещи, заменой которым он не является, в) совершенно не известно, что с ним произойдет в процессе «натягивания совы на глобус», т.е. попытки подвести продукт под вещи, заявленные в пункте «б».
                    +1
                    Просто природа самого проекта OpenWRT (и dd-wrt, до кучи) такова, что «немного через жопу» — это нормальное состояние. Задача «собрать некую штуку, которая будет работать на тысячах устройствах, которые не предназначены для запуска этой штуки в условиях отсутствия спецификаций на эти устройства»
                    Ну это вообще природа у опенсорса такая: делается в качестве хобби, квалификация разная бывает, бесплатно спеки не всегда дают и тд.
                    Ну про тысячи это немного преувеличено.
                    При всем многообразии роутеров поддерживаемых платформ не так много и их толи десяток толи два десятка, а специфичные вещи для конкретных моделей пишутся в конфигах для них. Тут больше вопрос экономии места возникает, тк объемы флеша и оперативки у роутера ограничены.
                      +1
                      При всем многообразии роутеров поддерживаемых платформ не так много и их толи десяток толи два десятка, а специфичные вещи для конкретных моделей пишутся в конфигах для них.


                      На выходе может получиться весьма и весьма разный результат. Лично наблюдал, как два роутера из одного модельного ряда на одной и той же версии прошивки OpenWRT не могли сконнектиться по OpenVPN. Так что там многое что роляет. Производители роутеров — боооольшие затейники, и своя специфика может вылезти на любом из роутеров из именно что тысяч…
                      0
                      Просто природа самого проекта OpenWRT (и dd-wrt, до кучи) такова, что «немного через жопу» — это нормальное состояние. Задача «собрать некую штуку, которая будет работать на тысячах устройствах, которые не предназначены для запуска этой штуки в условиях отсутствия спецификаций на эти устройства» — она сама по себе достаточно ресурсоемка, нетривиальна

                      какое это всё имеет отношение к поддержке openvpn?!? вообще аппаратно-зависимые вещи — только малая доля проекта openwrt

                        0
                        какое это всё имеет отношение к поддержке openvpn?!?


                        Ну, например, косяки сборки OpenVPN под OpenWRT иногда ошибочно относят к косякам самого OpenVPN, что мы и видели выше по истории этого треда… А так — да, никакого. Проблемы OpenVPN в контексте работы сервера из-под OpenWRT к OpenVPN отношения не имеют никакого, о чем я и говорю.

                        вообще аппаратно-зависимые вещи — только малая доля проекта openwrt


                        Тем не менее они вполне себе «аффектят» работу некоторых вещей, т.к. с одной стороны это только малая доля проекта, а с другой — самая сложная в тестировании. Одно дело для разработчика собрать проект и потестить на своей личной железяке или в виртуалке, убедиться, что все работает, а совершенно другое дело — прогнать все возможные конфигурации на тысячах доступных потребительских девайсов. Вот второй случай — нереализуем в принципе. Вот и имеем то, что имеем. С одной стороны есть относительно протестированная бОльшая часть проекта, и есть аппаратно-зависимые вещи, поверх которых это все работает, которые, откровенно говоря, вживую на всех доступных комбинациях никто не тестил, ибо нереализуемо и бессмысленно…
                      0
                      Если что, есть --compress lzo, и оно не deprecated
                        0
                        Но есть --comp-lzo, и оно deprecated
                0
                Стоило 1) протестировать до «боевого» деплоя (или хотя бы уточнить по changelog грабли, 2) обновить сначала клиента, и, раз уж так вышло, опустить версию сервера, обновить клиента, и снова поднять сервер.
                  0
                  Ну когда я реально распределенную сеть (15 точек по области на расстоянии 50-200км) переводил на новый конфиг — я был более осторожен, да и возможностей было побольше, сервером была FreeBSD, а не OpenWRT.

                  А в данном случае понизить версию было нельзя, тк старые (> 5 лет) репозитории OpenWRT были уже выпилены.
                +10
                Безопасность — мой главный приоритет, и сейчас у меня нет оснований полагать, что IKE или TLS как-то скомпрометированы или поломаны
                Понимаете, некоторые предпочитают секс с девушкой, а не с IPSec.

                Если кратко: нет, не быстрее.
                А я видел обратное. На обычном домашнем двухъядерном MIPS-роутере WG позволил выжать больше, чем юзерспейсный OpenVPN.
                  +5
                  OpenVPN однозначно самый большой тормоз, но если сравнивать с IPsec, WG ненамного быстрее.

                  Хотя самый большой недостаток IPsec (с точки зрения простоты настроек) — это огород с PKI (если использовать сертификаты), в то время как shared secret ну совсем не вариант.
                    +1

                    Автор пишет про ipsec. И да OVPN — тормоз, это очевидно.

                    +2
                    Ох и спорная статья получилась )

                    На текущий момент это не серебряная пуля, которая решит все вопросы с этим сложно не согласится.
                    Но, например, у нас в конторе был OpenVPN и сейчас все дружно переезжаем на Wireguard, потому что проще и работает лучше. С OpenVPN достаточно много было мучений, потому что у одного работает, а у другого нет, а с WG всё взлетает и все довольны.

                    У WireGuard есть своя специфика, нужно немного руками поработать, чтобы всё заработало как надо, но по скорости он прям очень хорош.

                    Я думаю, что в ближайшее время люди начнут работать над недостатками и в итоге всё станет более удобным, а пока будем чуть-чуть писать скрипты, пилить велосипеды и радоваться тому, что имеем.

                    У меня самый весёлый use-case, который не описан в статье — это то, что можно пробросить туннель со смартфона до сервера )
                      +3
                      У OpenVPN есть существенный плюс за счет директивы push, которой я могу менять, например, маршрутизацию или даже шифрование (с клиентской версии 2.4) без рассылки нового конфига клиентам
                        0
                        Тут ключевая фраза «с клиентской версии 2.4». У WG пока не такая длинная история.

                        Будет спрос. Будет развитие.
                          +1
                          с клиентской версии 2.4

                          Это только относительно шифрования, все остальное давно работает. В статье как раз говорится, что у них разные подходы с точки зрения архитектуры, WG сделан чтобы быстро поднять туннель, остальные популярные решения рассчитаны на более серьезные задачи. Конечно, следим за WG и ждем, лично я хочу tcp протокол))
                            0
                            Ходят слухи, что TCP уже не торт и будущее за UDP )))
                              0
                              Тут дело не в целостности передачи информации, а в пробитии стен)) Неприятно оказаться в сети, где можно только по сайтикам лазить, а впн отказывается подключаться. Если желать скорости и хорошего отклика, то udp безусловно будет лучше
                              0

                              Зачем вы хотите именно TCP?

                                0
                                Чтоб не было проблем в публичных сетях, где ограничивают трафик по портам. Предпочитаю вешать впн на 443 tcp
                                  0

                                  По видимому, это одна из специфичных задач, под которые не расчитан WG.

                                    0

                                    TunSafe уже имеет поддержку TCP, но тогда нужно и сервер на нём поднимать. Впрочем я не советую поднимать такие экзотические связки. Это скорее proof of concept.

                          0
                          У WireGuard есть своя специфика, нужно немного руками поработать, чтобы всё заработало как надо, но по скорости он прям очень хорош.

                          Один из серьёзных недостатоков — невозможность выяснить, жив ли клиент, равно как и невозможность что-то сделать в момент когда он подцепился. Можно косвенно это выяснить по времени последнего пакета (при включенном keepalive), но это криво и ненадёжно.

                          Если же есть только один VPN сервер, всем клиентам можно дать статический IP, отслеживать и ограничивать их соединения не нужно — да, хороший и простой вариант, очень шустрый к тому же.
                            +2
                            Есть ещё один недостаток. Пока не ходит трафик от клиента к серверу, то соединения нет. И нельзя пообщаться с клиентом, пока он сам не выйдет на связь, что очень неудобно в случаях когда нужно сделать что-то вроде ребута и потом продолжить работу с этой машиной.

                            У меня всё конфигурирование и установка соединения обёрнуто в сервис, который периодически пингует сервер, поэтому я всегда могу понять когда клиент жив. Да, костыть, но что делать.

                            Собственно об этом и говорил, что пока есть недостатки, но я думаю, что их решат со временем.
                              +4
                              У wireguard есть директива PersistentKeepalive, которая делает ровно то, что вы описали, раз в указанный промежуток времени посылает пакет серверу, чтобы поддерживать соединение за натом, например.
                          +3
                          ChaCha20 — это потоковый шифр, который легче внедрить в программное обеспечение. Он шифрует один бит за раз. Блочные протоколы, такие как AES, шифруют блок по 128 бит за раз.

                          Bullshit. ChaCha20 генерирует блоки размером 512 бит, которые затем xor-ятся с шифруемыми данными.

                            0
                            может я чего то не понимаю, но стал использовать IPSEC IKEv2 на сертификатах и горя не знаю
                            аппаратное ускорение творит чудеса
                              +2
                              А потом вам попадается Windows за NATом и вы начинаете крыть всё матом, поскольку на фазе обмена ключами при eap-tls работать с фрагментироваными пакетами научили только Win 10 (1803).
                              +1

                              Для домашнего роутера OpenWRT WireGuard настраивается в разы проще, чем OpenVPN и уж тем более IPSec. А работает не хуже. Проверено.
                              Поэтому автор прав, WG для людей, а не для корпораций.

                                0

                                Почему-то всегда рассматривал WG как "домашний" VPN — секундная настройка и можно цепляться с телефона к домашней сети.
                                В моем случае WG вообще идёт как add-on к HomeAssistant — установка и настройка из web интерфейса HA.
                                Сравнив количество теледвижений для подъёма VPN сервера на домашнем mikrotik и на WS, сделал выбор в пользу последнего.

                                  0
                                  ИМХО, не дожил еще WG до промышленных масштабов. Но для малой организации или для «домашнего» vpn — лучший вариант. У меня все устройства (стационарный, ноут, NAS, телефон) объеденны в сеть и доступны по серым адресам всюду, это удобно! Для меня Connection-less прям киллер-фитча.
                                    0

                                    Расскажете подробнее о решении?

                                      +2
                                      ZeroTier, видимо. Можно пользовать «ихние» мощности, а можно поднять свой контроллер.
                                      На Хабре есть статьи по нему.
                                        0
                                        Недорогой облачный VDS, на нем основной сервер WG к которому подключение, dnsmasq в роле DNS сервера (экспериментировал с pihole, тоже не плохо получается). Все девайсы работают через него. На мобильном оф приложение от WG в режиме постоянного vpn, по сути через него идут только dns запросы и данные по серой сети (обращение к NAS или другим железкам в общей системе). Так как сервер за бугром, достаточно включить WG с роутом 0.0.0.0/0 чтобы проксировать весь трафик и не думать о цензуре.
                                      0
                                      Использую WireGuard больше года для связи нескольких домашних сетей (в разных локациях), сервера за границей (сами-знаете-для-чего), рабочего компьютера и сетей (~20 маршрутов), при этом для PtP используется одна сеть /24 (и от одной до пары десятков сетей в каждой локации), но есть маршруты между узлами напрямую. Всё работает как часы, причём, в домашних сетях всё «крутится» на роутерах с OpenWRT.
                                      До этого был OpenVPN и IPSec (остался и сейчас, но не использую). WireGuard нравится больше.

                                      Only users with full accounts can post comments. Log in, please.