А как тогда тут фигурирует сплит? Разделение, кого напрямую с сервера (например доверенные ресурсы) и кого через другой IP (WARP/купленный)? Звучит более логичным при использовании прослойки РФ VPS, но там уже свои подводные камни.
Мне просто WARP скорость особо не режет + в некоторых сервисах кто-то уже видимо подгадил с прямого IP своей локацией и WARP это поправляет, поэтому нужды что-то заворачивать прямо не замечаю.
Даже при таком варианте может ругаться на впн, если зайти с браузера на кинопоиск из российского впс, будет писать что используете впн. Фиксируется asn хостинга
Появилась сама методичка. Предлагаю в первый пост.
Делимся с вами документом под названием «Методика выявления признаков использования средств обхода блокировок на клиентских устройствах».
Это не оригинальный документ, который мы получили, а распознанный текст в формате Markdown. Открыть и прочитать можно в любом текстовом редакторе или воспользоваться сайтом, наподобие Markdown Live Preview (https://markdownlivepreview.com/).
ocr_methodika_vpn_proxy.md (46.1 KB)
Хотя split-туннель в некоторых случаях может быть уязвим. Обнаружив VPN, шпионский модуль передаёт маячок на российский сервер, который идёт напрямую и ТСПУ его видит и начинает наблюдать за трафиком с адреса этого пользователя. Потом шпион посылает объём трафика с VPN и время, а ТСПУ смотрит свои наблюдения и находит адрес, с которого в это время этот объём трафика был получен.
А как быть в случае VPN по приложениям или для всей системы? есть ли какие-то способы послать трафик напрямую? можно наверное на DNS-сервер оператора послать какой-то запрос, который ТСПУ сможет увидеть?
Из того, что вспомнилось - когда активна раздача трафика, Андроид запускает DNS-сервер на 127.0.0.1, который выходит в сеть, минуя VPN. Приложение с VPN может послать запрос DNS на 127.0.0.1 со специальным именем домена, и ТСПУ обнаружит маячок. Но если раздачи нет?
Спасибо, добавил
именно поэтому твои выкладки и советы тоже не работают
ибо всегда можно предположить что будет скан самих конфигов vpn прям с ключами и ip
По методичке выходит, что на любых мобильных устройствах без диких костылей и кастомных ОС не спрятать наличие туннеля если он включен, и все упирается в детектируемый IP, где при полном совпадении с РФ без признаков хостинга вердикт, что туннель работает на что-то другое, а не обходы, либо (при всех признаках зарубежом) какая-то “дополнительная проверка“. Ну и очевидно что при частичном несовпадении вердикт прокси.
Я вот такое добавил в первый пост. Согласен, что это не решение всех проблем “шпионского ПО“. Даже сам факт наличия открытого порта 1080 / 2080 уже мотивирует цензора выделить больше ресурсов на проверку пользователя.
У миня начальнек напал с этим max все уши прожужал. С женои посоветовались и купили спицально для max второи тел. Это самыи лучшии метод
@Quqas подиржите мое пиво
Нет, все упирается в то, чтобы не держать на мобильном (да в общем-то любом) устройстве шпионский ру софт, я лично топлю именно за это. Если тебе нужен условный озон или госуслуги - пользуйся веб версией, у сайтов шпионские возможности сильно ограничены, по сути околонулевые в реалиях браузерного сэндбокса, кроме возможности собственно слать сетевые запросы “куда-то в инет”.
На сайте тоже можно реализовать сторонние чекеры IP и даже DNS, поэтому за этим имеет смысл следить, но да, это сильно ограничивает поверхность атак.
а он точно лично сам тебе плотит чтоб тратить бабло хотябы на доп тариф опсоса? не говоря уж про агрегат
Я бы просто сделал два браузера - один дефолтно провайдерский, выбран по умолчанию. Другой с обходами, где заблочено всё РУ по geoip и по TLD, чтобы даже случайно туда не зайти, ну и полирнуть это дополнительно хорошо настроенным сплитом, как на клиенте, так и на промежуточной ноде.
Кстати добавлю, что в кейсе с двумя браузерами можно таки сделать per-app маршрутизацию даже на iOS. Там нужно в настройках shadowrocket включить MITM https декрипцию, и сделать правило по юзер-агенту. Дефолтно-провайдерский юзер агент в директ, второй браузер юзер агент обрабатывать остальными правилами.
Начальнек ни платит ничего ага тольк дирет деньги за все. Выбора не было или ставешь max или грозил уволить я на птичех правах. Тел скинулись с женои за свои денги
а можно поставить max, зарегаться, войти в браузер без VPN, и удалить его с телефона, пользуясь только браузерной версией?
Ни знаю я на тел для роботы поставил приложенье . Мне этот макс не нужен и я веб не пробовал. Робота закончилась и я сразу выкл его.
Здесь стоит отметить, что доступ по ip к поднятным локальным прокси есть у приложений и из второго/рабочего пространства. Не знаю, почему это вообще работает, но стоит об этом знать.
Проверял я это следующим образом. Включил v2rayNG в режиме VPN на основном профиле. В настройках указал порт прокси 12345. Клонировал Телеграм в рабочий профиль (тоже использовал Shelter), указал в нём Socks5 прокси 127.0.0.1:12345. Он подключился. Это свидетельствует о том, что даже из второго/рабочего пространства приложения могут стукануть в ваш VPN, даже в режиме per-app маршрутизации. Как понимаю, тот же v2rayNG поднимает прокси инбаунд и в него заворачивает VPN. Но доступ к самому sock5/http прокси не ограничено.
На Android приложение Билайна, запущенное из Work Space обнаруживает VPN, включенный из Personal Space. VPN, разумеется, не работает внутри Work Space, но обнаруживается сам факт наличия VPN.
У remnawave панели можно вместе с подпиской прикрепить роутинг, но только для Happ.
Определяет он по флагу от системы, а не только выходном ip. Попробуйте Shelter скачать и там проверить
В настройках Core: basic settings есть настройка для авторизации на inbound proxy, попробуйте ее настроить
Можно ещё редактированием конфига ядра исправить эту проблему.
Примеры:
{
"listen": "127.0.0.1",
"port": 10809,
"protocol": "http",
"settings": {
"accounts": [
{
"user": "myuser",
"pass": "mypassword"
}
],
"allowTransparent": false
}
}
{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "password",
"accounts": [
{
"user": "myuser",
"pass": "mypassword"
}
],
"udp": true
}
}
У Knox такая же проблема. Выходной IP, естественно, не детектит.