Ponywka

Ну потому что если брать мой случай - в других прошивках (OpenWRT, DD-WRT, AsusWrt-Merlin и прочих) нет ndmc - это есть исключительно на роутерах семейства Keenetic (и, потенциально, на других роутерах, с ПО от https://ndmsystems.ru/)?

Раз уж началась такая пляска, то добавлю свои пять копеек в этот тред, т.к. он касается и меня в том числе, а также повлиял на мою дальнейшую смену роутера (в отрицательном для сообщества Keenetic значении). Моему софту MagiTrickle это тоже мешает. Я писал свой софт так, чтобы все правила жили в своих iptables chain, и уже они подключались в конец всех правил, и чтобы не пересекались с основными правилами (чтобы, например, если возникли какие-либо проблемы - мои правила можно было очень быстро найти и подчистить, не высматривая их среди огромного списка iptables-save). Под капотом в моём софте происходит что-то по типу: iptables -t nat -N MT_DNSOR iptables -t nat -A MT_DNSOR -d 192.168.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination :3553 iptables -t nat -A MT_DNSOR -d 192.168.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination :3553 iptables -t nat -A PREROUTING -j MT_DNSOR Время выполнения команды "iptables" если быть честным - очень долгое (уже не помню, но чот около 100мс на каждый индивидуальный вызов iptables, что выливается в секунды выполнения, за которые Keenetic успевает выполнить чистку правил). И по факту между выполнением этих команд Keenetic начинает чистку iptables, после чего я получаю ошибку в стиле "iptables: no chain MT_DNSOR", потому что мой код не успел вовремя заполнить таблицу нужными значениями. Моё ПО кросс-платформенное. Я не ориентируюсь только на один Keenetic. Городить костыли по типу "если зафейлилось - повторить" не собираюсь, потому что вместо ошибки "iptables: no chain MT_DNSOR" вполне может затесаться ошибка по типу "iptables: no module loaded" (условно), и в подобном случае аварийная остановка моей программы - оправдана, и пытаться выполнить перезагрузку - бессмысленно. В результате, из-за частых сбросов iptables, особенно в момент запуска роутера, мне пришлось городить костыль, который бы пытался запускать сервис после перезагрузки роутера в течении 5-ти минут. GitLab (/opt/etc/init.d/S99magitrickle) Потенциально эта проблема исправляется вызовами iptables-save и iptables-restore --noflush (высчитывая разницу между тем, что есть, и тем, что должно быть, формируя diff в формате iptables-restore), что я реализовал в коммите GitLab (Commit 6e4bd9c0), однако (далее скорее является моим багом, но если бы не ситуация с очисткой - мне бы и не пришлось делать что-то подобное) теперь возникает такая ситуация, что если Keenetic вызовет несколько раз вызов netfilter.d, то я получу такую ситуацию, что: --- Вызов netfilter.d --- iptables-save > (/dev/stdout) iptables-restore --noflush < (/dev/stdin) --- Вызов netfilter.d --- iptables-save > (/dev/stdout) iptables-restore --noflush < (/dev/stdin) --- Вызов netfilter.d --- iptables-save > (/dev/stdout) --- Вызов netfilter.d --- iptables-save > (/dev/stdout) iptables-restore --noflush < (/dev/stdin) iptables-restore --noflush < (/dev/stdin) По итогу из-за того, что я не могу заблокировать iptables между запросами iptables-save и iptables-restore - у меня происходит дубликация правил. Реализовывать нативную работу iptables на Go (как это делает сам бинарник "iptables" работая с самим ядром Linux) ради одного KeeneticOS, когда на других платформах всё работает и без этого - желания как такового ноль. И это не говоря о том, что мне в целом приходится ловить эвент с помощью Bash скриптов, оборачивать их в RAW HTTP соединение (либо городить внутренний бинарный API либо по собственному протоколу, либо gRPC), и уже обрабатывать это событие индивидуально в программе, что опять же, считаю костылём. GitLab (/opt/etc/ndm/netfilter.d/100-magitrickle) Этих проблем нет на таких прошивках, как DD-WRT и OpenWRT (где на последний я в итоге перешел, ведь он мне даёт больше возможностей, как энтузиасту-разработчику).

Ну вообще мой софт для этого не особо предназначен. Но если сильно хочется, то можно с помощью подсетей (здесь всё, кроме частных адресов (упрощенно говоря - те, которые не относятся к интернету)): 0.0.0.0/5 8.0.0.0/7 11.0.0.0/8 12.0.0.0/6 16.0.0.0/4 32.0.0.0/3 64.0.0.0/3 96.0.0.0/6 100.0.0.0/10 100.128.0.0/9 101.0.0.0/8 102.0.0.0/7 104.0.0.0/5 112.0.0.0/4 128.0.0.0/3 160.0.0.0/5 168.0.0.0/6 172.0.0.0/12 172.32.0.0/11 172.64.0.0/10 172.128.0.0/9 173.0.0.0/8 174.0.0.0/7 176.0.0.0/4 192.0.0.0/9 192.128.0.0/11 192.160.0.0/13 192.169.0.0/16 192.170.0.0/15 192.172.0.0/14 192.176.0.0/12 192.192.0.0/10 193.0.0.0/8 194.0.0.0/7 196.0.0.0/6 200.0.0.0/5 208.0.0.0/4 224.0.0.0/3

Ну... Мы на форуме по Keenetic, поэтому и отвечаю я ответом как бы оно работало на Keenetic. С OpenWRT пока что да, проблемки в плане поднятия репозитория + начиная с 25.X версии они сменили пакетный менеджер. Требуется настроить сборку с помощью OpenWRT SDK, что как бы занимает свободного время, которого, увы, у меня не так много.

mipsel-3.4_kn - Сборка под Entware с ориентиром под Keenetic mipsel-3.4 - Сборка под Entware Отличается тем, что в версии с Keenetic есть хук "ndm/netfilter.d" который существует только на Keenetic. А вообще, в инструкции по установке подключается репозиторий. Можно его юзать, тогда можно будет и не думать 🙃

v0.4.0 (GitLab Release) Changelog: Добавлена поддержка статических IPv6 маршрутов. Оптимизированы правила использующие RegExp. Ответы от DNS сервера теперь приходят сжатые (требуется для некоторых устройств, по типу PS5). (Frontend) При импортировании списка записей в режиме "Auto" домены второго уровня теперь будут определяться как "namespace". (Frontend) Кнопки импорта/экспорта поменяны местами. (Frontend) Неактивные интерфейсы теперь подсвечиваются серым цветов (спасибо @dan0102dan). (Frontend) Мелкие улучшения по дизайну (спасибо @dan0102dan).

Что подразумевается под "снята галочка". Если галочка снята, то домен не участвует в маршрутизации вовсе

Тут неправильная трактовка со стороны пакетного менеджера "opkg" Конкретно: Дословно переводится как: "Существующий конфигурационный файл /opt/var/lib/magitrickle/config.yaml отличается от конфигурационного файла внутри пакета." Фактически это должно трактоваться как "Конфигурационный файл был изменён. На работу влиять не должно, но конфигурация отличается от настроек по-умолчанию". Т.е. не является ошибкой

v0.3.0 (GitLab Release) Changelog: Теперь доступны сборки под Entware (DD-WRT, ASUS-Marlin и т.п.). Теперь доступны сборки под OpenWRT. Исправлено использование IPv6 Upstream DNS серверов (спасибо @dan0102dan). (Keenetic) Исправлен неработающий DNS сервер при подключении по L2TP. (Keenetic) Порог попыток запуска MagiTrickle после перезапуска роутера повышен до 5 минут. (Keenetic) Исправлена ошибка "Opkg::Manager: /opt/etc/ndm/netfilter.d/100-magitrickle: exit code 1" если MagiTrickle находится в оффлайн. (Frontend) Реализован поиск по группам и правилам (спасибо @dan0102dan). (Frontend) Реализовано массовое добавление правил в группы (спасибо @dan0102dan). (Frontend) Реализован Drag and Drop групп. (Frontend) Убраны лигатуры из шрифта (когда "^|" превращался в "↑" и т.п.) (спасибо @dan0102dan). (Frontend) Ну и наконец - добавлена щепотка новогоднего настроения! (опять же - спасибо @dan0102dan).

Ну тут видно, что зависает скачивание на bin.entware.net. Обратись в https://t.me/entware

KN-1012

Роутер может просто не выдерживать алгоритмы шифрования. Тем более, если опираться на KN-1810 указанный в вашем профиле - он на mipsle архитектуре, т.е. слабый на фоне процессоров на aarch64. Тут, увы, только обновлять роутер на что-то поновее

Увы, либо искать ядро, которое умеет поднимать UNIX интерфейс, который будет отображаться в списке "ip link", либо использовать tun2socks. А вообще, клиент прокси же есть внутри компонентов KeeneticOS. Достаточно просто в самом Keenetic создать подключение с адресом прокси на 127.0.0.1, и после использовать в MagiTrickle уже созданный туннель от KeeneticOS

Instagram является запрещенной экстремистской на территории Российской Федерации организацией. Я рекомендую заблокировать этот сервис через MagiTrickle, используя в качестве интерфейса "blackhole" и этот список: https://iplist.opencck.org/?format=text&data=domains&wildcard=1&site=instagram.com добавляя каждую запись в формате "namespace"

Можно

Вообще-то Wildcard (Подстановочный шаблон)

MT по-умолчанию занимает 3553 порт, и после с помощью iptables маскирует (форвардит) 53 порт на 3553-ий. Т.е. ничего менять со стороны adguard-dns не нужно. Кроме этого, люди отписывали, что у них всё работает

Так менять нужно не в "config.yaml.example", а в "config.yaml"

Известная проблема, просто у меня никак руки не дойдут это дело исправить Прошу прощения. Как-нибудь постараюсь исправить

v0.2.3 (GitLab Release) Changelog: Исправлен незапуск при невалидном ".pid" файле. Исправлено отключение HTTP сервера. (спасибо @dan0102dan) Frontend: Добавлена функция множественного импорта записей. (спасибо @dan0102dan) Frontend: Добавлена локализация на русский язык. (спасибо @dan0102dan) Frontend: Мелкие исправления по всему проекту. (спасибо @dan0102dan)

Очень странно... Попробуй переустановить пакет с помощью "opkg magitrickle --force-reinstall". Пожоже, что не ловятся эвенты KeenOS которые очищают таблицу IPTables. А на счёт ipset, то нет, его наличие не обязательно в системе. Ipset находится в ядре Linux, и утилита скачиваемая из репозитория Entware это не более, чем средство для управления. Моя софтина использует Netlink API, так что дополнительная утилита тут не нужна.

Скорее всего не все домены прописаны, и пока ты пересохраняешь правила браузер (или приложение YouTube) успевает после нескольких фейлов переключиться на другой сервер (домен). Тут нужно наблюдать, смотреть. Рекомендую вступить в чат Telegram и там более подробно описать!

Добрый день! Увы, нет.

Я бы с радостью, однако это ПО уже тестово запущено на таких прошивках как DD-WRT и OpenWRT. Хочу уйти в универсальность и совместимость, а не в интеграцию с конкретной прошивкой. Однако, когда-нибудь в будущем дойдет и до этого.

Дубли допустимы, однако толком не протестировано как оно будет работать. По логике вещей он сработает по самому последнему правилу.