Ground_Zerro

На БС разве что забрать списки руками с iplist - копировать, вставить.

Порт Entware 222, а не 22 (если в системе установлен штатный компонент SSH кинетик) - туда и подключайся под root keenetic. При установке из под admin или любой другой учетки созданной в роутере службы унаследуют ограниченные разрешения на доступ к системным сервисам. Работать не будет проще говоря.

Таблица сравнения Критерий HRNeo Keenetic DNS-маршрутизация Требования Entware (USB/opkg), любая версия ОС KeeneticOS 5.0+ (в 5.2 — привязка к произвольной политике), ставить ничего не нужно Доменов в списке Ограничено RAM: 200–500 тыс. на роутере со 128 МБ 300 на группу (жёстко) Число списков Не ограничено (лимит — 64 политики + 64 интерфейса) 256 групп → потолок ~76 800 записей Накопленных IP на список ipset maxelem 262 144 (настраивается) ipset maxelem 16 384 (фиксировано прошивкой) Источники имён DNS-ответы + L7: TLS SNI, HTTP Host, QUIC/HTTP-3 Initial Только собственный dns-proxy роутера Клиент с DoH / DoT / DoQ Работает (ловит по SNI/Host) Не работает — роутер не видит запрос Тёплый DNS-кэш клиента, hardcoded IP Работает (L7-канал) Не работает — без DNS-запроса нет маршрута Клиент со сторонним DNS (не роутер) Работает, если трафик идёт через роутер (пассивный AF_PACKET) Не работает — требуется роутер единственным DNS VPN-клиенты роутера Ловятся (AF_PACKET на PPP / ARPHRD_NONE / туннелях) Через штатный dns-proxy GeoIP / GeoSite Да — .dat v2ray/xray, потоковый парсинг, сотни тысяч записей Нет CIDR / подсети в списке Да (ip.list, geoip:TAG) Да, с 5.0 (include 10.0.0.0/24) Поддомены Автоматически (все домены с match_subs=1) Автоматически (* запрещён) Цепочка CNAME Разбирается из DNS-ответа Приходит из зеркала отдельными секциями, промежуточные имена тоже сопоставляются Точность матчинга домена Совпадение по границе метки: x.com не заденет yandex.com; при равном приоритете выигрывает более специфичный суффикс Суффиксная подстрока без границы метки: правило x.com захватывает yandex.com, ample.com — example.com. Ложные срабатывания молчаливые Протоколы, попадающие в маршрут Задаётся правилами HRNeo TCP, UDP, ESP (ipv6-crypt), GRE, ICMP Резерв при падении целевого интерфейса Цель — политика целиком: переключение по приоритету permit global, иначе blackhole (kill-switch). Правила привязаны к политике и при down не исчезают Резерв не задаётся, цель — одно подключение или шлюз. При down ndm сносит все ip rule этой марки, оставляя правило MARK → трафик уходит в main и утекает через основной WAN мимо туннеля Приоритет при коллизии PolicyOrder — правка одной строки конфига Только порядок ввода. Изменить нельзя: ни индекса, ни вставки; повторный ввод обновляет правило на месте. Единственный путь — удалить правило и создать заново (уйдёт в конец), то есть пересоздать вручную все правила ниже Маркировка CONNMARK (per-connection) + точечный conntrack-DELETE → мгновенный реконнект по политике MARK per-packet, затем CONNMARK --save-mark в конце цепочки. Точечного сброса conntrack нет → уже установленные соединения на новую политику не переезжают Отношение к политикам Может обходиться без них (DirectRouteEnabled → свои ip rule / ip route) Работает только поверх политики доступа Keenetic Охват политик доступа GlobalRouting=true — один флаг, и маршрутизация действует на устройства в любых политиках, перекрывая назначенную роутером; список и ipset при этом одни. false — уважать политики устройства Единого переключателя нет. Правило живёт внутри одной политики и заводится в каждой вручную; на каждую пару политика:группа — свой ipset, своя марка, свой лимит 16 384 IP. В 5.0 — только политика по умолчанию Обновление списков Замена domain.conf / .dat + SIGHUP; geosite-категории обновляются одним файлом Нативного механизма нет — только ручной ввод в веб-интерфейсе или CLI. Любая автоматизация (gokeenapi, keenetic-geosite-sync) — сторонний софт: на роутере он требует Entware, иначе внешний хост Устойчивость к перезаписи netfilter ndm Хуки netfilter.d + коммитер (немедленная запись + повтор раз в 3 с) Нативно, проблемы нет Совместимость с zapret2 / nfqws2 Да — NFLOG нетерминирующий, за трафик не конкурирует Да Ресурсы Один статический бинарь 185–250 КБ, один поток, epoll, без GC; RAM ≈ 50 МБ на 500 тыс. доменов Часть прошивки, отдельного расхода нет Датаплейн (скорость трафика) ipset hash:net в ядре — оверхеда нет То же самое — оверхеда нет Задержка попадания IP в ipset (§7) p50 0.12–1.4 мс, p95 1.5–4.8 мс, максимум 18 мс — хвост короткий и предсказуемый p50 ~0.1 мс, p95 до 264 мс, выбросы до 1.8 с Что происходит, пока IP ещё не в ipset Ответ уже у клиента, соединение может успеть уйти мимо политики. Окно закрывается точечным удалением conntrack: при появлении адреса в сете удаляются записи с этим адресом назначения (по DNS-пути — обходом таблицы conntrack, по L7 — по конкретному 5-кортежу), соединение рвётся и переустанавливается по нужному маршруту. Управляется ConntrackFlush (по умолчанию включено) Ответ придержан в NFQUEUE до наполнения сета, первое соединение сразу маршрутизируется правильно; платой становится задержка DNS-ответа. На петлевой трафик механизм не распространяется Пропускная способность DNS-канала 50 000 ответов/с без потерь, 9.8 % потерь на 100 000/с Предел задаёт сам dns-proxy: ipset наполняется только собственным резолвингом Когда чего достаточно Штатной DNS-маршрутизации хватает, если: списки небольшие и ведутся вручную; все клиенты используют роутер как DNS и не включают DoH/DoT; целевой туннель стабилен, резервирование не требуется; порядок правил задаётся один раз и больше не меняется. HRNeo нужен, когда: списков десятки тысяч записей и больше; нужны geosite/geoip-категории и их регулярное обновление; есть клиенты с DoH/DoT/QUIC или приложения с прошитыми IP (устройство использует только свой DNS); маршрутизация нужна без политик Keenetic; требуется мгновенный реконнект уже установленных соединений; приоритет целей меняется часто; нужен предсказуемый резерв при падении туннеля вместо утечки в открытый WAN; важна точность матчинга доменов. P.S. В наше время без табличек с FPS уже никак. Даже миленниалам нужно что-то показывать и желательно сразу с пометкой "лучше/хуже", чтоб им свой ум не морщить в попытке осмыслить написанное, самим думать сложно, что уж про зумеров говорить.

Чейто? ^-^

Это предмет споров. По мне так без особой разницы. Отмечу только, что на скорость работы это не влияет. В случае с HR - можно и в NAND, но туда скорее всего просто не влезут GEO.dat Нет, не нужно, это скорее будет иметь обратный эффект и создавать конфликты маршрутизации. Выбрать что-то одно.

RCI-авторизация в KeeneticOS 5.2: ответы разработчиков NDMS Материал подготовлен по итогам прямого диалога с командой разработки NDMS. Публикуется в формате Q&A. Информация актуальна на момент публичной альфы KeeneticOS 5.2 и может уточняться. --- Контекст В KeeneticOS появился новый механизм авторизации RCI — по токену, передаваемому в заголовке `X-NDMA-TKN`. Для сторонних пакетов (Entware/opkg), использующих RCI для настройки политик, маршрутизации и прочего, это ломает существующие сценарии работы. --- Часть 1. Механизм авторизации В: Будет ли документация по новому механизму авторизации RCI — формат токена, заголовок передачи, коды ошибок, время жизни, отзыв, привязка к пользователю/роли/интерфейсу? О: Да, документация будет опубликована, ориентировочно в ближайшее время. --- В: Есть ли машиночитаемый способ определить, какую схему авторизации поддерживает конкретная прошивка? Пакету нужно поддерживать старые и новые версии одним бинарём, а детект по номеру версии — хрупкий. О: Признаком служит наличие `x-ndw4-authenticate` в ответе `/auth`. Появится только в 5.2. --- В: Судьба интерактивной авторизации `x-ndw2-interactive` — сохраняется ли она ради обратной совместимости? О: Нет. Планируется убрать как можно скорее. --- В: Предусматривается ли endpoint, обменивающий валидные логин/пароль на токен доступа (аналог OAuth2 Resource Owner Password Credentials)? О: Прямого обмена «логин/пароль → токен» не будет. Вместо этого вводится бутстрап авторизации через браузерный редирект — разработчики отметили, что именно этого звена в текущей схеме не хватало. Схема бутстрапа: Стороннее приложение делает редирект на `/auth`, передавая финальный URL возврата в одном из параметров. Пользователь проходит обычную процедуру ввода логина и пароля. Дополнительно он предупреждается, что будет создан одноразовый токен, дающий доступ стороннему сервису. При успешной аутентификации роутер создаёт одноразовый токен с временем жизни 1 минута и выполняет редирект на переданный URL, подставляя токен в параметр. Приложение в течение минуты может ровно один раз авторизоваться по этому токену — то есть создать одну сессию. Уже внутри этой сессии выполняются нужные настройки, включая генерацию и сохранение постоянного токена. Технические детали бутстрапа будут описаны отдельно и пройдут ревью сообщества перед финальным утверждением. --- В: Есть ли более простой путь для случаев, когда браузерный редирект неприменим? О: Да, есть вариант проще, но менее безопасный — вызов `ndmc`, который всегда присутствует в прошивке в режиме выполнения команд. Важная оговорка: `ndmc` выполняет команды от имени `admin`, и полученный таким способом токен также будет только от `admin`. --- В: Формат токена уже утверждён и будет таким, каким он показан в публичной альфе 5.2? О: Формат будет утверждён. Предусмотрено три вида токенов: «навсегда», «с временем жизни» и «одноразовый». На текущий момент реализована возможность создать только токен «навсегда». Часть 2. Вопросы сообщества В: Возможно ли сохранить — штатно или опционально, флагом в конфигурации NDMS — неаутентифицированный доступ к RCI с `127.0.0.1`? Процесс в Entware работает от root на том же устройстве и уже имеет полный контроль над системой вплоть до остановки NDMS; авторизация на loopback не создаёт границы доверия, но ломает локальные сервисы. О: Нет. Цель — удалить любой открытый доступ на маршрутизируемых интерфейсах. `127.0.0.1` очень легко открывается наружу пробросом порта. При этом `ndmc` работает через unix-domain-socket, который не маршрутизируется, — и его пока допустимо оставить неавторизованным. --- В: Планируется ли расширение лимита 8 + 8 DoH/DoT-серверов? О: Нет. --- В: Рассматривался ли переход на dnsmasq ради полноценных настроек DNS в прошивке? О: Точно нет. --- В: Существует ли штатный механизм учёта kernel-интерфейсов, созданных вне NDMS, — регистрации интерфейса, чтобы политики и маршрутизация видели его как обычный? О: Да — `OpkgTun` и `OpkgTap` делают ровно это. О формате взаимодействия Перед публикацией настоящего материала было получено разрешение на распространение приведенной в нем информации. Также разработчики NDMS подтвердили готовность к прямому диалогу с авторами сторонних пакетов.

Hydra Route Neo 3.15.0-1 Hydra Route Neo 3.16.0-1 Hydra Route Web 1.45.0-1 Hydra Route Web 1.46.0-1 - 1.49.0-1

Форум forum.keenetic.ru, согласно официальной позиции ООО «Неткрейз», является только площадкой сообщества, приёма багрепортов и не рассматривается как канал коммуникации с представителями компании. У небольшого сообщества разработчиков открытых пакетов для платформы нет даже минимального способа прямого технического диалога с брендом. ИМХО

Присоединяюсь. Тезисно - порт не смотри во вне, - у пользователя уже есть ROOT чтобы сделать что угодно. Зачем??

Такого функционала не предусмотрено. В процессе синхронизации подписки происходит практически полная ротация конфигурационных ссылок, включая их символьные идентификаторы (названия). По статистике, до 90% узлов, имевших статус активных до обновления, отсутствуют в новом пуле. Предложите алгоритм парсинга и сопоставления обновленного списка для восстановления состояния активных узлов. При наличии внятной логики - попробуем реализовать.

Вспомнил старую тему на форуме. Такая штука есть. 6мб многовато конечно для пары функций, но работает стабильно.

В исходном запросе полностью отсутствуют какие-либо технические данные. Без вводных сведений локализовать проблему и определить причину некорректной работы сможет разве что экстрасенс. В неизвестных абсолютно всё. Какое там системное окружение, что ставилось, как использовалось и т.д. и т.п. Тезис "Не работает уже месяц" слишком широк чтоб даже приблизительно понять, что на устройстве происходит и почему. С подобными вводными рекомендация может быть только следующая: Единственным эффективным решением в данной ситуации является полная деинсталляция всех установленных компонентов и последующая чистая установка Entware и остального ПО с нуля. Лучший и наиболее быстрый способ получить помощь - написать в ТГ группу.

Ответ где-то рядом.

Для интересующихся Принятые меры: FP-репорты направлены вендорам. Будет добавлен GNU build-id. UPX сжатие - долой. Плюс ~356Кб к весу бинарника владельцам ARM надеюсь по силам. В процессе: Над динамической линковкой нужно подумать, это противоречит идее HRN «единый статический бинарь без зависимостей». Но "static stripped, no dynamic section" - основа сигнатуры IoT-ботнета, и увеличивает вес триггеров. Нужен компромисс. Релизов на GitHub не планировал, но видимо придётся это пересмотреть и изучить что такое "GPG-подпись".

Да, догадался залезть туда. В вирусах не силен, потому анализ исходников от Ai агента: Исходники открыты, кому нужно - проверяйте, смотрите.

@Кинетиковод Хз. Не прогонял антивирусами. А на что конкретно ругается хоть?

Всем привет. Давно не писал здесь. Короткий дайджест HydraRoute Neo портирован на Си добавлен второй источник имён хостов "L7-канал": перехват TLS SNI / HTTP Host (подоробнее см. Dosc) флаги запуска. Параметры можно передавать напрямую при старте, частично или полностью заменив ими файл конфигурации (подоробнее см. Dosc) опубликованы исходники (AGPL-3.0-only) и кое какая документация HydraRoute Web UI автоматическое обновление подписок работа с happ подписками (индивидуальные HTTP заголовки) dpi опции для Proxy интерфейсов mux режим для vless новый инструмент «Мониторинг»: фоновый мониторинг доступности интернета на интерфейсах Немного о целях и дальнейшем развитии Проект Neo был создан с идеей: сделать утилиту без «человека посередине». Уйти от классического MITM-подхода, на котором построено абсолютное большинство аналогов. Задача выполнена, демон остается пассивным наблюдателем не вмешиваясь в работу клиента с DNS сервером. Проект подошел к этапу, когда двигаться дальше без внедрения MITM не получится. Думаю, Neo в контексте своей цели полностью закончен. HR Neo, но не Hydra Route ^-^ Сурсы в паблике — модифицировать, развивать или использовать в каких-то своих целях может любой.

@NSGrid Праздники в стране, если конечно понимаете как это связано. Ну и плюс хостера ДДОСили сутки.

Не проверял никто. По логике если пересечений по доменам нет то корректно. Нет. Если отсутствие исходника проблема - настоятельно рекомендуется отказаться от HR Neo в пользу другого ПО или самостоятельной настройки.

@zlobnyi @nomadfromx Внешние зависимости больше не используются в диагностике - обновите HR web.

Спасибо, поправил в коде HR. В скриптах чуть позже.

Неправильный регистр, не `RU` а `ru`. CN tag как и домены cn/hk зон отфильтрованы в репозитории. Поправлю в документации.

Тут что-то явно произошло... Всем спасибо. У кого есть затруднения с HR - напишите в ТГ группу, всем поможем.

Кто как выходит из ситуации. Некоторые на время установки пакетов ставят VPN подключение первым в политике по умолчанию. В ТГ спроси, думаю помогут.

@sakol18 Нет пакета wget с поддержкой SSL. Запусти установку используя скрипт. @solitary23 Не может достучаться до некоторых репозиториев. Такое бывает с гитхаб.