UweStrich

"Баловался" когда-то игдрассилем на роутере, остановился тогда из-за лени накатать скрипт автозапуска и - особенно, - правила для iptables, так что большое спасибо за них 👍 От себя правда добавлю то, что и в тех тогдашних опытах, и в нынешних по следам темы, вместо radvd из Entware воспользовался функционалом ipv6 непосредственно роутера - пускай и не особо элегантным способом: прописал дополнительным соединением тоннель SixInFour на адрес роутера, указав в нём полученные из конфига адреса ipv6 и префикс: после чего в CLI задал mtu на тоннеле, прописал маршрут до подсети Yggdrasil, и сохранил, с последующей перезагрузкой роутера: interface TunnelSixInFour0 ip mtu 1280 ipv6 route 200::/7 TunnelSixInFour0 system configuration save Ну, и т.к. скорости в Yggdrasil только через роутер (KN-1011 в моём случае; интересно было бы посмотреть на скорости от роутера на ARM-процессоре вроде KN-2710 - процессор мощнее, а значит и шифрование пройдёт быстрее и с увеличением скоростей...) будут заведомо меньше чем от связки "Yggdrasil что на роутере, что на ПК", то дополнительно - ради стабильности соединения, - сменил всё в том же CLI роутера планировщик пакетов на интерфейсе тоннеля с дефолтного fq_codel на cake, с последующим сохранением: interface TunnelSixInFour0 tx-queue scheduler cake system configuration save Под катом - сравнение по замерам "до" и "после" смены планировщика пакетов на интерфейсе (хотя не буду отрицать, что могла также сказаться и нагрузка непосредственно на сервер тестирования скорости), из отмеченного - уменьшение колебания пинга (jitter):

На фоне новостей про "тестирование РКН окончательной блокировки 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...

Обязан сделать одну ремарочку, т.к. сам с пайтоном "на Вы", и слишком долго бился над установкой этого "колеса": при попытке установить его стандартной командой 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 🙂

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

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

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

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

Добавлю парочку дополнительных пунктов, улучшающих 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)?

Одна из возможных причин - серьёзный рассинхрон системного времени на роутере с фактическим, т.е. скорее всего понадобится в веб-интерфейсе включить автоматическую синхронизацию, плюс через telnet заставить роутер чаще обновлять время (не раз в неделю, как по умолчанию, а допустим каждые четыре часа), введя следующие команды: ntp sync-period 240 copy running-config startup-config

Радикально, но сработало. Благодарю.

Попробовал настроить блокировку рекламы через Privoxy (топик), настраивал по инструкциям в шапке с использованием конфигов и скриптов из этого поста. Хочу сразу сказать большое спасибо пользователям @Sunix и @Dorik1972 за инструкции по настройке, и @zyxmon - за советы по отладке правил маршрутизации: фильтр поднялся, и в текущем состоянии блокирует большую часть рекламы (в т.ч в некоторых приложениях на iOS после указания прокси в настройках WiFi). Теперь - к проблеме, с которой я столкнулся: скрипт от @Dorik1972 для обновления фильтров отказывается выполняться, жалуясь на отсутствующий модуль: ~ # ../etc/privoxy/privoxy-bl-upd.pl Can't locate strict.pm in @INC (you may need to install the strict module) (@INC contains: /opt/lib/perl5/5.24 .) at ../etc/privoxy/privoxy-bl-upd.pl line 28. BEGIN failed--compilation aborted at ../etc/privoxy/privoxy-bl-upd.pl line 28. Были подозрения, что где-то напортачил при установке/распаковке архива или не задал нужные права на исполнение, но поиск "strict.pm" по системе результатов не дал, т.е. нужный файл, похоже, и правда отсутствует. Пожалуйста, помогите. Пациент - Keenetic Ultra rev.A v2.08(AAGJ.0)C2, система - Entware-3x, список установленных пакетов - под катом. Если потребуется ещё какая-то информация - буду готов предоставить. privoxy_conf_v.2.tar.gz

Эх, появись эта тема на пару месяцев раньше - мне, как опытному ламеру и сертифицированному гуманитарию, было бы куда легче настраивать ntpd: в сети слишком много инструкций и советов по решению проблем для очень разных систем и версий программы. С другой стороны, какая-то информация пригодилась и осела в голове и конфигах - может, смогу помочь обтесать инструкцию. Для начала оговорюсь, что ставил и настраивал "голый" ntpd (без ntp-utils, ntp-keygen, и ntpdate) для Keenetic Ultra Rev.А (NDMS v2.08(AAGJ.0)C2, Entware-3x), т.е. возможно те проблемы, с которыми сталкивался я, у автора не возникали из-за разницы в оборудовании, версиях прошивок, и установленных пакетов. Теперь - к странностям, которые заметил в конфиге (опять же, крайне вероятно что это я ничего не понял) и решения тех проблем, с которыми я столкнулся: путь в параметре "driftfile" к файлу "ntp.drift" оставлен по умолчанию, хотя в скрипте запуска "S77ntpd" вместо пути "/opt/var/lib/ntp/ntp.drift" указан "/opt/var/spool/ntp/ntp.drift". Из-за этого расхождения демон ожидаемо ругался в логах на отсутствие нужной папки и не мог записать файл на постоянную основу: 6 Jul 17:11:50 ntpd[13546]: frequency file /opt/var/lib/ntp/ntp.drift.TEMP: No such file or directory Файл является критичным, т.к. именно в нём ntpd сохраняет вычисляемую им погрешность часов, и без неё работа демона не имеет смысла. Свою неполадку я решил редактированием пути в конфиге на путь из скрипта запуска. Помимо этого, стоит убедиться что ntpd имеет права производить запись по указанным путям и что файлы в указанных папках не стираются при перезагрузке роутера (в случае с путём из скрипта вышесказанное является верным - возможно, именно поэтому он и отличается от конфигурационного). Советую перепроверить оба пути на наличие файла погрешности, при его отсутствии - исправить конфиг. Во-вторых: возможны неполадки при одновременной работе разных процессов обновления времени. Мне, например, пришлось отключить обновление времени в веб-интерфейсе NDMS. В-третьих: при серьёзном расхождении времени системы с полученным временем от серверов (1000 секунд и более) ntpd "паникует" и отключается, с чем я по незнанию и столкнулся после перезагрузки роутера. Чтобы привести его в чувство, необходимо вручную задать дату со временем по любым достаточно точным часам и произвести перезапуск скрипта: date -s ГГГГ-ММ-ДД чч:мм /opt/etc/init.d/S77ntpd restart Чтобы каждый раз после перезагрузки роутера не заниматься вводом этих команд, дополнительно был установлен пакет "fake-hwclock", сохраняющий показания времени при выключении роутера в отдельный файл и выставляющий их при его включении (хотя, как понимаю, с этим так же может справиться и ntpdate, который себе я не ставил - призываю более компетентных людей на помощь). Допытывание у Гугла также показало, что аргумент "-g" при запуске ntpd заставляет его перестать паниковать и таки произвести сверку часов; я посчитал, что имеет смысл дополнительно его прописать в строке ARGS= скрипта автозапуска. Возвращаясь к конфигу, хочу обратить внимание на пункт "server 127.127.1.0 iburst". Cудя по документации для сравнительно недавней версии 4.2.8p8, этот адрес - указание для ntpd использовать драйвер, позволяющий использовать собственные часы системы (в нашем случае - роутера) как источник точного времени при отсутствии более надёжных, т.е. если я правильно понимаю, параметр iburst для него не нужен. При этом на других сайтах в официальной вики ntp.org (версия из кэша Google, на случай если страница не только у меня недоступна) из-за неточности этого драйвера рекомендуют обязательно настроить этот сервер как сервер Stratum-10, цитирую: Благо, для этого надо лишь дописать в "ntp.conf" всего одну строчку: fudge 127.127.1.0 stratum 10 Были у меня и ещё вопросы к предложенной конфигурации, но ввиду собственного ламерства будет гораздо честнее выложить инструкцию, на которую сам оглядывался при настройке, приложить собственный конфиг, и дождаться замечаний от более опытных пользователей.