Сейчас ни на что, кроме генерации ссылки в начале работы. Планирую его использовать на серверах с большим количеством секретов, чтобы по имени можно сразу было бы пробовать расшифровать с нужным секретом.
В ближайший час планирую поменять вывод адреса прокси по умолчанию, чтобы не использовалось base64 пока авторы Telegram не починят клиента для ios.
У меня больше всего опыта работы с этим языком. Но есть и другие реализации разной степени продвинутости: на go, erlang, си, c#, nodejs, java, pony и т.д.
Если нужна производительность, то лучше выбрать официальную реализацию на си. Её код всё ещё приводит меня в восторг. Правда, они уже пол года ничего не коммитили.
На практике проблемы производительности не возникает. Даже самой дешёвой виртуальной машины хватает чтобы обслужить несколько тысяч пользователей. Но столько пользователей набрать тяжело т.к. основные каналы распространения информации о прокси серверах мониторятся. При большом числе пользователей прокси сервер может быть заблокирован по паттернам трафика
Закончил экспериментировать и закоммитил эту функциональность. Сейчас можно указывать хост и порт на который будет незаметно проксироваться трафик "плохих" клиентов.
в то же время он является замаскированным прокси сервером tg://proxy?server=bitblockinfo.com&port=443&secret=7gARIjNEVWZ3iJmqu8zd7v9iaXRibG9ja2luZm8uY29t.
Это сделано для того, чтобы нельзя было задетектить прокси-сервер по особенностям работы с TLS.
Он в параллельной ветке: https://github.com/alexbers/mtprotoproxy/tree/pypi.
С докером хорошо в том плане, что можно зафиксировать environment: версию Python и библиотек. Другие способы хороши, но поддерживать пользователей чуть сложнее, приходится спрашивать какая у них ОС, как они запускают и т.д. Это позволяет поддерживать пользователей бесплатно, не тратя на это много свободного времени.
Тут даже можно пойти дальше — сделать один домен и если HMAC из поля random handshake-пакета не валидный, то редиректить. Сегодня вечером будет версия, которая так делает.
Насколько я понял, тут нужна поддержка со стороны фронта или клиента Telegram. Для себя можно поднимать веб-версии Telegram, но маловероятно, что сторонний человек согласиться ввести свои credentials на сайт, не связанный с тг.
Да, всё так. Написал эту статью параллельно с добавлением поддержки, но, видя как авторы телеграм маскировали её в коммитах бета-версий, решил подождать релиза, чтобы не дать создателям средств DPI времени подготовиться.
В плане процентов от теоретической скорости получалось около 80%: 159мегабит/сек из 200 mbit tx rate: https://alexbers.com/wifi/wifi2.jpg, но тут набор MCS'ов пришлось вручную подбирать.
За информацию по каналам — спасибо. Если всё пойдёт хорошо, воспользуюсь ей в следующем апреле.
Пол-года назад проводили соревнования в атриуме второй локации из статьи (Ельцин-Центр, Екатеринбург). Принесли для эксперимента wifi-точку, чтобы потестировать сеть в ситуации большой загруженности. Удивило то, что, хоть и на площадке находилось около 200 человек, сеть на 5ггц стабильно выдавала 206 мегабит/сек на получение и 196 мегабит/сек на отдачу. За 16 часов никаких проблем не наблюдалось. Намного выше ожиданий. А та же есть на 2ггц практически не могла передавать данные.
Те простые числа, для которых быстрый тест на простоту не врёт, можно не включать в таблицу. 3/4 можно исключить, если рассматривать числа в 30-ричной системе и проверять только те, которые заканчиваются цифрами "1", "7", "11", "13", "17", "19", "23", "29".
Чтобы код не усложнялся, можно использовать готовую библиотеку для поиска простых чисел, например primesieve, https://primesieve.org/api/namespaceprimesieve.html. Тогда сложность уйдёт в библиотеку. Кеширование можно реализовать через внешний класс для каждого блока, например, по 10 000 тысяч чисел, что позволит значительно уменьшить потребление памяти программой, насколько я понял, примерно на 23ГБ для первого 1трлн простых. Хотя, таблица будет быстрее при случайном доступе к простым.
Сейчас ни на что, кроме генерации ссылки в начале работы. Планирую его использовать на серверах с большим количеством секретов, чтобы по имени можно сразу было бы пробовать расшифровать с нужным секретом.
В ближайший час планирую поменять вывод адреса прокси по умолчанию, чтобы не использовалось base64 пока авторы Telegram не починят клиента для ios.
Устранил вероятную причину такого поведения. Проверьте, пожалуйста, что стало лучше.
Можно проверить, декодировав в обратную сторону. В клиенте для ios есть бага с декодированием некоторых символов base64.
Советую посмотреть это подробнее, вдруг там буфер переполняется и можно хакнуть.
У меня больше всего опыта работы с этим языком. Но есть и другие реализации разной степени продвинутости: на go, erlang, си, c#, nodejs, java, pony и т.д.
Если нужна производительность, то лучше выбрать официальную реализацию на си. Её код всё ещё приводит меня в восторг. Правда, они уже пол года ничего не коммитили.
На практике проблемы производительности не возникает. Даже самой дешёвой виртуальной машины хватает чтобы обслужить несколько тысяч пользователей. Но столько пользователей набрать тяжело т.к. основные каналы распространения информации о прокси серверах мониторятся. При большом числе пользователей прокси сервер может быть заблокирован по паттернам трафика
Теперь можно.
Закончил экспериментировать и закоммитил эту функциональность. Сейчас можно указывать хост и порт на который будет незаметно проксироваться трафик "плохих" клиентов.
Попробую продемонстрировать как это работает:
Это сделано для того, чтобы нельзя было задетектить прокси-сервер по особенностям работы с TLS.
Это значит, что обнаружить прокси автоматическим сканированием с перебором секретов будет легче. Лучше использовать уникальный секрет.
Советую использовать PyCryptodome или cryptography,
PyCrypto заброшен, как вы верно сказали. Думаю дропнуть его поддержку.
Он в параллельной ветке: https://github.com/alexbers/mtprotoproxy/tree/pypi.
С докером хорошо в том плане, что можно зафиксировать environment: версию Python и библиотек. Другие способы хороши, но поддерживать пользователей чуть сложнее, приходится спрашивать какая у них ОС, как они запускают и т.д. Это позволяет поддерживать пользователей бесплатно, не тратя на это много свободного времени.
Константа 0x0304 есть в коде клиента т.к. именно клиент отсылает пакет с supported_versions.
Да, вы правы, отдельные провайдеры экспериментируют с этим, но массово, как в Иране или Китае пока не блокируют по протоколу.
Прокси поддерживает сразу несколько библиотек:
Python-пакет есть: https://pypi.org/project/mtprotoproxy/, правда там стабильная версия, в которой ещё нет экспериментальной поддержки TLS.
Ещё есть образ на докерхабе: https://hub.docker.com/r/alexbers/mtprotoproxy
Как раз экспериментирую с этим.
Да, всё так. Написал эту статью параллельно с добавлением поддержки, но, видя как авторы телеграм маскировали её в коммитах бета-версий, решил подождать релиза, чтобы не дать создателям средств DPI времени подготовиться.
А сколько на практике получалось выжать из wifi в мегабитах/сек и в процентах от теоретической пиковой скорости?
У меня получалось 600мегабит/сек на ac между iphone'ом и ноутбуком с Qualcomm Atheros QCA6174:
https://alexbers.com/wifi/wifi.png, что примерно 70% от пиковых 867 Mbps, указанных на сайте. В самом описании продукта (https://www.qualcomm.com/media/documents/files/qca6174a-product-brief.pdf) у них написано WLAN TCP/IP Throughput 620Mbps/600Mbps TCP DL/UL (PCIe2.1), что примерно соответствует действительности.
В плане процентов от теоретической скорости получалось около 80%: 159мегабит/сек из 200 mbit tx rate: https://alexbers.com/wifi/wifi2.jpg, но тут набор MCS'ов пришлось вручную подбирать.
За информацию по каналам — спасибо. Если всё пойдёт хорошо, воспользуюсь ей в следующем апреле.
Пол-года назад проводили соревнования в атриуме второй локации из статьи (Ельцин-Центр, Екатеринбург). Принесли для эксперимента wifi-точку, чтобы потестировать сеть в ситуации большой загруженности. Удивило то, что, хоть и на площадке находилось около 200 человек, сеть на 5ггц стабильно выдавала 206 мегабит/сек на получение и 196 мегабит/сек на отдачу. За 16 часов никаких проблем не наблюдалось. Намного выше ожиданий. А та же есть на 2ггц практически не могла передавать данные.
Фото локации: https://alexbers.com/photo_from_location.jpg
Те простые числа, для которых быстрый тест на простоту не врёт, можно не включать в таблицу. 3/4 можно исключить, если рассматривать числа в 30-ричной системе и проверять только те, которые заканчиваются цифрами "1", "7", "11", "13", "17", "19", "23", "29".
Чтобы код не усложнялся, можно использовать готовую библиотеку для поиска простых чисел, например primesieve, https://primesieve.org/api/namespaceprimesieve.html. Тогда сложность уйдёт в библиотеку. Кеширование можно реализовать через внешний класс для каждого блока, например, по 10 000 тысяч чисел, что позволит значительно уменьшить потребление памяти программой, насколько я понял, примерно на 23ГБ для первого 1трлн простых. Хотя, таблица будет быстрее при случайном доступе к простым.