Comments 212
Устаревший проект, если нужен контейнер, работающий под ключ, то вот: https://github.com/An0nX/telemt-docker. Не только по tls фейкует, но при заходе через него со sni сайта, под который мимикрирует ведет себя как сервер этого сайта проксируя чеоез себя траффик. Да и контейнер в дистролесс, а апстрим вышел с месяц назад всего
Пробуем!
Всё красиво, но, для далёкого от админства сетей - не понятно. Хотелось бы приложуху с кнопокой "Сделать телеграмму хорошо".
Спасибо.
скоро появится) уверен что уже все делают это
К нарушению законодательства призываете ?
Приведите статью УК или КоаП, которая нарушается, путем реализации гражданином своих прав на поиск любой информации, гарантированных ему статьей 29 п.4 Конституции РФ, коя является высшим законом в стране
Конституции РФ, коя является высшим законом в стране
Вангую: еще немного и это станет составом статей по иноагентству, экстремизму и терроризму
Конституция? Это та, которую запретили?
а кто сказал что поиск информации это нарушение? реклама - это нарушение исходя из недавно принятого закона
Не любой. Поиск экстремистской информации с некоторых пор преследуется по закону
13.53 КоАП подойдет? Там вообще много каких свобод написано. Про мирные собрания тоже что-то было.
Конституции РФ, статья 55, пункт 3: кроет статью 29 как за нефиг делать. Ибо меру определить в других законах можно легко и непринужденно.
Да, я посмотрю на тебя как ты дойдёшь сначала до президиума верховного суда с целью отменить тебе приговор, а потом пойдёшь в Конституционный суд с просьбой отменить статью 29, который тебе скажет что твоё Конституционное право частично ограничено в соответствии с конституцией.
В этом и заключается принципиальная разница между нами. Вы считаете что даже в текущей ситуации надо бороться играя с системой-шулером на ее поле краплеными картами. Я же считаю что в текущей ситуации пистолет с одной пулей эффективнее исправляет несправедливый приговор - потому что законных способов это сделать нет, а так хотя ьы страдать из-за несправедливости не будешь.
"Нарушение законодательства" сейчас звучит как похвала для любого полезного сервиса. Если что-то не запрещено три раза за утро, значит оно не работает
Уважаемый, а почему вы зашли на ресурс во вражеской доменной зоне .com? Вам только в .рф и .ru
Для этого достаточно подписаться на указанный канал и периодически подбирать прокси из списка, имея несколько для автлпереключения при блокировках.
Там все прозрачно - просто нажать "Connect"
DPI и блокировки в России работают преимущественно на границе сети — там, где трафик уходит за рубеж
Очень сомнительное утверждение. Потому что DPI устанавливался изначально у провайдеров на границе Абонент-Интернет, а трансграничные узлы (точки обмена трафиком) до сих пор не покрыты из-за большого объёма данных. Хотя по информации от того же РКН внутри РФ VPN протоколы не блокируются. Так что надо проверять по месту.
Внутри РФ ещё как блокируется, многие мучаются, что корпоративный mTLS блочат.
Подтверждаю. Еще как блокируется.
Поэтому и говорю, что надо проверять по месту. Я письмо в РКН писал, на что они дали официальный ответ:
По вопросу предоставления перечня разрешенных VPN- протоколов. Роскомнадзор в рамках компетенции, установленной Положением о Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций, утвержденным постановлением Правительства Российской Федерации от 16.03.2009 № 228, не наделен полномочиями по ведению перечня разрешенных VPN- протоколов. В этой связи предоставить запрашиваемы сведения не представляется возможным.
Рекомендуем использовать VPN-сервисы, законодательство Российской Федерации, или организовать виртуальную частную сеть внутри территории Российской Федерации.
Специалистами Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» (подведомственный Роскомнадзору) проведен анализ сведений, изложенных в обращении. По результатам анализа установлено, что меры ограничения к указанным VPN-протоколам (я указал все, какие вспомнил) на оборудовании технических средств противодействия угрозам не осуществляются, соединения, построенные помощью VPN-протоколов внутри Российской Федерации, не ограничиваются.
Насколько это правда и можно ли их подтянуть за это не имею представления
да им соврать - что дышать
ну а что им будет за враньё-то?
Переехали в ЦОД - у нас сменился ip и l2tp теперь работает сильно с перебоями.
ТСПУ реагируют на впн внутри страны, но как-то рандомно.
Они провайдерам говорят «шоб ютуб не работал, иначе штраф. Нам пофиг что будет отломано в процессе». Формально, лично РКН, никакой из протоколов не блокирует, а что по их вине половина рунета разломана - так это же не они, это провайдеры.
Чиво-o-o? Провайдер сломал?
Они к управлению ТСПУ вообще доступа не имеют - это чёрный ящик которым чудаки из ркн рулят - вот и ломается всё подряд.
Да и YT у нас не запрещён, а намеренно сломан. Или за починку сломанного, тоже штраф?
Объясню более доходчиво: ответ РКН выше является отличном примером как нагло врать формально говоря правду. Как в старом анекдоте «бежали два бегуна: советский бегун занял второе место, а американский предпоследнее».
Чиво-o-o? Провайдер сломал?
Ну не лишено смысла. Есть версия, что провайдеры не стоят в стороне. Особенно ОПСОСы со своими неоднородными белыми списками.
чёрный ящик которым чудаки из ркн рулят
РКН ничем не рулят. Это обычная бюрократическая помойка. Непосредственным подрядчиком и исполнителем на оборудовании является ДЦОА. Странно, что реальных "героев" никто не знает в лицо.
построенные помощью VPN-протоколов внутри Российской Федерации, не ограничиваются
Это всё временно. Видно, что всё идёт к тому, что за использование ВПН скоро будут штрафовать. То есть страну превратят в новую Северную Корею. Митинги тоже Конституцией разрешены, но по факту запрещены. И это уже не изменится, как раньше (до 2022 года) уже не будет.
У меня есть письмо от прокуратуры, что Яндекс-метрика персональные данные не собирает )
Так что я бы не особо верил подобным письмам.
Тоже подтверждаю, блокируться!
Сильно по разному, у меня wireguard в пределах города работает без проблем - с мобильных провайдеров, с проводных, вот прям вообще никаких проблем. А вот на межгороде есть проблемы, но там внезапно работает pptp (пожалуйста не спрашивайте зачем и почему).
При этом из города wireguard до AWSа скорее мертв.
Мне вот больше интересно, раньше, ЦОДы выпадали из закона о блокировках, как сейчас? Точно помню, года 3-4 назад, яндекс.днс отдавал все нужные сайты т.к. не являлся провайдером и под закон не попадал.
На счет трансграничных узлов - у вас устаревшая информация.
РКН сам недавно отчитывался что ТСПУ установлен на 86-ти трансграничных узах.
Сейчас скорее всего их уже больше.
"Установили" это ввели в эксплуатацию или привезли и вкрутили в стойку?
Достоверных данных, которые можно проверить нет. Установить они могут всё, что угодно. И как угодно об этом отчитаться. Не забывайте, что РКН это обычная бюрократическая помойка, которая оправдывает своё существование выдуманными и неподтверждаемыми KPI. Фильтрация трафика неоднородна и разнится не только от региона к региону, но и от провайдера к провайдеру.
В декабре 2025 принят закон о том, что все провадйеры трансграничных каналов обязаны установить ТСПУ. Кроме того запрещены не зарегистрированные в РКН трансграничные каналы.
Дополнительно ввели обязательство установки ТСПУ влообще на всех точка обмена с каналоми более 10 Гбит (даже на внутренних и промежуточных).
Так что в самое ближайшее время будет 100% покрытие ТСПУ вообще всего трафика - и внутреннего и внешнего.
А если нарезать канал на виртуальные менее 10 гбс?
Кроме того запрещены не зарегистрированные в РКН трансграничные каналы
Они всегда были запрещены и всегда должны были регистрироваться в минкомсвязи
В декабре 2025 принят закон о том, что все провадйеры трансграничных каналов обязаны установить ТСПУ
Если быть точным, то он принят ещё в 2023 году
обязательство установки ТСПУ влообще на всех точка обмена с каналоми более 10 Гбит
пойду на 10Gbit пятипортовый tp-link попрошу ТСПУ, а то там трафик /s
Меня более другой вопрос интересует.
У меня на свитче домашней сети всего два 10 Gbit порта (а еще - 24 1 Gbit/s) и оба заняты. Мне тоже ТСПУ получать? Шумит сильно? А запитывать его через бесперебойник стойки или от штатной розетки (где скажем так не очень стабильно)?
У меня на свитче домашней сети
Почти не шутка: если у вас на свитче домашней сети есть обмен трафиком с соседом, то поскольку у вас с соседом нет лицензий на провайдерскую деятельность - то к вам нельзя поставить ТСПУ. Но вы соседом должны дотянуться до любой "реестровой" точки обмена трафиком, и уже пириться там. Через ТСПУ, разумеется.
Вопрос лишь в том, когда можно будет убрать слово "почти" и это перестанет быть шуткой...
Можно ли использовать совместно с Traefik, чтобы не занимать эксклюзивно 443 порт?
Если правильно понял, то да - просто укажите хост, который используете для маскировки
Да, пример конфига:
tcp:
routers:
proxy:
rule: "HostSNI(`1c.ru`)"
entryPoints:
- websecure
service: proxy
tls:
passthrough: true
priority: 100
catchall:
rule: "HostSNI(`*`)"
entryPoints:
- websecure
service: traefik-https
tls: {}
priority: 1
services:
proxy:
loadBalancer:
servers:
- address: "x.x.x.x:1234" # тут указывается адрес и порт куда нужно форвардить сырой tcp
traefik-https:
loadBalancer:
servers:
- address: "127.0.0.1:443" # весь остальной трафик не трогается
А если на сервере nginx с сайтом и SSL на 443, можно в нем ustream на субдомен прописать на порт контейнера? Или не будет так работать?
В случае nginx один порт может быть занят либо upstream с полным пробросом сырого tcp, либо http с терминацией TLS
Чтобы всё работало на одном порту нужно через upstream пробрасывать весь трафик с 443 порта, по sni разделять его вот так:
map $ssl_preread_server_name $upstream {
1c.ru x.x.x.x:1234;
default 127.0.0.1:1443; # порт для nginx http конфигов
}
server {
listen 443;
proxy_pass $upstream;
ssl_preread on;
}
Но в таком случае нельзя будет узнать настоящий ip адрес инициатора запроса, решается через proxy_protocol on, но сервер который принимает запросы тоже должен уметь работать с proxy_protocol (xray умеет)
В http секции все конфиги должны запускаться на 1443 порту с прокси протоколом если нужно знать настоящий айпи:
listen 1443 ssl proxy_protocol;
Попробовал применить это решение но
Если просто указать proxy_protocol в http секциях то начинаются ошибки вида:broken header: "��t�= �5�M���wv␦��F��<^��ޏ�-8� �3��)��'<n�jEz�u�(�ϴ��" while reading PROXY protocol, client: 127.0.0.1, server: 0.0.0.0:8443
Ошибки пропадают если добавить в server в stream proxy_protocol on; но это ломает работоспособность telemt. При этом в логах всё равно 127.0.0.1 и как я понял это можно решить только поменяв в логах с remote_addr на proxy_protocol_addr
Возможно ли включить proxy_protocol on; в рамках одного upstream чтобы он не задевал upstream telemt?
Я новичок в nginx, но нейронка мне посоветовала разделить server отдельно для тг и отдельно для сайтов:
stream {
preread_timeout 5s;
map $ssl_preread_server_name $backend_dispatcher {
1c.ru 127.0.0.1:10443; # Порт для Telegram
default 127.0.0.1:10444; # Порт для ваших сайтов
}
server {
listen 443;
proxy_pass $backend_dispatcher;
ssl_preread on;
proxy_connect_timeout 5s;
proxy_timeout 1h; # Телеграм любит долгие сессии
}
# Промежуточный узел для Telegram (БЕЗ proxy_protocol)
server {
listen 127.0.0.1:10443;
proxy_pass 127.0.0.1:1443; # Ваш докер
}
# Промежуточный узел для сайтов (с proxy_protocol)
server {
listen 127.0.0.1:10444;
proxy_protocol on;
proxy_pass 127.0.0.1:4443; # Внутренний порт Nginx HTTP
}
}Соответственно, в http-секциях сайтов:
listen 4443 ssl proxy_protocol;Не знаю, может быть конфиг избыточен, но как будто всё работает. Единственное, в логах telemt (использую его сейчас) не видно IP-адресов клиентов, там вместо них адрес докер-бриджа, по идее можно сделать "network_mode: host" в docker-compose.yml, но тогда будут 127.0.0.1 вместо адресов клиентов (не проверял), пока забил, в логах nginx есть айпишники, за загрузкой канала можно следить в iftop, mtg из статьи не пробовал еще.
Прошу прощения, отдельный server для телеграма не нужен, можно напрямую в map задавать порт контейнера. И у меня никак не получается получить реальные IP для сайтов, только 127.0.0.1. Реальные IP я вижу только в логах из stream, но там слишком базовая информация. И сами веб-сервисы по-прежнему не видят реальных IP.
да, SNI посылается в ClientHello, в ServerHello
грац, с помощью nginx и mask_host:mask_port смог настроить self-steal, когда на 443 и прокси, и свой сайт, под который прокси мимикрирует (не люблю чужие фейковые SNI потому что ну какой google.com на албанской впске за писят рублей)
а можешь дать минимальный пример?
nginx.conf:
stream {
# tg.mydomain.com -> 127.0.0.1:600 (на :600 MTProto proxy)
map $ssl_preread_server_name $backend {
tg.mydomain.com 127.0.0.1:600;
default 0;
}
server {
listen 443;
proxy_pass $backend;
ssl_preread on;
proxy_timeout 5m;
proxy_connect_timeout 1s;
}
}
http {
# страница tg.mydomain.com на :601 - фоллбек из MTProto
# для соединений без ключа
server {
listen 127.0.0.1:601 ssl;
server_name tg.mydomain.com;
ssl_certificate /etc/letsencrypt/live/tg.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/tg.mydomain.com/privkey.pem;
default_type text/html;
location / {
return 200 'hello world';
}
}
}telemt.toml (я без докера его использую, с докером наверн тоже можно, но надо будет порты прокидывать, чтобы 127.0.0.1:601 был изнутри него доступен):
# слушаем 600
[server]
port = 600
listen_addr_ipv4 = "127.0.0.1"
listen_addr_ipv6 = "::"
# коннекты без ключа - фоллбечим на :601
[censorship]
tls_domain = "tg.mydomain.com"
mask = true
mask_port = 601
mask_host = "127.0.0.1"
fake_cert_len = 2048А я же правильно понимаю что при такой настройке весь трафик будет сначала заворачиваться в telemt и только потом если нет ключа попадёт обратно в nginx?
Можно этого как то избежать чтобы например mydomain.com шёл сразу обрабатываться nginx как обычно а tg.mydomain.com заворачивался на telemt и потом уже telemt если не обнаружил ключ показывал mydomain.com?
Те у меня уже есть настроенный nginx который обрабатывает 2 разных домена и в зависимости от пути внутри домена отправляет трафик на разные докер контейнеры или статику в файловой системе. Я думал прикрутить 3тий поддомен чтобы через него работал telemt и можно было пользоваться телегой без включенного sing-box на телефонах. Но если весь трафик будет идти через telemt и только фолбеком попадать на основную обработку то лучше не надо.
Большое спасибо! Оттолкнувшись от сообщения @whynothacked и Вашего, я на свежекупленном VPS развернул telemt в одном контейнере, фейковый сайт в другом и поставил Nginx, который проксирует запросы к telemt и обслуживает сайт. Ещё раз благодарю!
Traefik не знаю, а через streams в Nginx довольно просто настроить.
@cyberscoper подскажите чайнику. Я правильно понимаю что нужно подключиться к VPS по SSH чем-нибудь типа Putty и там в командной строке всё это делать?
VPS есть, но уровень познаний - поставить амнезию туда.
Да там делов на три секунды:
Как я сделал (я если что не то что чайник, а прям тульский самовар - вообще не разбираюсь в этом всём от слова совсем - просто нужен стабильный тг):
- скормил эту статью gemini
- зашёл на vds по ssh
- Ctrl+C/ПКМ/Enter... Ctrl+C/ПКМ/Enter... Ctrl+C/ПКМ/Enter
- pm2 save
Руками пришлось только ссыль сформировать. Пока работает. Потестим-посмотрим
Если у вас windows 10/11, достаточно запустить командную строку cmd.exe и в ней пишете: ssh VPS_login@VPS_IP_address, потом пароль (он не будет печататься), подтвердить
Да
Все конечно замечательно, только проект не обновлялся с августа 2022г. Поэтому
Обновляйте Docker-образ (docker pull nineseconds/mtg:2)
звучит прямо-таки иронично
Устаревший проект, если нужен контейнер, работающий под ключ, то вот: https://github.com/An0nX/telemt-docker. Не только по tls фейкует, но при заходе через него со sni сайта, под который мимикрирует ведет себя как сервер этого сайта проксируя чеоез себя траффик. Да и контейнер в дистролесс, а апстрим вышел с месяц назад всего
Дельный комментарий, спасибо.
спасибо за то что упаковали!
если вы готовы - могу предложить делать образ в telemt/telemt-docker
Я автор устаревшего проекта выше. Он давно не обновлялся, потому что не было особой необходимости. mtg ведет себя точно так же, прозрачно проксирует вышестоящий домен: https://github.com/9seconds/mtg/blob/e68d0c7da53b266019d33644b902e8872c84fe32/mtglib/proxy.go#L173-L181 + https://github.com/9seconds/mtg/blob/e68d0c7da53b266019d33644b902e8872c84fe32/mtglib/proxy.go#L263-L287
Спасибо вам за mtg, в прошлый период блокировок Телеграма он мне здорово помог и понравился больше аналогов.
Он давно не обновлялся, потому что не было особой необходимости
А https://github.com/9seconds/mtg/issues/310 не является существенной проблемой?
Спасибо. Вы совершенно правы. В ближайшее время все обновлю и актуализирую. Тот проект, про который втайне надеешься, что он уже не будет актуальным.
Все причесал, пыль сдул, в порядок привел. Проблема выше оказалась не проблемой.
Подскажите, новый релиз как-то влияет на работу/стабильность прокси? Поднял, попробовал, пока ощущения остались смешанные - что-то стало работать лучше (кружочки, например, видео), что-то хуже (фото), что-то совсем отвалилось (стикеры). Можно ли какие-то флаги запуска подергать? Сильно ли влияет домен, под который маскируешься?
tl;dr - нет, и с этим, похоже, придется жить. Оно должно примерно одинаково работать во всех прокси с direct-режимом.
Давайте теперь чуточку развернутее отвечу.
Так получилось, что MTPROTO-proxy работают в двух режимах. Неофициально они называются direct и adtag.
Изначально был только direct-режим. Грубо говоря, он выглядит так: клиент открывает соединение и посылает хендшейк, из которого прокси должен получить информацию о датацентре, к которому хочет подключиться клиент + параметры для AES-CTR. Дальше прокси должен подключиться к нужному IP-адресу (захардкоженному) и по такой же процедуре передать данные дальше. То есть прокси фактически занимается тем, что потоково расшифровывает данные от клиента и зашифровывает для сервера и наоборот.
Есть еще режим adtag. Когда-то давно команда Telegram решила поддержать держателей прокси тем, что те могли закрепить какой-то канал у всех пользователей этого прокси и таким образом монетизироваться. Вот только работает эта штука совсем иначе: когда приходит запрос, нам недостаточно просто передать его куда-то. Telegram поддерживает постоянно ротируемый список так называемых middle-proxy, к которым должен подключаться наш софт. Но не абы как: для простоты своей реализации теперь пользовательские данные надо оборачивать в RPC-запрос, куда прописывается adtag сотоварищи. По сравнению с direct-режимом, для этого нужно держать целую тонну довольно неприятного кода, который сложно как тестировать, так и просто нормально написать из-за целой кучи чисто технических нюансов. Например, общение с клиентом идет в режиме потока, тогда как общение с middle-proxy - пакетное.
Во второй версии я выкинул из mtg поддержку adtag, поскольку мне показалось это тупиковой идеей: вместо того, чтобы монетизировать IP-адрес, надо наоборот, воспринимать его как нечто эфемерное. Поймали, заблокировали - новый поднимем. Разводить из-за этого целые церемонии с ботом + держать кучу реально неприятного кода не хотелось.
Где-то в 22 году чего-то поменялось, и через прокси стали тормозить кружочки, фоточки и видео. Я тогда не меньше месяца потратил на дебаг, и пришел вот к какому-выводу: https://github.com/9seconds/mtg/issues/283#issuecomment-1247789563 В телеграме появился CDN, который позволил снять часть проблем с загрузкой контента. Однако в direct-реализации все заворачивается в MTPROTO, и идет на DC-адреса. Технически, Телеграм умеет отвечать на запросы из каждого DC, но это долго, а иногда и таймаутится.
Как я понимаю, в других реализациях, которые тащут adtag-режим, все может работать иначе, потому что у них коннект к Телеграму идет по другим адресам.
Попробуйте https://github.com/alexbers/mtprotoproxy, https://github.com/seriyps/mtproto_proxy или официальный https://github.com/TelegramMessenger/MTProxy но только именно с adtag. Если с ними все будет работать - ну и славно. Здесь еще активно упоминается https://github.com/telemt/telemt - там вроде заявлена поддержка adtag.
Если и с adtag такие тормоза, то, боюсь, сделать ничего без подключения кого-то со стороны Telegram, будет нельзя.
Устанавливал через докер. Жалоба на 203 ДС осталась. Плюс ощущение, что не определяются ip подменного домена. Хотя на хосте всё работает. Написал в в обсуждениях на гитхабе, строки из лога приложил. Прошу посмотреть.
Причём интересно, текст в сообщениях отправляются и принимаются, а медиа не грузятся совсем.
Есть настройка, которая позволяет перенаправлять такие запросы в другие DC. 203 DC = CDN. Если кто-то вдруг имеет понятие, каким образом к нему подключаться - добавлю поддержку.
Ребята из https://github.com/telemt/telemt точно знают. Он что-то переписали в коде и в новом релизе добавили в конфиге
[dc_overrides]
"203" = "91.105.192.100:443"
и.. о чудо! Всё отлично работает и грузится с вполне приличной скоростью.
Без этих 2-х строк в конфиге - медиа не грузится.
Возможно, это Вам что-то подскажет в вашей реализации. Если что - тестировалось на зарегистрированном прокси с указанием adtag в конфигурации сервера.
Да, я уже выпустил новую версию. Спасибо!
Вам спасибо! )) Проверено на серверах Эстонии, Финляндии и МСК. Всё работает ровно и стабильно - конечная скорость на устройстве зависит только от ширины канала и пинга.
Что касается звонков - они прекрасно работают в рамках одно подсети и не происходит соединения, если в разных. Такое поведение характерно при проблемах с серверами рукопожатий (приходилось решать эту проблему для клиентского ПО, когда начали блокировать общедоступные сервера для Вотсап). Если в возможности прокси добавят выбор серверов и можно будет поднимать свои - мне кажется, что проблема со звонками будет решена.
mtg-proxy | {"level":"warn","logger":"proxy","error":"no addresses to call: cannot dial to tcp4:91.105.192.100:443: cannot dial to 91.105.192.100:443: dial tcp4 91.105.192.100:443: i/o timeout","timestamp":1771349702242,"message":"cannot dial to telegram"}
За сутки перепробовал разные образы и выяснил что все прокси что идут с fakeTLS не работают одновременно с КВН, во всяком случае на моем андройде. Запустил ваш образ в классическом режиме - полет отличный. Еще интересует что лучше классический MTP или сокс5, ваше мнение.
Для любителей запуска нативных бинарников прямо на роутере под OpenWRT с белым IP уже сущесвтует luci-app-telemt веб-интерфейс и скомпиоированные пакеты под все arm64 - https://github.com/Medvedolog/luci-app-telemt
Реально работает? Звонки тоже? Видно, что chatgpt. Звучит сомнительно, но окей.
Звонки не работают
алгоритмы MTProxy не подразумевают работу со звонками,
если Telegram это реализует - в течение недели добавим в telemt
Можете помочь с telemt?
В гите на страничке дан пример access.user, в который пишется '"username"="32_hex_chars_secret"', но у телеги ключик должен начинаться с "ee".
Как этот hex secret соотносится с ключиком телеги? Если я правильно понял, ключик состоит из 2х частей - имени домена в hex'е + ключ пользователя. Но сходу не разобрался, а лезть в код малознакомого языка очень не хочется.
Для стороннего наблюдателя трафик неотличим от обычного HTTPS-запроса к этому сайту
Как не отличим то? А IP адреса в пакетах почему не соответствуют адресу назначения из SNI?
Работает там, где VPN уже не спасает.
Правильно настроенный VPN пока везде спасает. Проще поставить на VPS Xray и настроить соединение VLESS+XHTTP+Reality да не забыть включить в клиенте мультиплексирование MUX. Будет работать не только Telegram, но и WhatsApp, и Youtube и всё остальное.
Если вам лень читать. Арендуем самую дешманскую ВМ-ку и делаем так:
curl -sSL https://raw.githubusercontent.com/itcaat/mtproto-installer/main/install.sh | bash
чет не робит, что на ру ВМ, что на зарубежной. Толком не копался в логах, но в тг висит бесконечное соединение
Порты же, разрешил?
поддерживаю, тоже не робит
Поправил - должно полететь. Спасибо что проверили
Зачем там traefik?
https://github.com/itcaat/mtproto-installer/blob/5dc208b47cfc714cc0220696eda89a628352e888/install.sh#L142
(если не менять домен, то скрипт останавливается )
[[ -n "$input" ]] && FAKE_DOMAIN="$input" || true должно быть?
Не хватает проверки на нужные приложения, например, попробовал на чистом новом дебиане, ругается на отсутствие xxd.
Медиафайлы через FakeTLS не загружаются. Вертятся бесконечно. Что на дектопной, что на мобильной (андроид) версии. Через обычный mtproto (dd), установленный на том же хосте, прекрасно работает.
PS: [dc_overrides] "203" = "91.105.192.100:443" решило проблему. В инсталляционный скрипт бы это добавить сразу.
PPS: почему в логах дикое количество WARN telemt::proxy::handshake: TLS replay attack detected (duplicate digest)?
Спасибо. Я далёк от админства сетей и мне мало что понятно, но арендовать сервер и сделать свой MTProxy по статье получилось. Больше 15 минут ушло, конечно, но я разобрался)
Да вот нет, блочат ру сервера только в путь. А вот на счёт дешевле - в забугорье есть выбор в диапазоне 1-2 бакса в месяц. (а сильно поискать, совсем задохлика и за 5-7баксов в год взять можно. Но для этих целей его хватит) С кучей локаций и крутым уровнем, LEB в помощь) у нас же за эти деньги будет скорее уныло чем хорошо.
Прямо вот тут написно
Suppose your city restricts deliveries to a particular foreign address (i.e., Telegram's IP). You could send your package to an out-of-town friend (i.e., MTProxy node) who then forwards it to the original destination. If your friend opens the package, he won't be able to see its content: Telegram encrypts all traffic.
Если это так, то какой смысл арендовать за платно сервер ради подняти MTProto прокси ноды, если можно использовать уже существующие бесплатные прокси? Раз содержимое сообщений сам держатель ноды не прочитает, то как будто и не страшно, нет?
Публичные ограничены в полосе, cpu и ram, при этом испытывают "публичную" нагрузку с эффектом ЧНН и другими телеком-приколами; а ещё - они могут показывать рекламу через ad_tag и middle-proxy, к слову - последний релиз telemt этого пока не умеет, но мы работаем над этим к версии 1.2
В telemt получается минимизировать оверхед на клиенте/подключение, но - у всего есть предел, да и жёсткая оптимизация - не самоцель;
В остальном, да: MTProxy не имеет доступа к вашим данным непосредственно, но видит:
- ваш IP и порт
- время когда вы подключились
- сколько пересылали и на какой dc-id
-> даже если быть параноиком, то относительно доступна мысль о том, что эти данные могут использоваться для ОРМ и других целей
Как совместить с каким-нибудь nginx на порту 443?
Например, через haproxy по SNI,
допустим, у вас задан petrovich.ru - клиент его посылает в ClientHello,
haproxy "вычитывает" и выбирает backend на основании SNI:
для petrovich.ru - MTProxy, для вашего блога/файлопомойки/etc %ваш_домен% - nginx :D
Textbook будет в репозитории telemt/telemt или telemt/telemt-haproxy завтра к утру по МСК
Раз уж подняли тему Haproxy. Коллеги, кому-нибудь удалось в нем разделить порт для доступа еще и для подключения по ssh?
Я пытался заняться некоторое время назад, но соединение так и не прошло. Есть подозрение, что пока не удалось подобрать правильный паттерн старта ssh-подключения. Хотя в этой части вроде инструкция как раз подробная, так что не факт что я вообще копаю в нужную сторону. Техническая деталь: настраивал всю эту радость на голом ip, без делегированных доменов на сервере. Некоторые побочные сервисы даже в таком виде удавалось конфигурировать с использованием SNI. Но, разумеется, не ssh. Неужели из-за него одного придется теперь разбираться с sslh, компилировать это дело и вручную закатывать в docker? Лень как-то) В итоге скорее всего так и так придется разбираться с sslh, уж больно много там интересных функций реализовано "из каропки". Однако то, что Haproxy не заводится как следует никак не дает покоя.
del, habr трет конфиг haproxy, без него смысла в комментарии нет
врапните в base64 и пихните текстом, 4 отступа пробелами слева - будет мило и копируемо.
К ответному комментарию выше: или можно залить листинг конфига в какой-нибудь публичный репозиторий/блокнот/etc... А возможно, весь конфиг целиком писать и не нужно. Те, кто в теме, смогут восстановить недостающее и по довольно мелким артефактам.
Сейчас еще раз попробовал на свежие мозги, и всё внезапно завелось. Кусок конфига Haproxy тривиальнейший, гуглится по ключевым словам if { req.payload(0,7) -m sub SSH-2.0 }. Важное напоминание себе в первую очередь, ну и для современников/потомков: внимательно проверять порядок, в котором в конфигурационном файле идут бэкенды, иначе (как и в случае с location в nginx, и в любых regexp-выражениях) отрабатывать будет стоящее выше более общее правило. Также внимательно читаем сообщение об ошибке, чтобы понять в каком состоянии у нас коннект. Если таймаут соединения, то на данном ip или порту вообще нет ssh, либо фаервол балуется. Если refused, вероятна ошибка в паттерне (искомой подстроке в payload) или дописаны лишние заголовки при проксировании или шифровании, если применяется. А если ssh соединение выдает ошибку remote side unexpectedly closed network connection, это повод проверить как раз порядок применения правил. Ошибки с другими сообщениями в процессе настройки лично мне не встретились, поэтому считаем список пусть если не полным, то условно достаточным.
В любом случае спасибо за внимание к вопросу и за то, что помогли найти мотивацию снова заняться допиливанием этой штуковины. Кто минусует не знаю, воткнул заслуженный плюс.
Спасибо нейронке за статью! Автор похоже даже не прочитал описание работы контейнера на dockerhub. И, наверное, даже ничего сам не устанавливал, иначе рассказал бы как починить статистику прокси, которая в "актуальном" образе поломана. Про нейровыдумки общего характера в статье даже писать смысла нет. Но особенно посмешило обязательное! требование освободить 443 порт.
А что не работает? Заведите issue
Скрипт статистики, приведённый в данной статье, действительно не работает.. Но, видимо, комментатор не про то - в оригинальном докере от Телеги статистика действительно поломана и лечится вот так: https://codeby.net/threads/razvertyvaniye-svoyego-mtproxy-telegram-so-statistikoi.67936/ (докер старый и именно так уже ничего не лечится). Правда ваш mtg для метрики юзает statsd и Prometheus, но это уже детали.. ))
Хотелось бы какое-то более простое лечение, чтобы видеть статистику с основными параметрами буквально 1-ой командой...
Трафик фильтруется на границе РФ.
Стоит пограничник и фильтрует трафик.
Трафик фильтруется на ТСПУ у каждого провайдера.
Спасибо за статью. Только что-то не пойму, если сам в РФ и VPS в РФ, то зачем ставить MTProto, когда телеграм поддерживает также стандартный SOCKS5, а внутри страны он не режется. Зато даст возможность гонять через VPS не только телегу?
Поднял прокси, что-то картинки не стали сильно быстрее загружаться :(
А если включаю впн на том же серваке, все летает
Тоже, половина не грузится. Так понимаю, устарел образ. Попробую другой из комментариев выше.
Вот этот попробовал https://github.com/An0nX/telemt-docker
Полёт отличный. Из минусов - конфиги ручками создать, в них поменял только 2 строки:tls_domain = "example.com"
поменял на реальный
[access.users] docker = "0123456789abcdef0123456789abcdef"
тут id из пункта 1 туториала.
Для стороннего наблюдателя трафик неотличим от обычного HTTPS-запроса к этому сайту.
Что мешает стороннему наблюдателю сравнить IP-адрес 1c.ru с IP-адресом сервера, до которого устанавливается соединение?
Ограниченность ресурсов и времени на принятие решения, блокировать пакет или нет (банально некогда заниматься async-штуками на ТСПУ). Вот если кто-то с мозгами получит сигнал о том, что вот на таком-то IP появился 1c.ru, достаточного уровня, чтобы не пропасть в потоковом шуме на детекторах (а шума там пока ещё овердофига) - этот сможет сравнить адреса, однако проблема для него будет именно в получении сигнала. (А уж если и DNS совпадёт... Хе-хе)
динамические адреса. разным клиентам могут отдаваться разные адреса. если начать их прибивать ляжет весь бигтех.
Заходите в канал @ProxyMTProto.
В моем случае такой вариант не сработал. Подозреваю что если поднять свою MTProxy на моем провайдере результат будет аналогичный
Если уж поднимать свой сервер, то лучше сразу смотреть в сторону Xray с транспортом Reality. Там маскировка на уровне протокола TLS, а не просто подмена заголовка. И работает для всего трафика, а не только для телеги. MTProxy хорош только как быстрый партизанский вариант, когда надо срочно перекинуть файл, а остальное лежит
там 200 рублем заплати там заплати, провайдер уже два раза абонентскую подымает сначала в ноябре и вот в январе из за НДС, коммуналка вот уже почти 20к стала, и это при ЗП в 30к , на что жить то теперь?
Подскажите, почему при использовании прокси не загружаются стикеры в telegram? чаты, фото, все работает без проблем, а стикеры нет. В логах (docker-compose logs -f) ничего нет
Подскажите, имеет ли смысл тогда арендовать VPS, чтобы поднять на нем свой сайт-заглушку и по его же SNI и к нему же подключаться через MTProxy? Или, все-таки, лучше использовать какой-то известный SNI, но с вероятностью погореть?
не пашет сабж
*похоже vds надо менять а не вариант прокси
Что то уж больно прожорливые эти прокси, первый так вообще два ядра под завязку использует, из закрепа немного лучше, до половины, это при то что подключен один клиент
Представляю лицо админа Сбера, когда он увидит в логах, что миллионы людей "заходят" к ним на сайт через домашние роутеры и подозрительные VPS, но при этом на самом сервере запросов нет
@cyberscoper Уточните, пожалуйста, если у меня куплен домен у одного провайдера, а впс вообще на другом провайдере, то на первом провайдере в веб админке, я днс указываю айпи моего впс сервера на доменное имя?
superroot@myvps:~$ curl -v https://domen.ru
Host domen.ru:443 was resolved.
IPv6: (none)
IPv4: myipvps
Trying myipvps:443...
ALPN: curl offers h2,http/1.1
TLSv1.3 (OUT), TLS handshake, Client hello (1):
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.3 (OUT), TLS alert, decode error (562):
TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
closing connection #0 curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading supperoot@7-d00d141fd04d:~$ ^C
я настроил на имя домменное адрес этого впс, не пашет. А если просто по айпи
мойвпс@d:~$ curl -v просто айпи:443
Trying просто айпи:443...
Connected to просто айпи (простоайпи) port 443
using HTTP/1.x
GET / HTTP/1.1
Host: просто айпи:443
User-Agent: curl/8.14.1
Accept: /
Request completely sent off
Empty reply from server
shutting down connection #0 curl: (52) Empty reply from server суперрут@d04d:~$
Хотелось бы описание поднятия mtproxy, а не описания запуска непонятного докера :(
Если нет желания использовать Docker, можно собрать и настроить самому, как я понимаю?
На гитхабе проект.
Кто-нибудь шел по этому пути?
Не понятно, там Fake TLS изначально есть или как-то отдельно ставить и настраивать плагин какой-нибудь нужно?
Непонятно по последним пунктам:
5. Generate the link with following schema: tg://proxy?server=SERVER_NAME&port=PORT&secret=SECRET (or let the official bot generate it for you).
SERVER_NAME - это что, IP сервера, на котором MTProxy?
6. Register your proxy with @MTProxybot on Telegram.
Зачем это? Это публичит мой сервер с MTProxy?
7. Set received tag with arguments: -P <proxy tag>
Зачем это? Это публичит мой сервер с MTProxy?
Это чтобы рекламу интегрировать в прокси для юзеров.
SERVER_NAME - это что, IP сервера, на котором MTProxy?
Да, но может быть домен, по которому будет доступ. SERVER_NAME это то, что слушает на 443.
Не понятно, там Fake TLS изначально есть или как-то отдельно ставить и настраивать плагин какой-нибудь нужно?
Что-то я не нашел на Гитхабе ничего про обфускацию...
А VPS какой лучше использовать наш скрепный или не наш нескрепный или все равно?
Не понятно, там Fake TLS изначально есть или как-то отдельно ставить и настраивать плагин какой-нибудь нужно?
Без понятия, лог из под докера выглядит примерно так:
telemt | 2026-02-11T10:50:55.241259Z INFO telemt: Modes: classic=false, secure=false, tls=true
telemt | 2026-02-11T11:49:37.049161Z INFO telemt::proxy::handshake: MTProto handshake successful peer=172.18.0.1:54578 user=default dc=-2 proto=Secure tls=true
telemt | 2026-02-11T11:49:37.049360Z INFO telemt::proxy::client: Connecting to Telegram user=default peer=172.18.0.1:54578 dc=-2 dc_addr=XXX:443 proto=Secure fast_mode=trueА VPS какой лучше использовать наш скрепный или не наш нескрепный или все равно?
Теоретически - наш, который не замедляется. Можно вкорячить там zapret, но он не везде работает. Проще, наверное, нескрепный.
Но эффект от mtproxy у меня на выборке 2 человек 50%: одному помогло, другому не помогло. Стикеры не грузятся. Медиа в сторону телеграма пошло быстро у обоих, со стороны телеграма только у одного ускорилось. хз что там происходит...
Местный не работает (
Попробовал. Почему-то скорость намного медленнее чем обычный SOCKS5 на том же самом сервере. Пробовал и этот вариант, и telemt. Пробовал менять маскировочный сервер на другой, но скорость все равно очень низкая..
в итоге ничего не заработало нормально: не текущий способ, не https://github.com/An0nX/telemt-docker, не публичные прокси. Подключается, текст открывается, видео еле-еле качает. На этом же сервере VPN поднят, с ним все отлично.
Может кто то подскажет наиболее актуальное на данный момент приложение для vless на айфон? foxray что то перестал работать.
Поменяй транспорт на grpc
Для яблок shadowrocket хвалят, https://apps.apple.com/ru/app/shadowrocket/id932747118
Но он платный, как внести деньги на счет apple из россии не подскажу, сам не знаю как. Слышал, что есть какие-то подарочные карты для пополнения баланса, но сам ими не пользовался никогда
Купите симку билайна (вроде можно и МТС) и воткните куда нибудь. Затем в AppStore укажите что оплата с баланса номера телефона. Если ошибка оплаты - идите в салон и спрашивайте чего https://moskva.beeline.ru/customers/products/oplata-v-app-store-i-itunes-so-scheta-beeline/ не работает, вы может песню $КТО_ТАМ_РУКОПОЖАТЫЙ_СЕЙЧАС в iTunes Music Store хотели купить а не выходит.
v2box неплохо, умеет маршрутизацию. Happ proxy utility сейчас хайпанул, народу нравится, простой и подключается одной кнопкой.
Разницы не заметил, что из статьи, что из закрепленного комента докер, помоему одинакого работают. В целом через раз, на комп дозвониться даже смогли, а на мобилку уже нет, подключение бывает висит, но возможно еще впс тугой очень, потестим еще.
В моем случае к сожалению не сработало. Прокси видит (в т.ч. и пинг) и даже подключается, но по факту трафик не идет на сервак. Будем пробовать иные пути)
Я там второй вариант рассмотрел, в профиле найдёте свежую статью.
А так жаль, они тоже не спят.
Попробуйте полноценный КВН или сокс5 прокси. Например установщик в 1 клик: https://github.com/xVRVx/autoXRAY или любой другой на выбор https://github.com/XTLS/Xray-core?tab=readme-ov-file#installation
Народ, через Docker не хочу.
В этих образах тоже самое что и https://github.com/TelegramMessenger/MTProxy/tree/master или нет?
Зачем через Docker, если можно самому собрать?
Используйте только порт 443.
А что делать, есть там уже висит КВН?
Заходите в канал @ProxyMTProto
Куча вариантов с иными портами. Как это соотносится с утверждением выше?
А давно на хабре перестали банить и вешать 451 на статьи по пропаганде средств обхода блокировок?
Из интересного - если запустить vless vpn и в нем уже пробовать поднять прокси - то она не работает.
Выключив vpn - прекрасно все пашет (из закрепленного комментария).
Подозреваю что коллизия какая то собирается.
На сервере уже установлен 3x-ui, соответственно 443 порт занят под другое дело, насколько критично например использовать 8443 порт и чем это грозит ?
Попробовал схему топикстартера. VPSка в РФ. Работает, но странно. Медиа на публичных каналах не грузятся, а вот в личных сообщениях всё замечательно. Пустил внутри VPN заграничного, т.е. прокси трафик идет внутри туннеля до Европы, обратно уже чистая прокси в сторону VPS в РФ (проверял, не проблема ли в домашнем провайдере). Но нет, в работе ничего не изменилось. SNI для TLS использовал 'vk.com'. Возможно это играет роль, другие не проверял.
Либо у хостера что-то, либо сетевая проблема (MTU? MSS?). Однако WG туннель с этим хостером - никаких проблем.
Это фича MTPROTO. Он, по сути, заброшен и морально устарел - со стороны Telegram были изменения, которые не совместимы с тем, подо что разрабатывался протокол. В частности по медиа. Выше писали.
Если вдруг кому нужен docker-compose.yml:
services:
mtproto-proxy:
image: nineseconds/mtg:2
container_name: mtproto-proxy
restart: unless-stopped
ports:
- "443:443"
command: simple-run -n 1.1.1.1 -i prefer-ipv4 0.0.0.0:443 <ваш секрет>
Для стороннего наблюдателя трафик неотличим от обычного HTTPS-запроса к этому сайту.
Подскажите пожалуйста, трафик неотличим (условно, понятное дело) ДО или ПОСЛЕ прокси? А то я не очень разбираюсь как работает fake tls.
Может кто знает, какой-нибудь прокси типа socks5 или mtproto можно развернуть на своём сервере, чтобы звонки работали? 😊
Не работает. Все домена перепробовал.
Странно, работает только в classic mode. Если ставлю classic=false не может подключиться. Не в secure, ни в tls mode. В результате, не грузятся видео и картинки.
Купил VDS, поднял, попробовал в местах где глушат всё кроме vk, к сожалению, не работает (
curl -s ifconfig.me возвращает ipv6
для того чтобы получить ipv4 используем curl -4s ifconfig.me
А безлимит на Telegram будет работать?
Без контейнеров есть вариант? Многие могут на гипервизоре развернуть еще одну виртуальную машину.
на заграничном VDS не заработало.
порт поднимается и слушается, но Telegram не может подключится к прокси.
А как поднять с приватным (dd) секретом?
Повышаем стабильность Telegram: поднимаем партизанский MTProxy с Fake TLS