OpenVPN 2.7.6 исправляет обход ограничений Windows и ошибку проверки сертификатов

OpenVPN выпустил версию 2.7.6 спустя чуть больше месяца после предыдущего пакета исправлений безопасности. Релиз закрывает обход административных ограничений в Windows и ошибку проверки сертификатов в сборках с mbedTLS, а ветка 2.6 получила отдельное обновление 2.6.22. Параллельно разработчики изменили обработку TCP-соединений, DCO и размеров пакетов.

OpenVPN 2.7.6 исправляет обход ограничений Windows
OpenVPN 2.7.6 исправляет обход ограничений Windows

OpenVPN выпустил две исправленные ветки 5 августа

Парадокс нынешнего релиза в его масштабе: список изменений сравнительно короткий, но он затрагивает границы доступа, проверку личности по сертификату и поведение сетевого транспорта. Проект OpenVPN опубликовал версии 2.7.6 и 2.6.22 5 августа 2026 года. Исходные архивы и установщики Windows появились на официальной странице загрузок.

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

Версия 2.7.6 относится к современной ветке с новыми сетевыми возможностями. Версия 2.6.22 сохраняет прежнюю архитектуру и получает более узкий набор исправлений. Такой параллельный выпуск позволяет увидеть, какие проблемы общие для обеих веток, а какие связаны с механизмами OpenVPN 2.7.

CVE-2026-63649 обходила ограничения каталогов в Windows

Самое заметное исправление касается openvpnserv — системной службы OpenVPN в Windows. Она принимает команды через управляющий сокет и запускает процесс OpenVPN с переданными параметрами. Администратор может ограничить каталоги, из которых разрешено загружать конфигурационные файлы.

До версий 2.7.6 и 2.6.22 проверка командной строки была недостаточно строгой. Специально сформированные параметры позволяли обойти правило разрешённых каталогов и запустить OpenVPN с конфигурацией из другого места. Ошибка получила идентификатор CVE-2026-63649.

Разработчики отдельно уточнили границу проблемы: обход каталога не давал процессу права читать файлы, к которым у пользователя уже не было доступа в Windows. Системная модель разрешений продолжала действовать. Уязвимость нарушала административную политику OpenVPN, поскольку служба могла принять конфигурацию из пути, который администратор исключил.

Для управляемых рабочих станций и терминальных серверов разница существенна. Ограничение каталога часто отделяет проверенные конфигурации от пользовательских файлов. После исправления служба тщательнее разбирает командную строку, переданную через управляющий сокет.

CVE-2026-63650 затрагивала mbedTLS и имя пользователя в сертификате

Вторая уязвимость относится только к ветке 2.7 и исправлена в OpenVPN 2.7.6. Опция --x509-username-field позволяет выбрать поле сертификата X.509, из которого OpenVPN извлекает имя пользователя. Такой механизм встречается в инфраструктуре с собственным центром сертификации, где доступ связывают с атрибутами выданного сертификата.

В сборках OpenVPN с криптографической библиотекой mbedTLS эта опция работала некорректно. При очень специфической конфигурации и наличии подходящего сертификата система могла принять сертификат, который по заданному правилу должен был быть отклонён. Ошибка зарегистрирована как CVE-2026-63650.

Сам проект называет проблему уязвимостью низкого приоритета. Для её проявления требуется особая схема проверки и сертификат, созданный центром сертификации с совпадающими полями. Массовые установки с OpenSSL или без --x509-username-field этот сценарий не описывает.

Здесь человеческий угол связан с доверием к сертификату. Администратор видит корректную криптографическую подпись, а OpenVPN дополнительно должен извлечь правильное поле и сопоставить его с учётной записью. Сбой на втором этапе меняет решение о допуске, хотя сам сертификат остаётся технически действительным.

DCO восстанавливается после рассинхронизации ключей

Обе новые версии дорабатывают DCO — Data Channel Offload. Этот механизм переносит обработку зашифрованного трафика из пользовательского процесса OpenVPN в ядро операционной системы или специализированный драйвер. За счёт этого снижается количество переключений между режимами работы процессора и растёт пропускная способность туннеля.

Исследователь сообщил о ситуации, когда обновление ключа могло рассинхронизировать состояние OpenVPN и DCO в ядре. При точном совпадении событий процесс доходил до внутренней проверки ASSERT() и завершался. Команда OpenVPN сначала рассматривала отчёт как проблему безопасности, затем признала сценарий непригодным для эксплуатации.

Исправление всё равно вошло в обе ветки. Машина состояний теперь умеет восстановиться после рассинхронизации ключей. Для серверов с DCO практический эффект выражается в меньшей вероятности аварийного завершения при редком конфликте между пользовательской частью и ядром.

TCP_NODELAY включён для всех TCP-сокетов OpenVPN 2.7.6

Самое заметное изменение повседневного поведения относится к соединениям OpenVPN поверх TCP. Версия 2.7.6 всегда включает флаг TCP_NODELAY, который отключает алгоритм Нейгла.

Алгоритм Нейгла временно накапливает небольшие фрагменты данных и объединяет их в более крупный TCP-пакет. Такой подход уменьшает количество пакетов, но способен добавлять задержку. В интерактивном туннеле пауза заметна при удалённой работе с терминалом, передаче коротких запросов или использовании приложений с частыми небольшими сообщениями.

OpenVPN 2.7.6 отправляет такие данные без дополнительного ожидания на всех TCP-сокетах. Опция --tcp-nodelay остаётся в конфигурации: сервер использует её для передачи настройки старым клиентам, у которых новое поведение ещё отсутствует.

Изменение касается только транспорта TCP. Туннели OpenVPN поверх UDP работают по другой модели и флаг TCP_NODELAY там неприменим. Разработчики описывают настройку как оптимизацию задержки, без обещания одинакового ускорения для любой сети.

Конфигурация tun стала короче, а таймеры получили предел

OpenVPN 2.7.6 меняет ещё несколько пользовательских настроек. Если директива --dev отсутствует, программа теперь выбирает --dev tun. Раньше тип виртуального сетевого устройства требовалось указывать явно.

tun передаёт IP-пакеты третьего сетевого уровня и используется в большинстве маршрутизируемых VPN-конфигураций. Альтернативный режим tap работает с Ethernet-кадрами второго уровня и нужен для более специализированных сценариев. Новый вариант по умолчанию делает короткие конфигурации однозначными для наиболее распространённого режима.

Параметры --ping и --keepalive теперь ограничены 24 часами. Причина связана с DCO: ядру пришлось бы поддерживать произвольно большие значения и отдельно защищать 32-битные счётчики от переполнения. Сутки значительно превышают обычные интервалы контроля соединения, которые чаще измеряются секундами или минутами.

В справке сборок с mbedTLS больше не показывается параметр --providers. Он относится к механизму провайдеров OpenSSL и не работает с mbedTLS. Изменение убирает из --help опцию, недоступную в конкретной сборке.

Изменение в OpenVPN 2.7.6Где проявляетсяПрактический эффект
TCP_NODELAY включён постоянноТуннели поверх TCPНебольшие сообщения отправляются без ожидания объединения
--dev tun выбран по умолчаниюКонфигурации без директивы devТип устройства становится определённым без отдельной строки
--ping и --keepalive ограничены 24 часамиКлиенты и серверы с большими таймерамиDCO получает предсказуемый диапазон 32-битных значений
--providers скрыт в mbedTLS-сборкахВывод openvpn --helpСправка соответствует возможностям криптографической библиотеки

Расчёт пакетов Epoch и TLS-рукопожатия получили точечные исправления

В соединениях между OpenVPN 2.7 и OpenVPN 2.7 неверно вычислялся размер идентификатора пакета формата Epoch. Ошибка составляла четыре байта. В результате пакет мог превышать запас, рассчитанный параметром mssfix mtu, на те же четыре байта.

mssfix ограничивает размер данных внутри туннеля, чтобы итоговый пакет с заголовками OpenVPN помещался в допустимый MTU сети. Ошибка на четыре байта выглядит небольшой, но на маршруте с жёстким ограничением она способна приводить к фрагментации или потере пограничных пакетов. В 2.7.6 размер заголовка Epoch учитывается корректно.

Сервер теперь отклоняет входящие пакеты HARD RESET с идентификатором последовательности, отличным от нуля. Такие пакеты противоречат ожидаемому началу сеанса и могли мешать установлению TLS-соединения в конфигурациях «точка — точка».

Ещё одна правка уточняет минимальную длину Ethernet-кадров с тегом 802.1Q при использовании --client-nat. Исследователи дважды сообщали об этом как о возможной проблеме безопасности. Разработчики объяснили, что внутренние буферы OpenVPN всегда выделяются под полный кадр, поэтому чтение нескольких байтов за логической границей пакета не приводило к выходу за фактическую память и не имело вредных последствий.

OpenVPN 2.7.6 и 2.6.22 различаются по составу изменений

Две ветки получили общий набор исправлений для службы Windows, DCO, пакетов HARD RESET и кадров 802.1Q. Дальше их содержание расходится.

КомпонентOpenVPN 2.7.6OpenVPN 2.6.22
CVE-2026-63649 в openvpnservИсправленаИсправлена
CVE-2026-63650 в --x509-username-field с mbedTLSИсправленаВ журнале 2.6.22 не указана
Восстановление DCO после рассинхронизации ключейДобавленоДобавлено
Проверка HARD RESETДобавленаДобавлена
Исправление размера пакета EpochДобавленоНе относится к списку 2.6.22
TCP_NODELAY по умолчаниюДобавленоНе указано
Автоматический --dev tunДобавленНе указан

Полный список для современной ветки опубликован в официальном журнале OpenVPN 2.7.6. Изменения поддерживаемой ветки перечислены отдельно в журнале OpenVPN 2.6.22.

Разделение показывает характер релизов. OpenVPN 2.6.22 сосредоточен на исправлении общей ошибки Windows и устойчивости сетевой логики. OpenVPN 2.7.6 включает те же изменения, дополнительную проверку сертификатов и несколько корректировок поведения, заметных в конфигурации и TCP-трафике.

Масштаб уязвимостей и скорость распространения обновлений пока неизвестны

На 6 августа 2026 года точно известны идентификаторы CVE-2026-63649 и CVE-2026-63650, условия их проявления и версии, в которых код исправлен. В журнале проекта отсутствуют оценки CVSS и сведения о подтверждённой эксплуатации этих ошибок.

Windows-уязвимость затрагивает границу между управляющей службой и разрешёнными каталогами конфигураций. Ошибка mbedTLS относится к узкому сценарию, где имя пользователя извлекается из поля сертификата. DCO-рассинхронизация после анализа признана непригодной для эксплуатации, хотя её обработка стала устойчивее.

Пока неизвестно, когда OpenVPN 2.7.6 и 2.6.22 появятся в пакетах Linux-дистрибутивов, на маршрутизаторах и в сторонних VPN-приложениях. Хотя проект уже обнародовал исходные коды и установщики для Windows, сроки интеграции зависят от сопровождающих каждого продукта. В новом релизе установлены конкретные границы доверия и изменены некоторые сетевые параметры, поэтому его реальное воздействие станет очевидным после того, как сборки начнут распространяться за пределами официального проекта.

При использовании материалов сайта необходимо указывать ссылку на TGLand.ru. Если вы копируете фрагменты текста в интернете, прямая гиперссылка, доступная для индексации поисковыми системами, должна быть размещена в начале материала.

Вам также может понравиться