Обход замедления Telegram

[kilcha]

Так уж совпало, что телеграм мне стал нужнее некуда, хотя ранее до замедления я не пользовался им так частно (иронично). Я максимально грубо накидал для себя рабочий вариант обхода для телеграма и сделал для себя интересное открытие. Оказывается MTProto это не только UDP, хотя мне почему-то казалось иначе. Я накидал рабочую стратегию для сообщений, но медия почему-то не грузиться. Неужели в телеграме медия работает как-то по другому или моя стратегия просто не пашет толком? Вообще изначально стратегия была только с одним фейком, но была проблема. Сначала все работало, а потом спустя время телеграм начал люто тупить и даже сообщения перестали нормально загружаться с медия. Я подумал вообще докинуть в payload также unknown, чтобы на всякий все перебросить и это вроде как мне помогло, но вроде и не помогло. Ещё более странно, что медиафайлы (причем любые, аватарки те же), тупо не грузяться. Пробовал также добавлять туда айпишники телеграмма, но мне кажется, что это бессмысленно, так как итак итак этот обход работает исключельно на этом протоколе и нет особого смысла прописывать ipset и тем более hostlist. В данный момент с этим профилем у меня телеграм грузит сообщения намного быстрее, чем без него и это уже прогресс. Буду рад каким-нибудь советам или просто обсудить как можно починить сраную телегу, я уже задолбался ночами не спать из-за того, что я не могу картинки смотреть и слушать голосовухи.

--name=Telegram
--filter-tcp=80,88,443,8443,5222
--filter-l7=mtproto
--payload=mtproto_initial
--lua-desync=fake:blob=stun:tcp_ts=-600000:repeats=6
--lua-desync=fake:blob=tls_4pda:tcp_ts=-600000:repeats=6
--lua-desync=fake:blob=tls_max:tcp_ts=-600000:repeats=6
--new

[kilcha]

Короче, для тех, кому надо, нашел более менее рабочий обход телеги для меого провайдера. Кому-то поможет, кому-то нет. Перед тем, как использовать, нужно сохранить ipset.

91.108.56.0/22
91.108.4.0/22
91.108.8.0/22
91.108.16.0/22
91.108.12.0/22
149.154.160.0/20
91.105.192.0/23
91.108.20.0/22
185.76.151.0/24
2001:b28:f23d::/48
2001:b28:f23f::/48
2001:67c:4e8::/48
2001:b28:f23c::/48
2a0a:f280::/32

Сохранил в файле zapret-ip-telegram.txt и закинул в папку самого запрета, где лежат все листы.
Саму же стратегию можно дополнить этим, чтобы телеграм заработал.

--name=Telegram                                                        
--filter-tcp=80,443,8888
--ipset=/opt/zapret2/ipset/zapret-ip-telegram.txt
--filter-l7=mtproto,unknown
--payload=mtproto_initial,unknown
--out-range=-d10
--conntrack-timeout=1200
--lua-desync=fake:blob=0x00000000:ip_ttl=5:tcp_md5
--lua-desync=split:pos=8
--new

[raidfb]

Прошу помочь с настройкой

Создал файл /opt/zapret2/ipset/zapret-ip-telegram.txt и поместил туда те IP-адреса, которые вы написали.

Затем добавил в уже существующую рабочую стратегию для ютуба в конец:

--name=Telegram                                                        
--filter-tcp=80,443,8888
--ipset=/opt/zapret2/ipset/zapret-ip-telegram.txt
--filter-l7=mtproto,unknown
--payload=mtproto_initial,unknown
--out-range=-d10
--conntrack-timeout=1200
--lua-desync=fake:blob=0x00000000:ip_ttl=5:tcp_md5
--lua-desync=split:pos=8
--new

Не заработало. Более того, перестала работать стратегия под ютуб.

В процессе запуска запрета, на этапе select filtering выбираю none.

[kilcha]

У меня ошибка с splitом. Убери строку --lua-desync=split:pos=8, из-за нее весь запрет встает, это моя ошибка.

[bol-van]

Нет смысла делать --payload unknown, когда в fake нет standard payload фильтра. Пропускаем то, что будет все равно отсечено с повышенным расходом cpu. В ipset тоже большого смысла нет, потому что mtproto_initial надежно отсекает протокол. А unknown все равно не работает

[kilcha]

@bol-van Исходил из логики, что DPI все равно распознает трафик для телеграма и замедление все равно работает. Что с unknown, что без, телеграм все равно работает скудно. В плане медия. Получается, что мне надо применять просто другие методы дурения, если не работает должным образом?

[bol-van]

Телегу замедляют по IP, дурение DPI не поможет

[kilcha]

--filter-tcp=80,443,8888                                            
--filter-l7=mtproto                                    
--payload=mtproto_initial                                                     
--lua-desync=fake:blob=0x00000000000000000000000000000000:repeats=3
--new 

Вроде рабочий вариант для сообщений. Медия работает худо бедно, но работает.

[Hi-Angel]

Учитывая замедление по IP, вряд ли много кому помогут anti-DPI техники. Я попробовал стратегии выше — даже сообщения не грузятся. Я думаю, тем, у кого грузятся, просто повезло что провайдер решил особо не париться.

Интереснее вопрос, мне кажется — как замедление по IP реализовано и можно ли что-то с ним сделать. К примеру: если провайдер на каждое соединение сохраняет пришедшие TCP пакеты и отправляет только через какой-то таймаут (для введения задержки), возможно со стороны приложения Телеграм можно было бы попробовать создавать несколько соединений, и отправлять пакеты одновременно. Соотв. для трёх соединений от одного клиента это ускорит загрузку в три раза!

Надо как-то придумать, как это протестировать…

[bol-van]

Сохранять - это шейпинг, он ресурсозатратен. Гораздо проще вариант с троттлингом - дроп пакетов, превышающих рейт. Или просто дроп по указанной вероятности.
Предложенное требует работы от Дурова, причем совершенно бесполезной. Даже если он сделает, быстро прикроют

[Hi-Angel]

Предложенное требует работы от Дурова, причем совершенно бесполезной. Даже если он сделает, быстро прикроют

Не обязательно — по-крайней мере десктопный ТГ опенсорсный 😊 Можно было бы хотя бы создать feature request — но стоит гипотезу как-то протестировать сначала…

[bol-van]

Не все можно такими топорными методами масштабировать

[Hi-Angel]

Гораздо проще вариант с троттлингом - дроп пакетов, превышающих рейт. Или просто дроп по указанной вероятности.

По поводу этих гипотез — наверное это можно обкостылить дублированием каждого TCP пакета по 2-3 раза через zapret2? 🤔

[bol-van]

Если там не тупой вероятностный стейтлесс, то репиты будут точно так же дропнуты и тоже будут считаться в бюджет. Проходимость полезной нагрузки упадет во столько раз, сколько будет дупов

[MagilaWEB]

В Telegram установка соединения происходит через протокол MTProto поверх HTTPS, следственно порты TCP 443 (основной), 80, 5222 которые необходимы для соединение с серверами Telegram для начала звонка, обмена метаданными, управления.

Так же для определение публичных IP и портов устройств для попытки установки прямого соединения применяется STUN (для P2P-сессий) в основном 3478, 5349 здесь же используются рандомно порты 49152-65535, обычно это исходящий трафик для передачи медиа данных (голос/видео).

Ещё стоить помнить о TURN (ретрансляция), предпочтительно используется для него UDP но так же TCP, TLS вполне возможны, это нужно для пересылки медиатрафика, если прямое P2P невозможно. Для групповых звонков — обязательно.
работает это по портам 3478, 5349, 443, самое главное это UDP соединения которые рандомные, ясны их приделы от 30000 до 40000, возможны и свыше 40000 до 50000 но на практике не удалось определить их занятость Telegram.

Следственно непосредственно RTP/Media по протоколу SRTP/SRTCP который и является для передачи зашифрованного аудио и видео работает по UDP рандомно на портах от 49152 до 65535.

Ну и главное самое что тут есть, это собственный протокол MTProto 2.0 от Telegram для обмена ключами и шифрования, без него групповые голосовые каналы не будут работать, работает он в диапазоне 30000 до 40000 а так же для личных звонков применяется порт 1400.

Вижу используете порт 8888 но он не применяется, он возможен только в двух случаях: либо при использовании MTProxy (часто ставят на 8888 для обхода блокировок), либо при кастомных настройках транспорта через библиотеки. Сами серверы Telegram на 8888 не отвечают, 88 тоже не используется.

Вообще можете забыть про обход через zapret, полноценный доступ получить более не возможно, как ранее ответили Телегу замедляют по IP, дурение DPI не поможет.

Используйте vpn или proxy.

[Hi-Angel]

Для записи: MTProto сам по себе и так маскируется (насколько понимаю, под https трафик), из документации:

MTProxy allows users to circumvent internet censorship that restricts Telegram access in certain regions. It does so by masking Telegram's IP and obfuscating user traffic, making it significantly harder for ISPs and governments to detect outgoing connections pointing to Telegram servers.

По идее, если используется MTProto прокси, никаких действий с Zapret не нужно.

[bol-van]

Если нет прокси, он без всяких tls и маскировки гонит по tcp mtproto на подсети телеги.
С mtproto прокси поддерживается fake tls, где создается видимость handshake при правильном ключе, а при неправильном - tcp проксируется указанный хост как в xray reality

[kilcha]

@bol-van Есть вообще смысл пытаться через zapret2 ускорить телегу?

[bol-van]

Нет

[bol-van]

Напрямую там нет волшебных битов, но если выполнить AES, то они появляются

[Hi-Angel]

Мелкая находка, которой решил поделиться — поскольку у нас ситуация с высокой задержкой, имеет смысл заменить TCP congestion алгоритм с дефолтного cubic на какой-то более подходящий для таких ситуаций — либо bbr, либо hybla.

У себя на ноуте сейчас тестирую hybla.

Мне трудно оценить улучшение — пробую запускать wrk -t1 -d1m -c1 --latency https://web.telegram.org (что, как я понял по ману, в рамках одного keep-alive соединения отправляет множество запросов), но результаты слишком варьируются для каких-то выводов…

Но чисто логически, мы действительно для ситуаций с троттлингом соединений хотим либо bbr, либо hybla, поэтому рекомендую их включить в системе.

Не знаю как под виндой или Маком — под Линуксом подгружаете драйвер алгоритма sudo modprobe tcp_hybla tcp_bbr, и затем переключаемся, напр. sudo sysctl -w net.ipv4.tcp_congestion_control=bbr.

UPD: так же вместе с bbr (на котором я в итоге остановился) желательно использовать алгоритм очереди fq вместо дефолтного fq_codel, сиречь: sudo sysctl -w net.core.default_qdisc=fq.

[bol-van]

На новых билдах вин 11 тоже есть bbr. netsh int tcp set supplemental template=internet congestionprovider=BBR

Не лишним будет здесь заметить, что на роутерах это работать не будет.
congestion alg относится к tcp endpoint-ам, на проходящий трафик он не влияет

[Pointoflook]

куда скачивать, что вставлять, что скачивать и где, ничего не понятно

[Nersdfast]

А ватсап, там тоже медиа перестали грузиться, там тоже нельзя починить загрузку медиа через Zapret?

[Hi-Angel]

Надо смотреть в табе "Network" (по F12 в браузере), реквесты на какие домены валятся, и пробовать менять стратегии.

Я не использую Whatsapp, поэтому не могу утверждать наверняка, но я сомневаюсь что он блокируется по IP.

[MagilaWEB]

В большинстве провайдеров не то ни другое обойти через zapret больше нельзя, блок по ip.

Реч о telegram и WhatsApp.

[Nersdfast]

В WhatsApp тоже медиа по ip блочат? это точно?

[Dzhake]

Может реально ли с помощью zapret2 обойти блокировку прокси, и через прокси зайти в телеграм? Или прокси тоже по ip блокируются?

[Hi-Angel]

Прокси сам себе «zapret» (по-крайней мере MTProto). Они маскируются под другой валидный трафик, добавлять сверху ничего не нужно.

Единственное, там в маскировке был найден косяк, пофиксенный в последних выпущенных версиях ТГ — рекомендую обновиться.

[momentics]

Попробуйте трафик морфер https://github.com/momentics/GhostWire
предназначено для корпоративных случаев, но должно помогать и тут

[PasaOpasen]

чел, ты красавчик!!!!