Report post 07/01/2018 11:36 PM (edited) К тестированию меня сподвигла ситуация, что при наличии подключения IPV6 дома Телеграм отлично работает напрямую по IPV6, но у моего мобильного оператора IPV6 на сети его нет. Гонять же VPN по соте крайне расточительно для аккумулятора. Также как показала практика, при работе смарта с MTProxy, чем меньше задержка до прокси из сотовой сети, тем меньше расход аккумулятора (но это не точно, и требует доп. проверок и изучения). Также учитывая то, что многие хостеры в РФ ввели у себя запрет на размещение средств обхода блокировок, а у себя дома этому никто не мешает и имея такой прекрасный роутер, как Keenetic я начал исследовать этот вопрос. Для тестирования была выбрана реализация прокси сервера на Python3 от Александра Берсенёва. ( Статья автора https://habr.com/post/414139/ ) Особенностью работы MTProtoproxy является то, что прокси может работать в двух режимах соедения с серверами телеграмма: напрямую, в режиме эмуляции клиента, и через middle-proxy Телеграмма, как официальная реализация. Отмечу, что тестирование показало, что работа напрямую происходит в полтора раза быстрее и занимает практически в 2 раза меньше памяти, чем через middle-proxy. Однако нужно отметить, что только работа через middle-proxy позволяет пользователям своего прокси подключать рекламный канал (ну а вдруг...) Для работы должен быть развернут Entware на Вашем оборудовании https://forum.keenetic.net/topic/4299-entware/ Инсталляция. 1. Устанавливаем, если их нет, Python3 и библиотеку Cryptography. opkg install python3 python3-cryptography 2. Устанавливаем Git, если его нет. opkg install git git-http 3. Разворачиваем с Git образ MTProtoproxy git clone -b stable https://github.com/alexbers/mtprotoproxy.git (Экстремалы могу развернуть и master-ветку, в которую например 01.07.2018 была добавлена также поддержка пакетов переменной длины, и теперь можно сказать определённо - привет DPI-ям, которые будет пробовать блочить на уровне пакетов mtproxy. git clone -b master https://github.com/alexbers/mtprotoproxy.git ) 4. Переходим к конфигурированию. cd mtprotoproxy/ Конфигурирование заключается в редактировании файла config.py 1. Генерим секретный ключ подключения к прокси. (Ставим при необходимости xxd: opkg install xxd) head -c 16 /dev/urandom | xxd -ps Можно сгенерить и другими путями, или придумать ключ самому. Вставляем его в конфиг после "tg":, заменив им нули. По умолчанию конфиг настроен на работу по двум ключам. Но их кол-во одновременно работающих ключей можно менять по необходимости, как сократив до одного, так и увеличив. MTProtoproxy ведёт статистику подключений по каждому ключу. 2. Для увеличения скорости работы рекомендуется добавить опцию к конфиге FAST_MODE = True . 3. При желании подключить рекламный канал или работать именно через слой middle-proxy регистрируем свой прокси у бота @MTProxybot. (Рекомендация: Лучше всего давать ему имя хоста в доменном, а не в ip формате, особенно при dual stack ipv4-ipv6 подключении) Получаем у него proxy tag, раскомментируем и вписываем его в конфиге в разделе AD_TAG. Запускаем для проверки: python3 mtprotoproxy.py Постоянный запуск из консоли лучше проводить командой python3 mtprotoproxy.py >> out.txt & Тогда прокси уйдёт работать в фон и будет выводить свою статистику раз в 10 минут в файл out.txt. Простенький файл для автозагрузки в /etc/init.d также приложен к сообщению. S61_mtprotoproxy Для подключения к прокси снаружи не забываем открыть соответсвующий порт в фаерволле Keenetic-a. Как говорилось ранее для хоста желательно, особенно для ipv4-ipv6 dual stack, иметь доменное имя, с AAAA и A записями, тогда перадавать ссылку можно будет не ip адресами, а просто хостнеймом одновременно для ipv4 и ipv6. Обсуждение работы и поведения лучше всего вести или здесь, или на канале https://t.me/Keenetic_ru где я тоже присутствую. Детали работы для опытных. Mtprotoproxy имеет возможность работать на 4-х библиотеках шифрования. Встроенной AES, очень медленной, фактически она подходит лишь для тестирования работы python-а, Cryptography, Pycryptodome и Pycrypto. Как показали мои синтетические тесты разницы в скорости работы между Cryptography и Pycryptodome практически нет, но если всё-таки найдутся проблемы, то следует удалить библиотеку python3-cryptography и поставить тестовый build http://bin.entware.net/mipselsf-k3.4/keenetic/test/python3-pycryptodome_3.7.2-1_mipsel-3.4.ipk для моделей DSL, LTE, VOX http://bin.entware.net/mipssf-k3.4/test/python3-pycryptodome_3.6.6-1_mips-3.4.ipk Edited December 11, 2018 by Kirya Редактирование ссылки на новый pycryptodome 5 Share this post Link to post Share on other sites
Report post 07/11/2018 01:34 PM В 01.07.2018 в 23:36, Kirya сказал: и теперь можно сказать определённо - привет DPI-ям, которые будет пробовать блочить на уровне пакетов mtproxy. Эмм, так Ростелеком же блочит по размеру пакетов. Потом и других операторов научат (( https://github.com/darkk/poormansmtproto https://habr.com/post/414099/ за развитием MTProxy не слежу (все и без проксей робит), может что-то и поменяют в реализации.. Share this post Link to post Share on other sites
Report post 07/11/2018 01:57 PM 7 минут назад, Вежливый Снайпер сказал: Эмм, так Ростелеком же блочит по размеру пакетов. Потом и других операторов научат (( https://github.com/darkk/poormansmtproto https://habr.com/post/414099/ за развитием MTProxy не слежу (все и без проксей робит), может что-то и поменяют в реализации.. Леонид сам писал, что они не успели проверить всё, поэтому "пробовал" (тут важно прошедшее время). Но суть не в этом. А в том, что после широкой огласки сигнатуры MTProto, основанные на размере пакета, были добавлены во многие корп. фаерволлы и DPI. (хотя скорее всего они и сами бы до этого дошли) Поэтому в MTprotoproxy появился дополнительный спец. ключ работы с клиентом (на скрине они с пометкой beta), где размер пакета динамически меняется. (поддержка данного режима работы в официальных клиентах уже тоже есть) Share this post Link to post Share on other sites
Report post 08/02/2018 08:27 PM (edited) Ускоряем работу MTprotoproxy. Ускорить работу фактически в полтора раза можно собрав для MTP python-библиотеку работы uvloop. https://github.com/MagicStack/uvloop/ Но ускорения достигается за счет более большого потребления памяти до 60-65 мб, но зато потребление перестаёт зависит от того работает MTP в режиме "эмуляции клиента" или через middle-proxy. 1. Скачиваем пакет библиотеки. http://bin.entware.net/mipselsf-k3.4/keenetic/test/python3-uvloop_0.11.3-1_mipsel-3.4.ipk (для DSL, LTE, VOX http://bin.entware.net/mipssf-k3.4/test/python3-uvloop_0.11.2-1_mips-3.4.ipk ) 2. Ставим. opkg install python3-uvloop_0.11.2-1_mipsel-3.4.ipk Запускаем MTP. Работать с uvloop он начинает при его наличии по приоритету сам. python3 mtprotoproxy.py >> out.txt & Edited December 11, 2018 by Kirya Изменение под uvloop 0.11.3. Share this post Link to post Share on other sites
Report post 08/16/2018 02:44 PM (edited) uvloop, оформленный в виде пакетов для mips (DSL,LTE,VOX) и mipsel (остальные): python3-uvloop_0.11.2-1_mips-3.4.ipk python3-uvloop_0.11.2-1_mipsel-3.4.ipk ! upd python 3.7 python3-uvloop_0.11.2-1_mips-3.4.ipk python3-uvloop_0.11.2-1_mipsel-3.4.ipk Edited September 16, 2018 by TheBB for python3.7 1 Share this post Link to post Share on other sites
Report post 08/16/2018 08:59 PM Respect и уважуха ! Working. Перепишу инструкцию. Share this post Link to post Share on other sites
Report post 09/15/2018 09:17 PM Подредактировал инструкции для свежего Entware 09.18. 1 Share this post Link to post Share on other sites
Report post 09/30/2018 02:08 AM (edited) Добавлю парочку дополнительных пунктов, улучшающих quality of life использования прокси. Для начала - случай с публичными вайфаями, которые блокируют нестандартные порты и, тем самым, перекрывают доступ к прокси. Поначалу пытался обойти напрямую, подняв MTProto на порту 443, и ожидаемо получил отказ от роутера по причине "место занято". После этого решил воспользоваться другим, простым как топор, решением - и оно таки сработало: провести переадресацию с порта 443 интерфейса выхода в интернет на порт, который занимает MTProto: Соответственно, ссылка для клиента меняется с tg://proxy?server=<АДРЕС-СЕРВЕРА>&port=54321&secret=<КЛЮЧ> на tg://proxy?server=<АДРЕС-СЕРВЕРА>&port=443&secret=<КЛЮЧ> Результат в "фашиствующем вай-фае": Скрытый текст Далее - про помянутый в инструкции AAAA-hostname: для него воспользовался другим топорным решением - хостом от No-IP. Судя по наблюдению, прок от него таки есть - зачастую соединение по буквенной ссылке идёт быстрее, чем по ip-адресу, ну и для роутеров с динамическим ip использование подобного сервиса - единственный вариант. От себя добавлю пару вопросов: возможно ли как-то дополнительно прописать фильтрацию (через iptables/ip6tables и/или acl для ipv4 и ipv6 в CLI-роутера, например) для 443 порта, чтобы на MTProto шли только обращения для него, а не безусловно все конкретно для этого порта, и имеет ли смысл дополнительно прописывать хост от No-IP в настройках DNS-прокси роутера (в моём случае - dnscrypt2)? Edited September 30, 2018 by UweStrich отправил пост раньше времени; уточнение вопроса Share this post Link to post Share on other sites
Report post 10/06/2018 12:36 PM (edited) Небольшое обновление через неделю "тестирования": безусловное перенаправление с порта 443 на порт mtprotoproxy, которое я описал ранее, и правда оказалось "топорным". Конечно, в быту оно редко даёт о себе знать, но при перезагрузке роутера оно начинает конфликтовать с запуском установленного у меня dnscrypt2, плюс не даёт получить список обновления для прошивки NDM. Если кто-то сможет предложить способ фильтровать обращения на порт 443 для mtprotoproxy без проброса по NAT - буду признателен. Между делом, попытался научить mtprotoproxy запускаться автоматически, т.к. файл автозапуска из шапки темы у меня при перезагрузке не срабатывал. В баше не силён, поэтому пришёл к костыльному, но рабочему решению - запуску скрипта в терминале screen. Если он ещё не установлен - ставим: opkg install screen И вставляем приложенный файл в /opt/etc/init.d/ Код скрипта с комментариями: Скрытый текст #!/bin/sh PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PROXYLOC=/opt/root/mtprotoproxy NM=MTProto #RULE="ip static rule 0 disable" #Переменная $RULE является командой CLI для отключения проброса портов по самому первому #правилу в списке (отсчёт ведётся с 0, в веб-интерфейсе роутера оно - первое сверху в списке), #и выполняется в CLI при помощи пакета ndmq. У себя я его использую для отключения проброса с #порта 443 TCP при отключении роутера, т.к. безусловное перенаправление конфликтует с #некоторыми другими пакетами (нпр, dnscrypt2) во время включения машины. Отсюда и номер 98 в #названии скрипта - чтобы скрипт автозапуска включился позже остальных скриптов, #и перенаправление для mtprotoproxy с порта 443 включилось тогда, когда остальным пакетам #порт 443 больше не был бы нужен. #TL;dR - в опубликованной версии скрипта переменная для пакета ndmq и команды для его вызова #закомментированы, т.к. для работы непосредственно mtprotoproxy на его личном порту они не #нужны. Однако, в случае использования переадресации с 443 порта - см. заметку выше и #раскомментировать их, при необходимости внеся в них правки, и проинсталлировать #ndmq, если это не было сделано ранее: #opkg install ndmq start() { screen -s /bin/sh -L -Logfile $PROXYLOC/log.txt -dmS $NM -t $NM python3 $PROXYLOC/mtprotoproxy.py #sleep 120 && ndmq -p "no $RULE" } #Запускаем скрипт прокси в отдельном терминале, включем правило переадресации. #При желании посмотреть на терминал, в котором работает скрипт, и на собранную за #последнее время статистику - ввести в терминале следующую команду: #screen -r MTProto #для выхода из терминала screen без прерывания его работы - зажать клавиши Ctrl и "A" и, #не отпуская, прожать "D" stop() { #ndmq -p "$RULE" && ndmq -p "system configuration save" screen -S $NM -X kill } #Отключаем правило переадресации и сохраняем это отключение в конфигурации NDM, затем - #отключаем терминал screen, в котором работает скрипт case "$1" in start) start ;; stop) stop ;; restart) stop start ;; *) echo "Usage: $0 (start|stop|restart)" exit 1 ;; esac S98mtprotoproxy Edited October 6, 2018 by UweStrich исправление в коде скрипта Share this post Link to post Share on other sites
Report post 10/06/2018 08:57 PM 8 часов назад, UweStrich сказал: Если кто-то сможет предложить способ фильтровать обращения на порт 443 для mtprotoproxy без проброса по NAT - буду признателен. А если попробовать в сторону публикации ресурса на домене четвертого уровня? Share this post Link to post Share on other sites
Report post 10/06/2018 10:04 PM (edited) 1 час назад, PoliceMan сказал: А если попробовать в сторону публикации ресурса на домене четвертого уровня? Создать внутренний интерфейс, который будет слушать mtprotoproxy на 443 порту (IP-адрес интерфейса можно задать в настройках версии master проксика), и на этот интерфейс устроить проброс по домену... Есть сомнения (формально ведь - то же перенаправление, только в профиль), но может и стоит попробовать. Впрочем, всё равно кажется что от правил фильтрации в iptables был бы больший прок - жаль, что я смыслю в них ещё меньше, чем в баше. Edited October 6, 2018 by UweStrich Share this post Link to post Share on other sites
Report post 10/06/2018 10:07 PM В веб-интерфейсе есть доступ к внутренним ресурсам по имени. Там можно выбрать на какой ресурс внутри сети давать доступ (в том числе и сам кинетик), по какому домену четвертого уровня и на какой порт внутри сети пробрасывать. Поднимаете mtprotoproxy на любом порту, настраиваете правило и ресурс становится доступным по указанному имени, на 443 порту. Не факт что взлетит, но попробовать стоит. Share this post Link to post Share on other sites
Report post 10/06/2018 10:39 PM (edited) 35 минут назад, PoliceMan сказал: В веб-интерфейсе есть доступ к внутренним ресурсам по имени. Там можно выбрать на какой ресурс внутри сети давать доступ (в том числе и сам кинетик), по какому домену четвертого уровня и на какой порт внутри сети пробрасывать. Поднимаете mtprotoproxy на любом порту, настраиваете правило и ресурс становится доступным по указанному имени, на 443 порту. Не факт что взлетит, но попробовать стоит. Т.е., если правильно понял, поднять поддомен tg на example.keendns.net на 443 порту, и выдавать ссылки формата "tg://proxy?server=tg.example.keendns.net&port=54321&secret=<КЛЮЧ>"? В таком виде пробовал: работало, но вплоть до подключения к "фашистскому" публичному вайфаю, на котором перекрыты все TCP-порты кроме 443-го, т.е. указанный в ссылке порт является также и портом для исходящего соединения от клиента. Наоборот (т.е. вешаем домен на порт Телеграма, а клиенту велим использовать порт 443) также не выйдет: соединения тогда не будет совсем. И сразу упреждая следующий вопрос: нет, часть "&port=<ПОРТ>" в ссылке обязательна - Телеграм ссылку без неё не распознаёт как ссылку на прокси-сервер, и задать проксик в настройках вручную, без указания порта, также не позволяет. Edited October 6, 2018 by UweStrich Share this post Link to post Share on other sites
Report post 10/06/2018 10:44 PM Нет, порт должен быть 443. keendns.net вроде не дает ssl сертификаты. См скриншоты. mtproto висит на порту 5443. Ссылка для телеги вида tg.<domain>.keenetic.link&port=443 Share this post Link to post Share on other sites
Report post 10/06/2018 10:57 PM (edited) В 07.10.2018 в 01:44, PoliceMan сказал: См скриншоты. mtproto висит на порту 5443. Ссылка для телеги вида tg.<domain>.keenetic.link&port=443 Нет, к сожалению, не работает: сейчас проверяю на телефоне через сотовое соединение, и без включенной безусловной переадресации на роутере телефон отказывается подключаться к прокси-серверу по такой ссылке. UPD: буквально только что на хабре наткнулся на статью по теме. Её пока не читал, но упоминаемый ещё в самом начале sslh имеется в списках пакетов Entware, так что завтра попытаюсь ознакомиться с материалом. UPD2: вчера решил подойти к проблеме с другого конца, и разобраться, что именно занимало порт на прослушивание. Оказалось - прошивочная служба для использования облака и ssl-подключения к роутеру. Т.к. я ими не пользуюсь - решил снести их и отключить службу через CLI (спасибо @KorDen за подтверждение в другой ветке, что нужная команда - 'no ip http ssl enable'). Внимание: непосредственно через CLI отключение через "no ip http ssl enable" может не произойти (у меня, например, происходило зависание терминала, и роутер в панике от неё начинал грузить одно из ядер), поэтому может понадобиться править startup-config прошивки (доступен в списке файлов в "Общих настройках системы" веб-интерфейса), где нужная строка примет вид "ip http ssl no enable". После этих манипуляций и смены порта mtprotoproxy на 443 всё завелось, как надо: и прокси работает с минимально возможными пингами, и роутер не жалуется на недоступность обновлений. Edited October 8, 2018 by UweStrich уточнения, орфография, ссылка на новую зацепку, обновление по 443 порту 1 Share this post Link to post Share on other sites
Report post 10/26/2018 01:54 PM OSError: [Errno 125] error while attempting to bind on address ('0.0.0.0', 3256): address already in use Всплывает такая ошибка. Может кто-то знает как исправить. Не могу понять куда двигаться,как исправить. Share this post Link to post Share on other sites
Report post 10/26/2018 01:58 PM Занят у вас уже чем-то порт 3256. У вас случайно в автозагрузке уже MTproto не стартанул и прописан ? Посмотрите запущенные процессы командой "ps". 1 Share this post Link to post Share on other sites
Report post 11/28/2018 02:38 PM .../python3-pycryptodome_3.7.2-1_mipsel-3.4.ipk .../python3-uvloop_0.11.3-1_mipsel-3.4.ipk Share this post Link to post Share on other sites
Report post 12/11/2018 12:21 PM Thx ! Обновил ссылочки в инструкциях. Share this post Link to post Share on other sites
Report post 12/15/2018 05:41 AM Друзья, я вот ламер в таких вопросах, может подскажите - есть возможность в конфиге mtprotoproxy указать parent прокси? Хоть socks5, хоть http? Чтобы он не напрямую ломился в инет, а через вышестоящий прокси-сервер? Share this post Link to post Share on other sites
Report post 12/15/2018 10:37 PM Нет, но этот функционал можно попросить добавить. Сделай запрос автору https://github.com/alexbers/mtprotoproxy/issues Share this post Link to post Share on other sites
Report post 12/16/2018 06:45 AM Попросил. Так удалось кому-нибудь через "облачный" KeenDNS расшарить этот прокси для телеги? Я уж по-всякому пробовал, но безуспешно. В "облачном" режиме только HTTP/HTTPS. Где-то читал, что MTProto - это почти HTTP. Выходит, что не почти? Если удалось, расскажите, пожалуйста, ещё раз - как пошагово сделать проброс именно на роутере (сам проект успешно развёрнут и из локалки доступен) при условии "серого" адреса и использования КинДНС. Share this post Link to post Share on other sites
