Hotery

ну команда opkg dns-override для замены прошивочного dns-прокси сторонне службой, это не совсем "то случай" - нужно разрешать 1/2/3/10 доменов через сторонний dns, не все подряд. очень хотелось бы чтобы пофиксили. может отпадет когда сделают "Возможность добавления маршрута по домену"

к сожалению почему-то нет возможности отредактировтаь, потому дополню здесь... хотелось бы 1) Чтобы с компьютеров (где гораздо эффективнее работает какое-то расширение браузера) не было фильтра 2) на планшете/телефоне/приставке был фильтр но не adguard и проч. встроенный в прошивку а работающий на каком-то устройстве в сети (типа pi-hole или adguard home) который можно подкрутить по своему желанию (например, adguard иногда блочит не то что нужно например не всегда работает переход в магазин с кэшбэк сервиса)

hostname роутера например

Очень классная штука эти интернет-фильтры, и много их добавлено, но т.к. это просто dns сервера, было бы здорово иметь возможность создавать свои. Это полезно, например, если где-то в сети (или на самом роутере..) стоит adguard-home ну или pi-hole, или что-то еще. Или dns сервер с фильтрацией которого еще нет в "интернет-фильтрах".

Добрый день! В Keenetic как-то было добавлена замечательная фича https://help.keenetic.com/hc/ru/articles/360001574779-Нестандартный-порт-для-DNS-сервера. В системе видимо сделана защита дурака которая не позволяет указывать dns сервером сам роутер (через 127.0.0.1, 192.168.1.1, 0.0.0.1 и проч). Вполне понятная вещь. Но оно также блокирует и указание dns сервера на нестандартном порту на роутере (например, 127.0.0.1#5353) - почему? там висит dnsmasq / unbound/... для каких-то доменов (config)> ip name-server 127.0.0.1 test.lan Dns::Manager error[22544486]: address: invalid IP address: 127.0.0.1. (config)> ip name-server 127.0.0.1:5353 test.lan Dns::Manager error[22544486]: address: invalid IP address: 127.0.0.1. кстати вот так работает, так и задумывалось? (config)> ip name-server 78.47.125.180:5353 test.lan Dns::Manager: Name server 78.47.125.180:5353 added, domain test.lan. и даже так, и нет никакой проверки (config)> ip name-server 78.47.125.180 Dns::Manager: Name server 78.47.125.180 added, domain (default).

В разделе "Сетевые правила" - "интернет-фильтр" все хорошо видно, табличка "сервер" - "домен" (или пустое место для всех прочих запросов" - "подключение". В дашборде в спойлере "подробнее о соединении" "DNS-серверы" все dns-сервера кучей, без каких-либо различий. Пожелание как-то "облагородить" этот список, например, или вообще убрать днс-сервера для отдельных доменов (в информации о подключении не очень-то нужны..) или как-то (бледным цветом или курсивом) отметить ну или вообще подписать. Особенно интересно этот список выглядит, когда несколько записей (несколько доменов) с одним днс сервером.

Это совершенно не мешающая и не влияющая ни на что проблема, просто "неприятные" красный строчки в логе...Они появляются когда в настройках dhcp пула стоит update-dns. Конечно, после переименования устройства проблема пропадает. Но было бы здорово если бы такие (недопустимые, с символом подчеркивания) просто игнорировались (при автоматическом добавлении в dns) ndm Dns::Manager: invalid domain name: yeelink-light-bslamp2_mibt32A Май 6 08:36:02 ndm Dns::Manager: invalid domain name: yeelink-light-bslamp2_mibt32A5.mynet.lan.

Вот при открытии того же адреса с телефона с мобильного инета (роутер за NAT, провайдер выдает серый ip типа 10.25** - так что точно через облако) 192.168.1.1 - - [04/May/2020:17:52:52 +0300] "GET / HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Linux; Android 10; HD1900) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Mobile Safari/537.36"

Добрый день. Вот тут написано что это в Реализованных пожеланиях. Пробую - не хочет работать (что-то не так делаю??) set_real_ip_from 192.168.1.1; set_real_ip_from 192.168.1.0/24; # для теста real_ip_header X-Forwarded-For; real_ip_recursive on; # наверно необязательно? Вот что в логах после после curl http://192.168.1.30 -H "Host: <domain>.keenetic.link" -H "X-Forwarded-For: 1.2.3.4" 1.2.3.4 - - [04/May/2020:11:43:12 +0300] "GET / HTTP/1.1" 302 5 "-" "curl/7.54.0" Вот что в логах после curl http://<domain>.keenetic.link" (т.е. идет через облако) 192.168.48.1 - - [04/May/2020:11:45:54 +0300] "GET / HTTP/1.1" 302 5 "-" "curl/7.54.0" Возможно что-то делаю не так? Или что-то не так работает?

Спасибо, понятно.

Добрый день. Не знаю куда уж писать.. В статье комменты закрыты (почему?) В статье "Включение авторизации для устройства с открытым веб-интерфейсом, при использовании удаленного доступа через службу KeenDNS" написано Теперь при открытии в веб-браузере адреса qnap.myrouter01.keenetic.pro вы увидите точно такое же окно авторизации, как при заходе на сам Keenetic по адресу myrouter01.keenetic.pro. Не, не такое же, а обычное окошко авторизации (basic-auth?) Это баг или так и должно быть, и в статье не верно написано? Или не так понимаю смысл "точно такое же".. Вот то, что на картинке неудобно тем, что, например, не все браузеры позволяют сохранить пароль

а так вариант с перенаправлением на dnsmasq через 78.47.125.180:<какой-то-порт> (ip name-server example.org 78.47.125.180#какой-то-порт) >и в dnsmasq что-то вроде port=<какой-то-порт>; ipset=/customlist вполне может работать. Кстати, прошивка (cli) блокирует указание днс резолвера на нестандартном порту на самом роутере? Видимо, для защиты чтобы на роутер сам на себя запросы не посылал? а указание нестандартного порта позже запилили и это поправить сложно\просто забыли?

Не знаю корректно ли писать в разделе текущей версии, т.к. это было и раньше. Проблема в общем-то косметическая но тем не менее... При подключении через клиента (клиент Windows, не другой роутер если это важно) в Системном журнале отображается следующее Фев 18 15:54:09 ppp-sstp sstp: proxy: connection from 10.255.222.15:55304 Фев 18 15:54:09 ppp-sstp ppp1:: connect: ppp1 <--> sstp(10.255.223.29:55304) Фев 18 15:54:09 ppp-sstp ppp1:toff: toff: authentication succeeded Фев 18 15:54:09 kernel sstp0: renamed from ppp1 Фев 18 15:54:09 ndm SstpServer::Manager: user "remoteuser" connected from "10.254.221.15" with address "172.16.5.38". собственно 10.255 - серый ip провайдера. Собственно, SSTP-сервер работает через облако. Сорри если чего-то недопонимаю, но кажется в последней строчке должен быть адрес клиента. Ну или что-то иное, никак не внешний ip роутера.

Хотелось бы добавить в голосовалку следующее пожелание. Возможность где-то в веб-интерфейсе (например, на странице сегмента сети, если возможно) поставить выпадающий список типа "разрешать адреса dns-сервером keenetic" и опциями "автоматически добавлять по hostname" (dnsmasq. windows dhcp+dns и прочие так умеют) "вручную" (зайти в свойства устройства и поставить галочку), "отключено". Возможность включать DHCP Option 15 тут же. И галочку вроде "дополнять все короткие dns-имена доменным именем" для пущей надежности разрещения имен (оно ведь точно ничего не сломает, в интернет такие за запросы все равно ходить не должны) (конечно должно включаться только при "автоматически" или "вручную") В статье Каким образом можно указать доменные имена устройствам в локальной сети Keenetic? все уже есть, но через cli + нужно указываеть полное доменное имя. И, если правильно понимаю, в случае, если по какой-то причине домен захотелось сменить - нужно менять и все записи... А вариант с DHCP Option 15 тоже cli (хотя бы в gui галочку...)+ полагается на клиент и может не отработать Да, в курсе про entware и dnsmasq. В курсе возможности в cli. Но очень хочется прекрасного юзерфрендли и чтоб все само... И да, LLMNR не так надежен и не на всех устройствах есть, в отличие от DNS.

почему-то нет кнопки "редактировать" поторопился и не знал про команду ip http log auth, теперь в логах Июл 28 14:41:17 Июл 28 14:41:17 ndm Core::Scgi::Auth: authentication failed for user admin. без адреса откуда логинился пользователь - хотя этой строчки вообще не должно быть, судя по статье...