Недавно разработчики Telegram выложили исходные тексты прокси-сервера, работающего по протоколу MTProto. На хабре вышли статьи об особенностях его сборки и перепаковке докер-контейнера с ним. Официальный прокси сервер, написанный на С, удивляет объемом кода — примерно 23 тысячи строк. Одновременно с этим, а иногда и чуть раньше, вышло несколько альтернативных реализаций, но ни одна из них не поддерживала возможность рекламы своего канала.
В данной статье хотелось бы, во-первых, рассказать о малоизвестных особенностях протокола общения прокси-сервера с внешними серверами и, во-вторых, рассказать о собственной разработке — реализации прокси-сервера на Python, которая только что достигла релиза и доступна всем желающим под свободной лицензией MIT.
Особенности взаимодействия прокси сервера с внешними серверами
- Официальный прокси сервер не взаимодействует с серверами телеграма напрямую, а использует для этого ещё, как минимум, один слой прокси-серверов. Мы будем называть их middle-proxy, их список доступен по ссылкам core.telegram.org/getProxyConfig и core.telegram.org/getProxyConfigV6. Соединение по IPv6 пока не поддерживается официальным прокси-сервером.
- Для шифрования данных между прокси-сервером и middle-proxy используется ключ, получаемый из ip адресов обеих узлов. Поэтому, прокси-сервер для соединения с middle-proxy должен знать свой внешний ip-адрес, иначе ключи шифрования на одной и на другой стороне будут разными. Помимо этого, в формировании ключа участвуют номера портов обеих узлов и общий секрет, доступный по адресу core.telegram.org/getProxySecret. Разработчики Телеграма рекомендуют обновлять этот секрет раз в сутки.
- При подключении прокси-сервера к middle-proxy, первый из них передаёт своё время. Если время отличается больше чем на несколько минут, вторая сторона закрывает соединение.
- При посылке сообщения от клиента к middle proxy, сообщение оборачивается в RPC-вызов протокола MTProto. В каждый такой RPC-вызов прокси добавляет несколько аргументов: ip и порт обеих узлов, случайный идентификатор соединения, а также тег прокси сервера, используемый для показа рекламного канала в приложении. Эти дополнительные аргументы занимают примерно 96 байт. Из-за этой особенности не получится показывать рекламные каналы при работе напрямую, не через middle proxy.
- Серверы Телеграма «верят» информации об ip клиента, получаемой от прокси-сервера. Эти адреса можно увидеть в информации о сессиях (прямоугольник дорисован):
- По одному TCP-соединению между прокси-сервером и middle-proxy передаются сообщения разных пользователей. В запросах и ответах есть аргумент «случайный идентификатор соединения», который нужен для того, чтобы данные попали к нужному клиенту.
- Прокси сервер не может расшифровать данные клиента, но может отличить обычные сообщения от передаваемых файлов. Так же, ему известен размер каждого сообщения.
Фуф, надеюсь не утомил техническими деталями. Теперь должно быть понятно, почему во многих альтернативных прокси нет поддержки рекламы — они передают сообщения напрямую серверам телеграма, минуя middle-proxy. Получается значительно проще. Во второй части статьи описывается первая неофициальная реализация прокси сервера, которая работает через middle-proxy. В данный момент в свободном доступе можно найти три таких реализации: официальную, на Erlang и эту.
Реализация прокси сервера на Python
Изначально прокси-сервер писался для того, чтобы понять особенности протокола и был развитием другого проекта — асинхронного сокс-прокси, написанного, в свою очередь, чтобы «потрогать» async/await в Питоне.
Постепенно у проекта появились пользователи, которые завалили вопросами, баг-репортами и фич-реквестами. После доработок проект вошёл в стадию бета-тестирования и стабилизации, которая длилась примерно неделю и задействовала пять серверов разных конфигураций.
Перед тем как рассказать о фичах, которых пока нет у официального прокси сервера, но есть у альтернативного (и умолчать о функциях, которые есть у официального и нет у альтернативного), расскажу о вещи, которая у многих первой приходит в голову при упоминании слова Python.
Производительность
Для тестирования производительности использовалась виртуальная машина в облаке минимальной конфигурации: 1 CPU, 1024MB RAM.
На синтетических тестах прокси сервер оказался способен передавать порядка 240мегабит/сек или 3000 сообщений/сек. При использовании альтернативной реализации event-loop'а на С, которая называется uvloop, а также при использовании интерпретатора PyPy данные производительности получаются иные (все измерения — в секунду):
При тестировании на реальных пользователях оказалось, что такого сервера хватает, чтобы с комфортом обслуживать 4 000 пользователей или 8 000 при использовании PyPy.Большим сюрпризом оказалось то, что как бы не рекламировался тестовый сервер в русскоязычных каналах, все равно 89% пользователей были из Ирана (возможно, для других стран количество одновременно обслуживаемых пользователей будет отличаться). Выглядит это так:
Я поспрашивал нескольких администраторов других серверов — у них ситуация такая же. Возможно, это связано с тем, что на территории России телеграм хорошо работает без прокси-серверов. В Иране тестовые сервера блокировались для населения спустя несколько часов после создания.
Нагрузка на сервер при 2 000 пользователях. Чётко виден момент блокировки сервера для граждан Ирана.
Таким образом производительность CPU не является узким местом на тестируемом узле. При 10 000 клиентах, скорее всего, закончится память.
Одновременное использование нескольких ядер CPU не реализовано (привет, GIL).
Фичи, которых пока нет у официального прокси сервера
Работа по протоколу IPv6.
Прокси-сервер без дополнительной настройки умеет использовать IPv6 для исходящих соединений. Соединения по IPv6 не блокируются на территории России (пока).
Режим работы без middle-proxy
Если реклама канала не нужна, прокси автоматически соединяется напрямую с серверами телеграма, минуя middle-proxy. Это быстрее и надёжнее.
Так же, реализован опциональный "быстрый режим", когда сообщения от сервера Телеграма до прокси и от прокси до клиента шифруются одним и тем же ключём. Таким образом прокси не нужно перешифровывать сообщения — он отправляет их как есть. На безопасность это не должно влиять т.к. в любом случае у администратора прокси-сервера нет доступа к сообщениям пользователей.
Автообновление списка middle-proxy и секрета раз в сутки.
Официальный прокси сервер для обновления списка middle-proxy рекомендует рестартовать docker-контейнер раз в сутки, что сбрасывает все соединения. Новые соединения могут не установиться если, например, в стране заблокировали сервер. Питоновская версия периодически ходит на сайт и обновляет список.
Многоплатформенность
Поддерживаются любые платформы, на которых запускается Python. Получалось запустить его даже на iPad, правда, внешние входящие соединения блокировались устройством. Отдельно поддерживается Windows, для меня стало сюрпризом как много людей запускают прокси под данной ОС. Хотя под Windows можно запустить и официальный клиент, если использовать технологии виртуализации или докер.
Возможность простого запуска без докера.
Если (вдруг) есть те, кто не любят докер, прокси может быть запущен и без него. Нужно указать минимум два параметра в файле конфигурации: порт и секрет, также можно задать опциональный рекламный тег, затем выполнить команду: python3 mtprotoproxy.py. Правда, в таком случае придётся думать над автозапуском в ОС, например писать unit-file для systemd. Ещё нужно будет установить pycrypto или pycryptodome, без него будет работать, но очень медленно.
В случае с докером контейнер можно пересобрать командой docker-compose up --build.
Фичи, запланированные на следующий релиз
Ограничение скорости скачивания больших файлов.
При скачивании больших файлов можно, на уровне TCP, «просить» middle-proxy или сервер Телеграма посылать данные медленнее. Сейчас это сделано с помощью установки маленького значения буфера приёма, что дополнительно экономит память сервера.
Потоковая передача сообщений.
Сейчас, все известные прокси-серверы, работающие с middle-proxy, сначала считывают от клиента сообщение и только потом его передают. Размер одного сообщения может достигать 1МБ. Требуется память на его хранение и немного увеличивается задержка передачи. Можно передавать данные потоково. Это усложнит код, но сократит потребление памяти в худшем случае.
Изменение длины пакетов для обхода фильтра по длине пакета.
Не успело попасть в релиз.
Установка и запуск
- git clone -b stable github.com/alexbers/mtprotoproxy.git; cd mtprotoproxy
- (опционально, рекомендуется) указать PORT, USERS и AD_TAG в config.py
- docker-compose up --build -d (или python3 mtprotoproxy.py, чтобы без докера)
- (опционально, выводит ссылку вида tg://) docker-compose logs
Другие реализации MTProto-прокси с поддержкой рекламы каналов:
Благодарности
seriyps — за помощь с тестированием на реальных пользователях
shifttstas — за советы по докеру
forst(github) — за идею и реализацию работы по IPv6
p1ratrulezzz(github) — за советы и за статью про проект
freekzy(github) — за патч бага с утечкой дескрипторов
UPD: репозиторий, в котором собраны разные реализации MTProto-прокси: github.com/mtProtoProxy
Комментарии (72)
Renaissance
15.06.2018 16:55Спасибо, в отличие от официального mtproxy, эта реализация работает без проблем.
Вопрос возник, при запуске оно ругается что нет pycryptodome или pycrypto, что из этого лучше выбрать в плане наименьшего потребления ресурсов? Или можно на slow AES implementation оставаться?alexbers Автор
15.06.2018 17:50+1В плане потребления ресурсов они pycryptodome и pycrypto работают примерно одинаково. Мне больше нравится первый, он активнее развивается и под windows легче устанавливается. Slow implementation медленный, но если скорости хватает, то можно оставаться на нём.
SirEdvin
15.06.2018 17:08Одновременное использование нескольких ядер CPU не реализовано (привет, GIL).
А думали над тем, что бы просто запускать несколько инстансов и через что-то их роутить? Как делает gunicorn например. Из самых простых способов, это nginx + streams.
seriyPS
15.06.2018 17:30Нужно как-то передавать по всей цепочке IP адрес клиента (если мы не хотим врать телеграму про IP адреса пользователей). При простой TCP балансировке это невозможно, нужно какой-то протокол изобретать.
alexbers Автор
15.06.2018 18:19+1Есть идея попробовать опцию SO_REUSEPORT, которая позволяет заслушать один и тот же порт несколькими процессами. Думаю, это должно помочь.
freekzy
15.06.2018 17:51Призываю Vespertilio. Он как раз интересовался подробностями.
Тем временем предпосылки к очередной головной боли.
Allineer
15.06.2018 17:51Я вот одного не могу понять, почему возможность использовать несколько SECRET есть, а несколько AD_TAG — нет?
Неужели только я хотел бы для узкого круга приближенных дать просто прокси, а всем остальным навязать свой канал и все это без необходимости запуска двух инстансов прокси?
schors
15.06.2018 18:30Отличная содержательная статья. Одна из лучших. А почему обойдены вниманием реализации на rust и go? На go даже вполне рабочая (хоть и простая).
alexbers Автор
15.06.2018 18:43+1Действительно. Дополнил статью ссылкой на репозиторий https://github.com/mtProtoProxy, в котором собраны разные реализации MTProto-прокси.
schors
15.06.2018 19:18Я бы ещё сделал автоматический образ (чтобы сам подтягивал изменения на github) docker на DockerHub. На той же alpine. И перебивку параметров config.py через командную строку.
schors
16.06.2018 05:33Причем на alpine pypy3
alexbers Автор
16.06.2018 07:50+1Хорошая идея, попробую реализовать в ближайшее время
flint
16.06.2018 14:33А можете сделать 2 образа, один с pypy, другой с cpython (либо один образ, но с опциональным переключением)? Если память является узким местом, то PyPy — не лучший выбор. Помимо скорости, он еще ощутимо более прожорливый в смысле оперативки.
alexbers Автор
16.06.2018 23:21На самом деле потребление памяти получается примерно одинаковым, там почти вся память — разнобразные буферы, которые занимают примерно одинаково на си и на питоне.
С pypy3 и alpine возникла проблема — такого пакета по умолчанию нет. Проблема находится в процессе решения.
schors
15.06.2018 19:39Кстати, а как определяется IP которым идет подпись?
alexbers Автор
15.06.2018 19:47По IP с которого пришёл пакет.
schors
15.06.2018 19:48Не совсем понял, там же мой proxy добавляет свой IP при коннекте к middle-proxy…
alexbers Автор
15.06.2018 20:25+1Прокси должен его знать. Официальному прокси нужно указывать ip при запуске с помощью ключа --nat-info, а то он использует ip какого-нибудь интерфейса. Официальный прокси в докер-образе ходит на https://digitalresistance.dog/myIp и узнаёт его. Питоновский ходит на https://v4.ifconfig.co/ip и https://v6.ifconfig.co/ip.
Зачем они так сделали и зачем нужен секрет https://core.telegram.org/getProxySecret, который все и так знают является для меня большой загадкой. Возможно, у них есть внутренние middle-proxy, секрет которых знают не все.
darkk
15.06.2018 19:58в формировании ключа участвуют номера портов обеих узлов
А проверяет ли middleProxy то, что по переданному IP:port слушает именно этот сервис?
darkk
15.06.2018 20:04Почитал. "Проверяет". Но используется не ip:port "сервиса", а ip:port исходящего соединения mtproto proxy в сторону middle proxy.
schors
15.06.2018 20:09А вот берет он откуда его…
darkk
15.06.2018 20:14Код берёт его из
getsockname(). Но из этого следует, что MTProxy адекватно работать не должна за почти любым NAT, в том числе и за докерным. А она вроде как работает.
Надо проверить что ли :-)schors
15.06.2018 20:15Родной лезет на сайт и там берет — посмотри в скрипт запуска
darkk
15.06.2018 20:33Это IP. С IP всё сравнительно просто в "обычных" случаях. Мне интересно поведение приложения, если случится на NAT изменение source port, которое в случае с docker носит вероятностный характер.
alexbers Автор
15.06.2018 20:50+1В таком случае у двух сторон получатся разные ключи шифрования и они "не поймут" друг друга.
darkk
15.06.2018 20:55Да-да. Так и должно быть. Но если это так, это означает, что инструкция имени schors по запуску
telegrammessenger/proxyнамного лучше, чем официальная. Что довольно забавно :-)
thekvs
15.06.2018 20:09Хотелось бы конфигурационный файл отдельной сущностью с возможностью указывать через опцию при запуске и в YAML или TOML формате.
schors
15.06.2018 20:10Да там параметров-то кот наплакал
thekvs
15.06.2018 20:20+1Ну как сказать…
github.com/alexbers/mtprotoproxy/blob/506d7505994c962bd1d2c4dce98d137183365820/mtprotoproxy.py#L64-L76
alexbers Автор
16.06.2018 07:46+1Чтобы конфигурационный файл был в yaml и указывался через опцию можно написать примерно так: https://pastebin.com/Amzh5jJe
Для других форматов это будет выглядеть аналогично.
thekvs
16.06.2018 09:37На мой взгляд конфиг было бы удобнее сделать полностью отдельной сущностью, которую можно положить в любое место и без правки питоновских исходников.
Radjah
15.06.2018 20:32+1Эта реализация не порождает 50 потоков сразу после запуска как официальная?
alexbers Автор
15.06.2018 20:47+1Не, не порождает
Radjah
15.06.2018 21:21Это уже радует. Запустил на погонять вместо официального. По аппетитам сабжевая реализация потребляет CPU/RAM заметно меньше.
schors
16.06.2018 05:13А сколько порождает? Или он деманд?
seriyPS
16.06.2018 16:28А что под потоками подразумевается? Трелы ОС в python версии не запускаются вообще, всё однопоточное (asyncio).
Важное различие между официальным прокси и всеми остальными, что официальный мультиплексирует много коннектов клиент-прокси в небольшое количество коннектов прокси-сервер телеграм.
Другие реализации всегда создают пару сокетов.
passerby
16.06.2018 10:36У меня тоже вопрос в стиле «Неужели только я хотел бы».
Интересно, почему в реализации прокси полностью отсутствует возможность использования по логину/паролю.
Неужели только я хотел бы сделать приватный прокси без рекламы только для пользователей своего сайта/сервиса/проекта/стартапа и т.д. Который бы был не публичный, соответственно и менее подвержен блокировке.
Т.е. чтобы не secret, которых всего 16 штук, а с привязкой к логину/паролю пользователя.
Отсутствие логина/пароля подается как плюс, однако для меня это жирный минус.alexbers Автор
16.06.2018 11:20+1Отличный вопрос. У меня есть проект, который работает ровно так как описано: https://github.com/alexbers/tgsocksproxy. Правда, работает по протоколу socks т.к. протокол MTProto не поддерживает испльзование логина/пароля.
passerby
16.06.2018 11:24Логин/пароль для socks передаются в открытом виде? Или я ошибаюсь?
alexbers Автор
16.06.2018 11:27+1Да, такой протокол. С этим, к сожалению, ничего не поделать
passerby
16.06.2018 12:38+1А впилить нельзя? Раз все-равно своя реализация?
alexbers Автор
16.06.2018 12:47+1Впилить можно, но тогда нужно будет пропатчить всех клиентов, чтобы они не передавали в открытом виде пароль.
В MTProto-версии поддерживается произвольное число секретов, но сильно много не рекомендуется.
passerby
16.06.2018 12:51А почему много не рекомендуется? Нагрузка больше?
seriyPS
16.06.2018 12:55+2Когда клиент подключается к mtproto серверу, то он присылает 64байта — данные сессии, зашифрованные этим вот секретом. Если расшифровать эти 64 байта правильным секретом, то там в расшифрованном пакете определённой позиции будет проверочная сумма. Если она не совпала, то нужно пробовать расшифровать следующим ключом. Т.е. в худшем случае придётся много раз расшифровывать, перебирая ключ.
seriyPS
16.06.2018 12:52А чего вы опасаетесь? Если боитесь, что перехватят пароль от вашего сервиса прослушивая трафик SOCKS, генерируйте вашим пользователям отдельные пароли для SOCKS, отличные от паролей от сервиса.
passerby
16.06.2018 14:13Да нет, все-равно нужно отдельный пароль делать.
Начал было отвечать, но понял, что опасения-то одни — что для открытого пароля, что для шифрованного. Разница по возможности утечки не велика, потому что утечка более вероятна от самого пользователя, чем от маловероятного перехвата.passerby
16.06.2018 14:25Это, конечно, в контексте обсуждения SOCKS-прокси, а не MTProto.
MTProto вообще не вижу как использовать в таком режиме — у всех один секрет (ну или у группы). В случае утечки менять секрет придется не у одного пользователя, а у всех сразу.
bevice
16.06.2018 12:08Телеграм сейчас сконцентрирован на количестве и качестве публичных прокскй, поэтому и монетизацию прикрутили в виде промоченный каналов. А приватные прокси в данный момент времени телеграму особо не нужны.
passerby
16.06.2018 12:37Как мне кажется, лучше множество неблокируемых приватных, чем быстро блокируемые публичные.
Точнее — может быть и не лучше, но добавило бы немало.flint
16.06.2018 14:40Все верно, именно так и живет все, что касается, например, ShadowSocks: быстро разворачиваем, пользуемся, пока не прибили. Сами прокси передаются либо сарафанным радио (во всех клиентах даже есть возможность считывания QR-кода + его генерация для каких-нибудь существующих), либо через сайты вроде free-ss.site Какие уж спонсорские штуки, да множественные секреты.
Yazov
17.06.2018 11:54>Возможность простого запуска без докера
Официальная версия тоже может работать без докера, достаточно собрать из исходников и запустить. Все это делается в течении двух минут.alexbers Автор
17.06.2018 15:52Ключевое слово "простого". Когда я собрал официальный прокси, я дочитал readme до слов "Simple MT-Proto proxy" и ошибочно подумал что запуск будет простым. Примерно таким ./proxy <port> <secret>. Я запустил его с --help и увидел следующее: https://alexbers.com/proxy.png. Затем было несколько часов безуспешных попыток его поднять, закончившиеся гуглением.
Перечислю несколько проблем, которые усложняют запуск без докера:
- Не указан минимальный набор опций, которые необходимо передать, чтобы прокси заработал.
- В параметрах сказано, что прокси может быть запущен с конфигурационным файлом, однако, нет информации о формате, в котором он должен быть или примера такого файла
- Базовые и экспертные опции идут вперемешку. Понять, что делают некоторые опции можно только читая исходный текст
- Для запуска нужно совершить действия, которые, кажутся "магическими": загрузить "секрет" из адреса в интернете, передать свой внутренний и внешний ip-адрес, загрузить некий список узлов
- В выводе --help надпись "Simple MT-Proto proxy" вводит в заблуждение. Вместо "simple" можно было бы написать что без чтения readme даже не пытайтесь его поднять.
Sly_tom_cat
> Одновременное использование нескольких ядер CPU не реализовано (привет, GIL).
После прочтения этой строки как-то сразу появилось желание попробовать повторить реализацию на Go…
el777
Можно попробовать запилить.
Но мне сама идея MTProxy не очень нравится, легкость обнаружения и блокировки. Имхо нужен протокол, который легче прятать.
alexbers Автор
Авторы протокола предприняли много усилий, чтобы заблокировать было сложно. В протоколе клиент телеграм<->прокси нет сигнатуры, трафик выглядит как случайный поток байт, в котором четыре определённых байта — проверочные, но проверить можно только если знать секрет прокси сервера. Можно блокировать пакеты, которые выглядят как случайный поток байт или определённой длины, но при таких блокировках пострадают другие сервисы, работающие на непопулярных протоколах.
schors
Вот тут проблема, что там всем наплевать что пострадает :(
el777
Недавно была статья, где по пунктам разобраны слабые места протокола, упрощающие обнаружение.
Можете подробнее рассказать, как именно протокол усложняет блокировку?
seriyPS
Erlang версия умеет по ядрам расползаться. Другой вопрос, что из за того как активно прокси блокируют, удобнее иметь 10 одноядерных виртуалок с 10 IP адресами, чем одну на 12 ядер с одним адресом. (Если есть возможность иметь одну с 10 IP адресами то это, конечно, приобретает смысл.)
Плюс к этому в статье умпоянуто, что обычно узкое место это не CPU, а память.
Sly_tom_cat
Ну так питон по памяти тоже немного прожорливее Go/C/Erlang.
flint
Эти 10 адресов будут наверняка в одной небольшой подсети)