Настраиваю Sprinter KN-3710 на KeeneticOS 5.0.12 в конфигурации multipath (MultiWAN) — два провайдера по PPPoE + SOCKS5-прокси Proxy3 для обхода блокировок. Устройств в сети много, все они в Policy0 (multipath) с permit auto.

Суть проблемы: мне нужно настроить доступ к определённому списку доменных имён таких сервисов как OpenAI, Grok, Gemini, YouTube и т.д. через Proxy3, оставив остальной трафик через провайдеров. DNS-Based Routes (dns-proxy route object-group domain-list6 Proxy3 auto) — идеальное решение, но…

Оно не работает. Потому что все клиенты висят в Policy0, а DNS-Based Routes, как оказалось, работают только в Default Policy. Получается, чтобы FQDN-роутинг работал, нужно сломать всю логику multipath и перевести все устройства в Default Policy.

Почему это критично: в моём конфиге Policy0 — это multipath с балансировкой между двумя провайдерами + авто-переключение. Переводить устройства в Default Policy — значит лишиться MultiWAN. Делать сотни статических маршрутов (ip route) — не масштабируется при динамических IP сервисов (Google, Cloudflare, Twitter и т.д.). Сейчас у меня уже более 80 статических маршрутов на подсети этих сервисов в конфиге, и это только ради обхода блокировок. Получается тупик: либо роутер, либо костыли.

И ещё две несостыковки CLI ↔ Web:

1. Нет команды «включить/выключить» статический маршрут в CLI.
В CLI есть ip route — добавляет маршрут, и no ip route — полностью удаляет его. Но нет команды включить/выключить маршрут без удаления (аналог галочки «Включить/Выключить» в веб-интерфейсе). Приходится либо держать в голове, какие маршруты «временно выключены», либо каждый раз пересоздавать их заново. Для автоматизации через скрипты это неудобно.

2. Нет метрики в Web.
В CLI можно назначить метрику статическому маршруту (ip route ... auto <метрика>), а в веб-интерфейсе поля для метрики просто нет.

Предлагаю:

1. Сделать DNS-Based Routes работающими в любой Policy, где разрешён целевой интерфейс (или хотя бы добавить параметр принудительного включения вне зависимости от Policy). Это решает корневую проблему — FQDN-роутинг становится полезным в реальных конфигурациях с MultiWAN.
2. Добавить приоритет FQDN-роутинга над статическими маршрутами — чтобы не плодить ip route ради обхода блокировок, а управлять маршрутизацией декларативно через домены.

Также было бы удобно:
3. Добавить в CLI команду включения/выключения статического маршрута без его удаления (ip route disable/enable или аналог) — чтобы соответствовало веб-интерфейсу. При этом нужна возможность идентифицировать конкретный маршрут без необходимости полностью переписывать всю строку ip route.
4. Добавить поле метрики в веб-интерфейс для статических маршрутов — чтобы соответствовало CLI.

Хотел попробовать, но был не приятно удивлен что это не работает из коробки. Может это как то реализовано не так очевидно как я себе представлял? 

Содержимое запроса зашифровано так, что relay видит IP клиента, но не видит содержимое запроса. Зашифровано ключом target-резолвера, а target-резолвер видит содержимое, но не видит IP клиента видит только IP relay.
Ни одна из сторон по отдельности не имеет обеих частей одновременно.

Зачем это нужно:
1. Разделение IP и содержимого запроса — ни relay, ни target-резолвер не видят полной картины "кто и что резолвит".
2. Если провайдер/DPI режет соединения к самому резолверу по домену в TLS ClientHello SNI — например, блокирует cloudflare-dns.com напрямую то при ODoH клиент устанавливает TLS-соединение с relay'ем, а не с target-резолвером. SNI, который видит DPI — это домен relay'я, который может не входить в списки блокировок.

Пока что данный протокол можно добавить только через dnscrypt-proxy2, но для этого надо устанавливать entware.

Пример настройки relay как у меня в dnscrypt-proxy2

[sources.relays]
urls = [
  'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md',
  'https://download.dnscrypt.info/resolvers-list/v3/relays.md',
]
cache_file = 'relays.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 73
prefix = ''

### ODoH (Oblivious DoH) servers and relays

[sources.odoh-servers]
urls = [
  'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-servers.md',
  'https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md',
  'https://cdn.jsdelivr.net/gh/DNSCrypt/dnscrypt-resolvers@master/v3/odoh-servers.md',
]
cache_file = 'odoh-servers.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 73
prefix = ''

[sources.odoh-relays]
urls = [
  'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-relays.md',
  'https://download.dnscrypt.info/resolvers-list/v3/odoh-relays.md',
  'https://cdn.jsdelivr.net/gh/DNSCrypt/dnscrypt-resolvers@master/v3/odoh-relays.md',
]
cache_file = 'odoh-relays.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 73
prefix = ''

Актуальные списки резолверов/relay/ODoH-серверов: github.com/DNSCrypt/dnscrypt-resolvers
Пример полного конфига с комментариями: example-dnscrypt-proxy.toml
Репозиторий и вики dnscrypt-proxy2: github.com/DNSCrypt/dnscrypt-proxy

Прикреплю схему и описание.

У нас есть Основной роутер (1), который подключен к провайдеру. Также есть Ретранслятор (2) и Ретранслятор (3)

При данных условиях (трёх-этажный дом) самым оптимальным будет следующий вариант: Ретранслятор (2) подключен к Основному роутеру (1), а Ретранслятор (3) подключён к Ретранслятору (2). При таких условиях, стороннее устройство (например телефон), подключенное к Ретранслятор (3) будет иметь максимальную скорость передачи данных. Однако, по каким-то причинам, иногда Ретранслятор (3) подключается к Основному роутеру (1) напрямую, минуя Ретранслятор (2), вследствие чего скорость значительно падает. Более того, невозможно как-то вручную изменить приоритет подключения и приходится перезагружать Ретранслятор (3), чтобы он снова подключился к Ретранслятору (2).

Также на втором скриншоте прикладываю сравнение скоростей и саму ситуацию в моей WiFi-системе.

Причина неработоспособности проста: хост в Wireguard-соединении (в поле "Адрес и порт пира" прописан домен) не резолвился роутером. Причём я это узнал через меню "Диагностика" - "Проверка сетевого соединения". Никаких сообщений в журнале роутера об этом не было, также не было на странице "Системный монитор".

Как видно, истинной причины неработоспособности Wireguard-соединения тут нет.

Исходя из этого я предлагаю:

1) Писать в журнале прошивки причину неработоспособности Wireguard-соединения: невозможность резолва доменного имени, прописанного в соединении.
2) Опционально: На странице "Системный монитор" в соединении писать более понятную ошибку, чем просто "Нет соединения"

Предлагаю добавить виртуальных скроллинг или постраничную навигацию (50/100/200 записей). Предпочтительно виртуальный скроллинг, тем более, что видно на проекте в других местах уже используется cdk scrolling.

Будет ли реализовано настраиваемое ограничение скорости клиентам PPTP/L2TP/SSTP VPN-сервера?

Рад за всех, у кого уже появился широкополосный доступ в интернет, но в отдельных уголках страны скорость в 3-4Мбит/с всё ещё считается

чем-то фантастическим, и данная функция была бы очень желаемой!

было бы намного удобнее иметь возможность указывать и конкретное число возможных подключений со стороны public интерфейсов для одного адреса и/или подсети
upd в принципе можно и не только для внешних, для внутренних тоже - например чтобы клиента с включенным dht и торрентами жестко ограничить т.е что-то типа ip conntrack max-entries private host

tunnel:
  name: t2s0
  multi-queue: false
  ipv4: 172.20.12.1
  ipv6: 'fc03:52b:6:a56:10c:14ac:945b:6300'
  post-up-script: /var/run/proxy-fb-Proxy0
socks5:
  port: 7890
  address: 127.0.0.1
  udp: 'udp'
  pipeline: false
  mark: 268434091
misc:
  task-stack-size: 24576
  tcp-buffer-size: 65536
  connect-timeout: 7000
  read-write-timeout: 20000
  user: nobody
  log-file: syslog
  log-id: Proxy0
  log-level: warn

Конкретно настройка read-write-timeout: 20000 приводит к тому, что приложения которые умеют "thinking" и работают через прокси - теряют соединение спустя 20 секунд.
 

Было бы замечательно управлять этим параметром через cli.

Для IPv4 загрузка/выгрузка маршрутов списком сделана практически идеально. Очень удобно при смене интерфейса.

Очень хотелось бы такой же функционал для IPv6 маршрутов. Пока приходится ручками пилить.

Спасибо за внимание.

В маршрутизаторе Служба UPnP установлена

На версии 4 .х.х.х работало все четко

Селф тест прикрепил 

Условия

В DNS-based Routes присутствует единственная запись:

x.com

Других доменов или похожих записей нет.

Проверка

При наличии единственной записи x.com в DNS-based Routes выполнение команды:

traceroute -n yandex.com

показывает, что трафик начинает маршрутизироваться через VPN. Это подтверждается уже на втором узле трассировки, который меняется с адреса провайдера на внутренний адрес VPN-интерфейса:

1 192.168.0.1
2 10.8.1.0
...

После удаления единственной записи x.com, применения конфигурации и очистки DNS-кэша выполнение той же команды:

traceroute -n yandex.com

показывает, что маршрут немедленно возвращается на основной интернет-канал. Второй узел трассировки снова становится адресом провайдера:

1 192.168.0.1
2 78.107.39.54
...

Таким образом, изменение единственной записи x.com в DNS-based Routes приводит к изменению маршрута домена yandex.com, что стабильно воспроизводится и подтверждается результатами traceroute.

Ожидаемое поведение

Согласно документации, запись

x.com

должна соответствовать только:

• x.com;

• *.x.com. (то есть всем поддоменам)

Домены, содержащие последовательность символов x.com в подстроке (например, yandex.com), не должны попадать под это правило.

Предположение

Складывается впечатление, что при сопоставлении DNS-based Routes происходит некорректная обработка доменных имен, из-за чего правило x.com ошибочно применяется к yandex.com.

Прошу проверить, воспроизводится ли данное поведение у других пользователей, а также подтвердить, является ли это известной ошибкой.

Если это действительно баг, хотелось бы, чтобы сопоставление выполнялось строго по доменному имени (x.com) и его поддоменам (*.x.com), как это указано в документации.

Когда-нибудь в далеком будущем))

Как сделать автоматическое переключение статических маршрутов между основным и резервным VPN при падении основного VPN, не используя флешек, OPKG, Entware и прочего? Когда будет реализовано "из коробки"?

На сегодняшний день в Keenetic OS реализована поддержка авторизации пользователей через сторонний radius server, только при настройке сегментов локальной сети, в частности при настройке wi-fi. Планируется ли добавить профиль "radius server" - по аналогии, как это сделано на маршрутизаторах Unifi и способность его применения к VPN подключениям keenetic, т.е. суть в том, чтобы авторизация подключения клиентов VPN keenetic была выполнена по сторонним учетным записям, не по пользователям keenetic?

Реализация данного функционала на порядок повысит востребованность продукции.

Лично мне это необходимо вот для чего:

Имеется сеть, в которой расположен NAS сервер с запущенными службами домен AD, DNS и RADIUS server. Требуется ввод клиентов через VPN в домен. Если это делать через keenetic VPN (по пользователю keenetic), то для реализации требуется второй роутер keenetic, при действующем соединении VPN машина заводится в домен. Если же организовать авторизацию клиентов VPN keenetic через RADIUS Server, то тогда можно будет напрямую, при входе, завести машину в домен инициируя VPN подключение с неё.   

Уважаемые разработчики, планируется ли поддержка USB-модема Huawei Brovi E3372-325?

Quote

Implemented Origin header enforcement for the KeenDNS Web application proxies. [NDM-3988]

• ip http proxy {name} force-origin {origin} — force the addition of the specified {origin} header to the {name} HTTP(s) proxy.

Однако уже на этапе добавления в конфигурацию получаю ошибку:

(config)> ip http proxy cdb force-origin Access-Control-Allow-Credentials
Http::Proxy error[18554588]: "cdb": invalid Origin value: "Access-Control-Allow-Credentials".

Что-то упустил или эта фича не ушла из альфы в релиз?

KeeneticOS 5.1.1

Настраивал в бизнес-центре Wi-Fi, сканируя свободные каналы, причем соседских сетей не много, но они постоянно прыгают (видимо, тоже автовыбор стоит).  Заметил, что 2-й Кинетик не сильно двигается от занятого канала по частоте (при единственном занятом в тот момент 6-м он упорно настраивался на 8-й). 

Поэтому мысль - можно ли реализовать в окне Wi-Fi галочку "использовать только непересекающиеся"). Тогда бы роутер при автосканировании на 2.4 выбирал бы только из 1, 6, 11, не используя пересекающие по часте промежуточные. С учетом того, что на 2.08 уже реализовано периодически сканирование свободного канала, такое бы решение позволило бы в незабитом эфире отлично расходится по частоте с другими Wi-Fi.

Не плохо было бы сделать плитку на которой выводить Активных пользователей системы. Тех кто в онлайн.

Например, будет видно кто залогинен в веб-админку, каким способом. Допустим admin и количество подключений во всех вариациях если возможно.

Видишь пользователей подключившихся с логином и паролем к любому приложению роутера. smb, VPN server, FTP, SSH, Telnet и т.д.

Можно просто цифрой показывать количество таких пользователей, а можно и IP адрес указывать.

Вообще, если даже и не плитка для дашборда, то такая оснастка не помешала бы и в основном меню. Например, в Диагностике в виде вкладки Активные пользователи.

Если дальше развивать тему, то там же можно было бы встроить методы принудительного отключения или бана по IP временного или перманентного, в тех вариациях где это возможно.

на hopper флеш 256MB из которых почти 100 доступны для opkg. может быть и на устройствах с 128MB можно сколько-то выделить под opkg?

Quote

HTTP: устранена уязвимость CVE-2026-42533 [NDM-4566]

22 июля 2026 это же исправление дошло до 5.1.2 (preview) (список обновлений только на support.keenetic.com, на форуме список изменений для 5.1.2 не опубликован до сих пор):

Quote

Mitigated the CVE-2026-42533 vulnerability for HTTP protocol. [NDM-4566]

В стабильной ветке на 24 июля 2026: 5.1.1; очевидно с уязвимостью.

Просматривая изменения для ветки 5.0 можно заметить, что в 5.0.6 (preview):

Quote

HTTP: устранена уязвимость CVE-2026-1642 в HTTP-прокси [NDM-4267]

в 5.0.7 (preview):

Quote

• Wi-Fi: устранены уязвимости [SYS-1542]
  • CVE-2014-3570
  • CVE-2022-4304

в 5.0.9 (preview):

Quote

HTTP: устранена уязвимость CVE-2026-28753 в службе веб-конфигуратора [NDM-4368]

и только с 5.0.10 (preview → stable) эти исправления дошли до пользователей стабильного канала.

Стабильная ветка ждёт исправлений уязвимостей неделю-две; при этом про эти уязвимости все знают, т.к. они светятся в списках изменений предварительных версий. Нельзя ли выпускать срочные обновления, содержащие только исправления безопасности сразу, вместо того чтобы ждать пока комплект новых фич/фиксов не связанных с уязвимостями стабилизируется?

Сокрытие исправлений безопасности из списков изменений предварительных версий не является решением: злоумышленники могут просто сравнить файлы текущего и предыдущего предварительного релиза, и поискать CVE для обновленных компонентов.