Ponywka

v0.1.4 (GitHub Release) Исправлен `config.yaml.example` Исправлено падение приложения при существующем интерфейсе в `DOWN` состоянии

v0.1.3 (GitHub Release) Добавлен HTTP сервер Добавлен API (Swagger документация находится в файле docs/swagger.yaml) Реализован базовый WebUI Исправлены некоторые ошибки Произведён частичный рефакторинг кода

Для v0.1.3 появится тестовый WebUI, как только я смогу убедиться, что в релизе нет критических багов.

Ну... Сейчас я делаю API HTTP для CRUD записей + CLI. Условно когда доделаю API - подключится другой разработчик, который будет фронт (WebUI) делать. Сроков не дам, но предположительно уже скоро.

v0.1.2 (GitHub Release) Переход от socat на свой CLI для /etc/ndm/netfilter.d Переход на HTTP в UNIX Socket

Но ведь... WireGuard доступен на Keenetic из коробки... Зачем?...

Перевёл автоматические сборки на GitHub: https://github.com/Ponywka/MagiTrickle/releases

Ну... Адреса занял - а там посмотрю что да как... https://t.me/MagiTrickle https://t.me/MagiTrickleChat

Так-то могу, прост вряд-ли будет время этим всем заниматься. Всё же делается всё на энтузиазме, который имеет свойство пропадать

Версия 0.1.0-9: https://gitea.20101010.xyz/Ponywka/MagiTrickle/actions/runs/38 Исправлены часть правил для IPTables

Попросили убрать схожий нейминг:

Проект был переименован в "MagiTrickle"! В связи с переименованием пакета, тем, кто успел установить его со старым именем, перед обновлением нужно будет провести миграцию: /opt/etc/init.d/S99kvas2 stop opkg remove kvas2 opkg install magitrickle_<version>_<arch>.ipk mv /opt/var/lib/kvas2/config.yaml /opt/var/lib/magitrickle/config.yaml /opt/etc/init.d/S99magitrickle start

MagiTrickle (произносится как Мэджитрикл) – утилита для точечной маршрутизации сетевого трафика по заданным доменным именам. Представляет собой установочный пакет, устанавливаемый в дополнение к операционной системе маршрутизатора. Принцип работы основан на подмене основного DNS-сервера через промежуточный компонент без его отключения. Это позволяет перехватывать входящие DNS-запросы, кешировать ответы и сопоставлять IP-адреса с доменными именами. Благодаря этому становится возможной маршрутизация трафика без необходимости очистки DNS-кэша на стороне клиентов. Очистка кэша требуется только при запуске или перезапуске сервиса MagiTrickle, поскольку в этот момент кэш ещё не прогрет, и маршрутизация невозможна до первого запроса к нужному домену. Установка пакета: Описание типов правил: Поддержка: Официальный сайт Канал Telegram Чат Telegram Финансовая поддержка проекта Исходный код: GitHub / GitLab Автоматические сборки: GitHub / GitLab

Это очень странно юзать Bash скрипты чтобы ловить те или иные состояния. Так например когда я пишу нативное ПО я могу вытворять все что угодно в фоне, но почему-то для того, чтобы получать какие-то эвенты - пришлось использовать UNIX сокет и перенаправлять поля из этих эвентов в этот UNIX сокет. Пример: #!/bin/sh SOCKET_PATH="/opt/var/run/kvas2-go.sock" if [ ! -S "$SOCKET_PATH" ]; then exit fi echo -n "netfilter.d:${type}:${table}" | socat - UNIX-CONNECT:"${SOCKET_PATH}"

Так у меня не слетали настройки - они изначально были по-умолчанию и работали правильно. Я говорю конкретно о том, что интерфейс неправильно обрабатывает состояние, когда в конфиге ничего не указано (поэтому и приложил Diff конфига до и после) Upd. А, всё, понял. Не заметил

Если никогда ранее не трогать настройку "Channel width" у Wi-Fi, то она будет отображаться в интерфейсе как "20 MHz", хотя по факту будет работать как "20/40/80 MHz": 2024-09-10 20-53-05_low.mp4 При сравнении двух конфигураций видно, что добавился параметр "channel":

Окей, чуть подразобрался и похоже всё-таки придется поддержать хук "netfilter.d", ибо (как я понял) подобное есть и на OpenWRT: https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmnetfilterd

Немного поизучав исходники оригинального kvas обнаружил, что там это исправляется с помощью хука "netfilter.d": https://github.com/qzeleza/kvas/blob/3fdbbd1ace7b57b11bf88d8db3882d94a1d6e01c/opt/etc/ndm/netfilter.d/100-vpn-mark Опять же - печально, ибо я хочу по минимуму привязываться к связке "KeeneticOS + Entware" в своём проекте

Кто-нибудь знает почему правила в "iptables" пропадают? Запускаю скрипты - он заполняют "iptables". Делаю "iptables-save" - всё ок: ~ # iptables-save | grep "KVAS2" :KVAS2_ROUTING_1_POSTROUTING - [0:0] -A POSTROUTING -j KVAS2_ROUTING_1_POSTROUTING -A KVAS2_ROUTING_1_POSTROUTING -o nwg1 -j MASQUERADE :KVAS2_ROUTING_1 - [0:0] -A PREROUTING -m set --match-set kvas2_1 dst -j KVAS2_ROUTING_1 -A OUTPUT -m set --match-set kvas2_1 dst -j KVAS2_ROUTING_1 -A KVAS2_ROUTING_1 -m set ! --match-set kvas2_1 dst -j RETURN -A KVAS2_ROUTING_1 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff -A KVAS2_ROUTING_1 -m mark --mark 0x1 -j RETURN -A KVAS2_ROUTING_1 -m conntrack --ctstate NEW -j MARK --set-xmark 0x1/0xffffffff -A KVAS2_ROUTING_1 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff Но стоит буквально самую малость подождать (например воспользоваться созданными правилами / потупить пару минут) и получаю следующее: ~ # iptables-save | grep "KVAS2" :KVAS2_ROUTING_1_POSTROUTING - [0:0] -A POSTROUTING -j KVAS2_ROUTING_1_POSTROUTING -A KVAS2_ROUTING_1_POSTROUTING -o nwg1 -j MASQUERADE Куда-то пропадает вся цепочка "KVAS2_ROUTING_1". Отдебажил свой код на всякий - он ничего не трогает. Мистика какая-то... Предполагаю, что сам NDM подтирает "iptables", однако ревёрсить бинарники не особо-то и хочется, чтобы найти виновника. Код для проверки: CHAIN_PREFIX=KVAS2_ ROUTING_ID=1 IPSET_TABLE=kvas2_1 MARK=1 INTERFACE=nwg1 ipset create ${IPSET_TABLE} hash:ip iptables -t nat -N ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t nat -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING -o ${INTERFACE} -j MASQUERADE iptables -t nat -A POSTROUTING -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t mangle -N ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -m set ! --match-set ${IPSET_TABLE} dst -j RETURN iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -j CONNMARK --restore-mark iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -m mark --mark ${MARK} -j RETURN iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -m conntrack --ctstate NEW -j MARK --set-mark ${MARK} iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -j CONNMARK --save-mark iptables -t mangle -A PREROUTING -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -A OUTPUT -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} # # --- Откат изменений --- # ipset destroy ${IPSET_TABLE} iptables -t nat -D POSTROUTING -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t nat -F ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t nat -X ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t mangle -D PREROUTING -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -D OUTPUT -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -F ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -X ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}

Здраствуйте! Использую KeeneticOS 4.2 Beta 2 на мониторе 2K разрешением (а у друзей вариант с 4K разрешением) и меня огорчает то, что интерфейс ограничили 1920px по ширине, хотя ранее таких ограничений не было и интерфейс растягивался на всю ширину (в моём случае 2560px). Планируется ли исправление ширины в будущем?

Делюсь опытом при переходе с Iskratel RT-GM-3 (Ростелеком, Воронежская область, г. Лиски): Настройки SFP-стика: Сам стик: DFP-34X-2C3 (как DFP-34X-2C2, только с зелёным разъемом без переходника) Прошивка: https://github.com/Anime4000/RTL960x/blob/main/Firmware/DFP-34X-2C2/M110_sfp_ODI_210702.tar Admin -> GPON Settings: Serial Number: ISKT0123ABCD (ISKT + из роутера последние 8 знаков 49534B540123ABCD) PLOAM Password: 0000000000 (там действительно такой пароль на моём роутере был) LOID: user (без него не даёт сохранить) Admin -> OCMI Information: OMCI Vendor ID: ISKT (*скорее всего не обязательно) WAN -> PON WAN: VLAN ID: 10 Connection Type: INTERNET Не забываем про Admin -> Commit/Reboot -> Commit and Reboot С такими настройками в Status -> PON -> ONU State получил O5 (Initial Status) На роутере: IPv4 Settings: IPv4 configuration: Automatic (DHCP) ISP Authentication: Type (protocol): PPPoE Username: abcdef01@vrn (см. в настройках роутера или звоните провайдеру, представленный - лишь пример) Password: Звоните провайдеру (88001000800), просите робота соеденить с оператором и просите у него "PPPoE пароль". Выдернутое из роутера "@&~*#()<>****@&^%*!####" - не пароль, Мне прислали 8-ми значный пароль вместо этого "нечто". Возможно потребуется после настроек перезагрузить питание роутера (перезапустить как и сам стик, так и роутер)

Отключи компонент "Фильтрация контента и блокировка рекламы при помощи облачных сервисов" ("Cloud-based content filtering and ad blocking")

Ага... Я вот купил второй Keenetic Giga (родствевнникам; из-за наличия SFP порта и желания иметь один висячий "коробок" вместо двух), ибо взял отпуск и планировал отвезти родственникам его. Только-только настроил WG как мост между двумя роутерами, а его на следующий день начали блочить 🤬

Ну, как вариант кстати 😕

Я имел ввиду про софт, который я пишу, который использует iptables и работает с UNIX'овыми названиями интерфейсов, но который запущен на роутерах Keenetic.