АРПП предложила создать орган для выработки политики в отношении VPN

АРПП предложила создать орган для выработки политики в отношении VPN

АРПП предложила создать орган для выработки политики в отношении VPN

Ассоциация разработчиков программных продуктов (АРПП) «Отечественный софт», объединяющая более 300 разработчиков ПО, предложила создать согласительный орган, который смог бы выработать «взвешенную политику» в отношении VPN. Компании, входящие в ассоциацию, готовы направить в него своих лучших специалистов.

Соответствующее предложение содержится в письме, которое АРПП «Отечественный софт» направила премьер-министру Михаилу Мишустину и главе администрации президента Антону Вайно.

Документ оказался в распоряжении РБК. В ассоциации подтвердили его подлинность.

«ИТ-сообщество умеет достаточно эффективно бороться с негативными явлениями в интернете — вирусами, атаками, мошенничеством, фишингом и спамом, и эти компетенции можно и нужно использовать», — говорится в письме за подписью главы ассоциации Натальи Касперской.

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

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

Как также говорится в письме АРПП, блокировки VPN затрудняют работу российских разработчиков ПО, поскольку многие компоненты с открытым кодом размещены на зарубежных ресурсах, а программисты нередко используют VPN, чтобы не раскрывать российский IP-адрес. Кроме того, отечественные компании привлекают зарубежных разработчиков, и блокировки осложняют взаимодействие с ними. Ситуацию усугубляют ложные срабатывания, из-за которых ранее блокировались репозитории Rust и пакетная база дистрибутива Linux Debian.

В документе также отмечается, что с технической точки зрения VPN сложно отличить от обычного зашифрованного трафика. Кроме того, в письме напоминается, что VPN не является единственной технологией обхода блокировок, а новые инструменты такого рода появляются постоянно. Не исключено и то, что действия регулятора могут подтолкнуть противников к имитации VPN-трафика, чтобы создавать сбои в Рунете.

Со своей стороны Роскомнадзор ранее заявил, что корпоративные VPN регулятор не ограничивает. В перечень исключений, по данным ведомства, вошли более 57 тыс. сетевых адресов свыше 1700 организаций.

Android-приложения научились обходить блокировку трафика вне VPN

Исследователь Армин Шупук обнаружил в Android механизм, позволяющий обычному приложению отправлять пакеты мимо VPN даже при включённой функции «Блокировать соединения без VPN». Никакого root-доступа, ADB и опасных разрешений не требуется — достаточно штатного системного API.

Проблема связана с NAT-T keepalive — короткими пакетами UDP/4500, которые поддерживают сетевое соединение активным. Android может поручить их отправку чипу Wi-Fi, минуя обычный сетевой путь приложения и проверки VPN Lockdown.

В результате установленная программа способна регулярно обращаться к выбранному злоумышленником серверу через физическую сеть. Передавать произвольные данные таким способом нельзя: содержимое пакета задаёт сама платформа.

Однако получатель видит реальный IP-адрес устройства, время отправки и факт его присутствия в сети. Этого достаточно для определения провайдера, сопоставления активности и отслеживания перемещений между сетями.

Исследователь подтвердил утечку на Pixel 8 Pro с Android 16: роутер фиксировал пакет вне VPN каждые десять секунд. На смартфоне Samsung соединение оставалось активным более 24 часов. Работа механизма также подтверждена на устройстве Nothing, хотя отдельный перехват трафика для него не проводился.

По оценке автора, проблема затрагивает большинство устройств на Android 12 и новее, поддерживающих аппаратную отправку NAT-T keepalive через Wi-Fi. Однако полноценные испытания выполнены только на трёх моделях, поэтому речь идёт об оценке класса устройств, а не о проверке каждого смартфона на рынке.

Отчёт передали Google 15 мая 2026 года. Корпорация признала его дубликатом уже зарегистрированной проблемы, но сведения о CVE, исправлении или сроках выпуска патча публично не раскрыты.

До устранения ошибки пользователям с повышенными требованиями к анонимности рекомендуют пропускать весь трафик смартфона через внешний VPN-маршрутизатор, отключив мобильную сеть и альтернативные подключения.

RSS: Новости на портале Anti-Malware.ru