Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 892
Так вот оно что! То-то я с утра сижу и бьюсь уже целый час — через Hiddify и все тайм-аут. Короче, понятно. И ведь надо же! Скажем так: не зря им там зарплату платят...
Happ работает нормально сейчас. Отвалился на днях hiddify на винде и самсунге у семьи, пришлось перевозить. У happ конечно открытого исходного кода нет, но в целом на нем сижу уже с год, проблем не знаю. Плюс есть раздельное проксирование даже на пк, правда замороченнее, чем на телефоне. И если немного пошаманить по их мануалу, то автобут с автоподкобчением есть. Хз на сколько контора надежная, но вроде пока норм
На днях отвалились старые версии hiddify. С последней версией на линуксе и андроиде всё работает, у меня по крайней мере.
отвал какой-то частичный кстати, 1 сервер работает, а другой, который на телефоне пашет в таймауте
В итоге, в моем случае, дело было в том, что просто нужно было поменять домен на нейтральный и не вызывающий особых вопросов, скажем так. Снова все заработало в итоге. Но я именно на Винде пользовался Hiddify (да и Happ тоже). На смартфоне (у меня iOS), пожалуй, принимая во внимание описанное в статье не буду заходить ни в какие приложения кроме ТГ.
happ, хорош в плане удобства чтения логов и настройки, но со временем тоже начал выдавать неожиданности, наиболее стабильный клиент сейчас v2raytun и FlClashX
наиболее стабильный клиент сейчас v2raytun и FlClashX
А для них где-то есть обновляемый routing наподобие
в v2rayn и v2rayng есть
еще в karing есть, там и для socks5 логин и пароль можно задать
Мне понравился Karing прекрасным режимом auto.
Подходит для subscribtion любого размера, большой и маленькой.
Но вот routing там непонятный. Ну да, обновляются .dat файлы. Но где там онлайн-обновление самих правил роутинга, наподобие https://github.com/frayZV/simple-ru-routing ?
Я не нашёл (возможно, дедушка ослеп (с)
А чем FlClashX кардинально отличается от FlClash ?
Подскажите, как сделать автозагрузку с автоподключением?
А пробовали обновлять данные профиля ("Update subscriptions")?
У меня тоже было такое пару раз, и это помогло.
Попробуй переустановить клиент, у меня тоже была такая проблема и я думал что отвалился сервер, но как оказалось проблема была именно в клиенте hiddify, так как при тестах выяснилось что с других клиентов подключение норм
Hiddify сам по себе довольно глючный, давно его не использую
Как понимаю, это про архитектуру Android VPN, а не iOS. На Android через VpnService + tun2socks часто поднимается локальный SOCKS, и при кривой реализации его можно дернуть. На iOS такого нет. Network Extension + sandbox не дают другим приложениям ходить в локальные сервисы. Так что это скорее косяк клиентов под Android, а не проблема протокола или всех платформ.
Слепая вера в какие-то волшебные sandbox’ы эппла ни к чему хорошему не приведет.
Apple точно так же уязвим, в том числе к атаке на Happ.
Поставьте, к примеру, libterm и попробуйте
curl --proxy socks5h://127.0.0.1:10808 https://ifconfig.me/ip
Вообще вокруг iOS очень много сказок.
Не до конца понял, какой именно сценарий вы демонстрируйте. С libterm ты же сам из своего процесса ходишь в 127.0.0.1, это ожидаемо. В статье речь про то, когда стороннее приложение без ведома пользователя может найти и использовать локальный SOCKS. Можете уточнить, как в iOS вы воспроизводите именно cross-app доступ к этому прокси, а не доступ из того же приложения?
Э нет, прокси запущен в одном процессе, libterm - в другом. Воспроизводится. Можно ещё к этому прокси подцепиться через апп который умеет подключаться к прокси, например телеграм
Ок, допускаю, что в отдельных реализациях это может воспроизводиться и на ios. Но насколько я знаю на ios при использовании network extension обычно нет необходимости поднимать socks наружу. Трафик обрабатывается внутри системного vpn стека. На android же из-за vpnservice часто используется схема tun2socks + локальный proxy, поэтому там этот сценарий куда более типовой.
Причем тут VpnService? Xray (по крайней мере раньше) не умел принимать трафик на TUN интерфейс. Единственным способом зароутить туда трафик был tun2socks.
Это справедливо и для Andoroid и для iOS (и даже для Windows)
Ааа, всё, теперь понял, не туда ушёл в размышлениях, спасибо за пояснение. Пытался выгородить клиентов и искать проблему в другом месте, а по факту всё упирается именно в их реализацию. Тогда действительно странно, что они до сих пор тянут эту схему, так как я думал, что Xray до сих пор не умеет нормально работать с TUN.
В IOS версии нет возможности сплитовать туннель, то есть указывать каким аппам можно ходить через впн, а каким нет, если у вас есть такой клиент для влесс на иос, напишите, я с удовольствием его скачаю и проверю.
v2rayTun на iOS есть роутинг и правила трафика, можно укзаать geosite, домен, ip и в таком случае с включенным впн, домены указанные в исключениях будут идти напрямую. С приложениями пока не проверял, но в том же мануале от эппл для энтерпрайза заявлена такая возможность в самом iOS
https://support.apple.com/en-mide/guide/deployment/depae3d361d0/web
но в том же мануале от эппл для энтерпрайза заявлена такая возможность в самом iOS
Оно только там и есть
Ну допустим настроив direct для всех ru geo/domain, блокировка "У вас включен ВПН" не появляется в приложениях ozon/yandex/avito и прочих, но это больше потому что они сейчас тупо смотрят страну входящего трафика, а не детектят именно наличие впн в системе, вопрос - мы же говорим именно про возможность приложения определить наличие впн в самой iOS даже если трафик не пошел через него?
Возможно ли развернуть свой сервак с MDM (nanoMDM), без привязки к ABM, для включения per-App VPN?
вопрос - мы же говорим именно про возможность приложения определить наличие впн в самой iOS даже если трафик не пошел через него?
Сетевые интерфейсы, таблицы маршрутов все еще доступны. Если очень хочется, то и порты на локалхосте на предмет запущенного прокси просканировать тоже дело пары секунд.
свой сервак с MDM
Не имел опыта, но это явно не массовое решение
На андройде 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 с трояном ничего не должно поменяться. По хорошему оно про рутованность телефона и знать не должно. Только бекаперы, фаерволы та еще несколько системных утилит нуждаются к расширенному доступу. Ну или если охота в кишки кому-нибудь залезть.
На рутованных телефонах разблокирован загрузчик. Если иметь физический доступ к телефону, то никакая защита не поможет.
Сами приложения при запуске могут запросить root доступ. Однако мы знаем много случаев, когда находили уязвимости в sudo на linux, так что root на андроиде может так же иметь 0-day уязвимости.
Единственный телефон куда можно поставить безопасно прошивку, это pixel. Так как там можно заблокировать загрузчик обратно.
Ведроид как был унылым недоделанным местами гуаном таковым и остаётся увы. Как его не крути он линуксом полноценным никогда не станет. Так как априори лишь базируется на линукс ядре.
Все что сверху данного ядра увы отношения к линукс увы не имеет.
Хорошо еще что китайцы на ряде своих устройств предпочитают весьма не слабо переделывать код ведроида, что бы свой собственный функционал реализовать, но увы все это не влияет на прискорбное состояние безопасности данной оси.
ни одна ос из-за кучи легаси не поспевает за реальностью в области безопасности.
из популярных лидер наверное огрызки, но слишком дорогой ценой полной анальной зависимости.
Угу.
А потом разработчики софта на сообщение о том, что что-то не работает, отвечают: у вас Xiaomi? Идите лесом, это не Android.
Сталкивался уже.
Magisk уведомляет, что приложение запрашивает root-права. Нужно больше деталей о ситуации, иначе при детальном разборе может оказаться, что root тут вообще ни при чём.
Тут палка о двух концах. Либо ты доверяешь закрытому банкингу, либо контролируешь систему через рут, но берешь все риски на себя
Я бы хотел такие галки в настройках телефона.
Я хочу разблокировать загрузчик.
Я хочу рут-права.
Я понимаю риски.
Я понимаю, что эти действия могут привести к потере гарантии.
Я принимаю все последствия на себя.
И без всех этих танцев с бубнами (подбор правильного recovery, кастомной прошивки и прошивальщика), ожидания недели, или сколько там сейчас, пока китайский бот не одобрит (я про Xiaomi сейчас) и сноса всех данных и приложений при разблокировки загрузчика.
Я понимаю, зачем данные при разблокировке загрузчика удаляются, но все же, может можно было как-то по-другому?
Проставил пять галок, перезагрузился, все у тебя рут и данные никуда не делись. Хочешь, живи на стоке с ним, хочешь - накати кастом...
Мечты...
В остальных случаях можно рут скрыть
Я зарёкся так делать. Лишился на своей трубке возможности бесконтактной оплаты. А доступ к банковскому приложению так и не появился. One+
позвольте надушнить, swoo(балалайка для NFC оплаты альфа банком) нивкакую не видит KSU, даже без всяких модулей
Что за странная вещь этот Swoo? Выглядит как GetContact, только для дисконтных карт.
А чем собственное решение банка Alfa Pay не устроило?
https://www.alfabank.by/services-perevod/pay/
это не ко мне
Happ - уязвим и особо опасен, не рекомендуется использовать ни при каких обстоятельствах... Только что прилетело обновление на Happ и он перестал детектиться per-app-split-bypass-poc
Подтверждаем, обновление закрыло уязвимость
Не подтверждаю, https://habr.com/ru/articles/1020080/#comment_29798626
Какую версию приложения у вас показывает? Обновление из g-play?
Обновил на самый последний Happ: стоит и маршрутизация с geoip.ru и geosite:category-ru в директ и выбор приложений (сплит тун) в котором нет PoC топикстартера. Да при проверке xray api не оперделяет. Но локальный порт находит и видит внешний ip vps сервера. Что именно должно перестать детектится? название клиента?))
Скрытый текст
Чушь.
Грамотность тут не причем.
Не составляет особо труда по гайду с 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, однако у них крайне специфическая разметка разделов памяти устройства если не дай бог что-то посыплется или сам напортачишь восстановить работу устройства будет мягко говоря проблематично.
Ну рут в наше время еще пока много на что можно поставить, но это "много что" зачастую компромиссное. Те же нихренафоны - ну камеры у них такое себе.
Гуглопиксели - вечная лотерея с радиомодулями вне США, отвалится-не отвалится, да еще и обновы бывают непонятные, плюс батарейки уровня "на один день", да и быстрые зарядки - смешные по современным меркам.
Я вот свой Vivo x200 FE за камеры прям дико люблю, основная прям отлично снимает сияния ночью, астрофото суперские для его цены, размер почти удобный (для 6.3), в общем, много чем устроил, но рут на виво отсутствует. Риалми туда же. Не на всё есть, а на что есть - то уже устарело морально, да и с рута не так много толку, если нет хороших сборок LOS.
Самсунги тоже так себе, ибо для полуфлагманов батареи никакущие по сравнению с китайцами. Galaxy S как во времена S3, S9 садились на глазах даже от простого веб-серфинга и шатания по системным настройкам - так и сейчас садятся, по крайней мере, на последней модели, побывавшей в руках (S23).
Салями номерные разве что, ибо там и почтикомпакт, и камеры норм, и батареи емкие, и рут с лосём, но у актуального Mi ценник сейчас 1000+ баксов, ну его нафиг. Да и неоф прошивки по-моему только на 14-й Mi есть, в более свежих на 4pda тишина.
Так что приходится выбирать "или шашки, или ехать") Сбалансированного по возможностям\цене\специфическим задачам давно уже ничего нету на рынке. Плюс в среднем сегменте (15-30 тыр) вдобавок почему-то только одни лопаты.
Спасибо за наводку. В любом случае после новостей о принудительном обнаружении VPN траффика на андроид НЕОБХОДИМО накатывать рут. Без него вы от ВК и Сбера не скроете наличие VPN-клиента на телефоне, даже если он отключен (Модуль HMAL). Как ниже писали "Повод для очередного повышения цифровой грамотности населения"
По поводу грамотности. Вы никогда не думали почему в современных ОС, будь таки они мобильные или ChromeOS, нету доступа свободного кому попало к root? Вы считаете это разработчики не грамотные или "жадные"?
Угу, жадные. Которые хотят продавать сервис, а не устройство. (альтернативная версия - чтобы снизить нагрузку на техподдержку от окрипичивших телефон пользователей. Так как спертые деньги из за зря розданного доступа никакой беды разработчикам не делают. Или я пропустил какую-то новость?)
Как ответили ниже, продают потому что теперь "пользование", а не устройство. Сейчас даже шанс на возвращение телефона в свои руки не дают, все ради "вашей безопасности". В этом деле всегда можно восстановить свое криворукое решение, не всегда бесплатно, но это уже совсем нужно недалеким быть. Где-то тут выше тоже писали, что на IOS даже шанса скрыть использование КВН не будет в случае чего, тогда как на рутированном андроиде это можно будет делать. Вот вам "преимущества закрытой системы". Терпеть в безопасности тем не менее, вам никто не запрещает, каждый делает свой выбор
Гайд можно ☺️
Напишите плиз в 4пда мануал как изолировать это нехороший квн от кого ненадо
присоединяюсь к тем кто попросил гайд. afwall стоит, но я его использую только чтобы блокирнуть интернет паре приложений, т.е. настраивать не умею.
Так простое решение ближе чем кажется .. Во первых не использовать клиенты отечественных сервисов во вторых можно использовать второй смартфон.. Это что бы пользователю не объяснять что ему можно и что нельзя очень долго) кроме того есть же разные варианты проксирования ..это не обязательно сокс и вообще не обязательно именно прокси и сплит тоннель..но за статью спасибо..информация полезна)
кроме того есть же разные варианты проксирования …это не обязательно сокс и вообще не обязательно именно прокси и сплит тоннель
Только у 95% населения это сокс и именно прокси
А вы не в курсе, на всяких Xiaomi, Realme и вроде даже Samsung есть второе пространство. Как оно устроено? Это отдельный пользователь в ОС по сути? Я к тому, если использовать в нём все приложения, которые потенциально занимаются слежкой (или наоборот ВПН + телега, Ютуб и т.д.), получится ли избежать такого способа слежки через описанную вами уязвимость?
Второе пространство <клонирует> уже установленное приложение.
Across all network едино для обоих пространств, можете проверить.
Нет, если устанавливать сразу во второе окружение, у самсунга тот же кнокс - это лютая отдельная песочница(читай отдельный телефон).
Нет, на пикселе private space не пробрасывает VPN. Но что насчёт портов — не знаю
В любом случае мы заходим на сайты, где могут быть такие же трекеры
У сайтов существенно меньше возможностей покопаться в содержимом телефона, в сравнении с приложениями
А копаться и не нужно. Посылаем запрос на получение ip с tld .ru и .com и запрос на заблокированный сервис. Если разные tld вернули разный ip, то баним. Если зарубежный ip, то баним. Если заблокированный сервис доступен, то баним. Этот скрипт можно внедрять куда угодно и никто не узнает, пока не станет поздно
Посылаем запрос на получение ip с tld .ru и .com и запрос на заблокированный сервис
Браузерный CORS: "Я для вас какая-то шутка?". Веб-версии работают в браузером контексте, там всё в разы строже, нет серверной вседозволенности.
Им нужно будет свои ресурсы поднимать и добавлять в AllowList по CORS, причём добиться блокировки одной из определялок IP-адреса в полном соответствии с процедурками РКН, чтобы быть уверенными. Либо добиться попадания определялки во все попудярные геобазы как ru и как не-ru. Это в разы сложнее задача.
Я, конечно, понимаю, что в этом всём фарсе мы все, участники этого недевственного цирка, зашли далеко - намного дальше, чем любая другая страна в мире - но в этом случая я точно понимаю, что овчинка выделки точно не сто́ит.
Но разве они не могут сделать свои сайты для проверки IP-адреса, где будут разрешены соответствующие междоменные запросы? Ну и также могут сделать свой сайт за границей, который будет специально заблокирован. То есть, всё решается, просто нужно настроить заголовки, возвращаемые браузеру, но это нельзя считать препятствием.
не помогает.
Да, но уже существующие клиенты, получив обновление от "гос" приложения с использованием этого эксплойта - засветят свои VPN сервера.
Вопрос кто быстрее - клиенты обновятся или "гос" приложения.
А как быть "наружным" россиянам за границей? Им VPN в любом случае нужен. Иначе при выключенном VPN есть вероятность, что либо РФ-сервис не откроется, либо постучит кому положено, что пользователь находится за рубежом (пора проверять на налоговое резиденство, например).
Ну это решается резидентным выходным узлом и использованием веб версий приложения..
Арендовать Didicated Server где-то в РФ или размещать его у друзей / знакомых причем у маленьких провайдеров, где чуть меньше шансов что прибегут парсить логи коннектов.
Использовать белый VPN который одобрил РКН, но от идеи проверки на налоговое резиденство не спасёт (но оно пока и не реализовано).
Использовать ВПН от непонятно кого в РФ, но под веб версиями сайтов. Есть шансы что и за такие впны возьмутся, но "не сегодня" и опять же надо будет не только поднять логи коннектов но и содержимое трафика, чтобы узнать кто залогиниться в сайт в этого ВПНа.
---
Мой взгляд дилетантский и обывательский, не стоит брать его за идеальный вариант
а на законодательное регулирование доступа граждан РФ к сервисам внутри РФ похоже, вообще забить решили. Почему нельзя гражданину РФ пользоваться госуслугами (и прочими сервисами в РФ) из-за рубежа? - Покачену!
Уже проскочила новость, что рустор будет предоставлять прям свой собственный VPN для посетителей из-за границы. Интересненько, значит, скоро нас ждет реестр выехавших за границу?..
Для внешних юзеров надо поднимать свой VDS внутри РФ. Готовые коммерческие сервисы отваливаются слишком непредсказуемо
Живя в России, невозможно практически не использовать клиенты отечественных сервисов
Банк, маркетплейс, банально погода точная, карты - как минимум
Вполне возможно, я перестал использовать их за долго до всего этого..но это не значит что нужно отказаться от этих сервисов ..те же озон и Яндекс как карты так и такси и доставка еды вполне работают через веб сайт) а карт так и вообще полно альтернатив если нужно именно приложение )
Если просто карты - полно. А, вот с нормальной навигацией. Уже большая проблема.
у OSM на андроиде карты в мск регионе были лучше яндерса во многом, но без пробок. не знаю, может можно и пробки прикрутить, но у меня надобность отпала раньше чем руки дошли.
Про карты речи нет. Куча разных. Но автомобильной навигации адекватней, чем у Яндекса, я не нашёл.
автомобильная навигация именно у яндекса в какой-то момент (лет 10 назад) перестала быть адекватной. я его еще до этого снёс когда он мне на развязке решил показать рекламный банер поверх схемы развязки и я 20 километров ехал до разворота. но насмотрелся на блуждающих курьеров и таксистов. при чем когда-то он был действительно лучшим.
органик мэпс на OSM строит маршруты вполне сносно, в моих глубенях он значительно лучше гугла (надеюсь тындекса тут нет вообще). но не учитывает пробки, что мне не актуально. тут либо нет пробок либо нет объездов.
Не согласна
Во-первых, на доброй половине устройств, так как у нас в стране много дешёвых телефонов, запуск маркетплейсов, банков или тем более карт в браузере - то ещё удовольствие. В вебе это всё очень плохо работает, если телефон слабый
Во-вторых, конкретно про карты - у яндекс и 2гис альтернатив на самом деле практически нет. Для "из точки А построить маршрут в точку Б" можно пользоваться чем угодно, хоть на OSM, но такой базы организаций нет больше нигде. Одновременно отзывы, фотографии, панорамы, данные о трафике, мгновенный учёт пробок и препятствий (так как много пользователей). Без всего этого карты - просто обрубок
Маркетплейс - без проблем, ни одного приложения ни разу не стояло. Погода, карты, почта - то же в браузере отлично работают. Единственное банк, тут как повезет, не у всех есть нормальный вэб интерфейс.
Дождаться пока клиенты заменят tun2socks на https://github.com/XTLS/Xray-core/tree/main/proxy/tun
Он скорее не работает, чем работает
Очень смелое заявление... В нем нет огромного чемодана управления сетью (менеджмент роутинга и ip адресов) который тянут за собой приложения типа tun2socks, но как интерфейс->xray core он вполне работает неплохо.
Это дизайн такой, не превращать приложение занимающееся трафиком в сетевой комбайн. Сетевым менеджментом должно заниматься приложение используещее библиотеку, но не сама библиотека которая занимается трафиком.
Очень смелое заявление…
Заявление человека, который пытался его использовать. Кроме того, что он не полнофункиональный, так еще и имеет примерно миллиард багов. То зависнет, то пакеты в /dev/null улетят, то еще что-то.
А для VpnService нужен полнофункциональный сетевой интерфейс.
И да, на андроиде скорее всего багов еще больше, я не видел ни один клиент, который его использовал бы. А вот к примеру в sing-box с этим проблем нет.
Вы это заявление делаете человеку который его написал.
Откройте issue в Xcore, опишите свои "баги" и посмотрим что к чему, а так вот на форуме смело рассказывать какие все дураки и не лечатся - не стоит.
Я тестил его далеко не сегодня, допускаю вероятность что большинство багов, с которыми я столкнулся при его добавлении в ядро были исправлены.
Но тем не менее, он очень свежий и клиенты его не используют, к сожалению.
Thank you for your service! Голый xray-core не тестил, а на последнем v2rayNG завелось сразу с дефолтным конфигом!
Он прекрасно работает, но я не вполне понимаю как он решает проблему сплит-тунелинга. Без изоляции сетевых пространств имён этот интерфейс точно так же доступен всем желающим, да ещё и аутентификации как в том же 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.
Он поддерживает per-app proxy?
Хорошее приложение, сижу на нем 2 месяца, но не подключала аутентификацию прокси, и роутинг по умолчанию вел в впн (был white list для директ). Как в статье и написано, из стороннего приложения через прокси на локалхосте или tun0 можно было спокойно вычислить выходной адрес. Настроила аутентификацию прокси и поменяла принцип роутинга: white list для впн и все остальное по умолчанию в директ. Еще на всякий случай geosite:category-ip-geo-detect тоже в директ. В настройках приложения можно заменить адреса получения geoip и geosite на runetfreedom и заюзать в роутинге geosite:ru-blocked. Красота :)
Вопрос, что делать с теми же браузерами, которые с Socks5 в Андроиде работать не умеют. Единственное известное мне исключение- Firefox с корявейшим плагином FoxyProxy, от которого не удается добиться ничего, кроме "HTTP 407 Proxy Authentication Required Error", несмотря на верные настройки логина и пароля. Ну или Хром с ним же, но плодить Хромы не хочется лишние... Ну а тем, кому только телега и ватсапп со встроенными настройками прокси-проблем неи, все работает.
Xray может работать в режиме КВН и поднимать tun0. Или вы используете режим прокси, чтобы не раскрыть адрес VPS? Я пока склоняюсь к тому, что риск раскрытия IP сервера - это проблема сервера, и соответственно решать ее нужно на сервере. Возможно выходить через Cloudflare WARP, или арендовать дополнительный IP/VPS. Ну и в крайнем случае, если с настройкой выхода ничего не выйдет или если она невозможна, можно скачать Chrome Beta (Beta будет жить без КВН) и установить все ру приложения как PWA (в браузере кнопка Добавить на главный экран). И хоба, это теперь по сути сайты и никакого tun0 им не увидеть. Но надо смотреть, что там у PWA по уведомлениям и насколько ими в целом удобно пользоваться. Хотя благодаря блокировкам приложений в App Store думаю многие PWA должны быть очень достойными. В итоге можно будет держать Xray в режиме КВН с tun0, распространив на приложения без встроенной поддержки прокси и не рискуя спалить адрес. Замороченно, но все еще удобнее, чем носить 2 телефона.
режим прокси
Именно... В первую очередь для того, чтобы не ругались приложения вроде WB или СДЭК и прочие :) Ну и риск утечки адреса ниже. Soсks5 с автоизацией, андроидные телега с ватсапом через него работает, ютубчики, понятно, нет. Ну и непонятки с браузером-несмотря на все потуги, Foxyproxy под Файрфоксом для Андроида жалуется в логе на ошибку авторизации на прокси, и не работает. Заодно пришлось временно уйти с v2raytun на husi, там все удобно и грамотно в плане настройки прокси в самом приложении, v2raytun только правкой конфига...
у меня сегодня отвалились 2 платных сервиса и 1 бесплатный, и причем часть сайтов в зоне ru тоже не открывается
Я теряю деньги из-за всех этих блокировок, что делать
Трактор.jpg :(( Что тут сделаешь...
Трактор может обойтись гораздо дороже
Надо подождать, пока из-за блокировок потеряется денег больше, чем из-за трактора, чтобы потом кусать локти.
Если вам есть что терять, то потом уже не оправитесь. Вся система капитализма так рассчитана
Вопрос тут не в деньгах, сколько трактор стоит, и не в том, есть ли что терять (терять всегда есть что), а в том, готов ли человек принять поражение, сделать вывод и перевернуть страницу или надо еще по лбу получить разочек, чтоб выйти из этого казино. Ну или не разочек. Мне вот несколько понадобилось. И никакого отношения это к капитализму не имеет, как бы свидетелям ссср ни хотелось, это стандартный паттерн поведения.
На дальних временных горизонтах цена трактора конечна, а цена его отсутствия - нет.
Расскажите подробнее, постараюсь предложить варианты
GeoIP ни на сервере, ни на клиенте, ИМХО, не поможет ничем, у них хватит мозгов стучаться на арендованный для этой цели зарубежный хост.
Получается, на стороне сервера два IP будут необходимы.
А на стороне клиента - старый добрый фаерволл не подойдёт? Чтобы ни одно приложение без явного разрешения не могло стучаться на локалхост.
А на стороне клиента - старый добрый фаерволл не подойдёт?
Подойдёт. Просто запретить приложениям-стукачам прозванивать локальные адреса и усё.
Имхо тут оптимален только вариант белых списков со своей стороны - youtube/instagram/github и тп все заворичивается в туннель на какой то входной ноде, который ретранслирует уже трафик как есть на VPS с развернутым wg/vless.
А все что не входит в "белый список" - шлется напрямую дальше в интернет.
Да, это проблематично, да надо будет постоянно обновлять список на основе личного опыта, но так эти упыри гарантировано не увидят ip вашей впски, максимум айпи русской впски, являющейся входной нодой для всех.
На выходном VPS можно арендовать еще один ip и использовать его для выхода в интернет, или использовать еще один VPS, можете настроить Proxy, и никто её ip кроме вас и вашего российского хостинг провайдера не узнает. Всё таки необходимо заботится об удобстве при пользовании интернетом.
Кстати может быть кто-нибудь знает предоставляют какие либо из VPS провайдеров второй серый IP. Ведь для выхода не нужен белый ip
Можно почитать в комментах, этого недостаточно.
скаМ (и в будущем всем российским приложениям, которые обяжут поставить библиотеку с этой логикой под угрозой исключения из белых списков и лишения аккредитации) достаточно иметь один зарубежный сервер. Затем делается два запроса: один к серверу скаМ, второй - на подконтрольный зарубежный сервер. Если айпишники различаются - отправляем в блок иностранный айпишник.
Так в том и смысл, что на ваш зарубежный сервер идет трафик только для специфичных доменов, совершенно не важно какой впс разрабы скама купят, он не попадет в ваш "белый список".
В таком варианте тоже есть свои уязвимости и проблемы - начиная с того, что отказ входной ноды повлечет отсутствия интернета для вас, но зато как минимум вы свой ip не спалите вообще никак.
Это тоже не панацея. Во-первых факт обхода блокировки все равно будет виден (скам может сделать запрос к telegram.org и увидеть, что он доступен).
Во-вторых, цензору даже необязательно покупать свой сервер за рубежом для этого. Достаточно найти в любом сервисе из вашего белого списка (Telegram, Discord, ChatGPT, всякие зарубежные CDN и так далее) один скрытый пусть даже сервисный или не предназначенный для публичного использования endpoint, который отдает ваш 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. Сетевой задержки ведь нет.
Скриншот из V2RayNG, разве это не запрещает все обращения с localhost?
А ещё можно просто
ПОСМОТРЕТЬ
ОТКРЫТЫЕ
ПОРТЫ.
Расскажите, как это сделать на android 14-15 (других у меня нет) без рута?
Это блокируется selinux’ом для обычных программ на современных android. Через adb можно.
А можно поподробнее пожалуйста, как через adb запретить лишним?
К adb нету доступа по умолчанию. Он имел ввиду, что список сокетов можно через adb посмотреть (вручную). Так как netstat -a в Termux (как приложению в песочнице) кажет пустой список.
отсканить открытые порты можно попыткой открытия в приложении по ошибке "порт занят". это в любом случае доли секунды. биндить на нестандартный локалхост без рута очевидно не получится. в сочетании с тем, что скам на вашем смартфоне никуда не торопится, это мёртвая идея.
биндить на нестандартный локалхост без рута очевидно не получится.
Откуда у пользователя RTFM такая уверенность?
uname -r = 5.4.242. И 127.42.67.99 действительно работает как разные IP, а не редирект на .1
ps: inet 127.0.0.1/8 scope host lo
ок, написано излишне категорично.
но, если не затруднит, можно пример работающего кода ява/котлин для бинда кастомного адреса? мне сей-час немного недосуг это гуглить. мне в своё время андроид отказал в такой роскоши, что на мой взгляд предсказуемо. т.е. он тупо сказал что нет такого интерфейса. а чтобы его добавить нужен рут.
v2rayNG:
Экспортируем конфиг
Добавляем логин-пароль к socks inbound (надежный!)
Импортируем конфиг обратно
В настройках v2rayNG выключаем "Использовать Hev TUN"
POC перестает обнаруживать SOCKS на 10808 порту
VPN для отдельных приложений при этом работает
Я уверен что есть еще дыры, но кажется автору надо свой POC расширить. Но вообще, инструмент классный для проверки защищенности конфига.
А как добавить логин-пароль к socks inbound? И можно ли в случае чего убрать его?
Редактированием экспортированного конфига xray в текстовом редакторе. И убрать можно абсолютно также.
А можно чуточку подробнее мануал
https://xtls.github.io/ru/config/inbounds/socks.html#inboundconfigurationobject
меняем там способ авторизации и будет заходить с паролем или просто.
Современные реализации masscan, zmap позволяют просканировать весь ipv4 интернет меньше чем за час. А тут вообще локалхост, как ниже написали.
Не проще просто клиенту генерировать случайный логин/пароль при запуске и передавать его уже tun2proxy? Тогда кроме как через tun2proxy никто не подключится.
К socks, но не к tun
https://habr.com/ru/articles/1020080/comments/#comment_29790062
loopback можно поставить адреса из диапазонов 172.16 и 192.168
Роутинг для 127/8 работает иначе ("loopback is on Mars")- будут проблемы с безопасностью.
Только у говнокодеров. В нормальном сетевом стеке 127/8 ничем не отличается от 10/8. Вся разница лишь в том, куда прибита подсеть в таблице маршрутизации. Обе, например, могут быть link-local, и тогда уже разница выносится на L2. Для loopback драйвер прост, как три копейки, там даже физики, как таковой нет, но IP-стеку до этого дела нет. В общем, с точки зрения L3 (IP), на loopback можно вешать абсолютно любой адрес и любую подсеть.
Пример годного софта, который пользуется стандартом: ntpd (127.127.1.0 для локального stratum).
Все мобильные клиенты на основе 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 серверов и прочее)
никаких никому оправданий
очевидный же разрыв в логике
ЗАЧЕМ проверять доступность ЗАБЛОКИРОВАННЫХ Telegram и WhatsApp в регионе, где они должны быть НЕДОСТУПНЫ?
ты и я разработчики? нет
ты и я в курсе маркетинговых инструментов заложенных в приложение для оценки работы конкурентов и сервисов влияющих на доступность ? нет
в статье явная проблема с логикой. технические данные не подтверждают однозначность утверждения ТС
ты и я разработчики? нет
Ты Вы — не знаю (но Вы утверждаете, что нет), но я — разработчик.
ты и я в курсе маркетинговых инструментов заложенных в приложение для оценки работы конкурентов и сервисов влияющих на доступность ? нет
Я — в курсе. И среди таких инструментов НЕТУ проверок доступность сервисов-конкурентов, VPN и наличия разделения маршрутизации. Такое обычно делают либо для отладки сети, либо для выявления "аномалий" — в нашем случае аномалиями являются наличие средств обхода и возможность использовать запрещённые сервисы.
А ещё такие фишки про проверки доступности, адресов и пр. используются в разных зловредах.
то есть вы разработчик Макса,Happ ? можете поделиться из первых уст подробностями зачем реализованы опросы сторонних сервисов доступности?
если серьезно - речь шла именно о разработчиках проблемных приложений из статьи, поскольку только они в состоянии объективно ответить зачем используется тот или иной инструмент , не гипотезируя как автор, вы или я.
поскольку уверенного, однозначного знания основанного на фактах нет ни у кого из нас - все что мы тут пишем домыслы и предположения.
я привел примеры выше , когда команда разработки использовала те же инструменты и методы для достижения совсем других целей диагностики
Аналитические данные обычно отправляются на адреса аналитических сервисов, а не смешиваются с основным трафиком таким образом, что либо блочишь всё приложение, либо не мешаешь ему собирать сетевые данные.
Для простого маркетинга и анализа конкурентов реализация слишком сложная и обладает такими особенностями, которые нехарактерны для простой аналитике.
Т.е. реализация для шпионства в пользу РКН получается проще, чем ровно тоже самое, но для маркетинга.
Если выразить мою мысль с точки зрения компетентности разработчиков, то получается, что нужно быть очень ту некомпетентным в сфере разработки, чтобы "маркетинг" реализовать таким странным мудрёным образом. А при таком уровне Max просто не запускался бы.
Но Вы по-прежнему (пока) имеет право быть с кем-то не согласны.
Быть несогласным с правильными людьми уже почти вне закона.
ни у кого тут нет достоверной информации чтобы заявлять однозначно
Не всё так однозначно (с) Давайте про половцев ещё с печенегами…
ни у кого тут нет достоверной информации чтобы заявлять однозначно
Мне не нужно однозначное доказательство, тем более которое фактически невозможно получить, для того чтобы не доверять софту. Достаточно «может», а не «делает». Такая, своеобразная, презумпция вины.
Разработчик применил для анализа методы для которых не видно логичного обоснования? Разработчик не пытается объясниться, а валит все на «всё так делают», «это нормально» и уходит в отрицание, мол «это не правда»?
Это точно способ повышения доверия?
даже указанных выше методичек никто не видел
Если вы не видели, это не значит что их никто не видел. Эта методичка уже давно слита в интернет и с ней может ознакомиться каждый желающий
Вам повезло. У вас, вероятно, 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
Я у себя все ру-приложения переместил во второе пространство через shelter и я просто его выключаю в шторке до состояния "полупрозрачности", что, как мне подсказал ИИ, говорит о том, что они в это время все заморожены и не работают. В это время включаю vless (который еще и со сплит таннелингом для определенных приложений), зная, что все стукачи "в клетке". Как временный workaround меня устраивает, тем более, что на 4пда и в телеге я сижу куда больше Озона, Сбера и прочих магазинов. Немного неудобно, но отсутствие пушей от Озона и банков я как-нибудь переживу, заодно и батарейку с трафиком сэкономлю. Когда похожим образом будет поступать существенное число людей, пусть даже используя все токсичное от РУ на втором телефоне, будет лучше всем, как мне кажется, кроме самих платформ, которые потеряют очень большую долю релевантной телеметрии - ну а как они хотят, за шпионство надо тоже платить. Цифровой профиль и поведенческие паттерны для биг-даты собирать будет все сложнее от меня, когда у меня 90% времени их приложения просто в состоянии "выключено". Я даже рад, у меня мобильный Adguard стал за сутки собирать в статистике раза в 4 меньше данных после всего этого. Понимаю, что он не работает на второе пространство, но меня удивил тот объем, который все эти финтехи качали в фоне, не придавал как-то значения, а тут прямо в глаза бросилось. Даже рад немного своему скромному результату, словно отмылся хорошо с мылом.
Очередная победа 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
Подумал, что это больше осветит проблему и добавит оперативности в её решении.
В идеале, конечно было бы PR закинуть, но android не моё. Может кто-то возьмется.
Закинул исправление AmneziaVPN под все платформы! Ждем, что скажут разработчики. Глядишь хоть один нормальный клиент будет.
https://github.com/amnezia-vpn/amnezia-client/pull/2453
Еще бы побороть выдачу ip прокси из клиентского приложения не из разрешенных к тунелированию командой "curl -s https://ifconfig.me/ip --interface tun0"
Прикольно обвинять команду 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
А генерировать пароль динамически - никак?
Поправил коментарий. Да, будем генерить на каждое подключение
а можете уточнить, что подразумевается под "подключением"? подключение = подписка/сервер или подключение = каждый раз при connect будет новый? будет ли вариант таки сгенерить и зафиксировать свой пароль?
или как это предполагается будет работать?
А можно это сделать опционально?
Я на этот прокси в клиенте TG ссылаюсь, чтобы не переключать каждый раз прокси в телеге. Т.е. дома имя хоста proxy.local.home разрешается как адрес роутера, а на улице при включённом happ+ - как локалхост через конфиг роутинга.
И менять каждый раз там пароли совсем не хочется.
Хорошо, мы поставим пароль на socks
Поставьте
Через день-два разрабы Max глянут пароль и научат Max подключаться к socks по паролю
Поставьте динамический
В чем проблема?
Если я правильно понимаю, приложения не используют этот локальный прокси-сервер напрямую, вы можете генерировать случайный порт и случайный пароль при запуске. Дальше max пусть брутит сколько хочет.
По тону комментария реально подтверждается утверждение автора статьи о манере общения :)
Доброго дня!
Скажите, пожалуйста, как там нынче у Happ с уязвимостями? В первую очередь интересна iOS.
Я думаю, в любом случае блокировать приложения-стукачи надо на стороне КВН-серверов. Потому что невозможно заставить миллионы нешарящих пользователей обновить клиенты (а некоторых - ещё и отказаться от любимой Windows-7, под которой запускаются только достаточно древние версии).
Кстати да, единственный рабочий вариант на данный момент. Запретить выход во первых на geoip:ru сервера, во-вторых, на сервера приложений-стукачей (типа того же Скама).
А вот такой роутинг - хороший выход?
https://github.com/frayZV/simple-ru-routing
Для клиента - хороший роутинг. Для сервера не подойдёт. Там должно быть что-то вроде geoip:ru -> blackhole.
Не выход, но хорошая практика для рентгена, отдавать роутинг на сторону клиента. Советуют каскад/мост из двух серверов, где точка входа ру-сервер, а выход eu-сервер, образно, чтобы не парится с отдачей роутинга для всевозможных клиентов рентгена, где трафик для ру оставляем на ру-сервере, заблокированное на eu. Но это все равно не поможет, стукач приложение проверяет доступны ли сервера telegram, whatsup..., а они доступны, через выходной сервер, и никакой роутинг не поможет, ни серверный, ни клиентский, что печально, ждем фикса клиентов)
Решение есть, использовать mihomo и singbox клиенты, с правильно отдаваемой конфигурации, только tun.
Как этим пользоваться?
А что помешает этим приложениям так же как и вам, лезть на арендованные из хозяевами VDS сервера в Европе и стучать через них таким же образом как вы обходите блокировки? Вот мы и поменялись ролями)) Сперва Роскомнадзор пытался блочить нам сервера, а мы говорили - мы все равно прорвемся, все сервера не заблокируете! А теперь наоборот, мы пытаемся заблочить его, а он будет кричать мы все равно прорвемся, все сервера не заблокируете!
Им даже не нужны арендованные VDS сервера. Достаточно иностранных сервисов определения IP. Типа ip-api.com.
Запретить на сервере доступ к подобным определялкам и серверам стукачей. Нечего им через ВПН в принципе работать.
По типу: {
"type": "field",
"outboundTag": "blocked",
"domain": [
"checkip.amazonaws.com",
"ipv6-internet.yandex.net",
"analytics.max-admin.ru",
"api.ipify.org",
"api.ok.ru",
"api.oneme.ru",
"calls.okcdn.ru",
"channels-showcase.max.ru",
"ext-bots.max.ru",
"frontend.sferum-dev.ru",
"gosuslugi.ru",
"hb.vkcloud-storage.ru",
"i.oneme.ru",
"ifconfig.me",
"ip.mail.ru",
"ipv4-internet.yandex.net",
"maxvd125.okcdn.ru",
"maxvd217.okcdn.ru",
"maxvd381.okcdn.ru",
"maxvd437.okcdn.ru",
"maxvd527.okcdn.ru",
"maxvd574.okcdn.ru",
"maxvd575.okcdn.ru",
"maxvd582.okcdn.ru",
"maxvd627.okcdn.ru",
"maxvd637.okcdn.ru",
"maxvd749.okcdn.ru",
"maxvd751.okcdn.ru",
"platform-api.sferum-dev.ru",
"portal-sentry-v2.vk.team",
"sdk-api.apptracer.ru",
"st.max.ru",
"tracker-api.vk-analytics.ru",
"videowebrtc.okcdn.ru"
]
Список энтузиастами вести обновляемый.
Это невозможно. Как вы отличите запрос от условного озона к условному 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…
Я постараюсь найти время и сделать
Вы путаете настройки маршрутизации и настройки самого клиента. Я говорю про пресет настроек для раздела 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. Так же, как и все остальные.
у меня v2RayTun. Я поискал внутри неё упоминание о socks5 и ничего не нашёл. в статье сказано, что разработчики v2RayTun не реагируют на алармы автора. Что они должны сделать? какой socks5 поправить? и при чём здесь вообще socks5?
Что они должны сделать?
Уже ведь написали: добавить аутентификацию на socks5.
какой socks5 поправить?
Который прописан в разделе inbounds конфига ядра (xray/sing-box) клиента. Через настройки клиента этот конфиг напрямую обычно нельзя поправить.
и при чём здесь вообще socks5?
При том, что открытый socks5 может использовать государственное spyware для обнаружения адреса VPN-сервера.
При том, что открытый socks5 может использовать государственное spyware для обнаружения адреса VPN-сервера.
в этом приложении нет открытого socks5
Который прописан в разделе inbounds конфига ядра (xray/sing-box) клиента.
в этом приложении он не прописан и не доступен к прописыванию пользователем
Уже ведь написали: добавить аутентификацию на socks5.
для этого в этом приложении нужно сперва добавить inbound 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 не запускается. Интересно, значит ли это, что и список интерфейсов нельзя будет получить?
Можно проверить через программу Ethwork
Отличная находка, уже начал допрашивать искусственного идиота по поводу собственной реализации, вот что он накидал, кому интересно:
Скрытый текст
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.
можете раскрыть для непосвященного в тонкости настройки, проблема не решается комментом выше?
sign-box позволяет заблокировать маршрутизацию от программ, которые применили SO_BINDTODEVICE на интерфейс прокси. Если программа исключена из использования прокси, она не сможет выполнить запрос через прокси, а сможет только через Wi-Fi/мобильную сеть. А если не исключена, то сможет и через прокси, и через Wi-Fi/мобильную сеть.
Определить само наличие прокси программа сможет в любом случае.
Странно. У меня правило по имени пакета в 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
Т.е. сводится к тому, что в рулах надо продублировать конфиг для аппов.
(а ну да, конфиг в спойлере же выше нашел)
И т.е. получается, что проблема решена?
тупой вопрос, но, для “rules”: [ { “package_name”: нужен рут?
Отправил автору sing-box issue с предложением по PR, переписываюсь с ним в tg-чате. Хочу, чтобы появилась возможность ловить правилом такие соединения, когда не удается распознать package name: https://github.com/SagerNet/sing-box/issues/4009
Проблема изначально, что из-за выбора интерфейса не работает поиск процесса getConnectionOwnerUid. Это API появилось, когда Google стал ограничивать доступ к /proc/net. И когда добавляли, то непривилегированные приложения еще не могли использовать SO_BINDTODEVICE. Так что скорее всего это пробел в дизайне API — его спроектировали под реалии, когда обычные приложения не могли привязывать сокеты к интерфейсам.
Не подскажете, плиз, я что-то делаю не так?
curl ifconfig.co --interface tun0 в termux в bypass листе у меня бесконечно висит, а IP прокси не выводит. Android 11, kernel 4.14, без рута.
Но когда убираю termux из bypass листа, то и tun0, и wlan0 выдают, ожидаемо, IP прокси.
Я правильно понимаю, в ядре 5.4 (у меня такое) эта дыра отсутствует? Если termux направить в bypass через per app, то curl адрес прокси не палит, выдает ошибку соединения по таймауту. Или на моем ядре он палится другим методом?
Это 3.143Dец! 🤦♂️
А из Shelter'а увидеть интерфейсы основного профиля можно?
По поводу 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, то ваш трафик для вашего провайдера внутрироссийский.
" цензуре достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах. " - ну тогда делаем сайт -заглушку и SNI совпадает с нашим хостингом.
Мелкие сервисы уникальным авторским SNI сидящие в пуле IP лаукостера из Нидерландов и просто так в бан отправляют, если специфический маршрут понятен цензору - можете жаловаться в Спортлото.
Фокус с критичным для бана SNI именно потому и работал, до поры до времени, что смотрели раньше только на SNI/сертификат. Сейчас проапргрейдились и смотрят уже и на маршрут.
SNI реасеблиться считывается мгновенно, еще несколько часов уходит на прогон по соответствию валидным пулам IP донора SNI(которые по определению достаточно взять из публичных DNS), после чего стелс VPN/прокси уходит в вечный бан.
Гораздо больший потенциал как показывают и теория и практика имеют “неоднокликовые” решения вроде Zapret
Который совершенно бессилен перед простой блокировкой ip адресов.
Отчасти верно, но такое цензор может позволить только для бана одинокого самохостинга с единственным фиксированным адресом. В остальных же случаях нет.
Бан по IP сколь либо серьезного ресурса хостящегося у инфраструктурного гиганта, пока недоступная опция - нужно будет положить кучу сервисов, что сидят в этих же пулах адресов(а они, эти адреса еще и динамические).
С точки зрения практического примера вспоминаем операцию "Телеграм 2018" когда бан был именно по пулам IP инфраструктурных гигантов, тогда РКН неожиданно для себя уяснил неприемлимый размер сопуствующего вреда при такой стратегии.
С точки зрения практического примера вспоминаем операцию “Телеграм 2018” когда бан был именно по пулам IP инфраструктурных гигантов, тогда РКН неожиданно для себя уяснил неприемлимый размер сопуствующего вреда при такой стратегии.
Прямо сейчас, в текущую минуту мы имеем заблокированными гораздо больший объем ресурсов и адресов на постоянку, чем то, что было заблокировано случайно тогда. Подумайте об этом, когда рассуждаете о приемлемом размере сопутствующего вреда.
Прямо сейчас, в текущую минуту мы имеем заблокированными гораздо больший объем ресурсов и адресов.
В Вашу логику закралась весомая неточность - дело не в количестве, а в критичности отсутствия сервиса, например регулярно проходят учения с баном нескрепного Клаудфлайра, но надолго положить при этом даже десяток дистанционных банковских сервисов(что каждый раз и происходит, кратковременно, в тестовом режиме) - это пока неприемлемый ущерб. Тоже про нескрепные дата-центры Гугла с неправильным Ютубом внутри, список можно продолжить...
в дефолте проксирует Майкросовтовский сайт(в попытке найти едва уловимые различия) - цензуре достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах.
Не существует никакого «дефолта» для Reality с микрософтовским сайтом.
Ну и совет «берите белосписочный фейковый домен под который маскируетесь обязательно из той же AS’ки где у вас VPS» из каждого угла трубят уже много лет как.
Вы несколько неккоректно вырвали из контекста. В исходном виде было
Цензуре нет необходимости проверять насколько реалистично Ваш, к примеру, "VLESS + Realiti" в дефолте проксирует Майкросовтовский сайт(в попытке найти едва уловимые различия) - цензуре достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах.
В целом же белосписочный фейковый домен лишь затягивает на несколько часов процесс отправки в бан. Без неприкасаемых(пока) SNI-доноров маршрут к лаукостеру в Нидерландах пойдет в бан еще быстрее(цензору плевать на вероятный ущерб от падения реального микропортала в столь подозрительном месте).
Главный "слоновий" признак VPN/прокси применяемых как средство обхода блокировок - крайне специфичный маршрут трафика(притом с явными статистическими аномалиями в использовании этого маршрута пользователем) виден цензору распрекрасно. Вопрос тут был лишь за какое время ТСПУ проапдейдят для определения этого главного патерна применения VPN/прокси непосредственно.
К этому добавлю, что для трансграничного пользовательского трафика(плевать куда именно) постепенно(пока для сотовых сетей) вводиться заградительный тариф.
а если так - купить мини-компьютер домой, прикрутить к нему белый статический IP адрес, ставить ubuntu, на ней настроить себе openvpn сервер и кучу правил, к нему подключаться клиентом с своего смартфона, и уже со своего сервера коннект к нескольким зарубежным VLESS серверам и переключать их
Так будет видно трафик с твоего сервера на зарубежный, а твой сервер это такой же обычный пользователь
так РКН стукач, сидящий теперь в каждом российском приложении не увидит локальный VLESS-клиент, потому что его на сматрфоне нет, а домашний провайдер увидит только что есть исходящее соединение на зарубежный IP
IP с которого исходит трафик на зарубежный всеравно будет виден
Может, лучше вообще не ставить на основной смартфон этих стукачей? Сегодня они сливают данные о впн-ах. Кто знает, что РКН прикажет делать им завтра. Лучше вообще выселить всех этих стукачей на отдельный смартфон.
Простите, а как вы будете подключаться к своему серверу с телефона?
По сути так мосты и работают. Проблема найти такой белый айпи, еще большая проблема потом поменять его в случае блокировки
обычно такой мини-компьютер называют роутером
Российское приложение-шпион "сливает" IP вашего зарубежного VLESS сервера, этот IP попадает в список блокировки, который раскатывают на ТСПУ. В результате, ваш домашний сервер больше не сможет подключиться к вашему зарубежному 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
Amnezia 4.8.14.5 - палево. Банковской приложение видит клиент Amnezia последней версии 4.8.14.5 на Андроиде и жалуется, хотя через ВПН идут только отдельные приложения, а не браузеры и не банковские приложения. Палево детектируется этой программой https://github.com/cherepavel/VPN-Detector (ссылка по UDP 3. в конце этой статьи).
а как в v2rayNG V2rayN отреагировали на запрос? у них самая удобная кастомизация и настройка маршрутизации включая порты
Месяц назад отказались фиксить. Сейчас вроде как собираются.
они отказались фиксить неработающий из меню мультиплекс, так что не удивлен ни разу.
Но в статье вы решили раскатывать именно Happ, интересно =)
А можно объяснить как именно в PoC должно все отображаться если все пофиксят?. Выше пишут что Happ фиксанулись, но с новыми обновами и в Happ и в v2rayng в PoC показывает и 127.0.0.1:1808 и директ ip и выходной (естественно удаленный vps) xray api не показывает при этом. Оба в сплит тунеле без галочки на PoC приложухе и оба с директом на ру зону.
Когда они пофиксят что должно быть в выводе PoC? Невозможность найти локальный порт и показать внешный Ip?
А как на Андроиде с автоматизацией? По идее если сделать жёсткий пул доверенных приложений, а все остальные принудительно гасить когда включается тот же vray?
Сделал MR для v2rayNG с обязательной авторизацией, можете подождать пока его вольют либо я могу выложить скомпилированные apk файлы
Ну а в целом, переход на айось с андроида в текущих реалиях оправдан?
Почему-то все стараются изолировать маха в песочнице, откуда он успешно выползает.
А что если поступить наоборот - сделать в телефоне отдельное пространство с квн и инстаргаммом? То есть в открытую на телефоне нет никаких подозрительных приложений. Но если запустить на нём некую программу (виртуальную машину?), то в ней уже запустится квн и нужные приложения. При этом квн будет виден только избранным программам.
Я так и сделал, все заблокированое живёт в папке knox. Но это не решает проблему, socks5 сервер торчит из knox папки в незащищённое пространство, то есть проблема из статьи актуальная.
без разницы в текущих архитектурных реалиях, макс песочнице или квн в песочнице, ваш квн все равно будет виден
буден виден незапароленный socks5, если его запоролить, то проблемы не будет, сканер хоть и найдет сервер, но авторизоваться на нем не сможет
Это уже разговор про теплое с моей стороны и мягкое с вашей.
Приложение может увидеть ваш транспорт ( NetworkCapabilities.TRANSPORT_VPN) и проверить имена сетевых интерфейсов (tun, tap, ppp, wg)
Ну виден им факт и что это дает? Заблокировать они его все равно не смогут.
Сразу и напрямую - нет. Отдать пару пакетов на пробу на сервер в условной Германии, чтобы обойти сплит туннелинг, посмотреть на ваш айпи, чекнуть его в нетласе или сразу забанить без нетласа.
Как я понимаю, на андроиде без рута нет возможности трафик определенного приложения пускать разными маршрутами
Неужели, если перед использованием КВН отключать рабочую область песочницы, где находятся все ру сервисы, не поможет в решении проблемы? Действительно ли тот же Макс, который в теории должен находиться в отключенном состоянии, будет видеть ВПН соединение?
Есть несколько причин, но основная в том, что из системы основной палится квн, который запущен в рабочем пространстве. Также и наоборот работает, что из рабочего пространства палится включенный в основном.
(Так работает на samaung, стоковая прошивка, но думаю везде так)
Но даже если бы было не так, то перенести youtube, наверное, будет проблематично, как и множество других системных штук, которые у нас уже не работают без квн толком.
Есть момент, что если квн включен на всю систему основную, то приложения из рабочего пространства могут палить только сам факт включенного квн, но не могут ходить через него (по крайней мере без использования лазеек). По сути раздельное тунелирование, но не на уровне приложения, а на уровне системы.
А сам факт того, что vpn включен - это задумка такая в системах специально предусмотрена, чтобы приложения, которым это нужно(банки итд) понимали, что кто-то может быть посредине, и не давали доступ, или что-то могли написать, типо соединение может быть небезопасным.
Не понимаю, почему приложениям в основном пространстве виден квн в рабочем пространстве? Кривая реализация?
Да, виртуализировать графику - не простая задача, но в какой-то мере решаемая.
Факт включения квн виден приложениям не всегда. По личному опыту: pixel 9 pro, стоковая прошивка андроид 16. Стоит adguard (без дополнительных букв, рекламорезка) в режиме квн. При дефолтных настройках банковские приложения ругаются. Но в настройках адгуарда можно для избранных приложений снять галочку "направлять траффик через Adguard" и тогда эти приложения начинают работать как на чистой системе. Но ключик в строке состояния продолжает гореть.
Ну а если, скажем нельзя сделать авторизацию, которую бы цепляли избранные для сплит туннеля приложения, то может лимит авторизаций на внутреннем 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, а инфантильное отрицание реальности. Реальность: слежка стала промышленной, дешёвой и обязательной. Чем больше людей «не парятся», тем проще государству контролировать всех. Технически грамотные люди (включая автора статьи на Хабре) уже показывают, как именно это работает. Игнорировать это — значит добровольно сдавать свою приватность.
Понятно, но такую дичь точно держи при себе, ещё и нейросетевую
VPN должен быть только «государственный» (RuStore уже готовит свой, который не разблокирует YouTube/Telegram).
источник?
что тогда он делает? разблокирует ChatGPT и ClaudeAI? А надолго?
Ну явно нейросесть писала! А если по существу: всё это верно только в том случае, если эта ваша privacy изначально является ценностью, что верно далеко не для всех. Если же смотреть с позиции «ну читает условный товарищ майор мою переписку с друзьями о том, куда пойти на выходные или спор, какой софт под Linux лучше, или с женой, что купить в магазине и сготовить завтра на ужин, ну да и ладно, мне это жить не мешает», то идея принимать кучу мер по противодействию этому кажется довольно странной. Особенно если это ещё затрат требует на лишний VDS и несколько IP-адресов для него.
Я тоже так подумывал, но пока лень
Выходные 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 и прочие.
На счёт жаргона не волнуйтесь. Профессионалы решат проблему. Обычным пользователям не надо будет в этом всём разбираться. Достаточно будет просто использовать обычные готовые клиентские приложения.
Текст по сути адресован разработчикам клиентов, а общественность должна выразить обеспокоенность, а лучшие из нас - сделать pull request. И это достойно сработало, happ поправили в тот же день, nekobox правится настройками.
как в обозримое время разобраться со всеми этими "заворачиваниями UDP", "входными-выходными IP", VLESS туда
Скорее всего, просто платить за готовые решения.
В обсуждении 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 явно.
Замечательно, так проблема на вид решена. Моё самое большое уважение, спасибо!
Опечаточки у меня немного:
Создать пул
Создать рул (правило)
все пары
все аппы (приложения)
Думаю, суть понятна, а там может кто нормальный гайд напишет.
Более того, в такой конфигурации фактически не нужно первое правило. С (2) и (3) через curl --socks5 возвращает empty reply.
Спасибо!
Единственное, что я заметил, что при такой настройке сам некобокс не может свои подписки обновлять
Тут я не подскажу, т.к. не пользуюсь системой подписок.
Могу предположить, что NekoBox нужно аналогично завайтлистить (в руле?).
(правда сходу не уверен, не будет ли какой-нибудь рекурсии...в голове сложно прокрутить)
В разных ветка на 4pda нашел мысли, как это починить.
Суть в том, что в изначальном рецепте нужно изменить 2 вещи:
правило 3 (block которое) нужно заменить на direct
{ "ip_cidr": ["0.0.0.0/0", "::/0"], "outbound": "direct" }список приложений в Настройках (НЕ! роутинге) выключить совсем, т.е. НЕ использовать
Итого:
per-app в настройках выключен
[правило про socks - по желанию, у себя оставил]
per-app в роутинге(!) включен, он идет в outbound = proxy
все, что не сдетектилось (по app-name) в шагах выше - идет в outbound = direct
т.е. вместо блокировки нецелевого трафика, мы его кидаем в direct (подписки по идее заработают)
К вопросу о подписках, тут пришли некоторые мыли, я их изложил на гитхабе.
https://github.com/MatsuriDayo/NekoBoxForAndroid/issues/1153#issuecomment-4217113284
Интересно, как такое сделать в husi, если это вообще возможно. Чтобы было понятно новичку ))
Можно в настройках прописать в пользовательский конфиг inbounds, тогда socks вообще не создаётся. Достаточно минимального:
{
"inbounds": [
{
"stack": "gvisor",
"tag": "tun-in",
"type": "tun"
}
]
}
Если скучно, то можно продолжить.
В комментариях видел вопросы о ханипоте для таких вот шпионах, которые могли бы ломиться в сокс5 или tun0 без спроса.
Можно попробовать сделать максимально топорно.
Сразу скажу, что в моем случае, если приложение (например termux) ломилось принудительно в tun0, то в логах некобокса оно фигурировало как app_name=android.
Так вот.
Создадим новый профиль, ведущий в http прокси (в нашем случае, его не будет, но ничто не мешает например на vps поднять http сервер на каком-то порте, логировать запрос и обрывать соединение прост).
Добавить профиль - Ручные настройки - HTTP. Назвать "honeypot", сервер 127.0.0.1, порт 1234
Добавить новое правило (после RULE2, которое про список аппов, но ДО блока)
{ “package_name”: [ “android” ] } и внизу, где outbound (в UI) выбрать наш профиль "honeypot" из п.1Теперь, если выполнить в термуксе (или др. приложении) сетевой запрос (допустим
curl2ip.io--interface tun0) то он упадет с ошибкой и появится в логах некобокса.
Примерно так (запросы в 2ip.io и ya.ru)ERROR[0161] [635963556 9ms] connection: open connection to 188.40.167.81:80 using outbound/http[g-34]: dial tcp 127.0.0.1:1234: connect: connection refusedERROR[0173] [3829107112 10ms] connection: open connection to 5.255.255.242:443 using outbound/http[g-34]: dial tcp 127.0.0.1:1234: connect: connection refused
Нагуглить по ip инфу не трудно, хоть что-то.
А вот если в качестве ханипота реально иметь простой http сервак и логировать, наверное можно интересного наловить.
Полное сканирование yourvpndead показало, что NekoBox открывает ещё один дополнительный случайный порт с socks5, помимо заданного в конфигурации, и на него правило не действует, светится outbound ip.
Подозрение пало на плагин Naiive, с ним такое поведение.
Т.е. у вас при полном сканировании показывает 2 (два) сокс5 порта?
А если некобокс принудительно остановить, сканирование уже не находит ни одного сокс порта?
А если вернуть некобокс (можно даже скан сделать до активации впн и после), то снова показывает 2 сокс порта?
У меня при запущенном некобоксе и активном впн - показывает только тот порт сокс5, который прописан в настройках (но его вроде заблочили же роутингом). Но порт 1 (как минимум именно сокс).
upd: насчет рула для блока сокс5 - проверил, да, работает (причем выше мы обсуждали, что если в конце идет блок всего, то вроде как сокс-рул не нужен, но у меня ппочему-то при выключении этого правила пустило curl, черех сокс. Т.о. я оставил и рул для блока сокса5)
А в amnesia vpn так можно сделать?
Тоже думал в этом направлении, но для ситуаций, когда socks нужен для использования в паре с каким-то приложением, которое занимает vpn слот (в моем сценарии это rethinkDNS + socks NekoBox) можно же кастомной конфигурацией настроить аутентификацию для создаваемого socks, не так ли?
Про дублирование пула per-app ниже прочёл. Однако, кажется, нашел компромиссное решение. В очередном форке sager-net "Exclave" есть настройка "Разрешить/не разрешить приложениям обходить VPN системными методами", "статистика трафика приложений", а ниже ещё одна, отвечающая за альтернативный способ получения списка установленных приложений. Я не успел проверить, но кажется они намекают на то, что при выбранных приложениях в per-app split tunneling, во время запуска туннеля этот список заносится в конфиг таким же образом.
Жалко только, что он кастомные конфигурации не поддерживает, как nekobox...
Хабр кстати буквально час назад отвалился вне России без прокси. Что-то опять шаманят, через Российский прокси работает
Может быть ребята из 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 и другие клиенты для роутеров?
Выкатили обновление
@Rollex ок, +rep за оперативность. Ещё бы от подментованного домена избавиться, то вообще было бы хорошо.
У меня стоит клиент 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 нафиг не нужен.
Для xray у вас будут с этим проблемы
А зачем он нужен, если есть sing-box. Да и в принципе более интересные, простые и эффективные протоколы.
если есть sing-box
Это там, где авторитарный разработчик крайне негативно относится к любым инновациям от RPRX, например, VLESS, XTLS-Reality и xHTTP, крайне неохотно внедряя эти технологии? xHTTP до сих пор в подвешенном статусе.
С другой стороны, разраб(ка) парвильно делает, что ратует за хоть какие-либо альтернативы вроде NaiveProxy и т. д. Это хорошо, не одним Reality единым...
Давайте без умных слов. Итак читать страшно.
Если развернём виртуалочку, и на запрещённые ресурсы будем ходить через неё, предположим, что там внутри клиент Амнезии.
Установим чистый FF/Гугл браузер и что, тоже задетектится?
Виртуалочку какой ОС? И почему на десктопной ОС у приложения не будет варианта выбрать соединение VPN/не-VPN (подсказываю: будет).
А если без приложений, то использовать всегда только браузер - уже хороший вариант. Но от WebRTC немного не помогает (тоже решето). Придется навешивать расширения и править конфигурацию.
Если у вас нет возможности получить второй 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 XHTTP похоже РКН научился его блокировать.
10 марта 2026 года я разослал разработчикам всех популярных VLESS клиентов информацию
Как ознакомиться с этой информацией? Я только сейчас об этом узнаю
У меня даже записи остались как и с кем связывался (писал чтобы не запутаться). Вот как есть:
v2raytun - написал в тг
@v2raytundev
v2box -
@v2box_support- написал emailadmin@hexasoftware.devи в тг@V2Box_App
Happ - написал email
admin@happ.su, дал доступ к репе
Hiddify - создал issue и написал на email
contribute@hiddify.com
v2rayNG - кинул инвайт на gh, написал на
captainIronng@protonmail.com, создал issue
Clash meta for android - создал public discussion с вопросом “как связаться”
sing-box - связался в тг
NekoBox - написал на
nekoha_matsuri@protonmail.comи создал issue
npv tunnel - написал в тг
@NapsternetVSupportи на почтуsupport@vonmatrix.com
Exclave - создал issue, зашифрованное gpg ключем, связался по email
Если вашего клиента в списке нет, то извините. Я его скорее всего не нагуглил или случайно пропустил по каким-то причинам.
На Nekobox выше решена проблема настройками - https://habr.com/ru/articles/1020080/comments/#comment_29792770
Ни к socks, ни к tun0 сторонние приложения обратиться не могут.
есть еще какой-то новенький - INCY. Утром смотрел их TG канал, разраб в курсе этой статьи и вроде бы уже даже что-то предпринял. Можете глянуть на этот клиент, насколько он вообще адекватный, если время будет?
Поясните, пожалуйста, каким образом раздельная маршрутизация типа geoip:ru -> direct, other -> proxy решает проблему? Что мешает приложению-стукачу слать через через прокси запросы в том числе и на эфэсбэшный хонейпот, поднятый где-то за рубежом?
В свете нынешний событий мне кажется разделение трафика по geoip назначения скорее слабым местом, так как это потенциально может послужить маркером “плавающий IP клиента”. Уж лучше выбирать между direct и proxy на основе приложений (src app).
Если у вас не одинаковый входной и выходной ip, с такой маршрутизацией они могут блокировать ваш выходной ip сколько угодно, это ничего им не даст.
А разве в таком случае приложениям не будет виден входной ip?
Клиент же подключается в первому серверу, а этот сервер уже ко второму
Клиент-прокси, а не приложение-стукач. Приложение-стукач взаимодействует с клиентом-прокси не зная куда он подключился
Почему "не зная" если суть статьи в том, что как раз зная
Нужно внести немного конкретики. Мы же говорим про так-называемый каскадный метод подключения?
Устройство пользователя - > входной IP (например в РФ) - > выходной IP (мировой интернет)
Разве приложение-стукач не может сдать входной, IP в такой схеме?
А разве сложно найти входной IP? По URL/конфигу это ведь на раз-два. В случае CDN CF чуть сложнее, однако в бан идет едва ли не весь CF.
Как думаете, обязательно для разделения использовать два разных сервера (например в разных странах)
Или достаточно докупить у хостера дополнительный IP адрес и использовать его как выходной, на одной и той же VPS. Имеет ли это какие-то риски?
Это было бы полезно, если бы прокси-сервер был включен по умолчанию чего нет для happ. По крайней мере для iOS
народ, разъясните пожалуйста простым языком в чем суть?
Суть в том, что любое приложение в принципе может воспользоваться включённым на телефоне VPN, даже если в настройках VPN указано, что данное приложение не должно работать через VPN. Через это подключение приложение может узнать выходной (зарубежный) ip-адрес VPN. Этот адрес обычно совпадает с входным адресом VPN. Далее информация передаётся в РКН, и он блокирует данный адрес ⇒ VPN больше не доступен из РФ.
ты капитальный красавчик топикастер
Подскажите совсем новичку во всех этих вопросах. Использование амнезии и режима туннелирования только для избранных приложений (телега, ютуп и тд), спасает от шпионажа или нет?
Что насчёт клиента Wireguard? В нем тоже есть уязвимость?
А если у меня до сих пор на арендованной VPS работает и OpenVPN и WireGuard и VLESS и всё это на одном сервере - то это мне просто повезло?
Клиент Happ по праву удостоился отдельного раздела в этой статье. По никому не известной причине они активируют xray api без авторизации с включенным
HandlerService, который позволяет буквально дампить пользовательские конфиги, включая ключи, входной ip адрес сервера и sni.
На уровне слухов злые языки говорят, что это бекдор и он был добавлен не случайно, а за некий крупный финансовый интерес. Я не знаю правда это или нет, но в любом случае исправить это уже невозможно. Их клиенты удалены из русского AppStore, так что они не смогут выпустить обновление.
Конкретно насчет этого момента - это исправляется очень легко со стороны сервисов простой передачей конфига, где HandlerService будет исключен (о чем уже было упомянуто здесь в комментариях). Ошибается каждый, но автор тут прямо и уверенно говорит, что исправить это уже невозможно, что является откровенной ложью. К тому же клиенты не удалены из русского AppStore, это тоже неправда. Насколько можно доверять остальным утверждениям автора и действительно ли он прямым текстом об этих уязвимостях сообщил представителям Happ, оставлю этот вопрос на суждение читателей.
это исправляется очень легко со стороны сервисов простой передачей конфига, где HandlerService будет исключен
Клиент передает его как дефолт.
К тому же клиенты не удалены из русского AppStore, это тоже неправда.
Да ну?. Одну из версий Happ тоже удалили (интересно, как вышло что вторую оставили?). И вот эту удаленную версию они обновить не смогут, все ее пользователи уязвимы.
Насколько можно доверять остальным утверждениям автора
Доверять мне как раз не нужно, я не прошу ни у кого слепого доверия. Я предоставляю доказательства, включая POC, с помощью которого вы можете сами убедиться что уязвимость реальна.
действительно ли он прямым текстом об этих уязвимостях сообщил представителям Happ
Вы ниже можете увидеть ссылки, где я сообщал об этом. Для OSS проектов остались доказательства в виде issue, к примеру. К слову, то, что я сообщал им об этой уязвимости Happ’ом никогда не оспаривалось.
автор же буквально в этой теме выше общается с представителем Happ и тот сливается, так ничего по сути и не ответив (https://habr.com/ru/articles/1020080/#comment_29789582), выводы после этого действительно каждый может сам для себя сделать
Доброго вечера, @runetfreedom, а клиент на iOS - Streisand тоже проблематичный? Еще какой-то новый клиент сейчас активно пилят - INCY. Про него ничего критично важного не слышали?
Хм. А говорили выше, про root права?
А как вам такой вариант: сделать два разных профиля андроид. На одном профиле КВН, на другом - рос приложения и переключаться между ними. Такое же предложение ля ПК (вин, Линукс)
Если вы прочитаете статью, то вы обнаружите что это не помогает.
Я всю статью прочитал вчера и все комментарии. Не всё понял, потому что новичок :(. Спасибо за статью! Я понял, что не работает для случая вторых пространств, рабочего профиля, island, shelter и т.д. то есть когда оба профиля работают одновременно. Я же говорю про случай, когда мы выходим из одного пользователя андроид и входим в другого. Я думал, что все приложения из памяти в таком случае выгружаются, соединения обрываются, порты закрываются и т.д. Короче, почти как перегрузиться в другую ОС. С точки зрения удобства это неудобно. Но я спрашивал с точки зрения безопасности, как альтернатива второму телефону. Если вы именно этот случай осветили в статье, то, прошу прощения, не заметил.
Могу сказать про ксиоми. У него раньше можно было войти в дополнительный профиль не заходя (не вводя ключ-пароль) от основного. тогда софт из основного не мог запускаться, как я понимаю. Но чтобы окончательно выйти из дополнительного (как и из основного) профиля надо было перегружать смартфон.
Но после очередного обновления в дополнительный профиль не войти не войдя в основной. Т.е. софт из основного профиля продолжает работать в обоих.
Но пока еще можно войти только в основной профиль (после холодной загрузки). Т.е. проксю надо размещать в дополнительном, а это может быть неудобно. Еще неудобнее перегружать смартфон каждый раз при переключении.
Вторая железка - очевидное более надёжное решение.
В других андроидах сейчас тоже бывают дополнительные пользователи, но после перезагрузки открывается строго основной, без выбора. Странно сделано. Также не знаю, работает ли основной во время работы дополнительного. По моему здравому смыслу не должен, но не проверял.
Это как будто бы норм вариант, если бы они на самом деле работали отдельно и если именно в "опасные" приложения нужно было редко заходить.
В связи с последними новостями потребовалось настроить клиент (v2rayNG) так, чтобы при заходе на ру сайты запрос шёл на прямую, а не через прокси. Для этого в разделе маршрутизация я добавил значения в поле домен geosite:ru и в поле IP geoip:ru. Но после этого мой клиент вообще перестал запускать соединение, а после того, как я убрал значение geosite:ru, то соединение с сервером произошло, но соединение с ру сайтами также было через прокси. В разделе файлы ресурсов я скачал другие геофайлы (runetfreedom), но и это не помогло мне. Кто знает решение сложившейся ситуации?
Была такая же проблема на том же клиенте. Нужно вместо geosite:ru указать geosite:category-ru.
Да, теперь .ru сайты соединяются напрямую, но почему-то конфиги, которые маскируются под ру сайты перестали нормально работать, а условный TCP с маскировкой под гугл работает нормально
С маскировкой под ру-сайты мне дело иметь не приходилось. Может, местная аудитория сможет посоветовать что-то ещё.
У меня маскировка, например, под yandex.com. Немного поэкспериментировав, я понял, что на свой зарубежный сервер меня пускает только под маскировкой под условный гугл, а на свой ру сервер пускает с маскировкой под yandex.com. Но самое интересное, что такое только на одном устройстве (где выбраны настройки с geoip:ru и т.д.), на другом то же соединение работает нормально (но там нет geoip:ru и т.д.) -_-
Grok пишет "метки geosite:category-ru в стандартных наборах правил (проекта v2fly/domain-list-community) не существует."
Grok вам врёт: https://github.com/v2fly/domain-list-community/blob/master/data/category-ru
LLM ненадёжный источник информации, когда речь заходит о таких тонкостях и нюансах, вроде этого случая.
Можете объяснить почему носки5 хранят именно адрес выходного сервера, а не входного. Не совсем понял, у нас же он запускается на локалхост устройства, с которого мы хотим отправить запрос?
Никто ничего не хранит. Через него делается запрос на "свой (ркн) подставной сервер в европе" и уже тот сервер видит откуда уши торчат с каким ip запрос приходит, паля выходной адрес
Можно и без своего (РКН) сервера. Есть общедоступные сервисы, определяющие ip, например, https://api.ipify.org и https://checkip.amazonaws.com
Приложение Wildberries обнаружило Vpn. Приложение не обновлял, в Wg tunnel стоит раздельное проксирование. Также видит впн в Island, в втором пространстве .
А оно обнаруживает параметры этого VPN, или только факт его наличия? Второе пока никаких рисков ведь не несет, соответсвенно это совершенно разные ситуации под одним событием "обнаружение Vpn". Или я ошибаюсь?
Добавлено: Вопрос про ситуацию именно когда используется 2 пространства, потому что мы имеем 3 варианта, и когда пишут "нет, это не поможет" не является ответом, потому что задающий не описывает все детали, а вопрос задается постоянно. Да и понятно что Вы не можете дать ответ, это вопрос в целом.
Добавил генерацию паролей при каждом подключении к серверу и рандомайз порта, приложение вообще не видит впн, хотя всё работает (vay2rayng
Решение костыльное, учитывая тот факт, что некоторые приложения умеют в proxy и указать для них 127.0.0.1:статический_порт -- это хороший вариант, чтобы не ставить глобальный VPN.
Это недоработка POC (он не всегда находит порт), а не защита.
В связи с публикацией на Habr.com статьи, содержащей ряд неточных и преувеличенных утверждений, официально сообщаем:
✅ HandlerService полностью удалён
Обновление уже отправлено на модерацию в Google Play и App Store.
К сведению: Сервис использовался исключительно в устаревших share-link подписках. После перехода большинства пользователей на JSON-подписки он остался в кодовой базе.
Меры были приняты, виновные лица наказаны.
✅ Реализована генерация пароля для SOCKS5 inbound непосредственно из ядра
iOS По-прежнему имеет архитектурные ограничения операционной системы
✅ Android-версия уже доступна • GitHub: 3.16.2 (https://github.com/Happ-proxy/happ-android/releases/tag/3.16.2) • Google Play и App Store — билды находятся в очереди на проверку. Как только обновления пройдут модерацию, сообщение будет дополнено.
Для обычных пользователей: Ничего страшного не произошло. Ваши данные и трафик были и остаются в безопасности. Обновите приложение сразу после появления новой версии.
Для владельцев VPN-сервисов:
Команда Happ всегда ставила и ставит безопасность конечного пользователя на первое место, и сегодняшний день это в очередной раз повторил.
Мы и разработчики xray-core продолжаем делать всё возможное для максимальной защиты конечного пользователей.
Напоминаем, что безопасность ваших пользователей - это также и ваша зона ответственности: используйте безопасные протоколы, грамотный роутинг, защищённую инфраструктуру и принимайте все возможные меры.
Мы все делаем одну большую работу - помогаем людям оставаться свободными в интернете.
С уважением, Happ
Проверяем с помощью https://claude.ai/:
Вот что я реально нашёл в коде — и это важно.
Что показывает GitHub
Релиз 3.16.2 существует — выпущен 7 апреля (вчера). Это факт.
Но есть серьёзная проблема. Единственный коммит в этом релизе называется "update add yandex link" — и он меняет только файл README.md, добавляя ссылки на Яндекс.Диск для скачивания файлов.
Описание релиза на странице говорит "Remove HandlerService from services" — но сам коммит этого не делает. Коммит трогает только README.
Это значит одно из двух:
Либо удаление HandlerService было в предыдущем коммите (
0f68084), который является родителем этого — и его я не смог проверить напрямуюЛибо описание релиза и реальный код не совпадают
Отдельный тревожный сигнал
APK для Android теперь также раздаётся через Яндекс.Диск — это новая ссылка добавлена в README именно этим коммитом.
Это плохая практика для приложения, которое позиционирует себя как инструмент защиты от слежки:
Яндекс.Диск — российский сервис под контролем Минцифры
Скачанный оттуда APK невозможно верифицировать так же, как релиз на GitHub
Подпись APK с Яндекс.Диска может отличаться от оригинала
Итог
Утверждение Happ Подтверждено кодом? HandlerService удалён ❓ Не видно в проверенном коммите
socks5 с паролем ❓ Не видно в коде
Приложение безопасно ⚠️ APK теперь на Яндекс.Диске
Если хочешь реально убедиться — единственный способ это установить v2rayNG (он полностью открытый и проверенный сообществом) вместо Happ. Happ так и не заслужил доверия прозрачными действиями.
И тем же способом (https://claude.ai/) проверяем v2rayNG !!!
Давай посмотрим на ключевые части кода — как генерируется конфиг xray и есть ли там что-то подозрительное.Отлично, я вижу реальный исходный код главного файла конфигурации. Разбираю по пунктам.
Что я нашёл в коде V2rayConfigUtil.kt
✅ HandlerService — отсутствует полностью
Ни одного упоминания HandlerService, api, APIService нет. Xray API не включается. Это принципиальное отличие от Happ.
✅ socks5 привязан к localhost
В функции inbounds() явно написано: если пользователь не включил "proxy sharing", то curInbound.listen = "127.0.0.1". То есть по умолчанию порт слушает только на локалхосте, не на всех интерфейсах.
Это хорошо — внешние устройства в сети не достучатся. Но проблема loopback внутри телефона остаётся — другие приложения на том же устройстве всё равно могут подключиться к 127.0.0.1:10808.
⚠️ socks5 без пароля — уязвимость из статьи подтверждается
Порт socks5 выставляется как v2rayConfig.inbounds[0].port = 10808 — без какой-либо авторизации. Это та самая уязвимость из статьи на Habr. Яндекс/MAX/Ozon могут подключиться к этому порту и узнать твой выходной IP.
✅ Никакой телеметрии, никаких внешних запросов
Весь код читает конфиг из локального хранилища MMKV и генерирует JSON для xray-core. Нет ни одного HTTP-запроса, нет отправки данных куда-либо.
✅ Маршрутизация прозрачная
Функция routing() строит правила маршрутизации на основе настроек пользователя — режимы 1, 2, 3 соответствуют "только private", "bypass CN", "private + bypass CN". Всё это локальная логика, ничего скрытого.
Итог проверки кода
Проверка Результат HandlerService / xray API ✅ Отсутствует socks5 на localhost ✅ Да, по умолчанию socks5 без пароля ⚠️ Да — общая уязвимость Телеметрия / отправка данных ✅ Не найдена Скрытые запросы ✅ Не найдены Яндекс.Диск или сторонние CDN ✅ Отсутствуют
v2rayNG чистый. Единственная проблема — та самая архитектурная уязвимость socks5 без пароля, которая есть у всех xray-клиентов. Но это открытая известная проблема, а не бэкдор.
Зачем проверять коммит на GitHub закрытого проекта? Там 2 файла - ридми и релиз, что он там мог увидеть, кроме изменения в этих файлах?
А кто-то с Husi пробовал настроить так, чтобы curl не определял ip? Прогонял через vpn-detector - вообще не находит vpn, показывает только direct ip. Хотелось бы понять, что нужно сделать новичку в данном вопросе, чтобы обойти и curl...
Опираться на SO_BINDTODEVICE всегда выглядело как сомнительная идея, это системная фича которая явно не задумывалась для защиты от шпионажа на уровне ОС
Было бы хорошо у клиентов не только сделать фикс, но и добавить ханипотов в виде таких вот открытых портов, чтобы изучать, кто туда ломится, куда, когда, зачем и как. Чтобы кидать алерты пользователю (туда ж по-хорошему никто не должен ходить), при случае обновлять кастомные geoip, geosite (смотреть, куда пойдут детектить выходную ноду), а то и отвечать, что выходная нода из белого списка (или из какого-нибудь тайного серьёзного списка, из которого людей не надо беспокоить).
Прочитал статью и все комменты. И вот такие сделал выводы для себя.
Найденная уязвимость - дырка в самом механизме маршрутизации приложений. Любое заинтересованное приложение сможет отправить запрос к вашему VPN серверу, даже если вы исключили это приложение из доступа к VPN.
Как показали дальнейшие исследования в комментах, найденная уязвимость НЕ СВОДИТСЯ к неавторизованному socks5, о чем была речь в исходной статье. Оказалось, можно спокойно сделать а ля “curl ifconfig.me --interface tun0”, при этом узнать название интерфейса tun0 - также не проблема.
Из п.2 следует, что ни пароль на socks5, ни случайный порт нам НИКАК НЕ ПОМОГУТ. И нет смысла ожидать патчей в эту сторону и тратить время на педалирование разработчиков.
Необходимо признать - найденная уязвимость приводит к неизбежной утечке внешнего ip адреса VPN-сервера. На этом участке мы проиграли. И не нужно тратить время, чтобы принимать неработающие полумеры. Это и есть главный вывод из статьи. Вот из этого и нужно исходить далее.
Единственный работающий выход, который и был уже предложен автором - прятать входной ip. Настраивать VPN-сервера только таким образом, чтобы входной и выходной ip не совпадали. Самый простой и пока доступный вариант - outbound на Cloudflare через WARP. Многие здесь так уже и сделали, судя по комментам. И на данный момент это единственное верное решение.
Nekobox, настройки https://habr.com/ru/articles/1020080/comments/#comment_29792770
Решают проблему
Необходимо признать - найденная уязвимость приводит к неизбежной утечке внешнего ip адреса VPN-сервера. На этом участке мы проиграли. И не нужно тратить время, чтобы принимать неработающие полумеры. Это и есть главный вывод из статьи. Вот из этого и нужно исходить далее.
Не совсем. Тесты показали, что атакующий посылает пакеты, которые ConnectivityManager.getConnectionOwnerUid() отлавливает как uid=-1. Это универсальный маркер для пакетов, которые самостоятельно решили пойти в VPN без разрешения. Все остальные приложения получают свой UID отличный от 0 и -1, например 10235. Таким образом, все такие пакеты можно обнаруживать с оговоркой: первый пакет в любом случае успеет пройти до того, как вы оборвете соединение. Но после этого - пожалуйста, просто гасим VPN по первому прошедшему пакету и дальше ищем виноватого.
Тесты на эмуляторе (Android 16) и одном физическом устройстве (Android 13) поймали несколько false positives DoH до 8.8.4.4, все они при желании отфильтровываются.
План из под нейронки
### 2. Surface uid=-1 from getConnectionOwnerUid as a user-facing alert (RECOMMENDED — Path A confirmed viable)
This is now the recommended ship target. Path A revision (2026-04-07, see [vpn-bypass-tun-binding.md](vpn-bypass-tun-binding.md)) confirmed empirically that calling ConnectivityManager.getConnectionOwnerUid from 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 bridge uid=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_check in app/src/main/cpp/tcp.c that fires at the new-session SYN point and calls Tun2HttpVpnService.onNewFlowCheck(proto, localIp, localPort, remoteIp, remotePort). The handler queries getConnectionOwnerUid and currently logs to the PathA tag. Productionising it requires:
1. Whitelist comparison. When uid is a real value, check it against the user's pref_vpn_allowed_application (or pref_vpn_disallowed_application in 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 == -1 is 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=-1 event 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 first uid=-1 flow. 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.xml and values-ru/strings.xml pattern.
#### Pros
- No special permission required (getConnectionOwnerUid is 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 found for exactly this case — same observation, different codebase.
#### Cons
- Detection, not prevention. The TCP handshake completes before onNewFlowCheck fires, 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 returns EPERM against 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 getConnectionOwnerUid plumbing already exist from Path A; what's left is the policy comparison, sliding window, notification UI, Settings toggle, and i18n strings).
Могу залить репу с victim и attacker для тестов, если кому интересно.
А почему первый пакет пройдет?
Это просто по результатом нейросетевого теста, который Claude гонял на эмуляторе, пока я работу работал. В принципе, ничто не мешает использовать подход NekoBox и просто роутить пакеты по uid=-1, если в клиенте есть механизм роутинга:
Скрытый текст
tun2http opens every upstream TCP/UDP socket with protect_socket() → VpnService.protect(fd). That call detaches the kernel socket from the VPN routing table, so every upstream connection the native engine makes is already physically going through the device's real network. For port-443 flows it then connects to the local HTTPS proxy bridge instead of the real destination. For non-443 flows (see tcp.c:1230) it already connects direct (redirect = NULL). So the "direct bypass" behaviour for port 443 is a one-line change: set redirect = NULL when the session is marked uid=-1.
Но если такого механизма нет, то тогда только дропать соединение.
Единственный работающий выход, который и был уже предложен автором - прятать входной ip.
Отказаться от самообновляемых списков неизвестного происхождения. Создать свой минимальный список доменов. Но прятать входной ip все равно полезное
На сервере: Все что не входит в список - блокировать.
На клиенте: 1. То что входит в список - в туннель. 2. Все остальное напрямую.
Кажется логически должно подходить, но это если сервер личный
Перенаправление всего трафика в WARP на сервере не помогло, YourVPNDead на Android палит IP входного сервера, при этом сайты https://ipinfo.io показывают IP WARP, как и должно быть (клиент V2RAYNG)
Это говорит лишь о том, что вы не весь трафик завернули в WARP. Или вообще не завернули. Проверьте логи x-ray на сервере, убедитесь, что все запросы идут в proxy. У YourVPNDead нет возможности узнать ваш входной сервер, если вы действительно всё завернули в WARP. У себя я проверил - входной ip YourVPNDead не видит при WARP.
Nekobox, настройки https://habr.com/ru/articles/1020080/comments/#comment_29792770
И exit IP не виден
UPD: Испоьзовал на сервере WARP, который "поставлялся" с 3x-ui, поэтому и не работало, поставил warp-cli, все заработало
@runetfreedom, могли бы вы написать список приложений, которые прошли проверку и не содержат уязвимостей? Чем можно пользоваться сейчас? FlClashX тоже уязвим?
Да я обязательно написал бы, если бы такие были бы…
Я упоминал клиенты на базе sing-box, которые безопасны если не указать mixed inbound. Но потом пришел @ValdikSS и упомянул про прямое обращение к интерфейсу. Следовательно и sing-box стал уязвим.
ИМХО цензор живёт в парадигме, что пользователь либо покупает продукт "из коробки" за подписку, либо выполняет самостоятельную настройку таким образом, чтобы всё работало как раньше. А что если не заворачивать весь забугорный траффик в трубу, а обеспечить себе доступ лишь к тем ресурсам, которые вам действительно нужны (тот же Intel, dell, st например и ряд китайских сайтов которые перестали работать из РФ). Да, таблица маршрутизации будет возможно длинная. Но за то все сервисы иностранной геолокации будут показывать "правильный" IP.
Единственный выход тут - заблокировать Happ на серверах своих подписок по UserAgent
Happ/*
не понял где выставлять это. может подскажет кто?
Сидел на Happ, после статьи переехал на FlClash, может кому пригодится.
На телефоне TUN include-mode, VPN только для нужных приложений, все остальные напрямую. SOCKS5 закрыл аутентификацией в конфиге:
authentication:
- "x:случайныйпароль"
Параллельно на всякий случай настроил сервере: российские домены, geoip:ru и IP-чекеры роутятся через WARP
Прогнал три инструмента:
PoC (runetfreedom): VPN not found.
RKN Hardering: "Требуется дополнительная проверка". GeoIP чисто, SOCKS не виден, TRANSPORT_VPN не обнаружен. Остались tun0 и DNS в приватной подсети, без рута (вроде как) не убрать.
YourVPNDead: "Вcё чисто, уязвимых: 0". SOCKS5 нашёл, но пишет "защищён паролем" и "перехват пароля невозможен - Android sandbox работает".
Это с моей модификаций и чуть чуть подкрученными настройками, vpn интерфейс к сожалению он будет видеть, только если с рут правами химичить но такой возможности у меня нет и у многих тоже, по крайней мере ip сервера spyware не узнает.
У меня вот так. Видимо, у вас обход выявлен исключительно из-за установленных пакетов, но это, энивей, само по себе - не угроза для сервера.
Отдельно интересный момент, почему у меня DNS валятся, надо будет разобраться.
В общем добавил генерацию auth и случайный порт в vay2rayng ни один детектор не видит ip, как то так, выложу на гитхаб позже
+1 про clash: в yaml конфига для Clash meta for android и Clash verge
bind-address: 127.0.0.1
authentication:
- “СлучайныйЛогин:ОченьСложныйСлучайныйПароль”
skip-auth-prefixes: []
Проверял включением прокси на адрес и порт из конфига CMFA в настройках wifi на мобильнике (чтобы приложения принудительно туда послать), POC от runetfreedom и RKN Hardering. IP сервера не палится, палятся косвенные признаки: установленные программы, интерфейсы и маршруты.
Картинки
@runetfreedom
А что если в качестве меры реагирования использовать идею honeypot. Пока клиенты (Happ-ы, v2ray-и и проч) реализуют (или нет) механику авторизации можно написать приложеньку, которая будет поднимать слушающие сокеты на локалхосте и сообщать если по ним кто-то постучал. Порты подобрать из упомянутого списка характерных. Свои приложеньки, конечно, же настроить на нехарактерные порты.
Таким образом мы:
Получим возможность (хотя и не гарантированную) понять, есть ли на устройстве описанные в статье сканеры. Возможно, даже поймём, что это за приложения.
Сможем отреагировать путём замедления сканирования. Я не спец, но что-то слышал про специально замедленные ответы от сервера (то есть от нашей honeypot приложеньки)
Или ерунда всё это?
Идея не плохая, но ханипоты в идеале должны реализовывать разработчики клиентов.
🤷♀️ как будто бы не их это ответственность. Вот дать механизм авторизации, о котором Вы написали -- это да. А скан-детектор-ханипот это будто смежная, но всё-таки другая задача.
Так или иначе я сам в такое не умею, к сожалению. Наверное, я хотел проверить идею на безумность и если она не совсем безумная - найти кого-то, кто сможет подхватить и сделать основное. То есть воплотить
С одной стороны да, к их функциональности прямо это не относится. С другой - они массово распространены и это их сфера интересов.
В конце концов это и реклама бесплатная (если ханипот что-то обнаружит) и снижение вероятности, что их вообще будут сканировать (что бы не нарваться на этот самый ханипот)
Сегодня полностью отвалился v2raytun. И на компьютере, и на телефоне. Это может быть уже связано с этой проблемой?
Раньше я не обращал на это внимание. Но с Amnezia wg2 4.8.14.5, приложения билайн и wb определяют что включён впн. И прямо говорят об этом. При том, что включено разделение трафика. И их трафик не идёт через впн. Раньше это не напрягало. Но теперь, со всеми этими новостями... Надо срочно закрывать эту уязвимость.
Это сейчас первостепенная опасность. Ни что другое не имеет значение, если российские приложения могут определить впн на смартфоне, и ip адрес сервера. А РКН эти сервера просто будет блокировать. Такие впн сервисы просто становятся не работоспособны.
Сейчас, это главная уязвимость.
стопроцентная уязвимость, пореверсил v2raytun под мак, выглядит как у них общая кодовая база с ios . и вот там также поднимается экстеншен и в нем заводится локал хост к которому можно прицепиться без авторизации
это конечно какой-то хайвмайнд, но как раз недавно закончил делать vless-tun командлайн-кли под мак и выложил в прошлую пятницу
https://github.com/relux-works/multi-tun
ну и на фоне этих событий как раз проверил v2raytun и подтвердил слова автора (по крайней мере касаемо вектора атаки и уязвимости конкретно этого клиента) , статью также выложил в этой репе
артефакты аудита лежат в той же иерархии, для тех кому интересно
Почитал комментарии.. В общем, я так понял, что, на стороне VPN серверов нужны свои белые списки. Других вариантов нет. Кто то случайно запустит приложение шпион со включенным vpn и все полезные ip утекут в список блокировок.
Других вариантов нет
Есть:
1) Использовать цепочку из двух прокси (или Warp на сервере).
2) На Android — использовать раздельное туннелирование по приложениям и отфильтровывать приложения, которые пытаются отправить трафик напрямую через сетевой интерфейс туннеля: https://habr.com/ru/articles/1020080/comments/#comment_29795878 (реализовано пока только на sing-box (SFA) и NekoBox, несколько я понял).
sing-box настроить inbounds type:mixed с паролем
потом фф + foxyproxy
тг через тот же прокси
ну и для верности запихать sing-box в samsung knox
что в списке приложений не светился
да, если в прокси, то не работает раздельное тунелирование по приложениям, но оно по сути и не нужно.
это то, что я натестил
Я так понимаю единственный вариант на 100% рабочий - это второй смартфон для ру-софта…
А на Винде пользоваться каким-нибудь Bluestacks эмулятором, в который понапихан ру-софт и серфить там ру-сайты - вариант? При условии что Блюстакс не идет через впн?
немного спорно я бы сказал. казалось бы да, но мне например легче на основном телефоне скрыть от ру-приложения что надо, потому что тут установлен рут и всё что надо чтобы приложениям ограничивать доступ куда не надо. в обоих вариантах есть нюансы. но именно легче конечно иметь отдельный телефон. (до чего докатились, отдельный телефон для ру-приложений, доверие население к правительству прям на высоте)
но не все приложения легко переносят ограничения в правах, некоторые отказываются работать. я так уже от двух приложений банковских отказался. теперь захожу через сайт. "всё для удобства пользователя".
Если я правильно понимаю, то можно поднять цепочку из 2-х серверов, оба вне страны. Тогда второй будет делать то для чего использую warp. По идее в такой ситуации будет абсолютно все равно что внешний IP второго сервера заблочили внутри страны, т.к. коннекты к нему идут только от первого. Но если нужно что бы точка входа была внутри, то придется поднимать еще один. При таком подходе все эти детекты не будут иметь смысла.
На самом деле, проблема достаточно новая. Исторически разделения на зоны не было. Т.е. если ты сам себе на устройство поставил трояна, то конечно же у него будет доступ ко всем твоим данным, включая доступ к документам и всему софту, включая VPN.
Потом начали запускать софт в chroot или в отдельной виртуалке (vserver, dockers), но все это не так просто и много нюансов. В мобильных телефонах эту фишку типа внедрили по умолчанию, но в Андроиде, например, оставили возможность определять VPN соединение вполне официально. Или шпионский софт может вызвать другое приложение (Youtube) через handler://youtube, и определить работает они нет.
Короче, вариантов определить VPN - масса, и мы только в начале пути.
Поэтому лучше тупо не ставить ничего на свой телефон. Вообще WPA уже давно придумали, и все сервисы вполне себе могут (должны) работать без установки отдельного приложения под каждый сервис.
Если я правильно понял, то не существует способов скрыть использования ВПН на смартфоне без root доступа от приложений, и даже такие ос как GrapheneOS, имеют такую уязвимость? И какие тогда решения?
Значит решений всего 2 ( самых простых)- либо удалить все российские приложения, либо заводить под ВПН отдельный телефон?
Использовать PWA вместо приложений если уж совсем необходимы? (типа банковские)? Заодно можно их в шелтер или нокс самсунговский посадить
Я так понимаю PWA самый удобный и безопасный вариант? В банках весь функционал есть, яндекс еду заказать вроде тоже можно, но не проверял, госуслуги тоже вроде норм работают, маркетплейсы тоже хорошо, только вот яндекс музыка у меня сбоит местами почему-то, и скачать музыку на устройство нельзя, а так вроде пойдёт.
Я скачал отдельно браузер Firefox и сделал так, чтобы весь трафик Firefox шёл напрямую, так как не нашёл метода как можно удобно разделять весь трафик Chrome и PWA приложений, которые я установил.
Есть ли какие-то подвохи у этого метода? Вроде идеальный вариант для банкинга, госуслуг, маркетплейсов и т.д., чтобы не мучаться со вторым телефоном.
ну либо блокируешь себе в клиенте доступ на ру сайты, вспоминаешь про это каждый раз, когда попадешь на них, выключаешь КВН и идёшь без него
установила на steam deck amnezia vpn. Пролем нет никаких, даже можно в игры играть.
Что с разработчиками v2rayNG? Будут ли решать проблему?
Когда ты ни разу не ИБ шник и не понимаешь почему порт закрывать не будут...
Ставим на этот порт свою прокси, исследуем куда ломятся приложения, фиксируем домены, получаем рута, подменяем сертификаты, подделываем трафик, блокируем того кого хотим с помощью РКН, жду приложения даже которое за деньги будет у тебя этот прокси держать ...
Реклама - заблокируем конкурентов !
я разрабатываю:
https://github.com/Leadaxe/singbox-launcher/
буду рад если тоже попаду на аудит =)
Итак, дорогие программисты! Прочитав весь рост и все комментарии я нарыла старый телефон, на котором никогда не устанавливался, как вы говорите, КВН, и скачала туда все российские приложения. Как я поняла, это самое надёжное. Я удалила их все со своего основного телефона. Скажите, как можно убедиться, что они снесены на 100%? В списке приложений их не вижу, апк тоже не нахожу.
И ещё один вопрос, подскажите, как мне заблокировать нахрен сайты белого списка у себя на телефоне и на компе? Чтобы даже если вдруг я тупану и забуду, не получится на них перейти. Или вдруг тыкну что-то не то.
Пожалуйста, объясните максимально просто, я филолог
Сайтов можно не бояться.
Ооо то есть если я зайду на российский сайт типа сбербанка или ВКонтакте с ВПН, то разве сайт не увидит, что я юзаю ВПН? Не увидит айпи адрес и все такое?
Сайтов можно не бояться в контексте этой конкретной проблемы, описываемой в статье, потому что у сайтов (опять же, насколько я знаю, я далёк от современного веба и мобильных штук) нет таких возможностей на телефоне, какие есть у установленных приложений. Но да, конкретно по IP сайт скорее всего увидит, хотя это и зависит от кучи разных нюансов, о которых мы не знаем. Дам лучше удочку, а не рыбу: спросите у нейросеток, они отлично помогут с этими вопросами, если им расписать всю ситуацию подробно и ловить их, задавая уточняющие вопросы.
Для сайтов нужно использовать маршрутизацию. Типа всё российское и + иностранные сервисы, которые НЕ заблокированы в России - пускать напрямую, а все заблокированное- через прокси. В некоторых клиентах готовые правила бывают.
Типа всё российское и + иностранные сервисы, которые НЕ заблокированы в России - пускать напрямую
а какие точно не заблокированы? cloudflare заблокировано, aws заблокировано, сейчас вот reddit не открывается (заблокирован fastly?). это львиная доля англоязычного интернета. конкретные ограничения варьируются в зависимости от погоды на марсе, но с ограничениями сталкиваются все. плюс куча западных сайтов самостоятельно огораживается от пользователей из рф.
проще всё зарубежное пускать через vpn, чем постоянно бороться с ветряными мельницами.
спасибо, happ удаляю
Подскажите, где приобрести у нас смартфон без предустановленного Рос ПО? Хочу завести чтоб по телеге общаться и ютубчик смотреть)
чуваки, подскажите пж как 3 пункт из статьи реализовать? чёт тыкаюсь в xray настройках, делаю блок на геоайпи ру и всё равно открывается.. или я не так понял посыл автора
Проверил клиент Trust Tunnel на Android из папки Knox. Тоже поднимает Sock5 без пароля
Если верить описанию обновления, разрабы вчера пофиксили уязвимость
hiddify довольно легко патчится (сам vpn работает)
А у меня вопросик. Прочитав статейку и комментарии, решил снести все российские приложухи с телефона. Но так как живу в россии, то хоть приложения банков мне нужны. Специально для этого, по совету нейронки установил firefox и через клиент amnezia vpn, через сплит туннелинг отключил подачу впна на лисичку. Так вот к вопросу: Если я с включенным впном и сплит-туннелингом зайду например на сайт сбербанка или мтс, они увидят что у меня впн? Если увидят то как этого избежать?
Хорошо, допустим. ВСЕ популярные клиенты, если вручную не шаманить с настройками, конфигами и если вы не фанат «песочниц», уязвимы для атаки и обнаружения вашего ip-адреса. Но вопрос встаёт насущный – что со всем этим делать? Неужто вариантов как-то это исправить совсем нет? Или только бесконечная самостоятельная настройка клиентов, не все из которых ещё это позволяют?
Кстати, для Windows нужная стратегия уже реализована в клиенте в v2rayN (пресет “Все, кроме РФ”)
А с чего вы взяли что это будет решением для мобильных устройств? Основная проблема что нативное приложение может что-то протестировать и выявить VPN включая его выходной IP. каким образом? Они подставят адрес например whoer.net и спалит иностранный ip и поймет что вы под vpn скорее всего. Решение не то что с приложения должно быть а с целой прошивки который такое шпионство должен запрещать)
А если наоборот, все вредоносы (максим и другие) в шелтере (knox и тд тп)?
Разве приложение изнутри песочницы может сканить локалхост на самом устройстве?
А КВН используется как раз вне шелтера.
Протестил на android 13 с помощью YourVPNDead v21 (2026.04.07) (https://github.com/loop-uh/yourvpndead/releases) все клиенты, что на телефоне (последние на тек.момент версии - v2rayng 2.0.15 и happ 3.17.0 (1451)) - уязвимость присутствует, ip vpn сервера раскрыто.
в версии happ 3.18.1 - закрыли, появилась в настройках inbound авторизация, правда отключенная по умолчанию... но если включить, то сканер больше ip vpn не может найти... но в целом это не спасает от того что любое приложение может видеть по косвенным признакам факт наличия VPN, а ip vpn сервера (или стоящего перед ним прокси) элементарно определяется на уровне оборудования оператора
Жесть, конечно. Я сначала даже усомнился, что Shelter реально пропускает прокси, но установил туда телегу, и она успешно подключилась через носки.
Вопрос про Amnezia. Я так понимаю, она пробрасывает SOCKS5 через порт 10808 только для Xray? А если используется AWG? Мне не удалось подключиться к телеге по этому порту. Ну и nmap -p- 127.0.0.1 ничего не выдаёт.
Так что в итоге, за 10 дней кто то из разработчиков исправил проблему?
Автор добавь еще один Upd: "в нелюбимом" сообществом выше Happ похоже закрыли и вторую часть дыры, в последней версии 3.18.1 (на Android) появилась настройка "Авторизация inbound", как понимаю она закрывает безпарольный доступ другим приложениям. Правда по умолчанию выключена... предполагаю разработчики побоялись включать по умолчанию новую фичу всем и пока ждут результатов насколько это все будет работать и востребовано у пользователей, надеюст позже включат по умолчанию On.
Специально зарегистрировался чтобы вставить свои пять копеек по поводу Happ вроде бы да добавили авторизацию в Inbound, но при этом она не работает если использовать режим авторизации только у socks то трафик от приложений не идет в туннель (у тех что выбраны в прокси приложениях), а если включить авторизацию у http inbound, то в Termux с помощью командыcurl -s https://ifconfig.me/ip --interface tun0" легко получается ip адрес сервака, при условии что termux даже не выбран в прокси приложениях для сплит приложений
У меня после включения авторизации Inbound для SOCKS5 (режим Auto) перестают работать ру-сервисы.
Прилетело уведомление о вашем сообщении, полез проверять... Обнаружил что сейчас с inbound авторизацией не то что ру-сервисы не работают, просто vpn не работает. Ошибка TLS при соединении с любым сервером. Это что то сломалось. До этого неделю ходил - не было никаких проблем. В настройках стояло Прокси для выбранных приложений - и сюда только то, что надо в VPN и браузер, в Маршрутизации block->direct->proxy настройки по gео и ip для ru и свои исключения, в inbound авторизации стояло Авто (и на socks и на http). Все работало как часы без необходимости отключения happ. Все ру сервисы открывались, даже те, что сейчас палят VPN и отказываются работать - тоже открывались. Единственное WB по-прежнему показывало кружок, что работает VPN. Ну и все сервисы, что должны были быть доступны через VPN, также работали. IP по забугорным сайтам показывался от страны VPN сервера, по нашим российский. YourVPNDead проблемы с IP vpn сервера не показывал - он не определялся. Но на сейчас 26.04.2026 на версии 3.18.1(1767) inbound авторизация реально "сломалась" и при ее включении у меня соединение с VPN сервером как бы выполняется.. но при попытке его проверить, пишет ошибка TLS. И по сути VPN просто не работает. Если отключить inbound авторизацию, то сразу все начинает работать. Ждем обновы или какой то реации разработчиков.
И пока писал это сообщение выше, сразу после его публикации "вдруг" всё снова заработало. Мистика какая то. Все открывается и ru и не ru с включенной inbound авторизацией, разделением по приложениям и маршрутизацией. YourVPNDead - все чисто. Забугорный определитель ip - Швеция. И WB перестал показывать уведомление о работающем VPN :)
У меня всё также не работает на текущий момент.
iOS 18.7.8
Happ 4.8.2
Утверждения в статье не соответствуют действительности.
Не все клиенты имеют эту уязвимость.
При нормальной настройке тех клиентов, которые ее не имеют. В частности sing-box.
"Сырой" запрос, что и происходит, например, через curl --interface tun0 ifconfig.me через vpn интерфейс отправить не получится.
Сама уязвимость, как подозреваю. Очень простая. VPN клиент не может сматчить трафик приложения. Т. к. при таком запросе нет информации, например о пакете приложения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из-за критической уязвимости VLESS клиентов скоро все ваши VPN будут заблокированы