Обход dpi блокировки торрентов провайдера
Обновлено: 03.07.2024
Пессимистичные прогнозы что до внедрения так называемого суверенного интернета с использованием технологии DPI не оправдались, но радоваться пока рано. DPI по-прежнему может использоваться провайдерами для блокировки неугодных сайтов, и чтобы обойти такую блокировку, одного VPN будет недостаточно, вернее, VPN в этом случае будет бесполезен. Существует два типа DPI : пассивный и активный.
Активный банально режет пакет, не давая ему дойти до пользователя, пассивный вместо этого подменяет пакет фейковым и переадресует пользователя на страницу-заглушку.
Звучит устрашающе, но не всё так безнадежно как кажется. Сила DPI одновременно является его слабостью, если проверять все байты трафика, скорость соединения может упасть в несколько сот раз, что сделает использование интернета в принципе невозможным. Поэтому система анализа пакетов исследует только наиболее часто встречающиеся запросы, игнорируя нетипичные. На этом и основывается метод обхода DPI . Чтобы сломать DPI , достаточно изменить регистр любого символа в заголовке или добавить в него лишние пробелы.
Обход DPI на Windows, Linux и MacOS
Это консольный инструмент, чтобы его запустить, нужно открыть командную строку от имени администратора, перейти в расположение исполняемого файла и выполнить команду:
goodbyedpi.exe -1 -a
Вместо -1 можно использовать ключи -2, -3 и -4, более подробную информацию ищите на странице разработчика.
GoodbyeDPI доступна только для Windows.
Второй более удобный вариант предполагает использование утилиты GreenTunnel с графическим интерфейсом.
Обход DPI на Android
На рутированных гаджетах автор приложения рекомендует установить в настройках использование DPITunnel прокси глобально, на устройствах с root в настройках Wi-Fi или APN нужно выставить прокси с адресом 127.0.0.1 и портом, указанным в настройках приложения.
Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.
Существует два распространенных типа подключения DPI: пассивный и активный.
Пассивный DPI
Выявляем и блокируем пакеты пассивного DPI
Поддельные пакеты, формируемые DPI, легко обнаружить анализатором трафика, например, Wireshark.
Пробуем зайти на заблокированный сайт:
Рассмотрим пакет от DPI подробнее:
Активный DPI
Активный DPI — DPI, подключенный в сеть провайдера привычным образом, как и любое другое сетевое устройство. Провайдер настраивает маршрутизацию так, чтобы DPI получал трафик от пользователей к заблокированным IP-адресам или доменам, а DPI уже принимает решение о пропуске или блокировке трафика. Активный DPI может проверять как исходящий, так и входящий трафик, однако, если провайдер применяет DPI только для блокирования сайтов из реестра, чаще всего его настраивают на проверку только исходящего трафика.
Системы DPI разработаны таким образом, чтобы обрабатывать трафик с максимально возможной скоростью, исследуя только самые популярные и игнорируя нетипичные запросы, даже если они полностью соответствуют стандарту.
OWS — опциональный один или несколько символов пробела или табуляции, SP — одинарный символ пробела, HTAB — табуляция, CRLF — перенос строки и возврат каретки (\r\n).
Это значит, что запрос ниже полностью соответствует стандарту, его должны принять многие веб-серверы, придерживающиеся стандарта:
На деле же, многие веб-серверы не любят символ табуляции в качестве разделителя, хотя подавляющее большинство серверов нормально обрабатывает и отсутствие пробелов между двоеточием в заголовках, и множество пробелов.
Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.
Этой рекомендации придерживаются далеко не все веб-серверы. Из-за двух пробелов между методом и путем ломаются некоторые сайты.
Спускаемся на уровень TCP
Пакет 1:
Пакет 2:
В настоящий момент, в РФ DPI устанавливают и у конечных провайдеров, и на каналах транзитного трафика. Бывают случаи, когда одним способом можно обойти DPI вашего провайдера, но вы видите заглушку транзитного провайдера. В таких случаях нужно комбинировать все доступные способы.
Программа для обхода DPI
Эффективное проксирование для обхода блокировок по IP
В случае блокировок по IP-адресу, провайдеры фильтруют только исходящие запросы на IP-адреса из реестра, но не входящие пакеты с этих адресов.
Программа ReQrypt работает как эффективный прокси-сервер: исходящие от клиента пакеты отправляются на сервер ReQrypt в зашифрованном виде, сервер ReQrypt пересылает их серверу назначения с подменой исходящего IP-адреса на клиентский, сервер назначения отвечает клиенту напрямую, минуя ReQrypt.
Долгое время разработка была заморожена из-за того, что автор не мог найти сервер с возможностью спуфинга. Спуфинг IP-адресов часто используется для амплификации атак через DNS, NNTP и другие протоколы, из-за чего он запрещен у подавляющего большинства провайдеров. Но сервер все-таки был найден, хоть и не самый удачный. Разработка продолжается.
Заключение и TL;DR
GoodbyeDPI — программа под Windows, позволяющая обходить пассивные и активные DPI. Просто скачайте и запустите ее, и заблокированные сайты станут снова доступны.
Для Linux есть аналогичная программа — zapret.
Используйте кроссплатформенную программу ReQrypt, если ваш провайдер блокирует сайты по IP-адресу.
Определить тип блокировки сайтов можно программой Blockcheck. Если в тестах DPI вы видите, что сайты открываются, или видите строку «обнаружен пассивный DPI», то GoodbyeDPI вам поможет. Если нет, используйте ReQrypt.
Долгое время я терпел ограничения РосКомНадзора и соответствующие действия провайдеров по различным ограничениям доступа к сайтам - но с определённого момента устал, и начал думать как бы сделать так, чтобы было и удобно, и быстро, и при этом с минимумом заморочек после настройки. Хочу оговориться, что цель анонимизации не ставилась.
Какие вообще уже есть методы решения?
Вообще, эта проблема имеет несколько решений. Кратко перечислю самые известные и их минусы:
Заворачивание всего трафика в VPN-туннель либо какой-то прокси - как вариант, TOR. В случае с TOR-ом о скорости можно забыть, в остальных случаях скорость и время отклика также страдают, поскольку необходимо проксировать через удалённый сервер. Поскольку РосКомНадзор у нас действует на всей территории России, получается что весь трафик придётся проксировать через зарубежный сервер, а значит время отклика (или "пинг") будет сильно страдать. Сразу отрезается весь пласт, например, игровых приложений.
"Гибридный" вариант с использованием списков. Основной трафик идёт напрямую, но часть IP-адресов перенаправляются через VPN/прокси/TOR. Списки можно забирать, например, отсюда. Минусы - приходится периодически обновлять эти списки, и какими бы они не были актуальными есть вероятность всё же наткнуться на заблокированный сайт. На самом деле, один из лучших способов для комфортного пользования интернетом без ограничений. Но можно лучше!
Использование "чёрной магии", связанной с особенностями применяемого провайдерами DPI-софта. Я, в общем и целом, про "дыры" в обработке трафика (например, блокирование только на уровне DNS, или пропуск необычно сформированных пакетов), и, в частности, про GoodbyeDPI уважаемого @ValdikSS. Самый большой минус - работает далеко не везде. И чем дальше, тем хуже работает. Рост вычислительных мощностей скорее упрощает жизнь провайдерам, чем нам в этом вопросе.
. и наконец, использование DPI для обхода DPI! На самом деле этот способ является подвариантом "гибридного", но безо всяких списков. Мы анализируем пришедшие пакеты от провайдера, делаем вывод, заблокировал ли он нам что-то, и на этом основании либо пускаем дальше трафик к запросившему, либо перенаправляем трафик через VPN/прокси/TOR. Всё ещё требует конфигурации VPN/прокси/TOR, но уже не требует никаких списков, а также позволяет принимать решения на основании теоретически сколь угодно сложной логики!
Про последний способ дальше и пойдёт речь. И поможет нам в этом NGINX.
Так ведь NGINX - это веб-сервер, а не инструмент для DPI?
И самым лучшим расширением NGINX является проект OpenResty - который добавляет практически ко всем аспектам NGINX-а поддержку Lua.
Мне могут сейчас возразить, что современный NGINX поддерживает "изкаробки" возможность скриптинга на JavaScript (njs), и будет прав, но, во-первых, OpenResty гораздо более развитый проект и его API имеет гораздо больше возможностей, а во-вторых, OpenResty использует LuaJit с поддержкой FFI, что позволяет вызывать C-методы напрямую из Lua-мира - и это создаёт такую возможность для расширения, которая njs даже и не снилась. Во всяком случае пока что.
При этом, NGINX имеет возможность проксировать и "сырой" TCP-трафик (теоретически и UDP тоже, но я реализовал "DPI" только TCP).
О деталях реализации
Конкретно у меня по причине отсутствия кабельного интернета дома сейчас используется 4G-интернет от Мегафона, поэтому описание будет происходить с точки зрения именно Мегафона.
Подробнее как именно всё сконфигурировать будет дальше. Здесь только общее описание и логика, которой я следовал при реализации.
Прежде всего, мы поднимаем NGINX в режиме stream на каком-то порту. Пусть будет 40443. Но сам по себе nginx не знает что делать с трафиком, что туда приходит. Именно это мы и будем разруливать с помощью Lua.
Прежде всего, мы перенаправляем весь трафик с 80 и 443 порта на этот самый 40443 порт при помощи iptables и его команды REDIRECT. Эта команда интересна тем, что прописывает в свойства сокета опцию SO_ORIGINAL_DST, в которой сохраняет оригинальный IP и порт, куда пакет изначально направлялся, до того как iptables над ним зверски поиздевался, переписав destination. Кхм, я отвлёкся. Эту информацию можно извлечь при помощи getsockopt. Правда из коробки обёртки над ним не было, так что пришлось написать простенький C-модуль для nginx.
Теоретически можно было бы использовать TPROXY, и пропатчить NGINX для поддержки SO_TRANSPARENT сокетов, но хотелось не прибегать к прямому патчу исходников NGINX-а и обойтись модулями, поэтому REDIRECT.
Для этого мы вычитываем первые данные, пришедшие от клиента (вплоть до 16 кбайт, но по факту первые пакеты весьма маленькие), перенаправляем их серверу и читаем ответ от него. Если находим в нём этот редирект - это означает сразу две вещи:
Сайт блокируется, значит этот коннект надо редиректить.
Если редиректа нету, значит мы просто отправляем этот запрос дальше клиенту и дальше просто проксируем трафик, не вмешиваясь в него.
Осталось только понять, как понять, куда именно мы изначально обращались, и как получить этот сертификат.
И здесь нам поможет SNI - дело в том, что (современный, мы не говорим про эпоху IE6, она ушла и слава богу) клиент отправляет домен, к которому обращается, в составе незашифрованных данных ClientHello. Самое интересное, что эти данные умеет вычитывать даже сам NGINX из коробки - модуль ssl_preread поставляется вместе с ним. Ну а Lua-биндинги позволяют получить эту информацию и для наших целей.
И всё было бы хорошо, если бы не TLSv1.3, который всю эту историю сильно обламывает.
TLSv1.3 наносит ответный удар
Во-первых, в TLSv1.3 SNI может быть зашифрованным. Хорошая новость в том, что зашифрованный SNI не расшифрует и сам провайдер, а значит он будет блокировать любые TLS-запросы к IP точно так же. Вторая особенность в том, что сертификат сервер клиенту теперь тоже отправляет в зашифрованном виде.
Проблема усугубляется ещё и тем, что Мегафон отправляет свой сертификат как раз таки по TLSv1.3, то есть зашифрованным, в случае если клиент поддерживает TLSv1.3. А все основные браузеры сейчас его поддерживают. Проблема.
На этом этапе я уже даже думал о том, чтобы патчить ClientHello, убирая из него поддержку TLSv1.3, осуществляя по сути атаку на downgrade до TLSv1.2, но вовремя почитал описание TLSv1.3. В нём реализовано аж ДВА механизма по предотвращению подобных даунгрейдов, поэтому вариант плохой.
. И здесь приходится прибегать к экстренным мерам. На самом деле этот метод я реализовал даже первым, и он по сути и является сутью метода peek and splice у Squid-а.
Единственным минусом такого подхода является то, что в случае, если Мегафон начнёт поддерживать eSNI, то коннекты к его сайту будут проксироваться, но пока что SNI у него вполне незашифрованный. Да и, на самом деле, сертификат там самоподписанный отдаётся, так что можно и углубить проверку.
А что дальше с заблокированным трафиком-то делать?
Итак, мы понимаем, что сайт блокируется. Что делать? Лучшее и наиболее универсальное что я придумал - это SOCKS5 прокси. Протокол проще некуда, к нему есть удобная клиентская реализация, которую чуть доработать - и можно пользоваться. Вдобавок, SOCKS5 реализован в Tor и SSH. Поднять SOCKS5-сервер - дело пяти минут.
Особенности некоторых сайтов и приятный бонус
Каково же было моё удивление, когда точно такое же поведение было и через VPN. Причём, с подключением через VPN IPv4 не соединялся, а по IPv6 вполне всё работало.
Тут я вспомнил, что у SOCKS5 есть два режима подключения к удалённому хосту - по IP и по хосту. Поэтому я реализовал следующую обработку соединения (Hostname мы получаем из SNI):
direct IP => direct Hostname => socks5 IP => socks5 Hostname
С таймаутом на соединение в 2 секунды. В чём смысл? Если вдруг оказывается, что наша машина, на котором развёрнут NGINX оказывается IPv6-capable, а изначальный клиент нет, то мы сможем спроксировать трафик через IPv6, при том, что клиент будет думать что соединяется по IPv4. Аналогично и с прокси-сервером.
А что насчёт производительности?
Итак, переходим к практике - что нам для этого потребуется?
В качестве железа подойдёт почти что всё что угодно, на чем можно запустить Linux. В моём случае, я запускаю это всё на Netgear R7000 с ARM-процессором внутри, и кастомной прошивкой с версией ядра всего лишь 2.6.36. В общем и целом теоретически запустится на практически любом Linux-е с версией ядра хотя бы 2.6.32.
Поскольку решение не совсем стандартное, придётся пересобирать NGINX/OpenResty из исходников. Я успешно собирал прямо на самом роутере - занимает некоторое время, но не так чтобы бесконечное.
OpenResty - это NGINX с LuaJit и основными Lua модулями. Я скачивал релизный тарболл из их раздела загрузок.
lua-resty-openssl и его C-модуль к NGINX lua-resty-openssl-aux-module. Нужен для получения и разбора сертификатов SSL-сессий.
Мой самописный C-модуль к NGINX и Lua-биндинг lua-resty-getorigdest-module для получения информации об IP и порте того, куда изначально обращался клиент.
lua-struct для парсинга бинарных пакетов (в частности, поиска сертификата после ServerHello).
Мой форк SOCKS5 Lua-клиента lua-resty-socks5 уважаемого @starius, которому была добавлена возможность соединяться через SOCKS5 не только по хостнейму, но и по IP-адресу.
SOCKS5 прокси-сервер для проксирования заблокированного трафика - например, socks-прокси TOR-а, либо обыкновенный ssh -D . Для VPN-сервера - надо установить его на самом VPN-сервере и проксировать через него. Настройка socks-прокси выходит за рамки этой статьи.
Также я исхожу из того, что запускаете вы это на устройстве, маршрутизирующем ваш доступ к интернету - в моём случае это роутер. Оно должно завестись в том числе и на локалхосте, но для этого придётся садаптировать правила iptables. Также, исхожу из того, что трафик от клиентов приходит с br0 устройства.
Подготовка и сборка
Предполагаю, что сборку осуществляем в /home/username/build. Устанавливать будем в /opt/nginxdpi
Разархивируем тарболл openresty, делаем git clone всем указанным выше дополнениям. Для удобства переименовываем папку openresty-X.Y.Z.V в openresty.
Переходим в /home/username/build/openresty, выполняем:
./configure --prefix=/opt/nginxdpi --with-cc=gcc \
--add-module=/home/username/build/lua-resty-openssl-aux-module \
--add-module=/home/username/build/lua-resty-openssl-aux-module/stream \
--add-module=/home/username/build/lua-resty-getorigdest-module/src
Выполняем make -j4 && make install , ждём пока всё соберётся.
После сборки копируем:
Готово! Можно приступать к конфигурированию.
Конфигурация
Вся логика содержится в следующем конфигурационном файле:
Можно было бы наверное разделить lua код от конфига, но мне было немного лень =)
Замените 192.168.120.1 и 45213 на хост и порт вашего SOCKS5-сервера!
Также замените 192.168.3.1 на IP-адрес DNS-сервера, которым вы хотите резолвить хосты.
Размещаем его в /opt/nginxdpi/cfg/nginx.conf
Создаём файл /opt/nginxdpi/cfg/start.sh со следующим содержимым:
Обратите внимание, что br0 - это интерфейс локальной сети, с которого подключаются клиенты!
Даём start.sh права на выполнение chmod +x /opt/nginxdpi/cfg/start.sh , и наконец запускаем всё это добро (от рута! В принципе теоретически может заработать и без рута, но я не пробовал. ):
Что можно сделать ещё?
На самом деле есть несколько вещей, которые можно доработать, разной степени сложности.
Во-первых, как я уже писал, для того, чтобы исключить проблемы с ненужным проксированием провайдерского сайта в случае если они начнут использовать eSNI, есть смысл проверять сертификат на самоподписанность - это несложно средствами OpenSSL.
Во-вторых, пока что совершенно не поддерживается IPv6. Добавить поддержку на самом деле несложно. С другой стороны, как правило IPv6 трафик сейчас фильтруется редко (если вообще где-то фильтруется).
И в завершение.
На самом деле этот механизм можно использовать и для полноценного DPI. По сути мы получаем полноценную TCP-сессию, которую можем инспектировать "на лету" - достаточно, по сути, пропатчить pipe-функцию. С другой стороны, смысла в анализе сырых данных после завершения SSL-handshake нынче мало, а зашифрованного трафика становится только больше.
Этот же метод в принципе позволяет и записывать трафик - закон Яровой исполнять, например. Надеюсь я не открыл сейчас ящик Пандоры.
. вдруг кому-то из провайдеров этот метод позволит сэкономить на DPI-софте и уменьшить цену тарифов? Кто знает.
Обход блокировок и ограничений операторов
- Имеется в наличии "Устройство" - донор (название/наличие рут/какая ОС/тариф)
- Раздача ведется на "Устройство(а)" (ПК, смартфон, планшет, smart tv и др.)
- IMEI - уникальный номер, использующийся для идентификации в сети телефонов, спутниковых телефонов, модемов и другого оборудования, использующего сим-карту для подключения. Представляет из себя последовательность из 15 или 17 цифр. Может быть изменен.
- TTL - параметр, определяющий время жизни каждого пакета, или же число прыжков между маршрутизаторами, которое пакет может пройти. Каждый проход через маршрутизатор снижает значение на 1. При значении 0 пакет уничтожается. Значение может быть изменено в диапазон от 1 до 255.
DPI - специальная технология накопления статистики проходящего трафика, позволяющая анализировать, фильтровать, блокировать трафик. В рамках заданной темы DPI опасен тем, что несмотря на смененные emei, измененные ttl, с легкостью определяет раздаваемый трафик, p2p-трафик, после чего происходит блокировки трафика или искусственное замедление скорости. - VPN - виртуальная частная сеть, набор технологий, реализующих так называемый туннель, по которому весь наш трафик идет из точки А в точку Б. В нашем случае полезен тем, что весь трафик шифруется, за счет чего DPI технологии провайдера не видят, какой трафик мы передаем (читайте: спокойно раздаем интернет; торренты работают)
-
Самый главный из них - TTL. Как я писал выше, каждый скачек пакета через маршрутизатор уменьшает значение ttl на 1, поэтому, когда с одного устройства приходят пакеты с разными значениями ttl, это означает раздачу трафика (ваш модем, роутер, планшет и т.д. при раздаче считаются маршрутизатором, имея свой IP)
-
О: Вам необходимо сменить IMEI от смартфона или лучше от Виндофона с поддержкой 4G.
-
О: Способ смены можно найти в теме своего устройства, а IMEI взять тут.
-
О: Для этого необходимо зафиксировать ttl на раздающем(доноре) или менять ttl на принимающих устройствах.
-
О: Способ смены ttl можно найти в теме своего устройства, а на что лучше сменить - читаем ниже
-
О: Необходимо настроить VPN или другие сервисы по шифрованию трафика.
-
О: Заходим в раздел Инструкции и решения для обхода блокировки p2p-трафика.
Чтобы сработала команда: iptables -t mangle -A POSTROUTING -j TTL --ttl-set 64 необходимо наличие пакетов: iptables-mod-ipopt installed и kmod-ipt-ipopt
Подборка решений для различных моделей модемов
Через терминал набрать sysctl -w net.inet.ip.ttl=65
Дабы не вызывать подозрений, изменять IMEI желательно на IMEI от Windows Phone (Важно! Изменять на IMEI от Windows Phone нужно только в том случае, если раздача ведется на ПК с ОС Windows или XBOX. Во всех других случаях нужно менять на IMEI от телефона на Android. Внимание! Если вы взяли IMEI от Windows Phone, фиксировать TTL нужно на значение 128, если IMEI от телефона Android, то фиксировать нужно на значении 64! )
В основном, инструкции по смене IMEI есть в темах большинства устройств, но если нет, идем сюда Хочу сменить IMEI (полезно изучить всем)
Проверить свежесгенерированный IMEI на реальное существование можно здесь
Инструкции и решения для обхода блокировки p2p-трафика С тем, что такое DPI, кратко вы можете ознакомиться здесь. Более подробно можно прочитать тут. Далее будут представлены инструменты для разных платформ.Отлично работающая программа, позволяющая обходить большинство известных систем DPI, как пассивного типа, так и активного.
Описание и инструкция по настройке
Последнюю версию всегда можно скачать здесь Еще одна утилита активного обхода DPI с графическим интерфейсом, использующая для обхода локальный прокси-сервер на вашем ПК.
Описание и настройка
WIKI по PowerTunnel
Последняя версия всегда здесь Аналог GoodbyeDPI под любые Linux системы с systemd, а так же под OpenWRT.
Описание, настройка и установка
А еще от всего сообщества,да и от всех пользователей модемов и роутеров в мире(и это не преувеличение) хочу поблагодарить Рустама(RUST3028) за весь его труд,мне не хватит жизни чтобы все перечислить.
Спасибо Рустам и всего Вам наилучшего. Куратор темы - Kodekc. По вопросам наполнения шапки обращайтесь в QMS
Активность в теме Обход ограничений раздачи мобильного интернета YOTA
2. В теме не обсуждаются:
-другие операторы
-вопросы по конкретным устройствам, в частности - модемам и роутерам. Ищите тематические форумы и задавайте вопросы там
3. Большая просьба не флудить в теме, рассказывая "а вот у меня. ". Если очень сильно хотите поделиться опытом - указывайте подробно устройства, механизм обхода ограничений, что произошло и т.д. Кураторы и модераторы оставляют за собой право удалять посты, которые кажутся им флудом, без объяснения причин.
4. Обратите внимание на верхнюю часть шапки: Yota как оператор, торренты и VPN обсуждаются в других темах, имейте это в виду.
5. В 3G практически везде шейпится медиаконтент. Это значит, что Speedtest будет показывать удовлетворительную/запредельную скорость, но YouTube вы сможете смотреть в минимальном качестве. Обходить только с помощью VPN. Опираясь на существующие тарифы, весь трафик и наблюдение за ним разбиты на три группы: модем, планшет, смартфон.
В настоящий момент ограничение раздачи присутствует только на безлимитном тарифе для смартфона. Соответственно, во всех остальных случаях нет необходимости осуществлять какие-то дополнительные действия, интернет будет работать, в т.ч. при раздаче со смартфона до исчерпания пакета трафика. Инструменты и способы определения раздачи оператора Yota Практические шаги находятся под спойлерами ниже, здесь только теория
Вся информация актуальна для любого региона, т.к. анализ производится на крупных магистральных серверах, настройки которых идентичны и обновляются параллельно
- Первый и самый очевидный анализируемый параметр- TTL. Пакеты с разным ttl от одного устройства в одной сессии=раздача.
- IMEI. Так как используется тариф для смартфона- оператор ожидает увидеть именно его, и imei на раздающем устройстве должен быть от смартфона. Для дополнительной надежности можно выбрать imei от windows phone.
- Определение и анализ приложений/сервисов, которые пытаются получить доступ в сеть.
Большинство программ, приложений и сервисов, так или иначе имеющих возможность или требующих для своей работы доступ к сети, используют специфичные адреса/домены для своих запросов и/или имеют уникальные отличительные особенности структуры и состава пакетов передаваемых данных. Именно благодаря этому оператор имеет возможность, проанализировав траффик, сделать вывод о том, что происходит раздача. Например, соединение с игровыми серверами playstation или настольной версии продукта adobe явно не характерно для смартфона и срабатывает как триггер анализатора и детектора раздачи.
-использование VPN (плюс: возможность пользоваться любыми сервисами, не боясь детекта; минус: вероятно меньшая скорость соединения за счет шифрования, ограничений самого vpn сервера, а так же низкого приоритета такого трафика у оператора)
-использование firewall, разрешая доступ в сеть только браузерам/приложениям, не вызывающим подозрений (плюс: простота настройки, стабильность, минус: все специфичные приложения не имеют доступ к сети)
-использование файла hosts или аналогов (плюсов практически нет, надежность и стабильность непредсказуемы, в готовых списках много устаревших неактуальных записей)
IMEI нужно менять на IMEI от windows-фона. Таким образом трафик на windows-ресурсы с ПК не вызывает подозрений, так как примерно на те же ресурсы ходят и мобильные Windows-устройства.
Как сменить IMEI ищите в теме вашего устройства , можно так же заглянуть: Хочу сменить IMEI, сюда, сюда, сюда или сюда
Генераторы WIN IMEI: первый, второй, а так же IMEI генератор, в частности на Lumia
Если хотите в НЕпланшете тариф для планшета - берите IMEI, соответственно, от планшета: генератор IMEI от win планшета
Важно!
Сменить IMEI на iPad либо крайне проблематично, либо невозможно. Задавать в этой теме вопросы бессмысленно .
Т. к. Xposed умеет только изменять все, что в пределах виртуальной машины Android, то смена IMEI модулем Xposed - есть ничто иное, как фикция. Модуль просто подменяет IMEI программам, которые запрашивают его. При этом, к оператору уходит обычный IMEI, т. к. сеть работает на гораздо более низком уровне.
Несколько слов о смене IMEI на различных устройствах
Читайте также: