Comments 520
Так вот оно что! То-то я с утра сижу и бьюсь уже целый час — через Hiddify и все тайм-аут. Короче, понятно. И ведь надо же! Скажем так: не зря им там зарплату платят...
Happ работает нормально сейчас. Отвалился на днях hiddify на винде и самсунге у семьи, пришлось перевозить. У happ конечно открытого исходного кода нет, но в целом на нем сижу уже с год, проблем не знаю. Плюс есть раздельное проксирование даже на пк, правда замороченнее, чем на телефоне. И если немного пошаманить по их мануалу, то автобут с автоподкобчением есть. Хз на сколько контора надежная, но вроде пока норм
На днях отвалились старые версии hiddify. С последней версией на линуксе и андроиде всё работает, у меня по крайней мере.
отвал какой-то частичный кстати, 1 сервер работает, а другой, который на телефоне пашет в таймауте
В итоге, в моем случае, дело было в том, что просто нужно было поменять домен на нейтральный и не вызывающий особых вопросов, скажем так. Снова все заработало в итоге. Но я именно на Винде пользовался Hiddify (да и Happ тоже). На смартфоне (у меня iOS), пожалуй, принимая во внимание описанное в статье не буду заходить ни в какие приложения кроме ТГ.
А пробовали обновлять данные профиля ("Update subscriptions")?
У меня тоже было такое пару раз, и это помогло.
На андройде AFWall+ может блокировать обращения приложений к localhost.
Указывайте, пожалуйста, что это только для rooted устройств, т.е 0.01%
Повод для очередного повышения цифровой грамотности населения)
root имеет свою цену, которую мало кто готов заплатить. Это банки, потеря Knox и так далее…
Knox, конечно, потеря, но это касается только Самсунга. В остальных случаях можно рут скрыть
А вы на практике пробовали рут скрывать? Это вечная война щита и меча. Сегодня удается крыть - завтра обнаружат.
У меня рут права и скрыто всё. Работает всё 3 года.
Для работы Mir Pay стоит модуль Pay Security Bypass. Если какое-то приложение жалуется на Root, в Magisk скрываю через Deny List
Собираюсь рутануться и поставить Magisk. Средствами magisk можно ли решить описанную в теме проблему? Например, посадить условный Max в песочницу, чтобы он думал, что он на телефоне Inoi подключён по wifi за лютым фаерволом, и открыт только https прокси на 10.0.0.1?
Если я правильно понял. То проблему уязвимости рутованных устройств это не решает. Понятно, что ещё нужно троян умудриться установить себе. Но вполне может и с обновлением какого-то приложения прилететь. И если я всё правильно понял, то лучше два устройство использовать, чем одно с root правами.
Нас ребут, а мы крепчаем :)
Magisk уже больше года ни хрена ни с одним банковским приложением не работает.
Я могу ошибаться в формулировке, но на lineageos через magisk скрыл рут права и пользуюсь банкингом и госуслугами уже около года без нареканий.
Мне такой подход нравится: по сути, отключу-ка я фичу безопасности, чтобы с этого устройства в банк ходить.
У меня знакомый есть, техдир в крупной компании, у него в заведовании случился зловред, который со счета юрлица несколько лямов украл, напрямую влезая в работу банк-клиента на ПК. Чувак офигел, никогда не верил, что кто-то такое сотворит, мишень для атаки оказалась совсем мелкой. А уж на своём телефоне, где стоит совсем одинаковый клиенты сбера и той же альфы с тиньком... Ну, в общем, рут штука такая, может и иной раз оказаться не совсем лишним.
Вот на PC рутом можно по страницам банков ходить, а на телефоне всё сразу становится плохо. Неужели линукс (на нем же андроид?) настолько хуже винды?
Линукс -- лучше. Но только если руту -- рутово, а пользователю -- пользователево.
(на самом деле вопрос в распространенности. десктопный линукс довольно редкий зверь и авторы зловредов просто не прикладывают достаточных усилий из-за незначительного выхлопа. чего не скажешь про андроид)
Так и не добрался купить рутующуюся модель телефона, но разве после этого увлекательного процесса все приложания становятся запущенными с рут правами, а не только те, которые мне надо? Думал что для произвольного apk с трояном ничего не должно поменяться. По хорошему оно про рутованность телефона и знать не должно. Только бекаперы, фаерволы та еще несколько системных утилит нуждаются к расширенному доступу. Ну или если охота в кишки кому-нибудь залезть.
Ведроид как был унылым недоделанным местами гуаном таковым и остаётся увы. Как его не крути он линуксом полноценным никогда не станет. Так как априори лишь базируется на линукс ядре.
Все что сверху данного ядра увы отношения к линукс увы не имеет.
Хорошо еще что китайцы на ряде своих устройств предпочитают весьма не слабо переделывать код ведроида, что бы свой собственный функционал реализовать, но увы все это не влияет на прискорбное состояние безопасности данной оси.
Magisk уведомляет, что приложение запрашивает root-права. Нужно больше деталей о ситуации, иначе при детальном разборе может оказаться, что root тут вообще ни при чём.
В остальных случаях можно рут скрыть
Я зарёкся так делать. Лишился на своей трубке возможности бесконтактной оплаты. А доступ к банковскому приложению так и не появился. One+
позвольте надушнить, swoo(балалайка для NFC оплаты альфа банком) нивкакую не видит KSU, даже без всяких модулей
Что за странная вещь этот Swoo? Выглядит как GetContact, только для дисконтных карт.
А чем собственное решение банка Alfa Pay не устроило?
https://www.alfabank.by/services-perevod/pay/
это не ко мне
Happ - уязвим и особо опасен, не рекомендуется использовать ни при каких обстоятельствах... Только что прилетело обновление на Happ и он перестал детектиться per-app-split-bypass-poc
Чушь.
Грамотность тут не причем.
Не составляет особо труда по гайду с 4пда рутировать устройство. Только попробуйте найти ещё устройства, в которых можно разблокировать загрузчик. С каждым годом их все меньше.
Так что зависимость не от "грамотности населения", как вы пренебрежительно сказали, а от самих устройств. Которых, опять же, с каждым годом все меньше.
Только попробуйте найти ещё устройства, в которых можно разблокировать загрузчик
Sony к вашим услугам. Там не то что разблокировать, кастомизация прошивок во все поля.
Разблокировать можно, кроме (пока) 1 VII и японских аппаратов.
https://developer.sony.com/open-source/aosp-on-xperia-open-devices/get-started/unlock-bootloader
https://wiki.lineageos.org/devices/#sony
Но комьюнити едва живое: lineage, еще полтора кастома да и всё. Это не десятые годы, когда там прошивок было на любой вкус и цвет.
Тенденция по заблокированным загрузчикам безусловно есть, но пока вариантов достаточно. Xiaomi (включая Redmi, POCO), Pixel, Samsung, OnePlus, Motorola, Sony. Там конечно подводных камней полно. Однако, на 4PDA они весьма подробно изучены.
> Xiaomi (включая Redmi, POCO)
Увы, у xiaomi процедура разлочки бутлоадера превратилась в лотерею с непредсказуемым исходом.
У Xiaomi есть квота на 2000 устройств в сутки. Для успешной разблокировки нужно скриптом кинуть запрос ровно в секунду обновления квоты. А так да, разблокировать можно.
разблокировать можно.
Кроме тех, что выпущены для китайского рынка и перешиты для продажи за пределы поднебесной. А их просто шквал на маркетплейсах из-за меньшей цены. Но и с "родными" сейчас всё очень плохо. Особенно из РФ с весёлым Чебурнетом.
Список производителей и моделей, где разблокировка бутлоадера возможна: GitHub - zenfyrdev/bootloader-unlock-wall-of-shame: Keeping track of companies that "care about your data 🥺" · GitHub
ЗЫ Под эти шпионские шняги недоверенные приложения из РФ был куплен Xiaomi Redmi 12 5G на Али. Разблокировка была доступна за ... $150. И то, недолго.
Samsung — уже нет. Устройства с OneUI 8, в том числе выпущенные раньше и обновленные, не позволяют разблокировать загрузчик.
Я вообще не знаю, дают ли Vivo и Honor возможность разблокировки загрузчика. Так что, возможно, рут на многих смартфона и вовсе невозможен. Можете посмотреть темы на 4пда или где еще, там все сдохло в этом плане с года 2020-21
Пф, проще за 15к отдельный телефон купить для ру приложений, чем гемороиться
Дык AFWall+ с iptables работает, а его долбаный гугель-мугель давно отрезал от простого трудяги))) Только с рутом. А рут сейчас далеко не на всех производителях поставишь, у BBK смартов, у Хуавея рута, увы, нету, в редких случаях на смартфонах, где умудрились взломать загрузчик)
Ойфон по той же причине отваливается.
Видимо, остается ждать пока поправят и выпустят обновы. Либо другие протоколы гонять.
На bbk смартах root имеется, но увы не на всех торговых марках которые данная контора выпускает. Коли мы говорим о root оптимальный выбор на сегодня устройства например от nothing phone, однако у них крайне специфическая разметка разделов памяти устройства если не дай бог что-то посыплется или сам напортачишь восстановить работу устройства будет мягко говоря проблематично.
Спасибо за наводку. В любом случае после новостей о принудительном обнаружении VPN траффика на андроид НЕОБХОДИМО накатывать рут. Без него вы от ВК и Сбера не скроете наличие VPN-клиента на телефоне, даже если он отключен (Модуль HMAL). Как ниже писали "Повод для очередного повышения цифровой грамотности населения"
Так простое решение ближе чем кажется .. Во первых не использовать клиенты отечественных сервисов во вторых можно использовать второй смартфон.. Это что бы пользователю не объяснять что ему можно и что нельзя очень долго) кроме того есть же разные варианты проксирования ..это не обязательно сокс и вообще не обязательно именно прокси и сплит тоннель..но за статью спасибо..информация полезна)
кроме того есть же разные варианты проксирования …это не обязательно сокс и вообще не обязательно именно прокси и сплит тоннель
Только у 95% населения это сокс и именно прокси
А вы не в курсе, на всяких Xiaomi, Realme и вроде даже Samsung есть второе пространство. Как оно устроено? Это отдельный пользователь в ОС по сути? Я к тому, если использовать в нём все приложения, которые потенциально занимаются слежкой (или наоборот ВПН + телега, Ютуб и т.д.), получится ли избежать такого способа слежки через описанную вами уязвимость?
Да, но уже существующие клиенты, получив обновление от "гос" приложения с использованием этого эксплойта - засветят свои VPN сервера.
Вопрос кто быстрее - клиенты обновятся или "гос" приложения.
А как быть "наружным" россиянам за границей? Им VPN в любом случае нужен. Иначе при выключенном VPN есть вероятность, что либо РФ-сервис не откроется, либо постучит кому положено, что пользователь находится за рубежом (пора проверять на налоговое резиденство, например).
Ну это решается резидентным выходным узлом и использованием веб версий приложения..
Арендовать Didicated Server где-то в РФ или размещать его у друзей / знакомых причем у маленьких провайдеров, где чуть меньше шансов что прибегут парсить логи коннектов.
Использовать белый VPN который одобрил РКН, но от идеи проверки на налоговое резиденство не спасёт (но оно пока и не реализовано).
Использовать ВПН от непонятно кого в РФ, но под веб версиями сайтов. Есть шансы что и за такие впны возьмутся, но "не сегодня" и опять же надо будет не только поднять логи коннектов но и содержимое трафика, чтобы узнать кто залогиниться в сайт в этого ВПНа.
---
Мой взгляд дилетантский и обывательский, не стоит брать его за идеальный вариант
а на законодательное регулирование доступа граждан РФ к сервисам внутри РФ похоже, вообще забить решили. Почему нельзя гражданину РФ пользоваться госуслугами (и прочими сервисами в РФ) из-за рубежа? - Покачену!
Живя в России, невозможно практически не использовать клиенты отечественных сервисов
Банк, маркетплейс, банально погода точная, карты - как минимум
Вполне возможно, я перестал использовать их за долго до всего этого..но это не значит что нужно отказаться от этих сервисов ..те же озон и Яндекс как карты так и такси и доставка еды вполне работают через веб сайт) а карт так и вообще полно альтернатив если нужно именно приложение )
Маркетплейс - без проблем, ни одного приложения ни разу не стояло. Погода, карты, почта - то же в браузере отлично работают. Единственное банк, тут как повезет, не у всех есть нормальный вэб интерфейс.
Дождаться пока клиенты заменят tun2socks на https://github.com/XTLS/Xray-core/tree/main/proxy/tun
Он скорее не работает, чем работает
Очень смелое заявление... В нем нет огромного чемодана управления сетью (менеджмент роутинга и ip адресов) который тянут за собой приложения типа tun2socks, но как интерфейс->xray core он вполне работает неплохо.
Это дизайн такой, не превращать приложение занимающееся трафиком в сетевой комбайн. Сетевым менеджментом должно заниматься приложение используещее библиотеку, но не сама библиотека которая занимается трафиком.
Очень смелое заявление…
Заявление человека, который пытался его использовать. Кроме того, что он не полнофункиональный, так еще и имеет примерно миллиард багов. То зависнет, то пакеты в /dev/null улетят, то еще что-то.
А для VpnService нужен полнофункциональный сетевой интерфейс.
И да, на андроиде скорее всего багов еще больше, я не видел ни один клиент, который его использовал бы. А вот к примеру в sing-box с этим проблем нет.
Он прекрасно работает, но я не вполне понимаю как он решает проблему сплит-тунелинга. Без изоляции сетевых пространств имён этот интерфейс точно так же доступен всем желающим, да ещё и аутентификации как в том же SOCKS нету by design.
А с изоляцией и localhost не проблема изолировать.
А в sing-box уже есть поддержка tun из коробки, кстати. Только, видимо, клиенты всё равно используют socks5 inbound, чтобы был общий интерфейс.
Мы уже догнали и перегнали китайцев в плане жесткости блокировок и борьбы с КВН. А значит халява закончилась и теперь придется писать софт их обхода самим. Беря за основу их опенсорсные наработки и приспосабливая их к нашим новым условиям.
...
iOS точно так же уязвим, на iOS точно так же уязвим Happ (проверено).
Не забывайте что на iOS вообще нет раздельного туннелирования, так что в целом обходить даже ничего не надо. Если у андроида будет шанс, то у iOS - нет.
Это не сплит туннелинг, это роутинг
А в чем разница, можете пожалуйста объяснить?
а что тогда такое сплит туннелинг? Это когда разделяешь туннелирование по определённым приложениям?
понимаю, вопрос названий, но по сути одно, другому не мешает. Говорить, что на иоси совсем этого нет – ну странно немного:
Смотрите, на пальцах есть два похода:
1) Смотрим, какое ПРИЛОЖЕНИЕ хочет попасть в интернет, если ПРИЛОЖЕНИЮ разрешено - оно использует VPN. Такое есть на android и нет на iOS. Это split tunneling.
2) Смотрим, на какой домен или IP хочет попасть приложение. Если IP или домен в списке - пускаем, если нет - нет. Это routing, такое есть везде, но это решето, потому что условный Макс может в любой момент просто взять и постучаться на сервер Telegram. Если он ожидает, что Telegram с вашего устройства доступен быть не должен, то увидев ответ "привет я телеграм", он может просто слить ваш IP куда надо.
Так иронично: едва ли не первая попытка собрать BigData в России для госнужд - это сбор IP адресов, 80% из которых принадлежат пользователям, зашедшим под впн помастурбировать на икс-хомяке.
вроде как и то и то split tunneling, просто первое это
app-based split tunneling
а второе
domain split tunneling (ну или на крайняк DNS routing)
А если оба подхода использовать. Ру прила по идее тогда, постучавшись, получит фиг, так как квн её не пускает
Это все до первого домена Макса где-нибудь в Польше, на той же впске за 5 баксов, которая живет только чтобы сливать ваши IP. Роутинг по доменам и геозонам - это решето, оно не работает против тех, кто за вас серьезно взялся.
странно думать что МОЖНО что—то утаить ХОДЯ в энторнет по Российским физическим каналам :) все равно пропалят по трафику и прокси и все что угодно, наше государство просто слишком лениво и неповоротливо чтобы превратить все эти потуги ваши укрыться от ока сарумяна в труху :)
Работает, если гнать в DIRECT абсолютно всё, кроме белого списка нужных вам доменов.
факт, "АЗС ГПН" на iOS уже год, как легко детектит vpn по списку интерфейсов и route table. Так что для iOS'еров 2 пути: сносить ру приложения или ходить с карманным роутером
Мне казалось, что в целом про Happ и его команду давно уже известно интересующимся, но видимо нет. И да, судя по информации в СМИ - в методичках отмечено, что на iOS есть проблема с детектированием из-за особенностей архитектуры, об этом тут, на хабре, так же есть статья.
в целом про Happ и его команду давно уже известно интересующимся
Можете подробнее рассказать про это тем, кто не сильно следит за этим всем? Спасибо
в методичках отмечено, что на iOS есть проблема с детектированием из-за особенностей архитектуры
Нагло врут, а то как эта новость разошлась по официальным СМИ, это только подтверждает.
очевидно, миру нужно приложение приложение псевдо-впн на мобилку, которое "сливает" ип произвольных серверов и тех, что в "белых списках".
Правильно ли я понимаю, что эта уязвимость актуальна только при включенном vpn клиенте (в том числе в режимах perapp/split-tunnel) ? При выключенном spyware к xray socks5 proxy никак не подключится? Если так, то "простое" решение отключить per-app и split-tunnel и включать vpn вручную(или чз автоматизацию) перед запуском условного telegramm с предварительной выгрузкой из памяти spyware-приложений.
Ну, только если вы готовы этим заниматься каждый раз и уверены, что не забудете когда-то в запаре.
на ios штатными средствами настраивается включение и выключение vpn при запуске/закрытии приложения, на android делается вроде через Tasker
Подскажите, как это делать на iOS?
Можно использовать Shortcuts. Но там задержка есть при автоматическом включении и отключении VPN.
На русском это приложение называется "Команды". Делаете автоматизацию, мол, открытие\закрытие приложения А будет триггером включения\отключения средств обхода блокировок
где гарантия, что прока вы чатитесь в условном телеграмме spyware-приложение не проснется (по таймеру, сайлент-пушу, жобШедулеру, етц) и не сделает свое черное дело?
Есть один клиент с поддержкой аутентификации Xray (репозиторий). Минусы только в удобстве: конфиг и правила маршрутизации придётся писать в json.
у меня сегодня отвалились 2 платных сервиса и 1 бесплатный, и причем часть сайтов в зоне ru тоже не открывается
Я теряю деньги из-за всех этих блокировок, что делать
GeoIP ни на сервере, ни на клиенте, ИМХО, не поможет ничем, у них хватит мозгов стучаться на арендованный для этой цели зарубежный хост.
Получается, на стороне сервера два IP будут необходимы.
А на стороне клиента - старый добрый фаерволл не подойдёт? Чтобы ни одно приложение без явного разрешения не могло стучаться на локалхост.
А на стороне клиента - старый добрый фаерволл не подойдёт?
Подойдёт. Просто запретить приложениям-стукачам прозванивать локальные адреса и усё.
Имхо тут оптимален только вариант белых списков со своей стороны - youtube/instagram/github и тп все заворичивается в туннель на какой то входной ноде, который ретранслирует уже трафик как есть на VPS с развернутым wg/vless.
А все что не входит в "белый список" - шлется напрямую дальше в интернет.
Да, это проблематично, да надо будет постоянно обновлять список на основе личного опыта, но так эти упыри гарантировано не увидят ip вашей впски, максимум айпи русской впски, являющейся входной нодой для всех.
На выходном VPS можно арендовать еще один ip и использовать его для выхода в интернет, или использовать еще один VPS, можете настроить Proxy, и никто её ip кроме вас и вашего российского хостинг провайдера не узнает. Всё таки необходимо заботится об удобстве при пользовании интернетом.
Кстати может быть кто-нибудь знает предоставляют какие либо из VPS провайдеров второй серый IP. Ведь для выхода не нужен белый ip
Можно почитать в комментах, этого недостаточно.
скаМ (и в будущем всем российским приложениям, которые обяжут поставить библиотеку с этой логикой под угрозой исключения из белых списков и лишения аккредитации) достаточно иметь один зарубежный сервер. Затем делается два запроса: один к серверу скаМ, второй - на подконтрольный зарубежный сервер. Если айпишники различаются - отправляем в блок иностранный айпишник.
Так в том и смысл, что на ваш зарубежный сервер идет трафик только для специфичных доменов, совершенно не важно какой впс разрабы скама купят, он не попадет в ваш "белый список".
В таком варианте тоже есть свои уязвимости и проблемы - начиная с того, что отказ входной ноды повлечет отсутствия интернета для вас, но зато как минимум вы свой ip не спалите вообще никак.
Для этого подставной зарубежный сервер Макса должен каким-то образом попасть в «белый список» на клиенте, о котором написал sloww. Не так ли?
Для андроид файрвол доступен только с рутом. Не на всех устройствах это можно сделать безболезненно.
" На сервере вам нужно заблокировать доступ обратно в geoip:ru:Есть ли инструкция, как это сделать? Не поломав доступ к самому серверу из РФ.
Диапазон loopback адресов от 127.0.0.0 до 127.255.255.255. Это 16777214 хостов. Диапазон портов от 0 до 65535. Умножаем 16777214 на 65535 и получаем более триллиона комбинаций. То есть решение простое со стороны разработчиков — дать юзверю возможность вручную устанавливать нестандартный адрес и порт (ещё лучше через рандомайзер адреса и порта), и пусть приложения-стукачи хоть обснифаются в попытках прозвонить искомый локальный адрес и порт.
А если и этого мало, как loopback можно поставить адреса из диапазонов 172.16 и 192.168 с соответствующим набором портов. Главное чтобы не было совпадений по пулам адресов при подключении к мобильной связи или Wi-Fi.
В v2RayNG порт можно поменять. В теории можно поставить любой до 65535, во всяком случае это на время задержит снифер (если он есть). Но проблема реальная и её надо исправлять. Правда относится она не к самому протоколу VLESS, а к его реализации.
При нормальной реализации просканировать локалхост можно секунд за 5. Сетевой задержки ведь нет.
Современные реализации masscan, zmap позволяют просканировать весь ipv4 интернет меньше чем за час. А тут вообще локалхост, как ниже написали.
Не проще просто клиенту генерировать случайный логин/пароль при запуске и передавать его уже tun2proxy? Тогда кроме как через tun2proxy никто не подключится.
К socks, но не к tun
https://habr.com/ru/articles/1020080/comments/#comment_29790062
Все мобильные клиенты на основе xray/sing-box запускают локальный socks5 прокси без авторизации.
Очень смелое утверждение. У меня в конфиге inbound только tun интерфейс.
Да такое ощущение, что автор просто хайпится на теме, как когда писали про то, что Макс просит разрешение к камере и прочему, как и любые другие мессенджеры. Недавно про прослушку ВПН затирал, будто другие приложения, в том числе иностранные, про включенный обход не через тест узнают.
Сейчас половина постов на этом хайпится, так что да, решили просто хайпануть
я специально искал вменяемый коммент вроде этого чтобы понять что я не один вижу
тезисы из его двух статей: они могут = они делают
безальтернативно
показано что MAX проверяет доступность хостов и статус VPN - значит цель Ловить пользователей с приватными VPN для РКН
а как же гораздо более необходимое для любого приложения, сразу навскидку:
-диагностика проблем подключения для улучшения UX ?
-AB-тестирование доступности сервисов в разных регионах ?
манипуляция и эмоции точно есть
Так точно, пока вы писали “ну может и не для блокировок Max это собирает” минцифры уже бизнесу рассылает требования помочь и заблокировать ВПНы.
Проснитесь.
а как же гораздо более необходимое для любого приложения, сразу навскидку:
Все эти аргументы уже обсосаны под соответствующими статьями. Для диагностики проблем подключения у VK есть сотни собственных серверов. И TURN-сервера у них тоже есть, которые сейчас с улюлюканьем абузят некоторые умельцы. Им не нужны сервера в Польше для этих целей, и определялок IP в ру-сегменте более чем достаточно, если по какой-то нелепой причине VK брезгует своими.
AB-тестирование доступности сервисов в разных регионах ?
Каких-таких сервисов VK в Европе? А к серверам Whatsapp они зачем стучались, тоже свою доступность проверять? Не надо их выгораживать, на таких поблажках и строится вся система защиты ура-патриотов "все не так однозначно, вот НА ХАБРЕ сказали, что ВК просто очень хочет пользоваться TURN-ами Whatsapp! Ничего такого в этом нет".
ни у кого тут нет достоверной информации чтобы заявлять однозначно, в том числе и у ТС, даже указанных выше методичек никто не видел
я сразу навскидку встречно альтернативы по твоим тезисам:
Приложение может проверять доступность конкурентов, чтобы выявить проблемы у пользователя с доступностью тг и прочих сервисов и предложением своего мессенджера.
Может использовать публичные сервисы (ifconfig.me, ipify) как нейтральные индикаторы выхода в интернет, что уменьшить количество точек отказа архитектурно, регулярно вижу такое в проектах ( пинги восьмерок при доступности своих DNS серверов и прочее)
никаких никому оправданий
очевидный же разрыв в логике
Вам повезло. У вас, вероятно, sing-box и правильный конфиг. К сожалению, большинство пользователей используют xray-based клиенты, которые построены на tun2socks.
А как tun помешает атаке? У него ж с авторизацией ещё хуже чем в socks5…
Официальный клиент sing-box для Android (SFA) использует VpnService напрямую, без SOCKS, так что он таким образом не детектится (если конечно ручками не добавлять SOCKS-inbound в конфиг)
Да, если у вас он не добавлен, то вы в безопасности. Просто обычно все его пихают. В статье так и указано:
в распространенных конфигурациях так же уязвимы.
а я правильно понимаю, что это тот самый переключатель "VPN\Proxy mode"
или как в Nekoray галочка - TUN mode.
И основное различие в том, что в режиме прокси - нужно явно сами апсы туда заворачивать (например выбирать "системный прокси"), а в режиме VPN (как он в v2rayNG называется) или TUN (в Nekoray) все идет через клиент и подвергается роутингу freedom\direct\block?
Или я совсем уже все напутал?)
Возможно ли выполнить данную атаку посредством web-app приложений? Если снести все ру приложухи со смартфона и перейти на web app, насколько высока вероятность успешности такой атаки?
Именно такую - нет. Браузер не даст подключиться просто так сделать запрос через порт на локалхосте.
Очень возможна. Например, так кое-какие две конторы систему отслеживания на Android сделали. На десктопе вспоминаю сразу апдейтер драйверов Intel - в трее висит сервер, а страничка на сайте работает как UI. В uBlock Origin есть фильтр "Block Outsider Intrusion into LAN" для хоть какой-то защиты от подобного.
Ну собственно по этой причине недавно наблюдались повальные запросы от веб сайтов к локальной сети? В целом в браузере же их и запретить можно
Браузеры постепенно и сами с этим борются: Chrome уже полгода назад запретил сайтам обращаться к локалхосту через загрузку ресурсов и fetch(), а в будущем это поведение будет распространено и на вебсокеты.
Все-таки это не критическая уязвимость. И это не относится к VLESS. Но тема открытого socks поднята верно, хоть и немного истерично.
У меня этот сканер из защищенного пространства Lineage (без рута, с гуглосервисами) ничего не нашел.
По сути это проблема конфигурации ядра. Ограниченность клиентов, которые не дают всё правильно настроить вручную. С тем же чистым sing-box такой проблемы нет (а с Nekobox, который его использует внутри себя, проблема есть). Активно пропагандирую использование оригинального клиента sing-box в статье на хабре: https://habr.com/ru/articles/1018964/
Правильные с моей точки зрения шаги:
Убираем mixed inbound в конфиге для Andoid. А если не убираем, то добавляем логин и пароль: https://sing-box.sagernet.org/configuration/inbound/mixed/
Добавляем плохие пакеты в
exclude_packageнастроек tun inbound (в статье по ссылке я туда добавил клиент Max). Эти пакеты (программы) не будут попадать в tun. Данную настройку можно переопределять в интерфейсе sing-box для Android (галочками выбирать приложения).На всякий случай добавляем плохие пакеты в правила маршрутизации по
package_nameв direct (в статье я так поступил с Max). Если приложение вдруг попадет в tun или в не удаленный mixed inbound, то оно всё равно пойдет в обход прокси, потому что правила маршрутизации работают и при поступлении трафика в ядро через локальный socks.
не то чтобы уязвимость, скорее недочет архитектуры клиентов xRay, но додуматся до такого - гениально, респект, исправил эту проблему в своем клиенте olcNG, спасибо вам еще раз!
А спасет ли ситуацию использование "второго пространства"? То есть все "ру" трояны в отдельном пространстве, а все остальное в отдельном, включая квн
Нет, не спасает.
В Xiaomi со второго пространства видно открытый socks порт.
Аналогично в GrapheneOS с Shelter.
т.е. смысла бежать покупать pixel особо нет? sandbox graphen'a не поможет?
А вот это прям огорчило, у меня как раз пиксель, думал графен поставить на него, но похоже что он все таки не настолько защищен? Или им куда-то можно написать чтобы добавили такую защиту в очередном обновлении?
ниже тут уже писали, что графен в курсе и может даже уже пофиксили
https://habr.com/ru/articles/1020080/comments/#comment_29791304
Очередная победа mihomo клиентов + для угарелых голый sing-box
Так же самые распространенные Clash и Sing-box клиенты в распространенных конфигурациях так же уязвимы.
А всякие Clash используют ядро Mihomo.
где там xhttp и finalmask в mihomo? А мне надо, уж извините.. Если вдруг уже стали поддерживать это, особенно xhttp с его обфускационными фиксами, буду очень рад
В happ ещё и при попытке настроить раздельное туннелирование все правила сбрасываются на дефолтные походу при каждом запуске
В идеале такие приложения должны использовать :0, т.е. генерировать автоматически свободный порт. Да, его все равно можно сканировать, но в сочетании с авторизацией должно быть норм. Есть вероятность, что в каких-то клиентах это уже будет работать.
а что по поводу клиента амнезии?
Я его не проверял, если честно.
Тоже интересно. Они же тут на Хабре есть. Может отпишутся
AmneziaVPN 4.8.14.5 (latest в playmarket) уязвима через socks без авторизации.
Только что проверил через termux, запихнув его в список-исключения.
Уже ишью написал ктото https://github.com/amnezia-vpn/amnezia-client/issues/2452
Прикольно обвинять команду Happ во лжи, основываясь на своих домыслах.
Теперь по делу:
Мы уберем HandlerService, который болтается у нас со времен царя гороха. Прошу заметить: если вы трупровайдер VPN, то наверняка кидаете свою JSONподписку, а значит, там его нет. Пароль на socks, который будет генерироваться случайно на каждое подключение, да, сделаем. Самая главная дичь: в iOS вы никогда не сможете защититься от проверки на VPN, потому что условный Max всегда сможет отправить пакет на условный ipaddress.my и узнать IP. Поэтому спекулировать и орать «смотрите, они плохие» может каждый. Вы предложите решения, если они правда существуют, а мы не поленимся и сделаем их для вас. От себя могу порекомендовать делать мосты в соединении, чтобы, даже если кто-то узнал ваш выходной IP, он не смог узнать входной.
Вас обвиняют не в отсутствии пароля на socks5, этим страдают буквально все xray клиенты и часть sing-box.
Вас обвиняют в том, что вы создали огромную дыру запустив xray api и отказались исправить ее после сообщения о ней 10 марта 2026 года.
А если не затруднит. Мне для личного расследования, скиньте пожалуйста на почту admin@happ.su где и кто отказался, что-то исправлять.
Ну на самом деле отказ был по началу даже канале “Флудилка” вашего телеграмм чата уже после выхода статьи даже под общественным давлением.
У вас с 10 марта был доступ к репозиторию.
Если вас интересует именно переписка, то она была в почте. Как раз с admin@happ.su
Если ваша позиция изменилась, вы можете заявить об этом однозначно и я добавлю UPD
del
А генерировать пароль динамически - никак?
Хорошо, мы поставим пароль на socks
Поставьте
Через день-два разрабы Max глянут пароль и научат Max подключаться к socks по паролю
Поставьте динамический
В чем проблема?
Если я правильно понимаю, приложения не используют этот локальный прокси-сервер напрямую, вы можете генерировать случайный порт и случайный пароль при запуске. Дальше max пусть брутит сколько хочет.
По тону комментария реально подтверждается утверждение автора статьи о манере общения :)
Я думаю, в любом случае блокировать приложения-стукачи надо на стороне КВН-серверов. Потому что невозможно заставить миллионы нешарящих пользователей обновить клиенты (а некоторых - ещё и отказаться от любимой Windows-7, под которой запускаются только достаточно древние версии).
Кстати да, единственный рабочий вариант на данный момент. Запретить выход во первых на geoip:ru сервера, во-вторых, на сервера приложений-стукачей (типа того же Скама).
А вот такой роутинг - хороший выход?
https://github.com/frayZV/simple-ru-routing
Для клиента - хороший роутинг. Для сервера не подойдёт. Там должно быть что-то вроде geoip:ru -> blackhole.
Не выход, но хорошая практика для рентгена, отдавать роутинг на сторону клиента. Советуют каскад/мост из двух серверов, где точка входа ру-сервер, а выход eu-сервер, образно, чтобы не парится с отдачей роутинга для всевозможных клиентов рентгена, где трафик для ру оставляем на ру-сервере, заблокированное на eu. Но это все равно не поможет, стукач приложение проверяет доступны ли сервера telegram, whatsup..., а они доступны, через выходной сервер, и никакой роутинг не поможет, ни серверный, ни клиентский, что печально, ждем фикса клиентов)
Решение есть, использовать mihomo и singbox клиенты, с правильно отдаваемой конфигурации, только tun.
А что помешает этим приложениям так же как и вам, лезть на арендованные из хозяевами VDS сервера в Европе и стучать через них таким же образом как вы обходите блокировки? Вот мы и поменялись ролями)) Сперва Роскомнадзор пытался блочить нам сервера, а мы говорили - мы все равно прорвемся, все сервера не заблокируете! А теперь наоборот, мы пытаемся заблочить его, а он будет кричать мы все равно прорвемся, все сервера не заблокируете!
Это невозможно. Как вы отличите запрос от условного озона к условному check-my-foreign-ip.com от вполне легитимного запроса туда же?
Вот например:
Условный озон при каждом запуске подгружает список зарубежных и отечественных чекеров, кэшируя их.
При каждом запуске он чекает ip через эти сервисы.
Когда-нибудь пользователь забудет выключить vpn и попадётся.
Вносить чекеры в блэклисты на сервере бесполезно, их очень много + ничто не мешает РКН тихонько свои поднять.
Маршрутизировать только заблокированные ресурсы просто нереально, если невозможно делать это по домену 2 уровня, потому что доменов 3 уровня у того же ютуба - воз и маленькая тележка. А у инсты они вовсе динамические. По подсетям - еще хуже, админить нереально, как и проверять, не затесался ли в подсеть какой-нибудь чекер.
Только сплит туннелирование по приложениям и фикс описанной в статье дыры спасут, имхо.
Ну и разделение входного и выходного ip, лучше вообще у разных хостеров.
Забанят выходной и черт с ним.
Простите за тупой вопрос, а как это делается? Здесь речь идет о https://docs.rw/docs/learn/server-routing об этом? Если рассматривать настройку на примере данной панели? Т е по такой же схеме коннектимся к условному серверу в Германии а выход будет из Финляндии ? благодарю!
Как вы отличите запрос от условного озона к условному check-my-foreign-ip.com
Если условный озон не будет открываться у пользователя без выключения vpn, это простимулирует пользователя таки настроить раздельное туннелирование, обновив сначала клиент.
@runetfreedomПодскажите, а нет ли у вас планов добавить ваш пресет настроек из v2rayN в v2rayNG? Было бы очень полезно, а то думаю почти все пользователи v2rayNG сидят на стандартном китайском Domestic DNS...
Если для этого нужен Android девайс, то думаю народ может помочь с этим)
Да я сам сижу на v2rayNG…
Я постараюсь найти время и сделать
ужеж всё есть, assets там уже есть runetfredom/geoip а json с роутингом можно взять отсюдова
Вы путаете настройки маршрутизации и настройки самого клиента. Я говорю про пресет настроек для раздела Settings, а не assets. В v2rayN прессет Russia включает в себя не только настройки маршрутизации, но и DNS серверов.
Очень ждем того же и для v2rayNG, ну или хотя бы на первое время текстовую инструкцию для обывателей о том, что куда прописать
На Android есть замечательный VPN клиент - Husi, основанный на sing-box. Public Archive так как автор мигрировал в другой репозиторий. Кроме того, данный VPN - клиент поддерживает маршуритизацию трафика по типу протокола(TCP, UDP и др.), по типу подключения (WI-FI, мобильные данные и др.).
AmneziaVPN Xray тоже уязвим из-за прокси. Это сложно пофиксить? Даже если сокс не закрыть, можно генерить на него пароль при каждом запуске.
Amnezia VPN можете прокомментировать, пожалуйста?
выше ветка обсуждения, там пишут что уже подсветили эту проблему:
https://habr.com/ru/articles/1020080/#comment_29791810
Оригинальный xray клиент умеет закрывать свой сокс5 паролем.
На iOS довольно попсовый клиент Shadowrocket. Как с ним дела обстоят?
интересно шо как с shadowrocket на ios
у меня нет возможности проверить, скачайте tcp port scanner и просканируйте 1-65535 на 127.0.0.1
Можно выбрать тип прокси HTTP или TUN Mode, но при втором варианте какие-то явные проблемы с загрузкой контента, начинает торчать порт который можно указать вручную, а также в адрес прокси тоже есть два варианта 127.0.0.1 и еще один.
но есть еще какая-то настройка "цепь прокси" где можно выбрать айпи, порт, логин и пароль. Возможно что это решение и как потестить?
Проверил, там без авторизации socks на 1082 порту, ip сервера возвращается. Неприятно.
По умолчанию торчит открытый 1080, но можно поменять на произвольный: настройки => прокси => порт
Получается что ваша DLL для проксирования голосового чата в Discord становится все более актуальной, раз TUN mode лучше выключить из-за UDP
Через час после публикации статьи разработчик Happ в своей телеграм группе отказался считать это уязвимостью и отказался исправлять даже под давлением своей собственной аудитории
а я не понял, что он должен исправить?
заменить порт 1080 на что-то иное? Но кто мешает злобным сканерам перебирать все открытые проты?
включить там авторизацию? но как быть с приложениями которые не умеют в прокси а просто ходят в интернет?
включить чистый роутинг/tun? но как заставить ходить spyware мимо этого tun?
Статья алармит: "на меня не реагируют", но как должны среагировать разработчики я не понял.
включить там авторизацию? но как быть с приложениями которые не умеют в прокси а просто ходят в интернет?
А как они сейчас ходят? Через tun2socks.
включить чистый роутинг/tun? но как заставить ходить spyware мимо этого tun?
Как и сейчас - через VpnService
ну так и что должны сделать разработчики v2rayTun, например? я так и не понял.
На проксю повесить ротацию портов + паролей, из-за чего сторонние сервисы не смогут через нее ходить и пойдут только как требуется через VpnService
если порты будут ротироваться, то приложениям тоже нужно будет постоянно менять настройки портов. но это не будет мешать spy сделать nmap и посмотреть "какие порты открыты?"
если авторизация будет у прокси, то далеко не все приложения смогут в это сходить. смысл прокси теряется
если же настроить tun, то как изолировать от него spy? непонятно
я пока не понимаю, какой комплекс мер предлагается для устранения "критической уязвимости vless"?
Включить авторизацию для socks5. Так же, как и все остальные.
Есть ли у вас свой тг канал где вы обсуждаете данную тему и какие клиенты безопасны для использования сейчас?
Что там с karing, тоже самое?
Открою вам страшную тайну (о которой не знает даже Минцифры): и на Android, и на iOS, и на Windows, и на Linux, и на macOS любая программа может выполнить запрос через любой сетевой интерфейс в системе.
Только что проверил на Android:
Устанавливаем VPN-соединение, отправляем запрос напрямую — IP VPN, через wlan0 — IP Wi-Fi
В VPN-клиенте настраиваем исключение для отправляющей программы, делаем запрос — IP Wi-Fi, отправляем через tun0 — IP VPN, т.е. исключение для программы обходится.
Достаточно в Termux запустить curl ifconfig.co --interface tun0, если на телефоне ядро 5.7 или новее (SO_BINDTODEVICE для непривилегированных пользователей появился с этой версии), а если старше — управлять через Network.bindSocket
Binds the specified DatagramSocket to this Network. All data traffic on the socket will be sent on this Network, irrespective of any process-wide network binding set by ConnectivityManager.bindProcessToNetwork. The socket must not be connected.
Per-app VPN это просто намёк программе на то, какой интерфейс (таблицу маршрутизации) использовать по умолчанию. Заблокировать это можно только галочкой “Block connections without VPN”, в этом случае сломается доступ к устройствам в локальной сети (принтеры, телевизоры, умные устройства, и т.п.).
А Happ пользуются исключительно потому, что во всех этих прокси-протоколах нет понятия сессии, и заблокировать конфиги для конкретного устройства нельзя, пользователи могут делиться ими бесконечно.
В Happ сделали HWID, прямо как в старфорсе :D
На сервер отсылается HWID и сервер не выдаёт ключи больше, если хоть раз они скачивались с одного HWID. Экспортировать их тоже нельзя.
Пользователям он не нужен, он нужен сервисам.
Так и есть ) А можно вместо tun0 создать интерфейс tun0398fgx0?
Получить список интерфейсов тривиально. Наберите в termux ifconfig
Действительно, сначала попробовал ip a, и получил access denied. Радость была преждевременной. Что ж, скрыть выходную точку от РКН не получится, ставь или нет на socks пароль. Нужно и от tun избавляться, получается.
В knox termux не запускается. Интересно, значит ли это, что и список интерфейсов нельзя будет получить?
Отличная находка, уже начал допрашивать искусственного идиота по поводу собственной реализации, вот что он накидал, кому интересно:
Скрытый текст
Android’s “Block connections without VPN” (lockdown) is the only real defense against the bypass technique in that comment. But users hate enabling it because it kills their LAN: Chromecast stops working, printers disappear, smart bulbs can’t be reached, web UIs on 192.168.1.1 time out. So most users leave lockdown off, and the bypass remains exploitable.
If we can make lockdown not break LAN, suddenly there’s no reason to leave it off. That’s what excludeRoute() does.
What excludeRoute() does (API 33+, Android 13+)
Normally, addRoute(“0.0.0.0”, 0) tells Android: “send all traffic to my TUN interface.” excludeRoute() punches holes in that: “…except for these subnets, send those out the physical interface as normal.”
So at VPN setup time on API 33+ we’d do:
builder.addRoute(“0.0.0.0”, 0) // existing — catch-all to TUN builder.excludeRoute(IpPrefix(“10.0.0.0/8”)) // private LAN builder.excludeRoute(IpPrefix(“172.16.0.0/12”)) // private LAN builder.excludeRoute(IpPrefix(“192.168.0.0/16”)) // private LAN builder.excludeRoute(IpPrefix(“169.254.0.0/16”)) // link-local (mDNS, AirPlay) builder.excludeRoute(IpPrefix(“224.0.0.0/4”)) // multicast (Chromecast/SSDP)
Now: Internet traffic → VPN. LAN traffic → physical Wi-Fi. Lockdown can be on without anything breaking.
The flow for one user end-to-end (API 33+)
App detects isLockdownEnabled() == false → dashboard shows a yellow warning card: “App-level VPN exclusions can be bypassed. Tap to enable system lockdown.”
User taps → opens Settings.ACTION_VPN_SETTINGS → flips “Always-on VPN” + “Block connections without VPN” → returns.
App detects lockdown is now on → warning card disappears, replaced by a green “Lockdown active” indicator.
Because we excluded RFC1918 routes, their printer / Chromecast / router admin page still work. They have no reason to turn it back off.
The flow for SDK < 33 (Android 10, 11, 12)
This is the awkward part. excludeRoute() literally doesn’t exist on those API levels — there’s no compat shim. Two realistic sub-options:
Sub-option A — degraded experience, honest warning (what I’d recommend):
On API < 33, we can’t carve out LAN. We still detect lockdown and show the same warning card.
But the “Fix it” CTA gets an extra line: “Note: enabling lockdown on your Android version will also block local network devices (printers, Chromecast). Upgrade to Android 13+ for full LAN compatibility.”
User makes an informed trade-off. If LAN matters more, they leave lockdown off and accept the bypass risk; if security matters more, they enable lockdown and lose LAN. Same status quo as today, but now they know.
Sub-option B — IP-route trickery (not recommended):
We could try to approximate excludeRoute() by not adding 0.0.0.0/0 and instead adding many narrow addRoute() calls covering “everything except RFC1918.” That’s the standard pre-13 workaround.
It works in principle (e.g. add 0.0.0.0/1 + 128.0.0.0/2 + 192.0.0.0/9 + 192.169.0.0/16 + … carefully splitting around the LAN ranges).
But it’s fragile, ugly, easy to get wrong, and hard to reason about. Mistakes leak.
Verdict: not worth it. minSdk is already 29, and Android 13+ adoption is high enough that the cleaner path (option A — honest warning on old versions, real fix on new versions) is fine.
TL;DR: нужен sdk 33+, не проверял лично пока, сейчас займусь.
UP: стена под спойлером решает проблему доступа к LAN, проблему доступа приложений без разрешения оно не решает.
Include/excluderoutes управляет маршрутами для главной таблицы маршрутизации. Если приложение забиндилось на интерфейс, оно их игнорирует (в обе стороны) — только что проверил на примере OpenVPN for Android, который настроил в режим «только локальная сеть» (маршрут только на диапазон выданного адреса). Curl’ом удалось достучаться до ifconfig.co через tun0.
Подумайте о другой стороне проблемы: многие программы, предназначенные для работы в локальной сети, отправляют ответы на запросы из локалки через направильный интерфейс (через VPN), потому что не биндятся на тот интерфейс, с которого получили запрос. Это типичный баг. Я даже просил разработчиков VPN-программ по умолчанию вводить подобные исключения хотя бы для broadcast-трафика (потому что он вообще в L3 VPN маршрутизироваться не должен, а L2 Android не поддерживает): https://github.com/schwabe/ics-openvpn/issues/1847
Выглядит как баг в Android. В документации к VpnService.Builder.addAllowedApplication сказано:
Adds an application that's allowed to access the VPN connection. If this method is called at least once, only applications added through this method (and no others) are allowed access. Else (if this method is never called), all applications are allowed by default. If some applications are added, other, un-added applications will use networking as if the VPN wasn't running.
Network.bindSocket(vpnNetwork) работает и делает ACL через ConnectivityService, но он не закрывает setsockopt(SO_BINDTODEVICE, “tun0”) - это ядро Linux, на ядре 5.7+ оно доступно непривилегированным пользователям и обходит ACL.
И действительно похоже на баг, даже два (еще позволяет отправлять запросы в обход установленных VPN-приложением маршрутов). Я был уверен, что это by design, но нет — Network.bindSocket даёт отлуп, а SO_BINDTODEVICE обходит даже allowBypass и allowFamily.
@m0xf, @nidalee, поможете корректно описать проблему в Google? Я сделал PoC, обходящий несколькими методами несколько разных конфигураций.
Запряг Claude уже писать, благо уже накидан достаточно жирный док на эту тему. Параллельно ищет решение в коде\архитектуре впн приложения, может что-то найдется.
Драфт багрепорта закинул на альтернативный пастбин, там есть TBD плейсхолдеры, я еще не запускал реальные тесты.
В GrapheneOS это фиксили похоже: https://grapheneos.org/releases#2025072700
This release resolves 2 upstream Android VPN leaks discovered by GrapheneOS and our community testers.
prevent using SO_BINDTODEVICE to bypass VPN lockdown mode (leak protection) to resolve an upstream Android VPN leak discovered by GrapheneOS testers where code specifies a specific interface via a special system call to bypass the VPN
prevent using NsdService#connect for components restricted by VPN lockdown mode to prevent a very limited upstream Android local network VPN leak discovered by GrapheneOS
https://github.com/GrapheneOS/os-issue-tracker/issues/2381
Фикс: https://github.com/GrapheneOS/platform_packages_modules_Connectivity/pull/33/changes (запретили SO_BINDTODEVICE пакетам из списка)
У меня и так последний Graphene. Я только что поставил Pixel OS, чтобы перепроверить на стоке (тоже работает).
Судя по репорту, раньше SO_BINDTODEVICE обходил даже системную опцию “Block connections without VPN”, и закрыли именно это.
Смотрите что нашел Claude Opus:
Скрытый текст
### 2. Surface
uid=-1fromgetConnectionOwnerUidas a user-facing alert (RECOMMENDED — Path A confirmed viable)This is now the recommended ship target. Path A revision (2026-04-07, confirmed empirically that calling
ConnectivityManager.getConnectionOwnerUidfrom Skyfall's own service UID, on every new flow read off Skyfall's tun fd, returns:- The real owning UID for any kernel-routed flow, including from other UIDs (verified for Chrome
uid=10154, Skyfall's own bridgeuid=10235).-
-1(Process.INVALID_UID) specifically and only for SO_BINDTODEVICE'd flows, regardless of caller UID.The discriminator is the bind mechanism, which is the exact property that makes the attack distinguishable from legitimate traffic. There were zero false positives observed in the production verification run — every Chrome browsing flow, every Skyfall bridge flow, every legit whitelisted app flow resolved to its real UID.
#### Implementation
Already partially in place — Path A added a JNI callback
notify_new_flow_checkinapp/src/main/cpp/tcp.cthat fires at the new-session SYN point and callsTun2HttpVpnService.onNewFlowCheck(proto, localIp, localPort, remoteIp, remotePort). The handler queriesgetConnectionOwnerUidand currently logs to thePathAtag. Productionising it requires:1. Whitelist comparison. When
uidis a real value, check it against the user'spref_vpn_allowed_application(orpref_vpn_disallowed_applicationin blacklist mode). Real UIDs that match the policy are fine. Real UIDs that violate the policy are also anomalies worth surfacing (this would only happen if Android's per-UID routing rule had a bug — never observed but a useful invariant check).2.
uid == -1is the attack signal. Increment a counter; record (proto, dst, port, timestamp).3. Sliding window + thresholding. First-flow vs sustained-pattern policies. A first-flow notification is the strongest possible signal because the attack only needs one round-trip to leak the exit IP — alerting after N events misses the exfiltration. Recommendation: alert on the very first
uid=-1event of any session, with optional rate-limiting to avoid notification spam if a misbehaving system service somehow generates many.4. Settings toggle: detection vs hard-stop.
- Detection mode (default for first release) — show a persistent notification "Untracked traffic detected on VPN — your exit IP may be exposed", with a tap-target to a details screen showing the destination IP/port and timestamp.
- Paranoid mode (opt-in) — immediately call
stopVpnWithError()on the firstuid=-1flow. Accepts the (small) risk of a stray system-service flow killing the VPN in exchange for a hard fail-stop before the leak completes. Recommend offering this only to users who explicitly opt in via a Settings toggle.5. Localised strings — both English and Russian, following the existing
values/strings.xmlandvalues-ru/strings.xmlpattern.#### Pros
- No special permission required (
getConnectionOwnerUidis part of the public framework API and the VPN owner has access by virtue of holding the tun fd).- No polling. Triggered by the actual event (the SYN arriving at the native tun reader).
- Cheap (~100 lines of Kotlin + the JNI callback already in place from Path A).
- Catches the attack at the moment it happens — not minutes later via stats buckets.
- Empirically validated discriminator. The smoking gun: in the Path A verification run, Skyfall's own bridge →
uid=10235, attacker SO_BINDTODEVICE →uid=-1, run side-by-side on the same tun in the same second. No ambiguity.- Independent confirmation in another VPN client: [sing-box's process detection](https://github.com/SagerNet/sing-box) logs
router: failed to search process: android: connection owner not foundfor exactly this case — same observation, different codebase.#### Cons
- Detection, not prevention. The TCP handshake completes before
onNewFlowCheckfires, and a fast attacker can complete an HTTPS round-trip in 50–100ms (verified in the smoking-gun ifconfig.co run). Paranoid mode mitigates this by tearing down the VPN on the first event but cannot retroactively prevent the leaked first request.- False-positive risk on edge cases is unmeasured at scale. Path A saw zero false positives in the verification run on a single emulator over a few minutes of mixed Chrome + Skyfall traffic. Long-term real-device behaviour may surface rare edge cases (e.g. very-short-lived kernel sockets evicted before the lookup happens, certain system services). Recommend a 1–2 week telemetry window with the detection-only mode before shipping paranoid mode by default.
- A sophisticated attacker could skip SO_BINDTODEVICE entirely if they discovered another path into the tun. None known today (Path A ruled out
Network.bindSocket— it returnsEPERMagainst the VPN network), but the workaround only catches the specific attack class we know about.**Verdict:** ship it. This is the only confirmed-viable defensive signal we have. Detection-only by default, paranoid mode behind a Settings toggle. Estimated effort: half a day to productionise (the JNI callback and
getConnectionOwnerUidplumbing already exist from Path A; what's left is the policy comparison, sliding window, notification UI, Settings toggle, and i18n strings).
Чем можно проверить в shelter? Termux туда не хочет заезжать
Спасибо огромное за находку. По-моему она важнее, чем то, что написано в статье. Проверил сейчас с чистым sing-box. И правда приложение может выбирать интерфейс, правила исключения из tun тогда не работают. Если включить в системе "Block connections without VPN", то выбрать wan0 уже не получится. Но если выбрать принудительно tun0 (а не просто по умолчанию в tun0), то процесс идет в прокси, даже если есть правило по имени пакета не пускать его в прокси (в секции route). Почему-то при ручном выборе интерфейса sing-box не может определить имя пакета. В debug-логах появляется ошибка: router: failed to search process: android: connection owner not found. Пытаюсь разобраться в причине, может быть баг, а может системное ограничение.
Изучил. Если приложение привязывается к конкретному интерфейсу, то per-app правила не работают, так как в этом случае невозможно определить пакет по соединению. Функция getConnectionOwnerUid не находит UID, если интерфейс указан принудительно. Поиск в функции выполняется по связке интерфейс (idiag_if), протокол, local, remote, а в качестве интерфейса всегда указывается 0 (и заменить значение нельзя). То есть это не баг в sing-box, а системное ограничение.
Проверил, рабочий профиль видимо от этого также не защищает: склонировал NekoBox в профиль, настроил туннель в нём, с личного профиля в Termux с curl --interface tun1 соединение идёт через туннель в рабочем профиле. В обратную сторону проверить не могу, Termux в рабочем профиле не работает, с другими терминалами тоже без удачи, в прошивке curl/wget нет, chmod +x эффекта не имеет.
Открою вам страшную тайну (о которой не знает даже Минцифры): и на Android, и на iOS, и на Windows, и на Linux, и на macOS любая программа может выполнить запрос через любой сетевой интерфейс в системе.
На Linux всё-таки не через любой интерфейс, а через любой в своём сетевом namespace, который не поменять без CAP_SYS_ADMIN.
Хм, проверил, чистый sign-box на android: curl ifconfig.co --interface tun0
выдал выходной IP. Был настроен впн для определенных приложений (в общих настройках sign-box). Действительно дыра. Поменял “inbounds”: { … “stack”: “gvisor”, “strict_route”: true, …}
И прописал: “route”: { “rules”: [ { “package_name”: [ “МОЕ_ПРИЛОЖЕНИЕ1”, “…” ], “outbound”: “MY_OUTBOUNDNAME” } …}
Теперь curl ifconfig.co --interface tun0
выдает ошибку Curl (7): Failed to connect to ifconfig…
Приложения прописанные в rules работают.
https://sing-box.sagernet.org/configuration/inbound/tun/#strict_route
When auto_redirect is enabled, strict_route also affects SO_BINDTODEVICE traffic:
Enabled: SO_BINDTODEVICE traffic is redirected through sing-box.
Disabled: SO_BINDTODEVICE traffic bypasses sing-box.
Странно. У меня правило по имени пакета в route не работает, если принудительно указать tun0. В том числе с strict_route.
Можете, пожалуйста, перепроверить?
Скрытый текст
{
"log": {
"level": "info",
"timestamp": true
},
"dns": {
"servers": [
{
"type": "udp",
"tag": "google",
"detour": "socks-out",
"server": "8.8.8.8"
}
]
},
"inbounds": [
{
"type": "tun",
"tag": "tun-in",
"mtu": 1400,
"address": "172.19.0.1/30",
"auto_route": true,
"strict_route": true,
"stack": "gvisor"
}
],
"outbounds": [
... PRIVATE INFO ...
{
"type": "direct",
"tag": "direct"
}
],
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
},
{
"package_name": [
... PRIVATE INFO ...
],
"outbound": "socks-out"
},
{
"outbound": "block out"
}
],
"auto_detect_interface": true
}
}Полный конфиг [почти)]. В общих настройках выключено прокси для отдельных приложений. Все только в конфиге. Приложения записаны в package_name естественно в формате "com.app.android". Приложения работают. curl ifconfig.co --interface tun0
Возвращает ошибку. Без --interface tun0 возвращается российский ip.
UPD! А нет, вру, так не работают другие приложения. В настройках надо включить "прокси для отдельных приложений" и еще раз выбрать их. Тогда остальное работает по умолчанию, а через tun0 - нет.
Теперь понятно. У вас по умолчанию блокируется. Когда указывается tun0, то имя пакета не определяется, идёт блокировка. Без tun0 имя пакета определяется. Выходит нужно перечислить вообще все программы, а потом новые добавлять, чтобы у них работал интернет.
Нет, я UPD написал к своему комментарию. В настройках надо включить "прокси для отдельных приложений" и еще раз выбрать их. После этого все работает как надо, но принудительно через tun0 обламываются те, не для кого ягодка цвела)
Я правильно понимаю, что тут я пришел к тому же подходу, что и вы?
https://habr.com/ru/articles/1020080/comments/#comment_29792770
Т.е. сводится к тому, что в рулах надо продублировать конфиг для аппов.
(а ну да, конфиг в спойлере же выше нашел)
И т.е. получается, что проблема решена?
Отправил автору sing-box issue с предложением по PR, переписываюсь с ним в tg-чате. Хочу, чтобы появилась возможность ловить правилом такие соединения, когда не удается распознать package name: https://github.com/SagerNet/sing-box/issues/4009
Проблема изначально, что из-за выбора интерфейса не работает поиск процесса getConnectionOwnerUid. Это API появилось, когда Google стал ограничивать доступ к /proc/net. И когда добавляли, то непривилегированные приложения еще не могли использовать SO_BINDTODEVICE. Так что скорее всего это пробел в дизайне API — его спроектировали под реалии, когда обычные приложения не могли привязывать сокеты к интерфейсам.
По поводу Happ
Меня сильно смущало всегда две вещи, как неискушенного пользователя, который не умеет делать такие вещи,как автор статьи:
их основной сайт находится в зоне su и зарегистрирован в российском регистраторе. Таким образом, владелец находится полностью под колпаком чекистов, если они того захотят
отсутствие открытого исходного кода. Насколько я помню они это объясняли,что это сделано с целью безопасности функциональности зашифрованных ссылок подписок .Может я путаю.
>На сервере вам нужно заблокировать доступ обратно в geoip:ru. Если вы этого не сделаете, то шпионы в яндексах/wb/ozon’ах и т.д. с
Речь только про приложения? или сайты тоже опасны? можно на телефонах тогда раздельным туннелированием по приложениям открывать в браузере Х только русское, а в другом браузере уже остальное (попимо настроенной маршрутизации в самом впн клиенте)
>для Windows нужная стратегия уже реализована в клиенте в v2rayN (пресет “Все, кроме РФ”)
А если использовать маршрутизацию все напрямую, кроме заблокированного? Я обычно это использую
И раз уж вы упомянули свой набор правил, то позвольте к вам @runetfreedom обратиться как простой пользователь по поводу вашего geoip.dat
С учетом того, что в например хорошем клиенте v2rayn невозможно выбрать другой источник геоип и геосайт данных кроме заданных (да, я знаю,что можно скачать просто с гита и положить в папку вручную и в настройках отменить автообновление геоданных,но это кривой костыль и не подходит для родственников и тд) и с учетом массовых блокировок\замедлений крупнейших хостеров и cdn , можно ли вас попросить добавить в ваш геоип файл категории, которые,например, есть у создателя проекта b4
https://github.com/DanielLavrushin/b4geoip
Спасибо!
отсутствие открытого исходного кода. Насколько я помню они это объясняли,что это сделано с целью безопасности функциональности зашифрованных ссылок подписок .Может я путаю.
Мега тупое оправдание по поводу безопасности, ведь они могли и могут опубликовать весь код просто без закрытого ключа и никаких проблем не было бы. Я уже не говорю о том, что этот ключ для расшифровки уже давно вытащили и есть даже сайты и боты для расшифровки.
их основной сайт находится в зоне su и зарегистрирован в российском регистраторе. Таким образом, владелец находится полностью под колпаком чекистов, если они того захотят
Если вы почему-то риск лишиться домена называете "под колпаком", то да.
Хотя, я не понимаю, почему наличие у меня домена, например, в зоне .com автоматически ставит меня под какой-то колпак западных спецслужб.
>Если вы почему-то риск лишиться домена называете "под колпаком", то да.
Нет я не это называю. "Под колпаком" я называю риск. услышав звонок в дверь, увидеть людей без формы в маска с вежливым предложением, от которого нельзя будет отказаться. Это если человек живет в России. А теперь. держа это в уме, добавим сюда то, что исходный код закрыт по надуманным причинам..
А если не в России ,то мне не очень понятна идея регистрации домена через российского регистратора, да еще через такую гнилую контору как рег.ру.
Насколько я помню они это объясняли,что это сделано с целью безопасности функциональности зашифрованных ссылок подписок
При этом настоящая ссылка из зашифрованной получается максимально тривиальным способом. Достаточно заснифить трафик с телефона при помощи mitmproxy и все. Я так спокойно тыбзил нужные ссылки (и они прекрасно работали в том же v2rayNG), что узнать какие конфиги используется для обхода БС.
Что насчёт клиента Throne?
Вопрос автору - это при запуске в режиме tun или socks5? Просто в режиме socks5 и имеется ввиду что запускается порт на локалхосте. Что тут исправлять если это так и должно работать? Человек который это включает должен понимать как оно работает.
А вот если это в режиме tun, тогда это реально опасно.
TUN режим в таких клиентах - это ничто иное как socks5 на локальном порту и интерфейс, созданный tun2socks, который и ходит в этот прокси.
Если сделать авторизацию в socks5, то использовать его смогут только приложения, в которых вы это специально настроили. Без авторизации - любое приложение (ему только надо порт найти, но это не сложно). Авторы клиентов авторизацию не сделали.
В теме в основном обсуждаются мобильные клиенты. А что для десктопа? Я например пользуюсь обходом блокировок только с десктопа, программой Throne в режиме прокси и отдельным браузером для заблокированных сайтов, настроенным на это прокси. В правилах на клиенте прописал на всякий случай запрет для geoip:ru, чисто интуитивно.
Наверное ещё имеет смысл удалить все российские приложения (хотя у меня почти их нет - приходит в голову только 2gis), и вообще тщательнее подходить к выбору приложений. Что ещё?
Автор просто нагнал воздуха.
В общем-то, не очень понятно, а в чем заключается уязвимость?
То что регулятор может узнать, о ужас, IP ваших проксей?
Хорошо, предлагаю ГРЧЦ/Минцифры следующий вариант: приложение Парковки, да любое российское приложение, будет смотреть - существует ли прокси интерфейс на iOS при использовании приложения; само приложение, в свою очередь, будет иметь эндпоинт который не метчится по ru правилам (TLD домена и айпи - зарубежные). Как ни крути, любое приложение будет по нему стучаться именно с вашего прокси. В прочем, даже смотреть, активен ли прокси интерфейс не обязательно.
Отказываться от огромного пула клиентов с яблоками - бред.
Существует еще несколько способов определить ip вашего прокси, которые в разы проще чем то, что описал автор.
Или то что можно узнать настройки аутбаунда?
И что потом? Регулятор будет пользоваться прокси? Будет ресселить ваши подписки?
Имея на руках publickey никакими митм'ами заниматься не получится без privatekey. Пользы от этой информации никакой.
Так что, вопрос к автору - и что с того?
Отказываться от огромного пула клиентов с яблоками - бред.
Когда автоматизируют и поставят на поток, выбора не останется - серверы будут жить часы или даже минуты.
В таком случае - откажитесь от использования браузеров вовсе. Ведь по методу описанному во 2 абзаце, на gosuslugi.ru тоже можно подставить эндпоинт, который не метчится никакими правилами.
Блокировка по отпечатку наиболее эффективная, собирать адреса долго и неточно, а ещё нужно системе доверять о том, какие данные отправило подконтрольное приложение, а это значит, что можно условый Макс заблокировать этим методом. Хотя возможно они так сделают, я не удивлюсь)
Не подумайте не правильно, но вот это вот "когда", "если" и т.д. уже слышали тысячу раз и каждые раз они обсираются что-то мало-мальски эффективное ставить на поток. Всем уже понятно, что это гонка вооружений, но Ваш посыл понятен: как говорится "Хорошим людям нужно выигрывать всегда, чтобы всё было хорошо, но стоит плохим людям выиграть всего 1 раз, и всё пойдет прахом".
Не подумайте не правильно, но вот это вот "когда", "если" и т.д. уже слышали тысячу раз и каждые раз они обсираются что-то мало-мальски эффективное ставить на поток.
Отлетающие по сибирским блокировкам вообще любые протоколы, отлетающие VLESS-ы с некорректным отпечатком браузера или что там было, отлетающий mtproto из-за кривой маскировки - это все "обсираются поставить на поток"? Я завидую вашему оптимизму. Сейчас начнут собирать IP проксей, потом введут за них административку (задним числом как обычно по длящемуся правонарушению) и поедут пативены, после этого любой ВПН станет просто золотым.
Отлетающие по сибирским блокировкам вообще любые протоколы, отлетающие VLESS-ы с некорректным отпечатком браузера или что там было, отлетающий mtproto из-за кривой маскировки
Частные случаи+буквально говорите про кривую маскировку. Вот и ответ. Сибирские блокировки очень редки на данный момент, особенно в западной части (их попросту нет у 99% хостеров. Плюс впн - это уже давно не про "решение из коробки", тут надо подтягивать и идти в ногу со временем (по себе знаю, приходится).
Про административку тоже байка, так как пользователей ну такое множество, что у них документооборота такого не существует (знаю из первых уст). Помню, так же и про мобилизацию пугали, а в итоге ни одного кейса даже админки не было задокументировано. Видите как, раз вы так говорите, значит их psyops по запугиванию и самоцензуре работает, а значит лишний раз потенциально убедит потенциального гражданина не заниматься обходами и идти на парковку
Нет, вы меня тоже не поймите неправильно: я даже свой VPN клиент навайбкодил для HTTPS, с WB и VK транспортами. Но градус шизы нарастает удивительными темпами, вам бы 5 лет назад просто не поверили бы, если бы вы сказали, что РКН сегодня успешно обнаруживает и блокирует. Если дальше такими темпами пойдем (мое хобби экстраполировать), то до конца года гайки докрутят уже. Списочки ВПН-то не просто так сейчас будут собирать.
Солидарен. Вместо того, чтобы самосовершенствоваться в хобби и работе и как-то духовно и физически я тоже вынужден практически ежедневно мониторить, что нового поднасрали мрази с верхов, чтобы оставаться свободным в своем легитимном конституционном, кстати, праве на свободу доступа к информации. Уж больно люблю быть свободным и не люблю думать так, как хотят наверху.
Но к сожалению, самый действенный способ - это голосовать собой и менять страну проживания, голосуя вкладом в экономику и рождаемостью (которые и так уже на дне, к сожалению или к счастью). Пока люди будут затерпливать и именно искать обходы, а не активно что-то делать с этой ситуацией, так и будем обитать в этом цифровом (а может скоро уже и не только) гулаге.
Как бы да :) Для того, чтобы вас спалить, достаточно посетить сайт палящего (ozon/wb/sber/max) а там, например, дёрнуть по js что-то, что должно быть заблокировано, например https://ipinfo.io/ip и всёго делов. Ну узнают IP адрес выходной ноды, дальше чего? Заблокируют его на границе? Ок, я в админке сменю адрес у этой виртуалки. Пфф, делов.
А такой вопрос - может ли подобным образом стучать чтото типа яндекс метрики и рекламы? В смысле у них есть отпечаток клиента и сопряжение с тем кто именно этот клиент и есть тысячи запросов и с относительно стабильных русских ip, и с десятка мест по всему земному шару. Они знают куда слать ответ с картинкой рекламного утюга. Что мешает сопрячь те же выходные ноды с вполне отечествеными ip тех же юзеров и посмотреть куда течет трафик с единственным рукопожатием в сутки зная что искать? Ресурсоемко, но грубо говоря вся информация у них уже есть и проанализировать ее (не полностью, а до первых результатов) вопрос суток.
Можно как угодно. А еще проще проверить, когда вы уже залогинены где-то (например на госуслугах). Тогда и матчить ничего особо не нужно. Смотря какая задача решается. Спалить факт юзания сплит впн? Легко. Вы даже и не заметите подвоха. Чтобы у вас не заблокировали выходную ноду на границе? Так сделайте каскад из трех нод: ру - зарубеж - зарубеж. И желательно в разных ДЦ/конторах. Тогда на блокировку выходной ноды вам будет наплевать.
А вариант с внесением подсети в бан? Или бан всех адресов этого ASN? Тоже пфф?
Я обычный юзер, и я так понял,с помощью этих впн могут получить доступ к устройству. Я пользовался happ и на пк, и на телефоне. Каким тогда впном пользоваться?
Я правильно понимаю по статье, что использование каскадной схемы здесь не спасает и сливается именно egress/exit hop ?
а что по поводу Amnesia?
Я ничего не понял особо, но возник вопрос: а если допустим будет какой-то портативный роутер между телефоном и интернетом, можно ли будет на нём как-то отсекать ненужный трафик, может быть там будет клиент наружу и сервер локальный, и так же на телефоне раздельный трафик, чтобы некоторые приложения напрямую пролетали мимо в большинстве своём
Так вроде IP прокси не так уж и трудно вытащить и без уязвимости... А ещё, если этим будет пользоваться государство, то так можно отправлять левые IP адреса и тогда можно будет заблокировать всё, если правильно всё это организовать.
После чтения новостей за последнюю неделю я решил не вводить ещё один контур тревоги в свою жизнь ("что они там ещё придумают?"), а сделал довольно простую вещь - снёс вообще все приложения отечественного бигтеха с основного телефона. Те, без которых совсем нельзя - поставил на вторую, девственно чистую от клуба весёлых и находчивых трубку. Ну и геоблок, конечно же, куда же без него.
Честно говоря, думаю, что затея с навешиванием обязанностей по блокировке на крупный бизнес в итоге не взлетит - у бизнеса цель зарабатывать деньги, а хотелки Минцифры только эти деньги отнимают (расходы на внедрение и поддержание системы, уход части клиентов итд итп). И плюс эти самые хотелки будут имплементировать на местах ровно те же самые программисты, которые тоже состоят в клубе весёлых и находчивых, потому что без нахождения в этом самом клубе свои рабочие обязанности невозможно исполнять с ноября 2025-го года (блокировка скачивания расширений вскода, хранилищ пакетов линукса, документации к различным пакетам и инструментам et cetera). Результат, думаю, предсказать несложно.
Честно говоря, думаю, что затея с навешиванием обязанностей по блокировке на крупный бизнес в итоге не взлетит
Как знать... зависит от бизнеса и его бенефициаров. Тот же VK Видео уже давно рекомендует отключить квн, если он на телефоне включен. Яндекс.Музыка тоже так делает. Что интересно, банковские приложения работают нормально. Во всяком случае я пробовал приложения Сбера и Совкомбанка: ни у одного претензий не было.
Но я тоже надеюсь на тихий заботаж этого дебилизма...
См. "Закон Яровой" и его реализацию. Бизнес его исполняет за свои деньги, перекладывая расходы на конечных потребителей. Не первый раз, не последний.
Если не путаю, Минцифры угрожает отзывом аккредитации тем компаниям, которые не будут сотрудничать. А это не только налоговые льготы, но и отсрочки от призыва. Т.е. если коротко и прямо: "или вы стучите на пользователей, или мы убьём ваших ключевых сотрудников".
Думаю, при такой постановке вопроса желающих отказываться найдётся немного. Как и желающих имитировать бурную деятельность по розыску пользователей VPN с риском для здоровья и жизни в случае разоблачения. И я, если честно, не могу их в этом винить.
свои рабочие обязанности невозможно исполнять с ноября 2025-го года
А власти по большому счёту уже не нужны программисты. Власти нужны дроноводы и немного хакеры. Т.е., читай - пули, которые можно выстрелить куда захочется, и тут же забыть.
Результат, думаю, предсказать несложно.
по-моему эту мантру пишут уже несколько лет
Правильно понимаю что если v2rayng работает mode: vpn, то данная уязвимость не релевантна?
Так физически смартфоны разделят. На официальный для этих приложух и личный. В целом то ничего криминального: ну не рассчитан средний телефон на безопасное содержание внутри себя шпионского ПО. И не будет рассчитан, потому что не существует в мире глобального спроса на эти функции. Нет тут таких продвинутых и удобных средств виртуализации, неймспейсов, полноценного фаервола, выдачи фальшивых данных вместо реальных на всякие системные вызовы. Все это где-то можно, но кусочками, не всегда, по чуть-чуть и в целом для гиков.
One UI 8.0, amneziavpn 4.8.14.5, без split-tunneling и с ним
Скрытый текст
Ну вообще на v2rayNG тоже существует возможность использовать пресет "Всë, кроме РФ", и очень давно.
Те кто умеют искать возможность включать подобное, всегда найдут)
А к sstp это применимо (и приложению sstp max)?
Многие пишут про способы решения этой проблемы с помощью рута или каких-то кастомных клиентов или настроек. Мой сервер используется не только мной, но еще и людьми, которые ради впн не станут так глубоко лезть ради устранения этой прорехи. Так что спасибо больше за статью. Мне удалось оперативно принять меры
и что вы в итоге предприняли?
Полагаю, что ничего, так как реальный стопроцентный способ: все рф приложения на отдельный телефон.
P.S. не думаю, что этот человек даст Вам фидбек, так как обычно такая манера речи только тогда, когда проблема не решена и автору комментария нечего сказать или поделиться решением
Воспользовалась одним из советов автора. Завернула трафик в варп
подробностей бы. что делать среднему владельцу vps с hiddify , которым пользуется он и семья/близкие? как можно обезопасить это дело со стороны сервера?
Подозреваю, что happ (и все квн-сервисы, подключающие исключительно через него) - засланные казачки
Когда автор врёт с самого начала, то проверять есть правда дальше по тексту уже не интересно. Точнее можно быть уверенным, что он будет продолжать врать и дальше. Речь про это заявление "Минцифры открыто потребовало от аккредитованных российских IT компаний внедрения в свои продукты шпионских модулей, которые будут помогать блокировать персональные впн серверы "
Если автору эта тема интересна, то он прекрасно знает, что речь идёт о запрете работы указанных приложений через впн, а не "внедрении шпионских модулей"
Раз он врёт в мелочах, то соответственно ложь, нагнетание и передёргивание фактов это для автора естественный подход, и тем более очевидно что он будет врать и в остальном...
Прочитайте саму методичку (открывается только по ipv6), конкретно разделы 6 и 7,
Забей на него, там либо бот, либо клиника
Для вас русский язык не родной? Я вам повторю еще раз, рекомендации минцифры относятся к недопущению доступа к указанным ресурсам с использованием впн. Определение впн производится через штатный функционал андроид и айос. Там нет ничего про передачу каких либо данных в минцифры или тем более встраивание шипионских модулей.
Хотя я думаю вы это и сами прекрасно знаете и это была очередная попытка надурить читателей...
Волну разгоняют
Там нет ничего про передачу каких либо данных в минцифры или тем более встраивание шипионских модулей.
Верим? Верим. Это поэтому в коде Макса были пинги и connect 443 до main.telegram.org и mmg.whatsapp.net, пока за руку не поймали? ;)
Они УЖЕ встраивали модули. Еще даже до официальных документов, которые это рекомендуют.
Ну вот почитай и поверь в другое) https://dzen.ru/a/aXT4fnkHWAInpkzP
Буквально нет интереса читать отмазки воришек, которых поймали за руку. У них никогда не было причин стучаться на заблокированные сервисы и никогда не будет. Стучаться они туда могли только с одной целью, да еще и "в крысу", с удаленным управлением.
То есть тому что он там что-то передаёт ты веришь, а то что это просто проверка, то это тебе лапшу вешают?)
Ничего тупее отмазки, что он соединяется с телеграм, что бы проверить, работает ли интернет, я не видел. Это я прочитал по вашей ссылке.
С чего вдруг это отмазка?
С того, что работоспособность интернета так не проверяют
А они может проверяют, их продукт, как хотят так и проверяют
А вот когда мы из РФ проверяем работоспособность ТСПУ, они жалуются, что их DDOS-ят... Заставляет задуматься!
Так в норме телеграм же заблокирован. То есть, они проверяют, а вдруг он доступен на самом деле? Вроде мы пришли к конечному заключению о том, что они проверяют на самом деле?
Так @runetfreedom в своей статье же вроде указал что они убрали их оттуда, да и они там были до блокировки телеграмма, так что логично, что они не это проверяют
А я почитал, там «Основная причина: проверка качества интернета». Причины почему для этого нужно проверять «именно эти ресурсы» я оставлю читателю возможность решить самостоятельно
Так ты дальше прочитай, а не только заголовок)
Я прочитал её полностью и все ещё жду логического обоснования: «Зачем для проверки наличия интернета использовать во-первых сторонний сервис, а во-вторых - ещё и заведомо заблокированный?»
Если что-то крякает как утка, выглядит как утка…
P.S. Выводы там тоже интересные, с которыми у меня никак не получается согласиться
МАХ не отслеживает пользование VPN-сервисами [и] не отправляет запросы на серверы WhatsApp и Telegram. Используемые технические решения направлены на обеспечение высокого качества работы сервисов — в первую очередь звонков и уведомлений. К персональным данным или пользованию другими сервисами, включая VPN, они не имеют никакого отношения
Ответ пресс-службы? Прекрасно
не отправляет запросы на серверы WhatsApp и Telegram
Вот эта часть прямо противоречит твоей предыдущей ссылке. И обсуждаемой истории. Отправляет (вернее отправлял раньше) проверяя доступность в том числе заблокированных ресурсов. Проверить наличие интернета можно и иначе. И я не вижу никаких логичных причин, почему «это» направлено на
Используемые технические решения направлены на обеспечение высокого качества работы сервисов — в первую очередь звонков и уведомлений.
Зато это хорошо вписывает в анализ этого
пользованию другими сервисами, включая VPN
"Если google.com недоступен, а telegram.org доступен - значит интернет есть, но что-то блокируется. Если недоступно всё - у пользователя просто нет связи."
"Если у пользователя нет доступа к max.ru - значит нет связи. Или что-то её блокирует. Все равно нам это никак не поможет и мы об этом даже не узнаем, пока пользователь не окажется в сегменте работающего интернета. Ну и конечно же, он тоже никому не напишет."
Ну а если доступ есть - то что мешает общаться?
Вот MAX делает проверку и если нет интернета так и говорит тебе об этом. Да и что с того что там whatsapp и telegram, миллионы сервисов и приложений могут к ним обращаться, как к google и к яндексу и почему-то никто не думает что в интернете миллион приложений и что все остальные приложения, те же мессенджеры ничего никому не передают и не собирают и не делают запросы на другие сайты
Мы ходим по кругу
Вот MAX делает проверку и если нет интернета так и говорит тебе об этом.
Для этого не нужно проверять доступность мессенджеров-конкурентов.
Более того, о какой проверке интернете идёт речь, если сервис-конкурент уже сейчас «щемят» на грани полной блокировки? Какую полезную информацию о «наличии интернета» даст такая проверка и для чего её можно применить?
Да и что с того что там whatsapp и telegram
Не укладывается в логику => презумпция вины в отношении сервиса который навязывают силой. А зачем строить нелогичный дизайн - я не понимаю.
и что все остальные приложения
мы сейчас обсуждаем не их
Для этого не нужно проверять доступность мессенджеров-конкурентов.
Telegram (порт 7)
Порт TCP 7 используется для протокола Echo - простейшей проверки связи. Сервер просто отправляет обратно то, что получил. MAX не "отправляет данные в Telegram", а делает технический пинг: проверяет доступность сервера.
WhatsApp (порт 443) Соединение с mmg.whatsapp.net (сервер мультимедиа WhatsApp) через стандартный шифрованный порт. Приложение пытается установить рукопожатие, чтобы проверить прохождение трафика.
мы сейчас обсуждаем не их
То есть остальные могут делать запросы и собирать и сохранять информацию, ну понятно)
Я понимаю почему в РФ так легко разводить людей. Им что не скажешь, они счастливо всему верят.
Вы думаете, что статья, где это описана - вранье? Думаете, что если дернуть исследованную версию, то там в коде этого не будет?
Мы ведь на техническом ресурсе, вы ведь понимаете, что это сразу же вскрылось здесь же в комментах? Это "все не так однозначно" сойдет для комментов на каком-нибудь Пикабу, но здесь ведь люди и сами могут проверить.
Я понимаю то, что это никому не интересно. Те кто считают Макс инструментом антихриста будут верять во всё, что будет подтверждать эту теорию. В прослушку, геопозиционирование, видеофиксации и т.п. Те же, кто считает, что Макс это просто второсортный мессенджер с господдержкой, не будут убивать час свободного времени что бы увидеть в сниффере искомые адреса. Потому что их наличие вообще ничего не значит, как и их отсутствие.
Просто почему-то в одну сторону только верят, кто что первое сказал или тому что они хотят услышать)
Вторые сказали "ихтамнет", это не ответ:
МАХ не отправляет запросы на серверы WhatsApp и Telegram.
https://habr.com/ru/news/1006950/
Это буквально псиоп уровня The Party told you to reject the evidence of your eyes and ears. It was their final, most essential command.
В коде есть - они говорят нет. Не верьте своим глазам, они врут. Не знаю, на кого это расчет, кроме ура-патриотов.
Полностью читай, а не кусками "Используемые технические решения направлены на обеспечение высокого качества работы сервисов — в первую очередь звонков и уведомлений. К персональным данным или пользованию другими сервисами, включая VPN, они не имеют никакого отношения. Там также объяснили, что данные об IP-адресах нужны МАХ только для корректной работы звонков в нем, а запросы на серверы — это касается Google и Apple — для проверки доставки push-уведомлений, что необходимо в «сложных сетевых условиях и ограничениях мобильной связи в отдельных регионах». «Технология WebRTC требует внешний IP, чтобы построить прямой маршрут "телефон-телефон". Это стандарт для всех подобных сервисов», — заключили в пресс-службе МАХ."
Там также объяснили, что данные об IP-адресах нужны МАХ только для корректной работы звонков в нем, а запросы на серверы — это касается Google и Apple — для проверки доставки push-уведомлений, что необходимо в «сложных сетевых условиях и ограничениях мобильной связи в отдельных регионах».
Это не объяснили, это отписка уровня «вы все врёте».
Технология WebRTC требует внешний IP, чтобы построить прямой маршрут "телефон-телефон". Это стандарт для всех подобных сервисов
Для этого не нужно определять IP через внешние непонятные сервисы (которые сегодня есть, а завтра - умерли), есть STUN. И такие сервера вполне есть у ВК, да и в целом, поднять не проблема
Ну ты же не разработчик, чтобы знать как что они там реализуют, да и что дают проверка доступен ли whatsapp и telegram, миллион сайтов и приложений могут делать эти запросы, точно также как и к другим сервисам google, яндексу
Ну, тут мы как бы как раз на ресурсе разработчиков, которые прекрасно понимают как, что и зачем делают. И нет, не для проверки доступности сети)
Я, честно говоря, не очень понимаю, зачем Вы так ръяно бросаетесь защищать Макс и планируемые меры обнаружения ВПН, когда сами в этом не особо разбираетесь, судя по остальным комментариям. Разве что...
Ну то что это ресурс разработчиков это не говорит о том насколько и сколько здесь высокий их уровень.
Ну это ваше мнение и возможно других что это не для проверки сети.
Что в MAX такого чего нет в других мессенджерах, с чего решили что они не собирают, не сохраняют информация, что-то не проверяют, просто этого нет в коде или просто никто не смог найти?
Если не смогли найти, а найдут потом, ну значит так себе здесь разработчики.Смотрю здесь каждый второй мамкин хакер, но у всех начинается какая-то паника, что же делать.
Для получения внешних адресов используются TUN сервера. У MAX есть собственные TUN сервера.. И уж совсем нет смысла подключатся к разным локациям. В случае без VPN адреса будут одинаковые в разных локациях, в случае с VPN адреса будут разными. Это ни в чем не поможет WebRTC.
вот вот, будут блокировать сайт, приложение при обнаружении VPN и возможно передавать сведения для блокировки IP, а не внедрять шпионское ПО для слежки за пользователем, но все думают, что они занимают какую-то высокую должность что за ними будут следить, да и другой вопрос, зачем включать vpn и заходить на сайт который отлично работает без него)
Правильно ли я понимаю, что если наши приложки начнут встраивать в себя таких троянов, то они могу получить репорты в апп сторах/гугл плеях и просто вылететь от туда?
Думаете, это остановит РКН ?
Наши приложки уже примерно четыре года как принято устанавливать из рустора, ведь там есть все банки, госуслуги, госключи и так далее и тому подобное (и фотошопы, перезалитые хз кем) с доступом даже в режиме белых списков. Прокатит только с ios-устройствами, но там есть успешная практика а) носить трубки прямо в банк для установки приложений через кабель б) быстра-быстра накатывать очередное приложение-календарь с доступом к банковским счетам пока не зарепортили и не удалили, поторопитесь! Так что дырки будут и в этой экосистеме (меньше конечно, но и того хватит)
Нет информации по поводу GUI proxy client Furious от автора Loren Eteval? Пользуюсь этим клиентом достаточно давно.
У Throne тоже есть пресет "Bypass Russia", который позволяет напрямую подключаться к рф айпишникам
Интересно, Streisand это тоже касается?
Есть более общая архитектурная уэявимость VPN/прокси по своей концепции, это не средство обхода блокировок. По части детекта факта применения VPN/прокси имеет концептуальный патерн - специфичный маршрут трафика.
Цензуре нет необходимости проверять насколько реалистично Ваш, к примеру, "VLESS + Realiti" в дефолте проксирует Майкросовтовский сайт(в попытке найти едва уловимые различия) - цензуре достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах.
Тоже самое про другие VPN/прокси применяемые как средство обхода блокировок - прячем "мух"(специфику пакетов), а "слон"(крайне специфичный маршрут трафика) виден всем желающим. Его то в 2026 году в РФ и начали "рубить" и технически(падеж стелс-VPN/прокси по мере апгрейда ТСПУ), так и экономически - решением о заградительных тарифах на трансграничных трафик конечного пользователя.
Гораздо больший потенциал как показывают и теория и практика имеют “неоднокликовые” решения вроде Zapret(которым серверная часть не нужна и как следствие отсуствует слив трафика в специфичный маршрут). Причем трансграничный пиринг инфраструктурных гигантов тарифицируеться не как у пользователя, и если вы обратились фактически например к российским GGC, то ваш трафик для вашего провайдера внутрироссийский.
а если так - купить мини-компьютер домой, прикрутить к нему белый статический IP адрес, ставить ubuntu, на ней настроить себе openvpn сервер и кучу правил, к нему подключаться клиентом с своего смартфона, и уже со своего сервера коннект к нескольким зарубежным VLESS серверам и переключать их
Так будет видно трафик с твоего сервера на зарубежный, а твой сервер это такой же обычный пользователь
По сути так мосты и работают. Проблема найти такой белый айпи, еще большая проблема потом поменять его в случае блокировки
обычно такой мини-компьютер называют роутером
А с амнезией что?
я сейчас сам проверил и у меня он не видит Xray API, но SOCKS5 нашел. У меня vless через 3x-ui панель и раздельное туннелирования приложений. Так что думаю у Amnezia все норм.
Версия приложения: 4.8.14.5
@runetfreedom
но SOCKS5 нашел
Так получается не норм, в этом и есть уязвимость всех, кроме happ
Socks5, а дальше вот: https://github.com/amnezia-vpn/amnezia-client/issues/2452
а как в v2rayNG V2rayN отреагировали на запрос? у них самая удобная кастомизация и настройка маршрутизации включая порты
А как на Андроиде с автоматизацией? По идее если сделать жёсткий пул доверенных приложений, а все остальные принудительно гасить когда включается тот же vray?
Сделал MR для v2rayNG с обязательной авторизацией, можете подождать пока его вольют либо я могу выложить скомпилированные apk файлы
Ну а в целом, переход на айось с андроида в текущих реалиях оправдан?
Почему-то все стараются изолировать маха в песочнице, откуда он успешно выползает.
А что если поступить наоборот - сделать в телефоне отдельное пространство с квн и инстаргаммом? То есть в открытую на телефоне нет никаких подозрительных приложений. Но если запустить на нём некую программу (виртуальную машину?), то в ней уже запустится квн и нужные приложения. При этом квн будет виден только избранным программам.
Я так и сделал, все заблокированое живёт в папке knox. Но это не решает проблему, socks5 сервер торчит из knox папки в незащищённое пространство, то есть проблема из статьи актуальная.
без разницы в текущих архитектурных реалиях, макс песочнице или квн в песочнице, ваш квн все равно будет виден
буден виден незапароленный socks5, если его запоролить, то проблемы не будет, сканер хоть и найдет сервер, но авторизоваться на нем не сможет
Неужели, если перед использованием КВН отключать рабочую область песочницы, где находятся все ру сервисы, не поможет в решении проблемы? Действительно ли тот же Макс, который в теории должен находиться в отключенном состоянии, будет видеть ВПН соединение?
Ну а если, скажем нельзя сделать авторизацию, которую бы цепляли избранные для сплит туннеля приложения, то может лимит авторизаций на внутреннем socks прокси частично решил бы эту проблему ?
Ну вот условно в vless клиенте разрешается доступ для 3 каких-то приложений. И далее, на сокс выставляется лимит в 3 анонимных подключения. Избранные приложения тут же занимают этот лимит, потому что подключаются по понятной методике. А условный шпионский модуль, даже если и вычислит порт внутреннего socks сервера и подключится к нему - доступ в интернет не получит.
По-моему, проще сделать два раздельных физических устройства. Взять старый мобильник (думаю, у большинства дома хоть один да найдётся) и на него поставить броузер, YouTube и VLESS-клиент (для надёжности можно ещё перепрошить на Lineage OS), на втором — держать всё остальное в обычном режиме.
А ещё проще не заниматься ерундой и просто пользоваться одним устройством, не думая что вы кому-то нужны за вами следить
Полностью согласен. Но лично мне не от слежки шифроваться надо, а ходить в некоторые недоступные обычным образом соцсети.
Хороший наброс, особенно в реалиях РФ на данный момент. +15
Этот комментарий действительно инфантильный и глубоко ошибочный. Он построен на трёх типичных заблуждениях: «я мелкая сошка, меня не тронут», «достаточно просто не высовываться» и «техника — это не проблема, если не заниматься ерундой». Реальность 2025–2026 годов в России показывает обратное: государство инвестирует огромные ресурсы именно в массовую, а не точечную слежку. Вот почему аргумент «просто пользуйся одним устройством и не парься» разлетается в пух и прах.
1. Слежка не выбирает «важных» — она тотальная по умолчанию
Государство не тратит силы на ручной отбор «кого следить». Система СОРМ (установлена у всех операторов) + DPI + «чёрные ящики» автоматически собирают метаданные и трафик каждого пользователя. Яндекс, VK, Сбер и другие в 2024–2025 годах выдали силовикам десятки тысяч запросов на данные пользователей — и это только официальные.
Данные хранятся годами, анализируются ИИ и используются потом — когда человек вдруг станет «интересным» (протест, жалоба, донос, проверка связей). «Ты никому не нужен» — это иллюзия. Нужны все данные, потому что это дёшево и масштабируемо.
2. Блокировки и борьба с VPN взрывно растут — именно потому, что люди пытаются защититься
К началу 2026 года Роскомнадзор заблокировал уже 469 VPN-сервисов (рост на 70 % только за несколько месяцев 2025 года).
В 2025 году количество блокировок материалов про «средства обхода» выросло на 1235 %.
Россия в 2025 году стала мировым лидером по отключениям интернета (тысячи случаев, миллионы затронутых).
Если бы «никто не был нужен», зачем такие усилия и миллиарды рублей на модернизацию АСБИ и DPI до 2030 года?
3. Российские приложения уже официально шпионят за VPN — это и есть «мощное доказательство»
Минцифры в марте–апреле 2026 разослало методичку крупнейшим площадкам (Яндекс, VK, Сбер, Wildberries, Ozon, Avito, X5 и др.):
Внедрять модули обнаружения VPN (включая локальные прокси и split-tunneling).
Ограничивать доступ к сервисам при включённом VPN (с 15 апреля 2026).
Сообщать о новых способах обхода.
Мессенджер MAX уже отслеживает VPN и передаёт данные в Роскомнадзор. Статья на Хабре (именно та, под которой оставлен комментарий) описывает уязвимость VLESS-клиентов, которую эксплуатируют именно эти шпионские модули в российских приложениях. Даже приватные пространства (Knox, Island) и per-app VPN не спасают — приложения сканируют localhost и видят прокси.
Вывод: «одно устройство» + популярные российские apps = твоё использование VPN видно государству прямо сейчас.
4. «Не занимайся ерундой» — это детский уровень мышления
Что такое «ерунда»?
Чтение заблокированных СМИ?
Переписка в Telegram/WhatsApp?
Поиск работы за рубежом?
Просто геолокация в «неправильном» месте?
Сегодня это «ерунда», завтра — повод для проверки. Метаданные (кто, когда, с кем) собираются всегда. А «чёрные ящики» и закон Яровой позволяют читать даже зашифрованный трафик при необходимости.
5. Это не паранойя, а системная политика «суверенного Рунета»
Государство прямо говорит:
VPN должен быть только «государственный» (RuStore уже готовит свой, который не разблокирует YouTube/Telegram).
Площадки будут блокировать пользователей с VPN под угрозой потери аккредитации и налоговых льгот.
Штрафы за отсутствие СОРМ растут в разы.
Комментарий предлагает «просто не думать» в ситуации, когда государство активно заставляет думать всех подряд.
Итог: аргумент «пользуйся одним устройством и расслабься» — это не взрослый pragmatism, а инфантильное отрицание реальности. Реальность: слежка стала промышленной, дешёвой и обязательной. Чем больше людей «не парятся», тем проще государству контролировать всех. Технически грамотные люди (включая автора статьи на Хабре) уже показывают, как именно это работает. Игнорировать это — значит добровольно сдавать свою приватность.
Я тоже так подумывал, но пока лень
Выходные IP VPN-серверов легко палятся разными способами, от задержек до категории IP и паттернов трафика. Мне кто-то кинул ссылку на сайт proxydetect.live, там сразу десяток способов используется, и все на стороне сервера. С проверками на стороне клиента ещё проще.
Если РКН узнает выходной IP, то это не так страшно - у нормальных VPN он как правило отличается от входного, заблокировали выходной, входной останется доступным.
Проблема в другом, что возможность передачи и по VPN-каналу, и в открытую создаёт возможность определить входной адрес VPN. Шпионский модуль в каком-то приложении в открытую передаёт пакет - триггер для ТСПУ, который начинает сохранять сессии пользователя, а потом передаёт информацию, что в такое-то время с VPN этим пользователем было скачано определённое количество трафика. А потом сессии анализируются и смотрится, с какого адреса в это время трафик приходил.
А возможностей передать триггер и спалить таким образом входной адрес предостаточно, от сплита по адресам и приложениям (какой-нибудь ВК может открыть ссылку в браузере, а там VPN), до локальных прокси, локального DNS (Андроид открывает DNS на 127.0.0.1 при включении раздачи трафика), и бинда к конкретному сетевому интерфейсу.
Поможет только второе устройство (но большинство людей не готово на это пойти) и добавление поддержки прокси в приложения (причём это должен быть не простой прокси, как HTTP или SOCKS, а с маскировкой под HTTPS, наподобие MTProto в телеграме, или хотя бы с защитой всего канала по TLS). Разработчики большинства приложений забьют на это скорее всего.
Интересно, сколько минцифры занесли бабок, чтобы распространить эту информацию?
Но если на устройстве пользователя находится spyware (к примеру как часть какого-то государственного приложения), то ничего не мешает ему напрямую подключиться к этому xray socks5 proxy минуя VpnService и узнать внешний ip адрес и заблокировать его.
Ну и пусть блокируют - выходная нода в РФ не светится, а адрес входной они так не узнают!
Сейчас только совсем уж начинающие энтузиасты используют одит и тот же IP для входа и выхода.
Просто теперь это станет настоящий бизнес - порог входа повысится, а потенциальная аудитория - десятки миллионов человек.
Запрос к сервису определения IP, который зароутился в выходную ноду, отдаст ответ с IP выходной ноды. Все сервисы определения IP вы не поймаете правилами роутинга. Они просто поднимут свой на том же сервере в Польше за 5 евро в месяц, на голом IP, и пойдет он в вашу выходную ноду. :)
Сейчас только совсем уж начинающие энтузиасты используют одит и тот же IP для входа и выхода.
как представитель именно этого меньшинства, подскажите, вот, допустим, есть vps с 3x-ui, как мне понять что это мой кейс ? если в админке vps провайдера указан только один ipv4 по которому я и захожу через ssh ? если это так, то нужно понять, можно ли арендовать у провайдера ещё один ipv4 и как то его сделать "на выход" ? по каким ключевым словам поискать как это делается в 3x-ui ?
а адрес входной они так не узнают!
Spyware на устройстве не узнает, но с высокой вероятностью это можно сделать, анализируя трафик пользователя на стороне ТСПУ. Для этого ТСПУ должен знать паттерн поведения spyware и накопить достаточно трафика
Что меня удручает, этот текст поймут 0.001% населения.
Мне как физику, и вообще, человеку не связанному с интернет-технологиями непонятно как в обозримое время разобраться со всеми этими "заворачиваниями UDP", "входными-выходными IP", VLESS туда, xray сюда... Для полноценного цифрового сопротивления нужны простые инструменты и инструкции не содержащие жаргона, терминов, и т. п... типа "скачать вот это", "нажать вот это", "если не заработало - поменять вот это и повторить".
С кем общаться в ТГ если 99% народа выдавят в Макс? Народ ругается, но ставит, потому что нужен инструмент общения. Если не с кем поделиться ссылкой на YT? Когда мне надо отправить какое-то видео (обычно музыкальное) я стараюсь найти его на rutube, потому что на той стороне скорее всего YT не работает.
В перспективе, в противостоянии государства и граждан, я бы поставил на государство. Потому что проблемы негров, как известно, шерифа не волнуют, а у шерифа есть кольт и наверняка домашний интернет в обход опломбированных ящиков. (Кстати хорошо бы выяснить этот момент).
С другой стороны, вроде бы возможен некий гомеостаз, когда у 99% населения заблокировано всё, а на 1% плевать, но... учитывая легкую воспроизводимость цифровых решений и если будут реализованы удобные однокнопочные решения, то этот 1% может быстро превратиться в 99% и опять...
Суть в том, что государство имеет возможность сделать так, чтобы VPN сервисы не смогли стать массовыми. Для пользования VPN нужны будут меры предосторожности, чтобы не спалить IP, и хотя бы один неподготовленный пользователь может заблокировать доступ сразу для всех, поэтому удобных однокнопочных решений уже не получится. Технари смогут сделать обход блокировок для себя даже в таких условиях, но не смогут предлагать его простым пользователям.
сложить яйца в одну корзину, самое глупое решение. В перспективе, что бы парализовать страну надо душить 2 сервиса госуслуги и мах(от слова махать)
сделать так, чтобы VPN сервисы не смогли стать массовыми
Этот поезд уже ушёл.
По состоянию на начало 2026 года, количество пользователей VPN в России оценивается примерно в 60 миллионов человек. Это составляет около 46% от всей аудитории Рунета.
Интерес к сервисам обхода блокировок продолжает расти, несмотря на активное противодействие со стороны регуляторов:
Доля пользователей: Различные исследования оценивают охват аудитории от 39% до 46%. В 2025 году спрос на VPN вырос на 36%.
Рекордный интерес: В марте 2026 года количество поисковых запросов по теме VPN побило рекорды весны 2022 года.
Демография: Наиболее активно технологией пользуется молодежь: среди россиян в возрасте 18–24 лет доля пользователей достигает 45–51%.
Блокировки: К январю 2026 года Роскомнадзор ограничил доступ к 439 VPN-сервисам, что на 70% больше, чем осенью 2025 года.
Новые меры: Весной 2026 года власти ввели дополнительные ограничения, такие как запрет на пополнение Apple ID через мобильные счета и планы по введению платы за международный трафик свыше 15 ГБ, чтобы усложнить использование VPN.
Хотите узнать подробнее о технических способах, которыми сейчас обходят блокировки, или о законности использования таких сервисов в 2026 году?
Пока что, выглядит так, что вполне можно сделать автоматическую систему, чтобы она не палилась. И чтобы один пользователь не мог её спалить. Так что, такие системы всё таки можно делать "одно-кнопочными".
Видео с ютуба можно скачивать. И кидать не ссылку, а само видео. NewPipe, SaveFrom и прочие.
На счёт жаргона не волнуйтесь. Профессионалы решат проблему. Обычным пользователям не надо будет в этом всём разбираться. Достаточно будет просто использовать обычные готовые клиентские приложения.
В обсуждении issue в репе NekoBox упомянули (тов. sou1jacker) такой вариант (чтобы хотя бы сокс5 "завернуть").
Routes -> Create new -> Custom configuration
{
"inbound": ["mixed-in", "socks-in"],
"outbound": "block"
}POC при тесте реально упёрся в блок.
С этой настройкой нельзя пройти через socks стороннему приложению, но порт остается открытым. Возможно с 2080 лучше его убрать.
Но от curl ifconfig.me --interface tun0 на Android это не спасает. Так или иначе стороннее приложение даже при включенном per app proxy имеет возможность узнать внешний ip.
Так, а давай вот что.
NekoBox, нужно в роутинг добавить 3 правила.
То, что для сокс выше описано.
{ "inbound": ["mixed-in", "socks-in"], "outbound": "block" }Создать пул, в нем продублировать все пары, что выбрали в настройках для per-app
И третье, последнее по порядку - это глобальный тупик. В него вписать кастомный конфиг
{ "ip_cidr": ["0.0.0.0/0", "::/0"], "outbound": "block" }
Я вроде попробовал через консоль выполнить curl 2ip.io --interface tun0
И перестало показывать ip vpn выхода.
Вместо этого пишет
curl: (7) Failed to connect to 2ip.io port 80 after 133 ms: Could not connect to server
Т.е. то, что из аппов не перечислено в руле #2 - не пробивается, даже если лезет в tun0 явно.
Хабр кстати буквально час назад отвалился вне России без прокси. Что-то опять шаманят, через Российский прокси работает
Может быть ребята из Happ вели себя так, потому что были очень недовольны тем фактом, что я вообще это нашел.
разработчик Happ в своей телеграм группе отказался считать это уязвимостью и отказался исправлять даже под давлением своей собственной аудитории
Happ все же согласились исправить обе уязвимости.
Знакомая ситуация. В моей практике разработчики сначала проигнорировали сообщение об уязвимости, отказавшись проверять пошаговую инструкцию. Мол, они по своему коду видят, что этого просто не может быть. Потом всё же проверили и тоже не подтвердилось. Позже выяснилось, что проверка была на другой версии (не той, о которой я писал). В прежней версии кода уязвимости не было т.к. была необходимая проверка. Но, потом её зачем-то убрали. Т.е. разработчики сами запутались: когда, что и зачем они проверяют. Фикс выкатили (только для мажорных веток). Но, при этом отказывались признавать это уязвимостью, пытались обжаловать CVE (неудачно). После чего сказали, что MITRE и я - ангажированные. Подробнее я писал в статье Как я зарегистрировал CVE и разозлил вендора.
Никому не нравится, когда находят проблемы в их работе, это, наверное, нормально.
Но нужно иметь мужество это признать и исправить. Судя по всему не все на это способны.
Так они признали же по итогу, выкатили обновление
Вам личное извинение нужно? =)
Во первых я написал коммент до того, как они выкатили обновление.
Во вторых имелось в виду признать когда тебе это говорят 1 на 1, а не когда к тебе огромная толпа людей приходит и требует фикса.
Вы можете зайти в их телеграмм чат, первый час после публикации статьи они кривлялись как дети, что-то признавать и исправлять они начали когда поняли что кривляниями не отделаются.
Первый UPD появился не просто так, они в явной форме отказывались это фиксить пока на них не надавили. Это не мужество, это страх.
Можно носить с собой коробочку с впн на портативном 4g-роутере с аккумулятором и раздачей вай-фай. Будет физическое отделение устройств.
Кстати у happ еще есть приложение в рф appStore, так же не все потеряно)
На Android использую связку AdGuard + v2rayTun, где AdGuard в режиме TUN (VPN) - обрабатывает весь трафик, v2rayTun - в режиме прокси.
Скрытый текст
В AdGuard настроил перенаправление трафика в SOCKS5 на порт 10808, на котором работает клиент VLESS.
Скрытый текст
VpnDetector видит, что на телефоне включён VPN, но это и понятно: AdGuard без root только в таком режиме и работает.
А вот Proxy Bypass не смог распознать внешний IP.
Скрытый текст
Понятно, что не каждому данное решение подойдёт, с учётом того, что для AdGuard нужна лицензия, но, возможно, как временный WA @runetfreedom ?
Подвержены ли данной уязвимости Xkeen и другие клиенты для роутеров?
Выкатили обновление
У меня стоит клиент v2rayng и happ на android (samsung s25)
Я скачал вашу утилиту потестировать, и он выдал следующий результат
v2rayng
последней версии, настройки по умолчанию+ per app включен, набор правил маршрутизации вариант runetfreedom только заблокированное в прокси
1) status: per app split disabled // это неверно он включен в настройках)
2) proxy SOCKS5 127.0.0.1:1080 // это он нашел ., ОК
3)DIrect IP провайдерский IP / правильно
4) IP via proxy : провайдерский IP / не правильно
5) Xray API : Not found
Happ
(последней версии, настройки по умолчанию+ per app включен, набор правил маршрутизации simple routing https://github.com/frayZV/simple-ru-routing/blob/master/README.md#happ-routing
1) status: Detected // правильно
2) proxy SOCKS5 127.0.0.1:1080 // это он нашел ., ОК
3)DIrect IP провайдерский IP / правильно
4) IP via proxy : IP прокси / правильно
5) Xray API : Not found
/
Попробуйте проверить socks5 аналогично: https://github.com/amnezia-vpn/amnezia-client/issues/2452
У меня нет сервера с Амнезией..Но я сразу вам могу сказать,что покажет команда
url -s --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 https://ifconfig.me/ip
в случае с v2rayng у меня- айпи адрес провайдера.
Потому что этот адрес не находится в списке заблокированных
Отсюда следует вывод,,если мы примеряем на себя роль злоумышленника, то нам необходимо всего лишь разместить чекер на замедленном\заблокированном ресурсе.
Но все равно непонятно,почему тулза не определи per app настройку
Да, я не очень внимательно прочитал и упустил, что в v2rayng маршрутизируете только заблокированное.
Ну, было бы интересно проверить, что уязвимость и в это клиенте есть, тогда можно попробоватьcurl -sL --socks5-hostname 127.0.0.1:1080 --connect-timeout 10 https://rutracker.org | head -15
Не все клиенты запускают Socks. Нужно выбирать правильные клиенты, а ещё лучше сток клиент для ядра и писать файл конфигурации самому. Там socks нафиг не нужен.
Давайте без умных слов. Итак читать страшно.
Если развернём виртуалочку, и на запрещённые ресурсы будем ходить через неё, предположим, что там внутри клиент Амнезии.
Установим чистый FF/Гугл браузер и что, тоже задетектится?
Если у вас нет возможности получить второй IP, то в качестве альтернативы вы можете завернуть весь ваш выходной трафик в CloudFlare WARP.
Уже давно пользуюсь только так, поскольку были прецеденты блокировки моего сервера по IP, и я подозревал, что это связанно со случайным заходом через него на российский сайт. Да и многие сайты не пускали к себе с IP хостингов, но при этом спокойно пускали через WARP
[del]
Подтверждаю, что разрабы Happ уж очень слабые люди, так как максимально не признают свою ошибку, хотя сами-же выкатили потом апдейт и всё-равно говорят, что всё норм и ничё там такого не было. Также они легки на оскорбления.
Ну их нафиг честно говоря, пойду V2RayTun пробовать. Если по функционалу будет норм, то на нём и буду сидеть. Либо попробую ещё что-то, но Happ в последнюю очередь после такого.
Прочитал этот тред и подумал: "Чего только русский человек не придумает, лишь бы только революцию не устраивать!"
Paper VPN Lite 2.0.17 - детектится жёстко.
Amnezia VPN (WG 2) 4.8.14.5 - детектится на половину.
Тестил рекомендуемым cherepavel/VPN-Detector.
У меня идентичная конфигурация AWG2 + split tunneling только для выбранных приложений. А опыт с ```curl ifconfig.me --interface tun0``` в Termux что-то выдаёт? У меня таймаут соединения (Termux 2026.02.11, Android 15).
Отчёт VPN-Detector
VPN Detector Report
Generated: 2026-04-07 23:16:44
=== OVERALL STATUS ===
VPN present outside active path
Android sees a VPN network in the system, but not on the current active network.
This often matches bypass or split-tunnel behavior: a VPN exists, but current traffic may not be fully routed through it.
=== OFFICIAL ANDROID API ===
TRANSPORT_VPN across all networks: DETECTED
TRANSPORT_VPN active network only: NOT DETECTED
Transport state: SPLIT / BYPASS
Transport subtitle: A VPN-related transport exists system-wide, but it is not the current active path.
API signals:
- Interface name
source: LinkProperties.getInterfaceName()
value: tun0
hint: The interface name looks tunnel-like and is consistent with a VPN being present somewhere in the system.
- Transport info
source: NetworkCapabilities.getTransportInfo()
value: VpnTransportInfo
hint: Transport info is present and aligns with a VPN existing somewhere in the network stack.
=== NATIVE LOW-LEVEL ENUMERATION ===
Signal value: tun0
Signal hint: Native enumeration found interfaces whose names or properties look tunnel-like.
lo: flags=0<>
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128
rmnet_data1: flags=0<>
inet 12.86.222.32 netmask 255.255.255.192
tun0: flags=0<>
inet 10.8.1.2 netmask 255.255.255.255
inet6 [REDACTED] prefixlen 64
wlan0: flags=2<BROADCAST>
inet 192.168.0.148 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 [REDACTED] prefixlen 64
=== JAVA INTERFACE ENUMERATION ===
Signal value: none
Signal hint: Java network enumeration did not find any tunnel-like interface names.
=== DETECTED VPN APPS ===
- Amnezia VPN (org.amnezia.vpn)У меня тоже сплит. Лишь выбранные идут через туннель. Но всё работает. Как на маленьком проводном провайдере, так и на мобильном билайн.
Curl ip-шник выдаёт.
Интересно. У меня только с wlan0 выдаёт IP. Nothing Phone 1 (A063)
Попробуйте в правила для сайтов добавить 1.1.1.1 и проверьте ещё раз вывод curl
Более подробный отчёт. Vpn Detector.
Скрытый текст
VPN Detector Report
Generated: 2026-04-08 04:42:27
=== OVERALL STATUS ===
VPN present outside active path
Android sees a VPN network in the system, but not on the current active network.
This often matches bypass or split-tunnel behavior: a VPN exists, but current traffic may not be fully routed through it.
=== OFFICIAL ANDROID API ===
TRANSPORT_VPN across all networks: DETECTED
TRANSPORT_VPN active network only: NOT DETECTED
Transport state: SPLIT / BYPASS
Transport subtitle: A VPN-related transport exists system-wide, but it is not the current active path.
API signals:
- Interface name
source: LinkProperties.getInterfaceName()
value: tun0
hint: The interface name looks tunnel-like and is consistent with a VPN being present somewhere in the system.
- Transport info
source: NetworkCapabilities.getTransportInfo()
value: VpnTransportInfo
hint: Transport info is present and aligns with a VPN existing somewhere in the network stack.
=== NATIVE LOW-LEVEL ENUMERATION ===
Signal value: tun0
Signal hint: Native enumeration found interfaces whose names or properties look tunnel-like.
lo: flags=0<>
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128
rmnet_data1: flags=0<>
inet 7.2.101.196 netmask 255.255.255.248
rmnet_data3: flags=0<>
inet 10.132.59.79 netmask 255.255.255.224
tun0: flags=0<>
inet 10.8.1.1 netmask 255.255.255.255
inet6 fe80::4eef:ec25:686c:aa2b prefixlen 64
wlan0: flags=2<BROADCAST>
inet 192.168.0.51 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::9c1d:b3ff:fe85:7a9c prefixlen 64
=== JAVA INTERFACE ENUMERATION ===
Signal value: none
Signal hint: Java network enumeration did not find any tunnel-like interface names.
=== DETECTED VPN APPS ===
- Amnezia VPN (org.amnezia.vpn)
На телефоне с ядром 6.1 помогло в правила раздельного туннелирования добавить IP адреса только тех сайтов, на которые нужно ходить. Получилось так: в app-based split tunneling находятся приложения Telegram и Whatsapp, в site-based адреса из cidr.txt Телеграма. В итоге адрес не утекает через curl.
Полагаю, что достаточно добавить в site-based правило для 1.1.1.1 или любой другой адрес, который заведомо не будет использован для сервисов определения адреса выходного узла, и тогда метод с привязкой к интерфейсу не сработает, так как сработают правила роутинга или iptables, смотря что использует AmneziaVPN. Тут только смущает, может ли злонамеренное приложение модифицировать эти правила в свою пользу?
Скриншоты Vpn Detector.
Скрытый текст
@runetfreedom Не смотрели не ведут ли такую активность по выявлению КВН Госуслуги? Может быть другие приложения засветились?
Вообще хорошо бы проводить периодически такой аудит по самым распространенным приложениям.
Пора свой аналог TOR для всей страны мутить.
Я на Android перешёл на v2rayNG с ручной авторизацией socks5, UDP вырубил. Пока живёт, но скорость просела
Из-за критической уязвимости VLESS клиентов скоро все ваши VPN будут заблокированы