Временные методы ещё могут пригодиться для определения входных адресов VPN. Допустим, наш сервис определил VPN, и передаёт достаточно большой поток данных (например видео) с определённой модуляцией (например, секунду передаёт, секунду нет). Если можно как-то предположить, что это определённый пользователь сидит (например, зареганный в каком-то сервисе), можно получить его netflow и посмотреть, поток данных с какого адреса имеет такую же модуляцию, это и будет входной адрес VPN. Но это конечно гораздо сложнее, и вряд ли, что будет широко применяться.
Оно может выбирать TRANSPORT_CELLULAR или WIFI, но зафорсить себя внутрь VPN в обход системной маршрутизации - нет.
В том же sing-box, если приложение вдруг попало в VPN (хотя оно добавлено в exclude в tun по имени пакета), то можно и уже в момент его маршрутизации по имени пакета направить в direct. Поэтому я всегда на всякий случай дублирую имя пакета и в настройках tun (для исключения), и в route.
В соседней теме я писал (думаю в этот топик те объяснения лучше подходят) про то что приложение на Android также может обойти системную же маршрутизацию, вызвав CustomTabsIntent, получив UID дефолтного браузера.
Ещё – любой “Open in Browser” → редирект на сайт с шпионом → изначальный сайт (куда хотел пользователь), получив при этом IP, через который маршрутизировался браузер.
О чём это говорит?
Просто – браузер был в туннеле (стандартная ситуация) – шпион получил IP, хотели ли вы это или нет.
Имя пакета дефолтного браузера, вызванного из изначального приложения, различается.
Например, как видно из логов пользователя сети.
Как решение - держать шпионские приложения в рабочем профиле через тот же Island. Там свой отдельный браузер, который нельзя туннелировать из основного профиля
Тогда не получится использовать одновременно и обычный профиль. То есть опять же прозрачно не получится пользоваться смартфоном. Это я молчу, что не на всех типах смартфонов есть изолированные окружения с изолированным сетевым стеком (банально – они для этого не предназначены).
Кто так жить согласен – вопрос. Это неудобно. В один момент пользоваться либо тем - либо тем.
А какие конкретно приложения являются шпионами – отдельный вопрос. Тогда либо отделить профиль “только впн” от “direct” вообще полностью, то есть программный и сетевой стек целиком для двух состояний туннеля (есть/нет).
Это ещё какой-никакой userspace sandbox. Процессы в неактивном профиле не работают. Тогда только так, а не иначе. Никаких VPN и в том и другом профиле быть не может, иначе теряется смысл.
То есть решение не в том, чтобы “шпионов” отдельно. А именно VPN / Не-VPN профили разделить. Только так.
Почему же? Они работают как обычно, просто изолированно от основных приложений. Как раз то, что нужно. Из бонусов - заодно скроем список установленых v2rang и прочих nekobox из основного пространства.
Это userspace изоляция. Сетевой стек он в ядре, общий для всех профилей.
То есть одновременно сетевые запросы могут слать как с рабочего, так и с основного профиля так? И с рабочего могут открыть браузер из основного, если он в рабочем не установлен.
Представьте что шпион окажется в основном профиле. Даже без всякой там авторизации они могут слать определенный уникальный fingerprint трафика, который при долгой временной корреляции можно будет однозначно идентифицировать и связать с конкретным человеком.
Это я молчу, что обоим профилям доступны те же fingerprint устройства.
Я же держу всех шпионов отдельно
Всех не перепишете, у них на лбу не написано. Даже типа “обычное” ПО много чего сливает (через телеметрию) и без зазрения какой-либо совести продаст эти данные РКН.
Я-то думал, что одновременно либо то, либо то, – куда бы не шло ещё.
Я считаю, что это абсолютно ненужное действие, на Android уж можно спуфить эти данные (фейковые названия и ID пакетов) это раз; это не говорит о чём-то запрещенном это два.
Короче, минимизировать вы риск, поместив “всё российское” на карантин – можете, полностью так исправить уязвимость – нет. Тут надо статьи (каждую) с припиской “CVE” читать и проверять, не устранена ли та или иная уязвимость на вашем устройстве.
Это игра в кошки-мышки, где кошка цапает всего раз, а убегаете вы – постоянно.
Полностью исправить можно только сместив точку наблюдения с ISP и конкретного конечного устройства на свой удаленный шлюз.
Нет, так нельзя. Если браузера нет, откроется веб вью текущего профиля.
В андроиде без рута позволено очень немногое. Это далеко не такой же линукс как у вас на пк, где делай все, что хочешь.
Хотя трафик в случае per-app VPN действительно не будет заворачиваться при использовании island, приложения там все ещё видят факт наличия VPN соединения.
Можете проверить - запустите network analyzer из профиля и посмотрите.
Да, с этим ничего не поделать, но сам факт использования впн им мало что даст
Так и не удалось мне проверить на реальных заграничных пользователях, но интернет-сервисы показывают работоспособность идеи.
Ссылка для проверки: http://81.177.139.211:49200/
Ответ приходит не сразу, а через 5-10 секунд, это нормально.
При подключении программа делает замер времени от отправки 301 кода HTTP до получения нового запроса от пользователя (т.е. пробует оценить RTT до клиента), после чего запускает mtr в сторону адреса клиента и получает RTT до ближайшего ответившего узла, если разница достаточно мала (меньше 50 мс), значит VPN за границей скорее всего нет (это реальный заграничный пользователь), если больше - нужно смотреть ещё (делать повторную проверку, анализировать диапазоны IP, часовые пояса в браузере, ещё какие-то признаки…). Возможно порог 50 мс слишком мал или слишком велик, надо экспериментировать.
Попробуйте запускать с заграничным VPN, а также из-за заграницы без VPN. Мобильные сети могут давать false positive. Я вижу логи, хотя естественно не могу знать, есть ли у вас VPN или нет. Обещаю с РКН не сотрудничать 
это чисто академический интерес. У меня самого чётко определяет, зашёл я с VPN или нет.
PS: пока довольно чётко видно, что датацентровые адреса (причём российские) у меня определяются как VPN, а домашние нет.
Да, с моей прокси цепочкой определило что я VPN / мобильная связь.
А без – туннеля нет.
А возможно ли как-то вообще отличить мобильную связь от проводной? Если можно, то получается это довольно-таки точный инструмент по обнаружению туннелей.
UPD: второй раз замерил, уже не задетектило VPN.
Welcome to VPN checking page.
Processing time is 56.2 msec
Ping time is 7.7 msec from X.X.X.X
Delta time is 48.5 msec
You aren't a VPN user.
UPD2: Теперь снова детектит.
UPD3: после долгой паузы снова не задетектило.
Summary
Welcome to VPN checking page.
Processing time is 52.5 msec
Ping time is 5.3 msec from X.X.X.X
Delta time is 47.2 msec
You aren't a VPN user.
Welcome to VPN checking page.
Processing time is 52.9 msec
Ping time is 6.0 msec from X.X.X.X
Delta time is 46.9 msec
You aren't a VPN user.
Welcome to VPN checking page.
Processing time is 52.7 msec
Ping time is 3.0 msec from X.X.X.X
Delta time is 49.7 msec
You aren't a VPN user.
Welcome to VPN checking page.
Processing time is 53.7 msec
Ping time is 4.5 msec from X.X.X.X
Delta time is 49.2 msec
You aren't a VPN user.
Логи когда детектит
Welcome to VPN checking page.
Processing time is 55.9 msec
Ping time is 5.6 msec from X.X.X.X
Delta time is 50.3 msec
Too big delta, you are a VPN or mobile network client!
Welcome to VPN checking page.
Processing time is 61.1 msec
Ping time is 3.5 msec from X.X.X.X
Delta time is 57.6 msec
Too big delta, you are a VPN or mobile network client!
Welcome to VPN checking page.
Processing time is 54.9 msec
Ping time is 4.8 msec from X.X.X.X
Delta time is 50.1 msec
Too big delta, you are a VPN or mobile network client!
Можно только по диапазонам мобильной сети (то, что адрес относится к диапазону мобильного оператора).
Я вижу, что кто-то попробовал обойти проверку, добавив задержку пинга. Можно в таком случае игнорировать слишком большое значение пинга, а брать его с предыдущего хопа. Или вообще не учитывать его с конечного узла.
У вас IP московского ДЦ Cloudflare.
Если VPN достаточно близко к клиенту находится, то таким способом его не обнаружить. Но такие достаточно близкие сервера в России и так в зоне досягаемости ТСПУ находятся. А заграничные дают достаточно большую задержку, чтобы их можно было задетектить.
Интересный IP попался 95.217.223.х - ДЦ Hetzner в Хельсинки, у него 30 мс разницы, что достаточно немного. Интересно, действительно ли это VPN? клиент может быть, например, в Питере, оттуда до Хельсинки достаточно близко, поэтому не задетектился.
Порог у вас 50 мс. Этого не хватит, что покрыть, например, Москва - Дальний восток. Если чекер у вас в Москве. Надо смотреть город клиента и направлять в локальные чекеры. Хотя бы 3 на страну.
А на Дальнем востоке трафик ещё и весело бегает. Может в Японию (если там впн) пойти напрямую, а может через Москву. Так что и ваш местный дальневосточный чекер может ошибиться.
Это порог разницы, а не чистого времени. Если клиент на другом континенте без туннеля, то у него и пинг будет большой, и время запроса, а разница все равно останется небольшой. Мне попадался какой-то американский IP, и он не определился как VPN.
Интересно как скрипт через каскад прокси узнает реальный ip
А у него нет цели определить реальный IP (он даже X-Forwarded-For не смотрит), он смотрит только на выходной.