Jump to content

UweStrich

Forum Members
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    1

UweStrich last won the day on May 26

UweStrich had the most liked content!

Community Reputation

7 Neutral

About UweStrich

  • Rank
    Member
  • Birthday October 26

Equipment

  • Keenetic
    Zyxel Ultra Rev.A

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. UweStrich

    На фоне новостей про "тестирование РКН окончательной блокировки Telegram на тюменцах", а так же продолжающемуся развитию python-версии MTProto, решился на выходных основательно засесть за "допиливание" крутящегося на роутере личного проксика таким образом, чтобы он и в качестве бэкэнда работал за другим проксирующим сервером (в моём случае - nginx), и чтобы при этом работала поддержка fake-tls, маскирующегося при этом под сертификат на фронтенде. Важный дисклеймер: описанный ниже способ несовместим с защищёнными доменами от KeenDNS (по крайней мере - на прошивке 2.16), так как nginx из Entware нужно будет слушать на порту 443, также используемой прошивочной службой. Помимо этого, должен оговорить что доменное имя получено от noip (статья по настройке), айпи-адрес при этом - "белый", купленный за сотню в месяц у провайдера. Шаг нулевой (поначалу - неочевидный): скомпилировать nginx, как минимум - поддерживающий необходимый для проксирования набор опций ("--with-stream_proxy_module" и "--with-stream_ssl_preread"), а как максимум - ещё и несколько опций, полезных при логировании перенаправлений ("--with-stream_realip_module", например); полный вывод "nginx -V" - под катом, установочный архив под mipsel - nginx-extratest_1.16.1-1c_mipsel-3.4.ipk (под mips - т.е. для Zyxel Keenetic LTE, например, - не компилировал, но позже могу добавить, если окажется востребованным) Шаг 0.5: настройки в веб-интерфейсе. Отключаем доступ к админке через интернет: настраиваем перенаправление с 80-го порта внешнего интерфейса на другой адрес (в данном случае - 127.0.0.1:8888) Шаг 1: настроить получение сертификата Let's Encrypt для nginx. Настройка проводилась по инструкции на гитхабе проекта Entware (на английском, но наиболее современная; некоторые команды и ссылки в аналогичной инструкции на русском за годы с момента написания успели устареть). Неизбежные отклонения из-за другого пакета (пакет на базе nginx-extras вместо обычного nginx) и из-за требований для маскировки прокси под TLSv1.3: во-первых, за неимением какого-либо поднятой на роутере обычной страницы, пришлось методом копирования "привить" от обычного пакета "стандартную заглушку" (html.zip), т.к. в своё время при настройке nginx-extras стандартной заглушки от него я не заметил; во-вторых, описанные в инструкции настройки, по большей части, проводились не в nginx.conf, а в "/sites-available/default"; изменения для поддержки TLSv1.3 также пришлось внести и в "ssl.conf". По окончании всех шагов, содержимое файла "default" приняло такой вид (комментарии из оригинального файла удалены для краткости, домены - заменены): а файла "ssl.conf" - такой: сертификат при этом запрашивался следующей командой: bash ./dehydrated --domain имя.дднс.нет --ocsp -a rsa -t http-01 --cron Шаг 2: Настраиваем config.py у mtprotoproxy для работы с фронтендом: далее - в папке /opt/etc/nginx создаём файл "stream.conf" с примерно таким содержимым: и прописываем строчку "include stream.conf" в конфиге "nginx.conf" перед/после блока http, а в шапке конфига - прописываем load_module "/opt/lib/nginx/ngx_stream_module.so"; пример рабочего "nginx.conf": после чего - перезагружаем mtprotoproxy и nginx ("/opt/etc/init.d/S80nginx reload") Эта конфигурация обеспечивает не только работу fake-tls на 443 порту, но также и обеспечивает "обратную совместимость" с более старой версией mtproto (секреты, начинающиеся с "dd"); работает она у меня уже несколько дней, и насколько могу судить - mtprotoproxy за nginx оказался даже более производительным, чем наоборот, как понимаю - в первую очередь из-за использования юникс-сокета во временной памяти: по "оценкам на глаз по пингу в Телеграмме" - где-то в полтора-два раза быстрее. Однако хочу сразу заметить, что всё описанное выше не претендует на "идеальность" или "полноту", и если имеются какие-то замечания и исправления от опытных специалистов - готов внести исправления и уточнения. P.S.: минутка зависти к владельцам роутеров с поддержкой ядра линукса 4.9 - на них, скорее всего, в ядре включен REUSEPORT, а значит - с Debian вместо Entware можно было бы добиться большей производительности и nginx, и самого mtprotoproxy.py...
  2. UweStrich

    Обязан сделать одну ремарочку, т.к. сам с пайтоном "на Вы", и слишком долго бился над установкой этого "колеса": при попытке установить его стандартной командой python3 -m pip install ./uvloop-0_12.2-cp37-cp37-mipsel-34_Ent1903.whl пип ругался подобным образом - ERROR: uvloop-0_12.2-cp37-cp37-mipsel-34_Ent1903.whl is not a supported wheel on this platform. С энного захода в гугл и по удачной ссылке в выдаче, таки выяснил что pip чувствителен к названию файла .whl, т.к. в нём содержится информация о версии пайтона и о платформе, для которой колесо собрано, и что переименование файла "для удобства хранения" чревато вот такими ошибками при попытке установки колеса. Вооружившись этим знанием (а так же способом выяснить, какие "колёса" поддерживает пайтон на роутере): переименовал файл из "uvloop-0_12.2-cp37-cp37-mipsel-34_Ent1903.whl" в "uvloop-0_12.2-cp37-cp37-linux_mips.whl". После этой манипуляции колесо успешно установилось: python3 -m pip install ./uvloop-0_12.2-cp37-cp37-linux_mips.whl Processing ./uvloop-0_12.2-cp37-cp37-linux_mips.whl Installing collected packages: uvloop Successfully installed uvloop-0.12.2 Надеюсь, этот "дебаг" поможет остальным обновиться до более актуальной версии uvloop 🙂
  3. Минимум - А (именно начиная с него пакет Entware из этой темы начнёт работать), С - более новая, её можно считать стабильной, и большая часть багов в ней прихлопнута. Шанс "окирпичить" девайс резкими движениями есть, поэтому стоит прочитать инструкции по перепрошивке; ссылки на них даны в той теме, на которую указал @Михаил Лукьянов
  4. Значит, нужно ставить из экспериментальной ветки (на files.keenopt.ru - вот здесь, последняя версия там - 2.12.A.1.0-4), либо - скачивать более новые для своей модели с неофициального хранилища в облаке (2.13.C.0.0-4 - Яндекс.диск) Предварительно советую всё, что возможно, сохранить - перепрошивка подразумевает сброс настроек.
  5. Не столько оттуда, сколько отсюда:
  6. UweStrich

    Нет, к сожалению, не работает: сейчас проверяю на телефоне через сотовое соединение, и без включенной безусловной переадресации на роутере телефон отказывается подключаться к прокси-серверу по такой ссылке. 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 всё завелось, как надо: и прокси работает с минимально возможными пингами, и роутер не жалуется на недоступность обновлений.
  7. UweStrich

    Т.е., если правильно понял, поднять поддомен tg на example.keendns.net на 443 порту, и выдавать ссылки формата "tg://proxy?server=tg.example.keendns.net&port=54321&secret=<КЛЮЧ>"? В таком виде пробовал: работало, но вплоть до подключения к "фашистскому" публичному вайфаю, на котором перекрыты все TCP-порты кроме 443-го, т.е. указанный в ссылке порт является также и портом для исходящего соединения от клиента. Наоборот (т.е. вешаем домен на порт Телеграма, а клиенту велим использовать порт 443) также не выйдет: соединения тогда не будет совсем. И сразу упреждая следующий вопрос: нет, часть "&port=<ПОРТ>" в ссылке обязательна - Телеграм ссылку без неё не распознаёт как ссылку на прокси-сервер, и задать проксик в настройках вручную, без указания порта, также не позволяет.
  8. UweStrich

    Создать внутренний интерфейс, который будет слушать mtprotoproxy на 443 порту (IP-адрес интерфейса можно задать в настройках версии master проксика), и на этот интерфейс устроить проброс по домену... Есть сомнения (формально ведь - то же перенаправление, только в профиль), но может и стоит попробовать. Впрочем, всё равно кажется что от правил фильтрации в iptables был бы больший прок - жаль, что я смыслю в них ещё меньше, чем в баше.
  9. UweStrich

    Небольшое обновление через неделю "тестирования": безусловное перенаправление с порта 443 на порт mtprotoproxy, которое я описал ранее, и правда оказалось "топорным". Конечно, в быту оно редко даёт о себе знать, но при перезагрузке роутера оно начинает конфликтовать с запуском установленного у меня dnscrypt2, плюс не даёт получить список обновления для прошивки NDM. Если кто-то сможет предложить способ фильтровать обращения на порт 443 для mtprotoproxy без проброса по NAT - буду признателен. Между делом, попытался научить mtprotoproxy запускаться автоматически, т.к. файл автозапуска из шапки темы у меня при перезагрузке не срабатывал. В баше не силён, поэтому пришёл к костыльному, но рабочему решению - запуску скрипта в терминале screen. Если он ещё не установлен - ставим: opkg install screen И вставляем приложенный файл в /opt/etc/init.d/ Код скрипта с комментариями: S98mtprotoproxy
  10. UweStrich

    Добавлю парочку дополнительных пунктов, улучшающих 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)?
  11. Одна из возможных причин - серьёзный рассинхрон системного времени на роутере с фактическим, т.е. скорее всего понадобится в веб-интерфейсе включить автоматическую синхронизацию, плюс через telnet заставить роутер чаще обновлять время (не раз в неделю, как по умолчанию, а допустим каждые четыре часа), введя следующие команды: ntp sync-period 240 copy running-config startup-config
  12. Хм... попробуйте установить пакет ca-certificates - может, он поможет. В ином случае - стоит спросить в топике с инструкцией.
  13. Походу, провайдер производит блокировку через подмену DNS; подтвердить подозрение можно через утилиту blockcheck (ссылка на релизы), а бороться с подменой DNS - при помощи dnscrypt-proxy:
  14. Насколько понимаю, пытаетесь настроить для работы клиентов Telegram на компьютерах и телефонах? Попробуйте прописать аналогичные правила для других подсетей телеграмма (на вскидку - 149.154.160.0/20, 149.154.164.0/22, 91.108.4.0/22, 91.108.56.0/22, и 91.108.8.0/22) - может, поможет.
  15. Ну, всё равно было полезно - что мне, что вам Жаль, правда, что так и не выяснили, что барахлило - tor или curl... *** Как и обещал на прошлой неделе - текущий конфиг; как я заметил, 3proxy почему-то не любит комментарии в той же строке, что и работающий параметр (или отбивку этих комментариев табуляцией), поэтому в этом конфиге строк будет больше: Особое внимание на строки "monitor /tmp/currentip" и "socks -4 -n -p63128 -i$/tmp/currentip -e127.0.0.1 -S8192" - в файле по пути /tmp/currentip хранится ip-адрес, принадлежащий интерфейсу для выхода в интернет. Этот файл можно создавать и модифицировать при помощи скрипта в папке /opt/etc/ndm/wan.d - Выставляем исполняемые права скрипту, введя в консоли следующую команду: chmod +x /opt/etc/ndm/wan.d/01-current-ip.sh Благодаря такой связке можно конкретно указать программе, какой интерфейс она должна прослушивать. Для постоянного же подключения к роутеру, даже при изменении его белого ip (разумеется, если динамические ip от провайдера белые), можно использовать DynDNS (статья в базе знаний). Ну, и обязательный дисклеймер о том, что способ выше вполне можно считать "стрельбой по воробьям из пушки" - с тем же успехом вместо конкретного ip интерфейса можно указать прослушивать все интерфейсы, т.е. строка конфига, поднимающая socks-прокси, примет следующий вид: socks -4 -n -p63128 -i0.0.0.0 -e127.0.0.1 -S8192
×
×
  • Create New...