Опять же, очень спорная тема. С одной стороны, в теории может быть синхронизация с ТСПУ и обнаружение входного IP прокси через netflow. С другой стороны, палится сам факт VPN/Proxy. И непонятно, что важнее?
Поставь прокси-клиент с возможностью включить авторизацию на локальном прокси.
Разве это спасет от этого?
Запросы идут не к SOCKS прослойке, а к TUN.
Да, тоже заработали. Видимо это ещё вчерашний сбой наложился. Как раз в то время делал.
Не спасёт. Только переводить клиент в socks-режим без интерфейса и заворачивать проги другим софтом. Но другой софт так же создает tun-интерфейс и схема ломается. То ограниченное использование софта с нативной поддержкой прокси.
По итогу получается, что в рамках особенностей андроида нет удобного варианта огородить свой прокси от шпионского ПО, при этом проксируя все нужные приложения.
Возможно, спасение будет в модифицированных пакетах отечественного ПО, но это тоже дырявая тема, так ещё и на доверии.
Это про 2-й пункт:
Там никаких интерфейсов нет, но поддержка со стороны приложений ограниченная.
Как универсальную схему я бы это не рекомендовал всё равно.
- Не все приложения принимают прокси – неудобство.
- Синхронизация с ТСПУ + анализ netflow никуда не исчезает – хоть это пока и теория, но кто их знает (прецеденты уже есть)?
Я не очень понимаю, что имеете в виду под синхронизацией ТСПУ + анализом netflow, но если имеете в виду анализ выходного и входного трафика, как делают в Китае, то достаточно разделить полностью up/downstream (на который способен XHTTP, как минимум), потребуются как минимум 2 IP-адреса и на входном сервере, и на выходном сервере, а лучше 4 отдельных VPS с IP-адресами у разных AS.
Edit: В Китае используют вместо отдельных VPS разные CDN, но у нас это, увы, не вариант уже.
Умные Головы, пересоберите клиент с возможностью редактирования названия интерфейса и прикрутить авторизацию
Проще уж свой создать, универсальный, с учётом всех этих уязвимостей. Для Android и iOS. На базе sing-box. Раз авторы проигнорировали просьбу автора статьи – зачем для них делать форки? Ну можно и форк, конечно, но в их огороде копаться не охота. Там уже свой сетевой стек прикручен и надо переписывать дохрена чего.
Все эти реализации наследуют SOCKS прослойку + tun2socks (сетевой стек) (от старых реализаций). Я не уверен в их модульности, для реализации in-process маршрутизации. Короче – работы очень много и проще с нуля.
Не для всего есть веб-версия. Самый очевидный пример - Мир Пэй.
Я писал об этом тоже. Шпионский модуль в каком-то приложении в открытую передаёт пакет - триггер для ТСПУ, который начинает сохранять сессии пользователя, а потом передаёт информацию, что в такое-то время с VPN этим пользователем было скачано и передано определённое количество трафика. А потом сессии анализируются и смотрится, с какого адреса в это время трафик приходил. Раздельные сессии вверх и вниз тоже скорее всего не помогут в таком случае - счётчик трафика исходящего тоже может передаваться. Передали через VPN какой-то большой запрос, потом посмотрели netflow, нашли входной IP. Можно конечно пойти дальше и использовать много сессий с разными IP, только так IP не напасёшься, они все равно рано или поздно обнаружатся. Разве только IPv6 использовать, но там статистика может считаться не по отдельным IP, а по целым подсетям.
Как будто невозможно связать входной IP исходящего и входной IP входящего соединений, если связка между ними находится зарубежом (а так и есть при правильном разделении). Но возможно я что-то недопонял.
Edit: В том же XHTTP хотели (а возможно уже) добавить разделение ещё по времени, т. е. входящее и исходящее соединения начинаются в разное время.
Я думаю, что все равно можно. Если сервис знает, что передал какой-то объём трафика с выходного адреса VPN, а ТСПУ - что такой объём трафика передан в то же время с входного адреса VPN, то не важно, есть ли там промежуточные соединения или нет.
Но при разделении upstream/downstream такой связки банально же не будет.
У вас все исходящие запросы идут через одно соединение, а все входящие - через другое. Внутри соединения ТСПУ взглянуть не сможет, поскольку всё зашифровано. Одно дело, если просто каскад - тогда очень легко, поскольку там российский сервер сначала получает X байт от клиента, передает их же зарубежному серверу, затем получает Y байт от того же зарубежного сервера и передаёт эти же Y байт сразу обратно клиенту. Но при разделении трафика на up/down у вас передаётся X байт на один VPS, а Y байт приходят от совсем другого. И если ещё эти соединения в разное время начинать, то будет непонятно, связаны ли эти соединения вообще друг с другом, особенно если правильно настроить настройки XMUX.
можно, приложение shelter называется
А если наоборот сделать? Прокси и, например браузер + ютуб в тот же shelter запихнуть, программы в основном пространстве увидят, что впн поднят?
Если честно, я бы не сливал адрес ТСПУ вообще. При долгой корреляции трафика связать и выявить туннель всё равно получится. Даже с рандомизацией и т.д просто потребуется больше времени на анализ.
Только я не понимаю как с прокси внутри приложений, как-будто шпион не может влиять и генерировать мусорный трафик с уникальным паттерном. Он же не может условный прокси в телеграме заставить начать генерировать трафик.. Могу ошибаться.
Сами разработчики Xray, кстати, говорят, что с временем ровно наоборот случится:
из https://github.com/XTLS/Xray-core/discussions/4113#discussioncomment-11468947
Ну, ТСПУ и так может увидеть входной IP цепочки и IP самого клиента. А выходной IP не будет палиться, если с него в российские сервисы не стучать. Но тут ключевое слово, что может, будет ли, не знаю, может быть. Хотя, если он выстроит схему с RU клиент → RU узел → Зарубежный узел, то в целом входящее соединение может палить. Но это всё теория, сам не уверен.
Речь идёт о том, что условный Telegram подключится к локальному прокси с поддержкой аутентификации, который запущен с клиента Xray/sing-box/т. д. (без режима VPN/TUN). Но оказывается, что аутентификация SOCKS происходит в незашифрованном виде, поэтому его можно легко палить. Этот вариант в целом отпадает уже, если я всё правильно понял.
Имхо, раз цензоры борются с впн на мобильных устройствах, то один из выходов - отказаться там от впн. Вместо туннеля использовать https-прокси на 443 порту c авторизацией. А прокси поднимать не на самом устройстве, а на сервере. Запретить там по geoip все ру сервисы. На мобильном устройстве тогда не нужны никакие прокси/впн клиенты. Адрес и логин-пароль прокси задается в настройках конкретного приложения, будь то тг или браузер (НЕдефолтный). Т.к. с этого браузера не откроется ни один ру сервис, использовать для них 2ой, дефолтный, без прокси. Либо приложения, которые идут в директ. Что увидит условный шпион? Впн отключен, прокси на локалхост не найден, чекеры возвращают чистый ip. Уже отпадает часть уязвимостей. И не требуется ни отказываться от ру сервисов, ни таскать с собой 2ой тел.