Для случая с мобильным интернетом важна правильная настройка “split по приложениям”. Также стоит учитывать, что большинство клиентов поднимает прокси на localhost без аутентификации, который банальным сканом портов палится. Но это можно починить с помощью пользовательской конфигурации.
Для случая с домашним интернетом GeoIP может очень легко палиться, достаточно стучить на сервис, который будет проходить через VPN. Даже если вы используете каскадную схему, это всего лишь решит проблему потенциальной блокировки входного узла, но не решит проблему обнаружения факта использования VPN.
В обоих случаях столкнётесь с этапом “требуется доп. проверка”, а не “обход не обнаружен”.
Утечки неизбежны, не работает это ваше разделение. Разный IP на вход / выход – обязателен. Раньше это всё вы считали необязательным, теперь на 100% обязательно.
Не вижу смысла прятать факт использования VPN – без полной изоляции утечки неизбежны. Просто предоставьте всем в мире шпионам свободный доступ в интернет к любым ресурсам.
Причём нельзя сливать домашний IP ISP шпионам, которые в теории могут синхронилироваться с ТСПУ для анализа netflow для анализа трафика и выявление входного IP туннеля (например генерированием трафика к шпионским серверам вне geoip:ru через туннель, сопоставление уникальных паттернов трафика и т.д)
Любые пожилые люди и тостеры будут счастливы. Сетевая гигиена и дисциплина вокруг конечных устройств не требуется.
А как же так, что шпионы смогут детектить доступность “заблокированных” ресурсов?..
Пусть, без доказательства SRC IP – ничего не дает. Потом решайте проблемы по мере их поступления.
Всё работает. То, что конечный пользователь его не умеет грамотно настроить - это его проблема, а не проблема самой фичи. Я до сих пор не разделяю входной и выходной IP и проблем не вижу.
Не вижу смысла не прятать, этим вы вызовёте “дополнительные проверки”, которые лучше избегать любой ценой, тем более когда непонятно, что за этим стоит.
Вы это гарантируете? То что нет 100% утечек, причем вы со своими знаниями (речь про всех кто уверен в том, что он уверен) это проверили и доказали это?
Что будет, если каким-то образом шпион (опять же, через утечки), скажем, воспользуется вашим туннелем к IP чекеру, расположенным все всяких публичных списков? Причем маскируясь под “заблокированные” SNI в том числе. (лучше отвечать не в этой теме, это слегка оффтоп)
Ладно, смысла спорить не вижу, делайте со своими конечными устройствами что угодно, только не рекомендуйте обычным людям пожалуйста потенциально непроверенную информацию, которую нельзя доказать.
Тем более людям, да, которые на 100% не знают что наверняка всё закрыли. У меня же идея в том что доверять конечным клиентам-людям – нельзя.
Вся эта уверенность – до поры до времени, пока не выяснится что оказывается утечка есть. Рекомендовать такое новичкам – нельзя. Это как идти по тонкому льду. Я же рекомендую не ходить по льду вообще. Вместо того чтобы синей изолентой, соплями, коричневыми массами затыкать утечки в корабле, а потом обнаруживать новые, и снова закрывать – я предлагаю не тонуть вообще.
Допустим если нужно скрыть признаки туннелирования с exit узлом (просто признаки туннелирования скрывать не обязательно – не запрещено) – пожалуйста, OpenWRT роутер (в т.ч мобильный) как средство переноса точки наблюдения с дырявых устройств на контролируемое, причем на 100% для этого созданное устройство. + резидентский exit с другой сети (не в той же с SRC IP).
А вы сами докажете, что есть уязвимость? Я могу и то же самое спросить и про то решение, которое вы предлагаете. Любая схема имеет свои уязвимости. Но никто (пока что) не нашёл уязвимости в самой схеме split tunneling, Минцифры в том числе, а это схема очень старая.
Сам сервис VPN на Android не позволяет приложениям обходить split tunneling по приложениям (а если пользователь только настроил по geosite или geoip, это, опять, его вина), и это ещё давно проверено, а схема обнаружения прокси, висящего на localhost, меня лично не касается и тем более исправимо.
К слову, я ничего и не рекомендую, а обнаруживаю и указываю на недостатки той или иной схемы. Не нужно делать вид, что “моя” схема 100% нерабочая, а ваша - гарантированно будет работать навеки веков. Опять, то, что пользователь безграмотен - это его вина, а не вина системы.
Пока существует утечка через локальный прокси, через который полезет ру софт, раздельный туннель, а так же разные профили не имеют смысла. Dreaght прав, надо все заворачивать в туннель. И на выходе чтоб был варп для всего, что вызывает подозрение. Чтобы хоть напрямую, хоть через чекеры отдавался варповский ip. Тогда будет просто факт включенного vpn, установленное приложение(надо пересобирать или менять внутри апк на свое название). Реальный ip не светится.
Если у тебя флаг IS_VPN, выходной IP - домашний резидентский, а телефон при этом шлет данные через мобильный интернет, это уже явный признак наличия туннеля и повод для более глубокого зондирования.
Проблема локального прокси - это проблема негибкого локального клиента. В том же чистом sing-box такой проблемы нет. Плюс для спокойствия можно добавить в конфиг не только правила по пакетам для заворачивания tun, но и правила по пакетам в саму маршрутизацию, если вдруг пакет как-то попадёт в ядро.
Ну это гениальный ход. Превратить весь софт и веб в стране в spyware. И устанавливать его ещё на все устройства при продаже. Реально многие впн полягут.
Ещё и угрожать всем компаниям викинуть их из белых списков. Почему сразу так не могли сделать? Зачем все эти миллиарды на дипиай.
Per-app split tunneling и приватные окружения не спасут.
Все мобильные клиенты на основе xray/sing-box запускают локальный socks5 прокси без авторизации.
Ваша схема рабочая, но не панацея, это временный хак и минимизация риска.
Моя же схема другая – заранее предполагаем, что пользователь - дурак и где-то ошибся (а ошибаются все). Отталкиваясь от этого меняем контроль со всех дырявых устройствах на свою ноду (все дураки а мы же умные).
Вот ровно потому что и обнаруживаются всё новые и новые уязвимости, я и отталкиваюсь от того что они 100% есть (и потенциально скомпромитированы) и цензоры (если не дураки) – ими воспользуются. Поэтому и схему надо делать отталкиваясь от этого.
Да, здорово описано. Используйте только клиенты с открытым исходным кодом, доверять дырявым клиентам и их реализациям больше нельзя.
Вообще на 100% исправить можно – OpenWRT роутер и ванильный sing-box (или выборочно патчи потаскать форков, если вы на 100% уверены в том что в них нет очередного бэкдора) с ванильной /etc/sing-box/config.json - уверен, что за хорошую финансовую плату бэкдор могут вставить и в ваши графические панельки (типа 3xui), которые намного сложнее проверить.
Также скажу, что схема с localhost прокси - это недоработка самих клиентов, а не архитектурная проблема сервиса VPN и схемы split tunneling. Переход на другой клиент (или же custom config с аутентификацией) решает данную проблему.
почитал статью на habr об уязвимости vless клиентов, но не увидел там упоминания shadowrocket для ios. Как проверить есть ли у него такие же уязвимости или для ios они в целом не актуальны?
Вы правы, при условии что все ваши клиенты – архитектурно изолированы – схема рабочая.
Чтобы говорить, что это временный хак – понимаем, что невозможно гарантировать полную изоляцию без изоляции сети + userspace.
Исторически есть куча примеров как ломали гипервизоры, а у вас тут даже гипервизора нет.
То есть при допущении, что вы на 100% всё исправили – эту проблему и прочие известные это чинит. Молодцы, залатали очередную дыру, ждём следующую.
Понимаете, всё-всё-всё закрыть не получится. Потому что неизвестны все возможные уязвимости. Решать проблему нужно архитектурно, например QubesOS не пытается запатчить и залатать всё что угодно, он изначально подразумевает что всё что будет запускаться – шпион и схема дырявая. Вот такой подход мне нравится. А у вас стоковый Android, который не предназначен для изоляции сети архитектурно (shared loopback) – то есть подразумевает что мы живем в мире розовых пони и всем можно доверять (я про цензоров).
Проверить реализацию сетевого стека. Есть SOCKS прослойка + tun2socks – уязвим. Встроенный сетевой стек (то есть in-process маршрутизация с встроенным сетевым стеком) – не уязвим.
Я это и предполагал (и предполагаю) изначально. Но это касается любой схемой, не только “моей”.
Edit: Единственное, что я вообще могу с уверенностью рекомендовать - это 2-е устройство, которое не будет подключаться к каким-то “уязвимым” сетям, а только мобильному интернету и публичным точкам доступа без всяких VPN.
На том же устройстве – в той же точке наблюдения гарантировать ничего обычно не выходит. Ваша схема рабочая сейчас, пока не внедрили новые проверки на устройстве, используя все дыры не предназначенных для этого (устойчивость к обнаружению / к цезору) устройств.
Неудобство.
Непонятно как делить шпион / не-шпион – всякие трекеры / телеметрия / шпионы могут появится в совсем неожиданных местах, цензоры это знают и будут именно туда бить. Вы же не знаете в какой момент появится шпион на том устройстве, где вы будете использовать туннель.
Моя же схема – используйте 100% благ интернета и возможностей своих устройств, ни в чём себя не ограничивайте, не парьтесь по поводу уязвимостей. Единственное требование – держите туннель 24/7, а весь контроль над маршрутизацией – на ноде. Если клиенты не способны это гарантировать – OpenWRT роутер как клиент.
Судя по тому что я нарыл, исходный код этого клиента закрыт. Обходите такие клиенты стороной.
На сайте https://shadowlaunch.com/ указан знак “All rights reserved.” – закрытого для распространения ПО.