Ponywka

Ну вообще этого долго быть достаточно. Нужно логи смотреть. Сам же я не пользуюсь лентограммом, так что хз... Мб адреса новые появились

По итогу даже такой костыль не помог моей программе. Вообще этот лог я получил давно, просто руки никак не доходили отписать об этом здесь. Я получаю ошибку "iptables-restore: line 8 failed" при применении следующей цепочки: *nat :PREROUTING - [0:0] :MT_DNSOR - [0:0] -F MT_DNSOR -A MT_DNSOR -p tcp -d 192.168.133.1 --dport 53 -j DNAT --to-destination :3553 -A MT_DNSOR -p udp -d 192.168.133.1 --dport 53 -j DNAT --to-destination :3553 -I PREROUTING 1 -j MT_DNSOR COMMIT Т.е. да, оно падает на операции "COMMIT". Добавлю немного контекста - эта пробема происходит во время запуска роутера, и, соответсвенно, во время прогрузки сервисов Entware. Если без остановки перезагружать роутер, то с шансом на 1496 запусков 280 будут провальными. Инфу случайно собрал на моменте, когда в init скрипте на Dev-роутере у меня была реализована перезагрузка раз в 3 минуты, и когда у меня дома кто-то передёрнул свет, тем самым позволив собрать такую статистику. Я понимаю, что необходимость в MagiTrickle как в утилите для настройки выборочной маршрутизации немного отпала, т.к. у Keenetic появилась своя стоковая, но всё же - много кто отписывает, что моё решение, которое по факту является костылём, работает лучше этого самого стокового решения (сам не использовал - много кто в моём чате об этом пишет). Собственно я уже немного без понятия куда писать, ибо ветка по факту мертва. Подсказали, что нужно пингануть @admin, и в таком случае на неё могут обратить внимание, поэтому... Надеюсь, что в эту ветку заглянут.

Ну да... В новых версиях он сломан. Хз насколько критично это, ибо не сказал бы, что там есть полезная инфа

Это не относится к MagiTrickle - это Sing-box

Ну это уже звучит интересно. На Omni II всего 64 мб ОЗУ. Момент в том, что у меня нет Giga II 🙃 Оно просто всё денег стоит, даже если и Б/у.

Ну так-то поддержка KeenOS 2.X нигде и не гарантировалась. Я могу конечно потыкать посмотреть на Keenetic Omni II, но там MT в стоке даже не запускается, потому что ему модулей ядра не хватает для полной поддержки, так что поддержку таких устройств я отложил в долгий ящик, по той причине, что реализовать весь функционал на них будет проблематично. Это если не говорить о целесообразности, учитывая, что MagiTrickle в себя кеширует много данных (т.к. не имеет доступа к кэшу DNS сервера Keenetic) и на таких роутерах просто тупо мало ОЗУ под стабильную работу MT

Очень сложно будет в этом списке совместить и названия, и тип паттерна, и сами паттерны, и при этом чтобы это было юзабельно. Пока что нет идей, как это можно реализовать красиво.

v0.6.0 (GitLab Release) Changelog: Сборки .apk файлов для OpenWrt. Исправлен выбор меток и таблицы для ip rule (спасибо @badigit). [Frontend] Добавлен логотип на странице авторизации (спасибо @dan0102dan). [Frontend] Исправлена логика сортировки правил (спасибо @dan0102dan). [Frontend] Дублирующиеся записи теперь помечаются восклицательным знаком (спасибо @dan0102dan). [Frontend] Прочие исправления (спасибо @dan0102dan).

Если не разбираетесь - можно оставить оба По жалению. Если не прописывать - выставится "singtun0" Это просто пример записей. Эту группу можно удалить и создать новую

Что под этим понимается ввиду? Веб интерфейс хранится там же, куда и установили MagiTrickle

Нужно было подождать и ещё раз обновить страницу. Либо же просто ребутнуть сервис. Сервис не сохраняет конфиг, если вдруг что-то пошло не так. А группы не отображались из-за того, что в тот момент пересобирался список, и если честно, списки у MT пересобираются не так быстро, как хотелось бы.

MagiTrickle появился за год до добавления подобного функционала в сам Keenetic. Да и тренд на GUI, словно, был задан этим самым MT, хотя могу ошибаться. GUI решения как-то резко начали в одно время появляться

Увы, они слишком старые. Потенциально можно завести новые версии MT с удалением поддержки hash:net в ipset (прошивка ещё не поддерживает данный подтип списков), однако я бы рекомендовал просто обновить роутер.

Пропиши в качестве DNS сервера IP адрес домашней сети

Побольше бы информации на счёт этого... Отваливается DNS?

Исправлено в обновлении выше

v0.5.2 (GitLab Release) Changelog: Ошибки, возвращаемые iptables-restore теперь отображаются на конкретном вызове iptables-restore; [Keenetic] Возвращен назад костыль, связанный с исправлением незапуска сервиса в течении первых 5 минут;

v0.5.1 (GitLab Release) Changelog: Отключена авторизация по-умолчанию; Приоритет соединения в группе (между соединением и Blackhole) теперь определяется метриками, а не CIDR'ом; Перезапуск сервиса при установке/обновлении пакета (спасибо @spatiumstas); [Frontend] Исправлено отображение выпадающего меню группы (спасибо @dan0102dan); [Frontend] Исправлена логика кнопки сохранения (спасибо @dan0102dan); [Frontend] Прочие мелкие исправления и улучшения (спасибо @dan0102dan и @shevernitskiy);

Проблема известная. Будет исправлено в 0.5.1

v0.5.0 (GitLab Release) P.s. После установки не забудьте перезапустить сервис!!! (Команда: "/opt/etc/init.d/S99magitrickle restart") Changelog: Использование "iptables-restore --noflush" вместо "iptables" (ускорение сохранение правил); [Keenetic] Убран костыль связанный с перезапуском сервиса в течении первых 5 минут с момента запуска роутера (пропала необходимость из-за изменения выше); Оптимизация обработки DNS запросов (исправление вылетов на роутерах с низким количеством ОЗУ); Оптимизация перебора IP адресов для маршрутизации (увеличение RPS на каждый DNS запрос); Добавлена авторизация по паролю пользователя Entware/OpenWrt; Frontend: Выделение кнопки сохранения конфигурации; Frontend: Исправление логики определения изменений; Frontend: Все полезные ссылки теперь скрыты под кнопкой "Info"; Frontend: Поиск теперь уменьшается до размера кнопки в неактивном состоянии; Frontend: Добавлена сортировка правил в группе (только в Desktop версии); Frontend: Добавлена возможность выбора добавления к существующей, либо замены полностью конфигурации при импорте файла; Frontend: Добавлен предпросмотр типов правил при их массовом импорте; Frontend: Прочие изменения по фронтенду; За все изменения по фронтенду огромное спасибо @dan0102dan и @shevernitskiy!

Потому что это задевает также частные подсети (на которых расположен роутер)

Запустите "magitrickled" и покажите лог

Есть такой момент. Пока не нашел причину. Даже если проводить стресс-тесты MT - всё равно проблема себя не проявляет (и что самое забавное - у меня тоже в целом не припомню такого)

Ну потому что если брать мой случай - в других прошивках (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 (где на последний я в итоге перешел, ведь он мне даёт больше возможностей, как энтузиасту-разработчику).