Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 111
Закреплённые комментарии
Прокси здесь особо не причем. Проблема была в TLS-финегрпринте, с который Telegram подключался к прокси, то есть проблема на клиенте. Будем надеяться, что в ближайших обновлениях клиента все снова заработает.
Работало оно странно, потому что блокировка не очень детерминированая: подозрительный трафик определялся сразу, но пропускалось несколько соединений, прежде чем IP-адрес отлетал в бан.
Я понимаю, что время тревожное, но как было бы здорово, если бы авторы статей поэкономили яркие формулировки. Не переживайте, в будущем еще пригодятся.
Просмотр TCP dump дал понять, что ТСПУ массово высылают TCP RST от имени клиента. Говорят что блокируют по fingerprint клиента telegram, только вот на втором сервере из той же AS перестал работать outline (shadowsocks) с такими же симптомами (вроде как соединение есть, но по факту не работает и в дампе RST.
При этом различные UDP протоколы работают так, будто ничего не происходит. Ох зря я это написал, сейчас в минусах утопят
Если интересуют технические подробности, то разработчики Telegram налажали в коде генерации TLS-расширения encrypted_client_hello:
Telegram/SourceFiles/mtproto/details/mtproto_tls_socket.cpp
StartPermutationElement(); {
S("\xfe\x02"_q); // <--- id расширения должно быть 0xEF0D вместо 0xFE02
OpenScope();
S("\x00\x00\x01\x00\x01"_q);
R(1);
S("\x00\x20"_q);
R(20); // <--- перепутали 20 и 0x20, ну бывает
OpenScope();
E();
CloseScope();
CloseScope();
}Из-за подобных косяков оно легко определяется. Может быть, это не единственный косяк у них, вызывающий явные подозрения у фильтрующего оборудования.
Pull Request для исправления есть, надеюсь что его быстро примут и обновят клиент.
Основная версия, обсуждаемая в сообществе - внедрение обновлённых механизмов DPI, способных выявлять трафик, маскируемый под TLS (в частности, Fake-TLS).
Видимо обновили ПО
Это VAS Experts. Если я ничего не путаю, ТСПУ делают RDP.RU. У них там система экофильтров и ecoDPI, так что...... немного не в тему.
Общаются ли эти компании, не знаю. Казалось бы, они конкуренты.
у них там "зоопарк" из 4х платформ? и на каждой свой проприетарный софт крутится?
Старые песни о главном - 29 марта 2018 г. - устарело
Положительное заключение Роскомнадзора получили девять программных продуктов для фильтрации трафика (UBIC, EcoFilter, “СКАТ DPI”, “Тиксен-Блокировка”, SkyDNS Zapret ISP, Carbon Reductor DPI, ZapretService и ADM Filter, “Барьер”).
Конкуренция там чисто номинальная, за бюджетные деньги. Алгоритмы обфускации развиваются медленнее, чем они пилят новые регулярки для блокировок
Да, есть проблема. Дома соединение отваливается, на мобиле работает. Веб-морда прокси при этом работает норм.
При этом какие-то запрещенные торрент-трекеры открываются, какие-то нет (rutracker уже давно какой-то полурабочий).
При этом нельзя исключить того, что блокировка идет не по причине какой-то хитрой детекции, а тупо банится все, что не похоже на сайт госуслуги ))
Скорее всего проблема в самой телеге, нужно ждать когда они пофиксят, вообще ни один режим в MTProto не работает. При этом все остальное, включая ss, так же работает. Телега могла бы просто ss интегрировать.
Комментарий из разряда "минутка юмора"
А в чем юмор, если я оказался прав? https://habr.com/ru/news/1018232/comments/#comment_29763468
На мобиле через MTProto все летает. Но несколько раз в день надо менять.
На пе ВПН с белыми списками и не икаких проблем.
Хабр, ткни меня пожалуйста, в ссылку, где можно почитать про современные префиксы - ee, ss и вот это всё.
А то я особо за МТпрото не следил и мои знания ограничиваются одним паддингом dd.
Дополнительное внимание привлекло появление обновлённого Docker-образа официального MTProto-прокси (версия 2.0beta от 1 апреля 2026 года). Пользователи уже заметили изменения
А вот тут даже я знаю, что докер-образ давно не обновлялся и отстал в своём развитии.
Есть мнение, что тесно связано с датой релиза. )
тесно связано с датой релиза. )
Если вы про 1-е апреля, то точно нет.
Когда началось, я бегло посмотрел, что стали предлагать гранды и новички отрасли. И до 01.04 точно видел МТпрото с ключами на ее..
При этом, если к ним дописать дд, то их даже форма добавления прокси не принимает, без попыток соединения. Ещё ключи у них длиннее обычного.
Хабр, ткни меня пожалуйста, в ссылку, где можно почитать про современные префиксы - ee, ss и вот это всё.
Если в общих чертах то ИИшка знает: https://www.perplexity.ai/search/sekrety-mtproxy-format-i-prefi-K2iBQp9SSHas9DC5lWjBgg
ss - такого префикса нет, думаю выше говорили про ShadowSocks
Хз, все работает на телефоне. На компе не знаю, пока не добрался до него. Да и квн есть, на всякий
Работает связка с 2 мя прокси: в телефоне + MTProto в телеге
В этот раз как-то странно оно работает. Обычно сильнее гайки затягивают на мобильном интернете, а тут наоборот на кабельном.
Пожалуй, пора переезжать из этой страны...
Прокси здесь особо не причем. Проблема была в TLS-финегрпринте, с который Telegram подключался к прокси, то есть проблема на клиенте. Будем надеяться, что в ближайших обновлениях клиента все снова заработает.
Работало оно странно, потому что блокировка не очень детерминированая: подозрительный трафик определялся сразу, но пропускалось несколько соединений, прежде чем IP-адрес отлетал в бан.
Я понимаю, что время тревожное, но как было бы здорово, если бы авторы статей поэкономили яркие формулировки. Не переживайте, в будущем еще пригодятся.
Спасибо за уточнение!
А есть какие-то позитивные ожидания, что клиент будет допилен? Ну то есть может у них тикет на это есть и он в работе, или просто ждать и надеяться?
И вообще было бы интересно узнать, откуда такая информация. Самостоятельный анализ? Краткая выжимка чьего-то анализа? Гадание на кофейной гуще? Быстрым гуглежом ничего не находится
В моем случае (Linux/Flatpak) обновление десктопного клиента до последней версии (6.7.1) пофиксило проблемы с подключением к прокси.
Не шейпят один заветный ip DC Telegram. На этом базируются все текущие методы обхода(hosts)
есть проблема на клиенте. Будем надеяться, что в ближайших обновлениях клиента все снова заработает
Если вы знаете ticket/issue/whatever, где это правится и следите, скажите: есть ли шанс, что это можно как-то бэкпортировать или добавить вручную в старые клиенты (заменить библиотеку и т.п.)?
Очень уж не хочется на свежих жручих монстров со спорным дизайном обновляться.
Раз проблема на клиенте, как вы объясните то, что есть некоторые зарубежные хостинги, развернув на которых mtproto - соединение не дропается.
Тем, что по некоторым направлениям фильтрация более строгая, а по некоторым - менее?
Притом по моим ощущениям, она выборочно включается периодически, сначала долго всё нормально, потом вдруг перестаёт нормально работать, потом через какое-то время снова всё нормально (может быть ещё зависит от того, на какой ТСПУ попадёт балансировка нагрузки или каким маршрутом трафик пойдёт).
Вообще не понимаю что они не сделают чтобы прокси работал поверх чистого https. Ну т.е. обычные GET/POST запросы, любой сертификат (хоть blabla.ru), обычные endpoint-ы (которые можно хоть через nginx проксировать) - а внутри шифрованный уже своими шифрами контент. Поставил nginx, сертификат, настроил форвардинг дальше - прокси готов. Вебмастерам можно хоть на легитимных сайтах ставить такие прокси, и никто не разберет, человек странички открывает или в телеге шарит.
Никакой DPI не отличит это от обычного серфинга. Открыли чатик - отправилось несколько GET запросов, отправили сообщение - отправился POST. Вместо этого изобрели какой-то свой транспортный протокол и пытаются выдать его за легитимный трафик.
так websocket-proxy работают
Который обращается к заблокированным IP-адресам Telegram и нативно самим клиентом не поддерживается (нужно поднимать его рядом с клиентом).
Он не позапросный, а открывает одну длинную сессию и TLS там не терминируется на стороне прокси, а пробрасывается до телеги. Все это по сигнатурам, по длительности сессий и т.п. легко вычисляется.
Нужно чтобы к примеру владелец какого-нибудь supersite.ru мог сделать у себя в конфиге что-то типа проксирования от supersite.ru/telega/* куда следует. Ключевой момент - это должно быть позапросное проксирование, без websocket/connect и прочего, как обычный web-трафик, с тем же сертификатом что остальной сайт. Телеграм по логике вполне пригоден для позапросного обращения за контентом - если бы его разработчики таким озаботились.
Для любого DPI это будет выглядить, что я просто шарюсь по supersite.ru - запросы идентичиные полностью. Еще это будет работать через любой коммерческий CDN (в т.ч. как православный российский, так и что-то типа cloudflare). И еще много чего интересного отсюда вытекает.
Запросы ну совершенно разные. Почитайте здесь же на хабре как работает dpi на 4х уровнях, что такое сигнатура ja3. Трафик который идёт от хрома очень сильно отличается от трафика, который идёт от телеграмма. Как вы хотите, в общем-то и работает mtproxy fake tsl, но о чем и написан данный пост - dpi научился его успешно дропать. Что касается "любой администратор сайта", так и сейчас настроить теле прокси делов 15 минут.
Еще раз. Ничто не мешало бы (но этого нет) телеге прикинуться хромом и отправить GET запрос за содержимым чатика или очередным видосиком куда-то на https://mysite.ru/blabla/video.mp4. Еще раз - на стороне этого сайта должен быть обычный nginx, с обычным сертификатом Lets Encrypt. Это все, что увидит DPI (хотя даже URI он не увидит). А вот то что сам контент (!) внутри GET-запроса уже будет еще раз шифрован каким-то отдельным способом и его понимать его будет только телеграм - DPI ни при каких обстоятельствах отличить не сможет.
Ещё раз. Прикинуться хромом это очень сложная задача.
Для этой цели и хромиум какой-нибудь внутрь клиента не зазорно запихать. Если другие пути очень сложны.
Суть вопроса не в этом, а в том, что телеграм в принципе не умеет позапросно работать с прокси, и шифровать не на транспортном уровне, а позапросно на уровне контента. В итоге сильно сужаются варианты заставить его работать в условиях ограничений.
А вы знаете как работает mtproto, в чем его преимущество и почему Дуров младший его изобрел? А вы предлагаете переделать телеграмм на банальный rest. На таком банальном протоколе работает Вацап и давно почивший Вайбер. Вацап к слову поддерживает тот способ прокси, о котором вы просите, из коробки. И почему же он заблокирован наглухо? Читайте матчасть. А уж встраивать целый хромиуи в телеграмм клиент - ну это вообще зло за гранью разума.
Ну так целый и не надо, достаточно netstack. Naiveproxy на этой идее основан.
Заблочить воцап было настолько легко, что там и протоколы смотреть не надо. Их прокси-сервер требовал открыть 5222 TCP в обязательном порядке и никаких нестандартных портов. Это детский сад для галочки.
Недоумения для, отмечу, что "встроенный браузер" в телеграм клиентах на всех платформах уже есть.
Прикинуться хромом это очень сложная задача.
Имитация отпечатков TLS-рукопожатия разных браузеров реализована в этой библиотеке: https://github.com/refraction-networking/utls, которая применяется, например, в Xray.
Там проблема не в JA3, а в JA4 на этапе хендшейка. Порядок cipher suites отличается от chrome кардинально и присутствует extension, которого никогда не может быть в chrome. Это надо чинить.
Телеграм по логике вполне пригоден для позапросного обращения за контентом - если бы его разработчики таким озаботились.
Ну, вообще-то не очень. Там свой сессионный протокол, который поддерживает подтверждения доставки и держит постоянное соединение, то есть концептуально гораздо лучше кривой модели Web’а и Websockets. Это я вам авторитетно как автор статьи с критикой протокола телеги заявляю. Да, у протокола есть проблемы, но архитектурно подход лучше. Никто просто не думал, что Интернет будут принудительно переводить в режим “только HTTPS”.
Чистый https не подходит для реалтайм-доставки пушей. Вебсокеты держат постоянный tcp-коннект, но их легко спалить по длительности сессии и отсутствию типичного http-трафика (запросил html - получил картинки)
Завершил сессию на десктопном ТГ и всё теперь, QR код не генерится, смс не приходит)
При этом подключен к работающему прокси.
На десктопном уже несколько лет не приходят и не будут приходить. только мобильный официальный клиент получает смс
C android v.12.2.11 и 6.3.5 на десктопе добавили поддержку passkeys.
Почту не успели подвязать для получения кодов? Не так давно предупреждали, что смс больше не будут рабочим способом логина, как это уже случилось с Ватсапом и Сигналом
подключитесь к работающему впн, так qr-код сработает
Пока у РКН не получилось побороть Телеграм ;) Всё отлично работает без КВНов через публичный прокси, оператор Ростелеком, СПб.
VK Play Игровой центр вчера попутно поломали , авторизация сбрасывается до запуска игры или уже в самом клиенте пишет что неверный логин\пароль .
На самом сайте игры и Вконтакте тоже разлогинило .
Работает в зависимости от прошивки
Вместо этих паразитных блокировок лучше бы чем-то полезным занялись, а не портили жизнь людям
Честно говоря, даже обидно, что единственное, что наши затонекаклохи больмень осилили из аналоговнетов создать - это блокировки интернета)))
Были б еще мозги, да с таким рвением - за более чем 10 лет могли бы уже и заводов с кремнием понастроить, и автопром поднять, и много чего еще.
Но мозгов хватило только на одно направление из тысяч возможных, да и то, долгосрочный эффект от этого прям вот вообще сомнителен...
так нет никакой долгосрочности планирования. в ближайшее время что-то они ожидают, поэтому последние месяца столько всего придумали. как сторонний наблюдатель мы не можем оценить содержимое зашифрованного пакета, но можем оценить интенсивность и размер, так и тут же, интенсивность возросла. ждут чего-то. что именно-хз
пока тебе лично в окно ракета или дрон не залетит ты не поймешь чего в данный момент происходит
Все бы замечательно, да только дронам эти блокировки, судя по всему, летать вообще никак не мешают. Тем более, что ими явно не через телегу или видосик на ютубе управляют =)))))
Зато по экономике это дерьмо куда сильнее бьет. Впрочем затонекаклохам на это пофигу, эффект от этого будет только в будущем, а им на него вообще начхать, у них итак все хорошо.
Просмотр TCP dump дал понять, что ТСПУ массово высылают TCP RST от имени клиента. Говорят что блокируют по fingerprint клиента telegram, только вот на втором сервере из той же AS перестал работать outline (shadowsocks) с такими же симптомами (вроде как соединение есть, но по факту не работает и в дампе RST.
При этом различные UDP протоколы работают так, будто ничего не происходит. Ох зря я это написал, сейчас в минусах утопят
А если использовать DROP на RST пакеты?
В теории можно, RST от DPI можно отличить от здоровых (TTL, время прилета), но по факту может получится такое, что будет кучу зависших соединений и придется руками чистить (а если забудешь почистить, то уже хостер может сервер тормознуть, ибо в ToS есть лимит на количество соединений). Я помню через conntrack глянул, ранее было по 50-80 соединений вечером, когда все сидят. А когда мне написали, что с прокси что-то не так, увидел 1500+. Пересоздал прокси, думал слили в паблик. Но когда с одного клиента набрал 120, понял откуда 1,5к было. Вообще странно, что при фильтре на установленные соединения столько выпадает, когда вроде как RST был отправлен и надо прекращать.
Наверное алгоритм у прокси чем-то на brutal у hysteria похож (что в свою сторону лишнее палево), но в случае TCP это уже работает больше, как SYN флуд для самого сервера.
Подтверждаю. Вижу аномальное завершение сессий с RST от клиента на своей проксе.
То есть похоже не на блокировку по IP/домену, а на DPI по сигнатурам трафика. Возможно, shadowsocks попадает под те же эвристики, поэтому ловит такие же RST.
Понять бы как теперь это пофиксить.
Скорее всего сейчас сезон охоты на TCP протоколы, в итоге режут все то, что хоть как-то отличается от нормального TLS трафика.
Из каждого утюга говорят, что надо vless ставить, а потом делают фатальные ошибки, вроде не 443 порта и домена, который ну никак не может в Нидерландах/Финляндии быть))
В итоге сижу с WG, на него ноль жалоб. В крайнем случае хватает клиент с обфускацией handshake пакетов поставить. Учитывая всю ситуацию, выкорчевал все от 3x-ui с сервера, xray и позакрывал порты. Просто мне рассказывали историю, как чувак поднял у 62yun vless, в итоге на следующий день бан IP (даже SSH не работает) при двух пользователях.
Попробуй отключить проксю, мне это помогло оживить оутлайн на одном из серверов
И Павел Дуров такой: "Помощь близко! Скоро вернётся кончающий баклажан, плюс в продажу поступила новая партия нарисованных шапок!"
Для братьев Дуровых борьба с телеграмом - это челлендж(для одного PR для другого технический), но не долг перед бывшими согражданами - он проживут успешно и без российских телеграмм премиумов
У Дурова другая забава. Двумя днями ранее попап выскочил: “У вас последняя возможность купить премиум на тг”. По большой скидке, аж на два года. Учитывая все обстоятельства даже не знаю, или это жест доброй воли, или попытались нажиться впрок на тех, кто потом не сможет даже попользоваться премиумом.
Было вчера проседание минут 20, подобрал новый прокси и пока работает.
Настроено одновременно dd и ee, работает точно лучше, чем просто ee (независимо от того к dd или ee подключен сейчас)
Настроено одновременно dd и ee, работает точно лучше, чем просто ee
А как это так?
У меня своего МТпрото нет, я попробовал пару бесплатных (тормозных). Если ключ начинается с ее, то дд к нему дописать нельзя.
Там даже просто форма добавления прокси такое не принимает. Соединяться, понятно, не пытается.
Эти ключи даже выглядят по-разному - с ее.. заметно длиннее.
присоединяюсь к вопросу - как получилось так настроить? Можете показать конфиг?
[general]
use_middle_proxy = false
[general.modes]
classic = false
secure = true
tls = true
[server.api]
enabled = false
[censorship]
tls_domain = "rkn.gov.ru"
mask = true
mask_port = 443
mask_host = "rkn.gov.ru"
fake_cert_len = 2048
[access.users]
user0 = "00000000000000000000000000000000"
user1 = "00000000000000000000000000000001"
[server]
port = 443Национальная ИТ-забава: государство тратит миллиарды на железки, чтобы мы не читали телеграм, а мы тратим свои нервы и вечера, чтобы эти железки обмануть
а мы тратим свои нервы и вечера
Гораздо больше людей тратит тоже деньги.
И вот это действительно "забава". Было бы интересно узнать, что можно было бы создать (полезного), если и те, и другие затраты просуммировать и направить их в созидательное русло, а не на покупку серверов и последующий нагрев атмосферы ими и прочими коммутаторами.
А те, "чья нога - кого надо нога", продают согражданам 3буквы. «Бизнес крутится, лавэха мутится».
те, "чья нога - кого надо нога", продают согражданам 3буквы
Отнюдь.
По-моему, за последние месяц-полтора кто только не начал этим самым торговать.
Я для себя решил сделать беглый обзор из интереса, так наткнулся на несколько предложений БТР из Дагестана. И ещё пару человек оттуда же видел, интересующихся дешёвыми выделенными серверами.
Всё случайно, специально я их не искал.
На мой взгляд, сейчас куда актуальнее озаботиться тем, чтобы не купить "три буквы от других трёх букв".
Только миллиарды это тоже мы тратим, это наши деньги.
Улыбаемся и машем.
*** наше все!
Обновил сегодня докер образ, стало хуже работать, до этого проблемы были только на мобильном, теперь и домашний периодически не может соединиться.
Если интересуют технические подробности, то разработчики Telegram налажали в коде генерации TLS-расширения encrypted_client_hello:
Telegram/SourceFiles/mtproto/details/mtproto_tls_socket.cpp
StartPermutationElement(); {
S("\xfe\x02"_q); // <--- id расширения должно быть 0xEF0D вместо 0xFE02
OpenScope();
S("\x00\x00\x01\x00\x01"_q);
R(1);
S("\x00\x20"_q);
R(20); // <--- перепутали 20 и 0x20, ну бывает
OpenScope();
E();
CloseScope();
CloseScope();
}Из-за подобных косяков оно легко определяется. Может быть, это не единственный косяк у них, вызывающий явные подозрения у фильтрующего оборудования.
Pull Request для исправления есть, надеюсь что его быстро примут и обновят клиент.
Интересно, тут надо ждать исправления от оригинального клиента Телеграм?
Или авторы форков могут внести такое исправление у себя?
Уже есть готовые решения, пока в официальный репо не смерджили, но уже сейчас можете протестировать
Было внесено в ветку dev этим коммитом, ждём теперь в проде
Я так понимаю, проблема не в прокси, а в самом клиенте? Кто может пнуть разработчиков телеграма для исследования проблемы?
Лучше б уже перешли на белые списки, меня больше напрягает не необходимость борьбы с блокировками, а постоянное переключение на ВПН/без ВПН, сказали бы - все баста, реально уже напрягает, при чем фиг угадаешь куда с ВПН, а куда без.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MTProxy и telemt массово теряют работоспособность на фоне новых DPI-фильтров