The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск OpenVPN 2.5.6 и 2.4.12 с устранением уязвимости

17.03.2022 08:52

Подготовлены корректирующие выпуски OpenVPN 2.5.6 и 2.4.12, пакета для создания виртуальных частных сетей, позволяющего организовать шифрованное соединение между двумя клиентскими машинами или обеспечить работу централизованного VPN-сервера для одновременной работы нескольких клиентов. Код OpenVPN распространяется под лицензией GPLv2, готовые бинарные пакеты формируются для Debian, Ubuntu, CentOS, RHEL и Windows.

В новых версиях устранена уязвимость, потенциально позволяющая обойти аутентификацию через манипуляцию с внешними плагинами, поддерживающими режим отложенной аутентификации (deferred_auth). Проблема возникает, когда несколько плагинов отправляют отложенные ответы аутентификации, что позволяет внешнему пользователю получить доступ на основе не полностью корректных учётных данных. Начиная с выпусков OpenVPN 2.5.6 и 2.4.12 попытки использования отложенной аутентификации несколькими плагинами будут приводить к выводу ошибки.

Из других изменений можно отметить включение в состав нового плагина sample-plugin/defer/multi-auth.c, который может быть полезен для организации тестирования одновременного использования разных плагинов аутентификации, чтобы в дальнейшем избежать уязвимостей, подобных той, что была рассмотрена выше. На платформе Linux налажена работа опции "--mtu-disc maybe|yes". Устранена утечка памяти в процедурах добавления маршрутов.

  1. Главная ссылка к новости (https://github.com/OpenVPN/ope...)
  2. OpenNews: Выпуск OpenVPN 2.5.5
  3. OpenNews: Представлен модуль ядра, способный в разы ускорить OpenVPN
  4. OpenNews: Обновление OpenVPN 2.5.3. Отключение Opera VPN и VyprVPN в РФ
  5. OpenNews: Обновление OpenVPN 2.5.2 и 2.4.11 с устранением уязвимости
  6. OpenNews: Доступен OpenVPN 2.5.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/56866-openvpn
Ключевые слова: openvpn
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, timur.davletshin (ok), 09:06, 17/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Мне больше всего нравятся нелогичности в трендах.

    Ну, вроде как из-за переключения контекста ядра OpenVPN медленнее, чем реализации на уровне ядра. ОК, одни написали Wireguard, другие написали OpenVPN kernel accelerator. Вроде как счастье, мир и процветание.

    Но в пользовательских протоколах обратный тренд и все массово (доля HTTP/S трафика выше, чем все VPN) ломанулись в обратную сторону и перешли на HTTP/2 over UDP (aka HTTP/3) и получили более громоздкие реализации в пространстве пользователя, подверженные джиттеру и "затупам" userspace'а. Я просто напомню, что сначала предпосылкой было внедрение более агрессивных протоколов congestion control'а вроде BBR, но эта идея провалилась и подавляющее большинство реализацию использует условно старые CUBIC и RENO. Да, быстрое внедрение новых алгоритмов управления потоком может быть важно для сервисов доставки контента, которые всё это и затевали (привет, Гугл). Но это модификации только на стороне сервера и внедрение ядерной реализации для них настолько же трудоёмко, как и внедрение userspace'ной, пользователю менять ничего не нужно, исходящий трафик на Ютубе минимален. В результате получили новый протокол, который на 20-30% тупее TCP и представляет собой реализацию старого в пользовательском пространстве. Я уже не говорю о большом количестве проблем в реализациях. Начиная от кол-ва проблем в nginx и до "приколюх" вроде падения скорости в 3-5 раз у пользовательской реализации Firefox.

    Ну а в остальном да, прогресс. Прогресс на уровне очередного цикла оквадрачивания/скругления круглых/квадратных кнопочек в Android'е 😄

     
     
  • 2.5, Аноним (5), 09:57, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На "HTTP3" перешёл кто-то, кроме мегакорпов? Это же их игрушка. В частности Гугла.
     
     
  • 3.7, timur.davletshin (ok), 10:07, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > На "HTTP3" перешёл кто-то, кроме мегакорпов? Это же их игрушка. В частности Гугла.

    Ну, для начала, они составляют 9/10 трафика, а во-вторых и обычные сайты переходят тоже, что вызывает недоумение.

     
     
  • 4.10, keydon (ok), 10:44, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Мегакорпы тоже не перешли. Никто не знает как с этим жить. Если что и работает то чисто с учетом небольшого трафика с возможностью отключения/фэллбека на другой протокол в случае ддоса.
     
     
  • 5.13, timur.davletshin (ok), 10:55, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Мегакорпы тоже не перешли.

    Крупнейшие видео-сервисы перешли. У меня статистика в пользу UDP на роутере уже больше года как превышает TCP. В ряде академических работ разбирается то, что, например, Google использует в Youtube какую-то свою реализацию Congestion Control'а, которая отличается от BBRv1 и от ещё недоработанного BBRv2 — https://www.comp.nus.edu.sg/~ayush/images/sigmetrics2020-gordon.pdf (там в основном про TCP, но есть и разбор про Google Quic и его особенности).

     
     
  • 6.17, Аноним (17), 11:35, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле - гугль и гугль? Ну да, перешли. Им же важнее сэкономить копейку, а не чтоб у тебя было плавное воспроизведение и еще остался канал параллельно что-то другое делать.

    А вот зачем другие идиоты изо всех сил пытаются следовать - это действительно вызывает небольшое недоумение. Небольшое, потому что на то и идиоты. Несть числа им.

     
     
  • 7.18, timur.davletshin (ok), 11:38, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А нетфликсы всякие не считаются? Про гугл я не понял, т.к. проблема там не в буферизации, это вообще отдельная история. Я про то, что пользовательские реализации создают бОльшую нагрузку на систему, чем ядерные. Именно за это OpenVPN и критикуют. Но в главном сетевом протоколе HTTPS тренд совершенно обратный.
     
  • 7.28, Аноним (28), 14:25, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Земляне из всех сил пытаются себя уговорить, что весь этот так называемый рост и есть прогресс и развитие, типа "Не стой, замёрзнешь". Наверное. Их же никто не похвалил за этот путь. Но и не поругал. Вселенной сходить по-большому и жидкому на потерянную Землю. 😁

    PS "Жопа есть, а слова такого нет" )

     
  • 2.8, Аноним (8), 10:19, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >BBR runs purely on the sender and does not require changes to the protocol, receiver, or network,
     
     
  • 3.9, timur.davletshin (ok), 10:41, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > BBR runs purely on the sender and does not require changes to the protocol, receiver, or network

    Перечитай мой пост ещё раз. Я об это прямо написал. Я так же написал, что реальные пользовательские реализации отказались от него в пользу уже классических Reno/CUBIC (RFC тоже). У оригинального BBR есть проблемы к "честностью" и неадекватная работа с ECN. Кроме того, BBR есть и в ядерной реализации для TCP. Его зачем-то многие стали использовать (стадный инстинкт айтишников?) после пары статей во всяких Medium с заголовками типа "Как ускорить TCP на 100%". Описанные проблемы есть у обеих реализаций. Кроме того, у CUBIC уже достаточно давно появился включенный по умолчанию режим гибридного старта, что де-факто сделало его гибридным алгоритмом, а не packet-loss-based.

    P.S. Гибридные протоколы хороши, но на "длинных трубах", в локальных запросах они позорно сливают в дефолтном своём состоянии. BBR на локальном Wi-Fi сольёт CUBIC'у на 30-50%. Есть, например, CDG (две реализации, родная из FreeBSD и значительно расширенная тем же hybrid start реализация из Linux), который примерно на такой же процент сливает на локальном уровне, но его можно настроить, доведя уровень агрессивности до сопоставимого уровня. С BBR это не представляется возможным.

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

     
  • 2.29, Фняк (?), 14:48, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    «Логичность» подразумевает наличие какого-то гранд-плана, какой-то общей идеи, которой решение или соответствует или нет. В жизни этого нет. Есть множество акторов, которое занимаются тем что им в данный момент важнее/интересно
     
     
  • 3.38, timur.davletshin (ok), 08:56, 18/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Логичность подразумевает единый алгоритм принятия решений в схожих ситуациях. За "гранд-планами" в другое место.
     
  • 2.49, Аноним (49), 09:50, 19/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, ну надо же о каких-то успехах манажорам докладывать.
    Как говорил наш Ильич в небезывестном анедоте- "имитировать движение!".
     

  • 1.1, Аноним (1), 08:57, 17/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чем оно лучше wireguard?
     
     
  • 2.2, Жироватт (ok), 09:00, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Чем грузины. Проще в развертывании, более зрелая технология сама по себе, есть поддержка даже на утюгах. В отличие от хипстерского вайргарда.
     
     
  • 3.3, Аноним (3), 09:03, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    про проще я б поспорил :-)
     
     
  • 4.14, Аноним (14), 11:01, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Специально для вас:
    https://github.com/Nyr/openvpn-install и https://github.com/Nyr/wireguard-install
    Полтора действия для ленивых.
     
     
  • 5.50, Аноним (49), 09:51, 19/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    специально для Вас- я администрирую openvpn сервер около 18 лет.
     
     
  • 6.52, Аноним (14), 10:31, 20/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И к чему этот "невероятный" срок? Он должен сказать о каком-то профиссионализме или показать статусность?
     
  • 3.20, Аноним (20), 12:32, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Проще в развертывании

    Чего? Особенно, замороченность на X509 "проще".

     
  • 3.43, Аноним (43), 15:15, 18/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Упоролся или ты живешь в альтернативной реальности? Где это есть OpenVPN где нет Wireguard?
     
     
  • 4.51, Аноним (49), 09:59, 19/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    EdgeOS, например
     
  • 2.6, Abyss777 (?), 09:58, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Они разные, для разных целей.

    Когда нужно тоннели точка-точка создавать на разном оборудовании wireguard больше подойдет ИМХО.

    OpenVPN больше подходит для подключения многих клиентов к одному серверу. Сертификат сервера залил и всё. Клиенты сами там в CA себе получают и подключаются... Ну или Логины/пароли в radius или ldap ходить проверять.

    А с wireguard надо со всех еще открытый ключ собрать, в конфиг прописать, конфиг перечитать...

    wireguard стоит с ipsec сравнивать, вот тут точно он проще чем ipsec


    А, ну и OpenVPN умеет пушить маршруты

     
     
  • 3.22, Жироватт (ok), 12:51, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С точки зрения сетевого архитектора - безусловно. Разные задачи требуют разных решений, сравнивать их можно так же, как мультиварку и хлебопечку.
    С точки зрения админа - да, но не совсем. Разный геморрой в настройке и поддержании сетей. Разные возможности по развёртыванию на клиентском оборудовании, в т.ч. и старом маршрутизирующем, которое оптимизировано для себя может ходить по овпн, но не в курсе про вайргард. Разные сценарии, но задача одна - сделать туннель из пункта А в пункт Б.
    С точки зрения просто админа локалхоста с опеннета - уже нет, они одинаковые. Они создают туннель до некоторого уже готового сервера и вся разница сводится к чисто внешним признакам черного ящика: что быстрее и что проще настраивается.
     
  • 2.11, keydon (ok), 10:46, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    работает за натом без stun/turn серверов
     
     
  • 3.21, Аноним (20), 12:36, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Когда клиент за NATом только.
     
     
  • 4.23, Аноним (23), 13:00, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем сервер прятать за NAT?
    Уверен что через port-forwarding openvpn заведется, хотя я не проверял... (Не представляю зачем это может понадобится)
     
     
  • 5.24, Аноним (24), 13:13, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если домашнюю машинку хочется сделать видимой извне - не получится, все провайдеры сейчас держат юзером за натом. Если, конечно, не покупать белый ип.
     
     
  • 6.27, Сталин Жив (?), 14:18, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Далеко не все. В моем городе из более двух десятков провайдеров только 1 держит клиентов за нат. Хотя нат для простого обывателя скорее плюс – меньше головной боли с безопасностью.
     
     
  • 7.32, Sadok (ok), 19:27, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Открываем учебник для первого класса "Сеть для самых маленьких" и вдумчиво читаем главу "Почему NAT не файрвол"
     
  • 6.31, Аноним (8), 19:21, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В моей деревне до сих пор бесплатно айпишники выдают. И, судя по заявлениям прова, выдавать будут ещё не одно десятилетие. Так что насчёт всех ты перегнул.
     
     
  • 7.34, keydon (ok), 21:44, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что же это за провайдер? У всех российских проблемы с айпишниками в принципе. А корпы готовы платить за них солидную денежку.
     
     
  • 8.39, Судья из Калифорнии с опытом программирования (?), 09:41, 18/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    gtk su,например ... текст свёрнут, показать
     
  • 4.25, keydon (ok), 14:02, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда клиент за NATом только.

    А других вариантов и нет. Централизованные приложухи без белого (или серого в некоторых вариантах ната с ручным пробивом) ip сервера не работают в принципе.

     
  • 2.48, Аноним (48), 00:24, 19/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно отключить шифрование
     

  • 1.26, Сталин Жив (?), 14:15, 17/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тормозная хрень! Сжирает 50% скорости.
     
     
  • 2.37, Abyss777 (?), 07:12, 18/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.opennet.dev/opennews/art.shtml?num=55843
     
  • 2.45, Аноним (45), 16:18, 18/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для тебя специально придумали ваергард.
     

  • 1.30, Аноним (30), 18:15, 17/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > отовые бинарные пакеты формируются для Debian, Ubuntu, CentOS, RHEL и Windows

    Последние 3 лишние

     
     
  • 2.33, dullish (ok), 21:06, 17/03/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А первые 2 - ненужные.
     

  • 1.35, Аноним (35), 00:12, 18/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > готовые бинарные пакеты формируются

    Где формируются? Чет там не видно или это про apt ?

     
  • 1.36, Аноним (36), 06:47, 18/03/2022 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру