Leaderboard

Версия 2.14.B.1.0-2 (официальная бета): ACME: отключен отзыв сертификата при автоматическом продлении Web: исправлено отображение настройки "NAT для клиентов" (сообщил @Кинетиковод) Web: исправлены различные проблемы с разметкой всплывающих окон (сообщил @T@rkus и другие) Web: исправлены единицы измерения пропускной способности и размера DECT: добавлена поддержка трубок: Panasonic KX-TGA806 Panasonic KX-TGA810 Panasonic KX-TGA550RU Yealink W52P DECT: исправлена ошибка замены номера исходящего вызова при выборе линии через # удален компонент NortonDNS (сообщил @Sfut) оптимизирован размер прошивки

Версия 2.11.D.0.0-2: удален компонент NortonDNS (сообщил @Sfut) ACME: отключен отзыв сертификата при автоматическом продлении добавлена поддержка модема Huawei E5776 (сообщил @Orbit) IPsec: восстановлена совместимость с сервисом CyberGhost обновлен OpenSSL до версии 1.1.0j обновлен пакет tzdata до версии 2018g WiFi: версии драйверов синхронизированы с 2.14

@r13 @ankar84 @Vik2018 "добавлена защита от перебора паролей HTTPS" - да, все правильно, но это касается старого WebUI \ nginx. Для нового WebUI поддержку 'lockout-policy' для протокола HTTPS планируется добавить в 2.15

Думаем над этим.

Да и у вас ошибка в написание команды, надо так:

Пока еще нет. Думаю, сперва стоит обновить transmission до версии 2.94. Кто за?

Проблема найдена, в ближайшем драфте будет исправлена.

Сейчас тупо по ip-адресам все нужно смотреть. Если правило одно-два, то нет проблем. Когда их пару десятков - это уже жесть. Поле "описание" есть в разделе переадресации портов, добавьте и сюда, пожалуйста.

Keenetic Giga II 2.14.B.0.0-1 Modem E3372H Ping Check не выключается, установлен режим автоматический, я выбираю режим выключена и жму сохранить но не сохраняется всё равно остаётся режим автоматический, много раз пробовал и перезагружал роутер но безрезультатно.

Это наверное к @eralde вопрос, чтобы Web перед скачиванием запрашивал доступ к файлу. 404 показывается специально, потому что намного лучше сказать, что файла вообще нет, чем показать 403 forbidden и дать злоумышленнику знать, что он есть, и чтобы он долбился, пытаясь его получить.

После обновления прошивки до 2.14.B.1.0-2 (с 2.14.B.0.0-1). Правильно написал, или все-таки надо в раздел "Мобильное приложение"? Селф-тест нужен?

Лимиты для доменов keendns и keenetic.io сильно повышены, столкнуться с ними малореально, а с 429 ошибкой мы разбираемся.

Вопрос из разряда 90-х. Что лучше Sony или Panasonic. Ясно понятно что выбирать вам. Надо себе ясно понимать что нынче железо имеет, как бы это странно не звучало, вторичное значение на фоне OS. И в данном ракурсе, ndms порой на голову круче вышеназванной компании, в плане юзабельности и френдлинности. Всё перечисленное, выше сугубо IMHO...

Делюсь работающим примером Function Get-StringHash([String] $String,$HashName = "MD5") { $StringBuilder = New-Object System.Text.StringBuilder [System.Security.Cryptography.HashAlgorithm]::Create($HashName).ComputeHash([System.Text.Encoding]::UTF8.GetBytes($String))|%{ [Void]$StringBuilder.Append($_.ToString("x2")) } $StringBuilder.ToString() } $session="" $user = "admin" $pass= "ppp" $authorized = $false try{ $site = Invoke-WebRequest -URI 'http://my.keenetic.net/auth' -SessionVariable session $authorized=$true }catch{ $s = $_.Exception.Response if($s.StatusCode -eq "Unauthorized"){ $token = $s.Headers["X-NDM-Challenge"] $realm = $s.Headers["X-NDM-Realm"] $id= $s.Cookies["session_id"].Value $tomd5=$user + ':' + $realm + ':' + $pass $hashmd5=Get-StringHash $tomd5 "MD5" $tohash = $token+$hashmd5 $hashed=Get-StringHash $tohash "SHA256" $body=@{"login"=$user ; "password"=$hashed} try{ $rv = Invoke-WebRequest -URI 'http://my.keenetic.net/auth' -Method Post -Body ($body|ConvertTo-Json) -WebSession $session -ContentType "application/json" $authorized = $true }catch{ } if ($authorized){ $v = Invoke-RestMethod -Uri 'http://my.keenetic.net/rci/show/ip/hotspot/host' -Method Get -WebSession $session -ContentType "application/json" } $v.Length } }

Данная тема создана по следам инструкций по использованию предыдущих версий первой ветки замечательного приложения dnscrypt-proxy, которое автор вернул к плотной разработке, правда, сменив язык на Go. Для начала рекомендую ознакомиться с первыми статьями: Сразу уточню, вторая версия dnscrypt-proxy подойдет скорее тем пользователям, у кого роутер с достаточным количеством оперативной памяти, так как приложения на go довольно требовательны к ресурсам. Например, на моей Keenetic Ultra проблем с памятью нет, поэтому я и перешел на вторую ветку dnscrypt-proxy не особо раздумывая. Ознакомиться со всеми преимуществами dnscrypt-proxy2 перед первой веткой можно на странице проекта на GitHub. Хочу заметить, что при использовании dnscrypt-proxy2 уже нет необходимости в связке с dnsmasq или чем-то еще. dnscrypt-proxy2 сам умеет и кэшировать запросы и работать с несколькими серверами сразу, выбирая наиболее быстрый и ещё много чего. На момент написания данной статьи актуальной версией является dnscrypt-proxy 2.0.14 Итак, начиная с версии 2.0.8 (кажется) dnscrypt-proxy2 собрана уважаемым @zyxmon в тестовой ветке репозитория Entware. Пользователям Entware-3x и Entware-NG нужно перейти на репозиторий Entware с помощью следующих команд, введенных 2 раза подряд (за подробностями и решением проблем нужно пройти в соответствующую тему) иначе будете получать ошибку, что пакет dnscrypt-proxy2 не найден. opkg update opkg upgrade Установка Начиная с 2.0.11 пакет dnscrypt-proxy2 доступен для обычной установки из репозитория Entware следующей командой: # opkg install dnscrypt-proxy2 Далее установим вспомогательные пакеты: iptables для того, чтобы "приземлить" все DNS запросы наших клиентов на наш dnscrypt-proxy2 cron для того, чтобы обновлять список блокируемых адресов в автоматическом режиме на регулярной основе. # opkg install cron iptables Стандартный конфигурационный файл достаточно полно документирован комментариями по той или иной настройке, да и в целом по-умолчанию всё должно запуститься успешно командой: # /opt/etc/init.d/S09dnscrypt-proxy2 start Хранение файлов DNSCrypt По-умолчанию, файл конфигурации создается в папке /opt/etc/dnscrypt-proxy.toml но лично мне гораздо удобнее все файлы (а их у меня набирается около 10ти) держать в отдельной папке, например, /opt/etc/dnscrypt/ Во-первых, когда все файлы, с которыми DNSCrypt работает располагаются рядом, под рукой, это удобно. Во-вторых, не создается лишнего беспорядка в корне папки конфигурации - /opt/etc/ Но, если вы, как и я решите перенести файл конфигурации и другие сопутствующие DNSCrypt файлы, необходимо учитывать, что при каждом обновлении нужно будет править скрипт запуска /opt/etc/init.d/S09dnscrypt-proxy2 указывая фактическое расположение файла. Для ознакомления приведу полный листинг своего файла конфигурации: Приведу некоторые отличия моего конфигурационного файла от стандартного. listen_addresses = ['192.168.1.1:53', '[::1]:53'] В отличии от дефолтовой строчки, где сервер будет слушать на 127.0.0.1 мне было необходимо, чтобы сервер "слушал" на 192.168.1.1, чтобы я мог прописать данный сервер в настройках DHCP как сервер DNS для всех устройств моей домашней сети. Кстати, так как будем использовать dnscrypt-proxy2 как единственный DNS сервер на роутере, необходимо отключить (а точнее перевести в специальный режим работы при котором компоненты прошивки все равно смогут обращаться к DNS резолверу прошивки через RPC оставив порт 53 свободным) основной DNS сервер NDMS. Сделаем это следующими командами в Cli (не в Entware): opkg dns-override system configuration save Включать только на устройствах с функционирующим IPv6. На самом деле я особой скорости у серверов IPv6 не увидел, так что можно и не включать. ipv6_servers = true Я сейчас вообще рекомендую включить опцию use_syslog и смотреть события DNSCrypt в веб интерфейсе Кинетика на странице Диагностика - Системный журнал use_syslog = true Но если все же привычно работать с логами в виде фалов, то Когда все работает хорошо и стабильно, уровень логгирования нужно вернуть на исходный - 2 (можно и выше) log_level = 0 Далее идет fallback_resolver. Вообще его можно не менять, но мне захотелось поставить популярный ныне CloudFlare DNS с его красивым адресом. fallback_resolver = '1.1.1.1:53' Размер кэша я ставлю в 4 раза больше, чем по умолчанию. Можно не менять. Кстати, в ответах просьба высказаться, какой размер кэша оптимальный по вашему? cache_size = 2048 Блокировка рекламы Далее идет раздел блокировки. В качестве значения параметра blacklist_file указываем полный путь до вашего файла с блокируемыми доменными именами. Я свой файл получаю скриптом автора dnscrypt-proxy blacklist_file = '/opt/etc/dnscrypt/dnscrypt-blacklist-domains.txt' А обновляю этот список еженедельно с помощью cron: Создаем файл скрипта /opt/etc/cron.weekly/generate-blacklist для еженедельного обновления со следующим содержимым: #!/opt/bin/sh cd /opt/etc/dnscrypt/ python generate-domains-blacklist.py -i > list.txt.tmp && mv -f list.txt.tmp /opt/etc/dnscrypt/blacklist-domains.txt /opt/etc/init.d/S09dnscrypt-proxy2 restart И не забываем сделать его исполняемым: chmod +x /opt/etc/cron.weekly/generate-blacklist Можно в принципе логи не зачищать, тогда строчку с rm нужно закомментировать или удалить. Для нормальной работы скрипта генерации blacklist-domains.txt необходимо установить еще 2 пакета: opkg install python ca-certificates После того, как пакеты будут установлены, переходим в папку, где расположен скрипт генерации и проверяем его работу (ошибок быть не должно.? python generate-domains-blacklist.py -i > list.txt.tmp && mv -f list.txt.tmp list Для диагностики корректности блокировки того или иного ресурса или для отлова false positive блокировок рекомендую включить журнал того, что блокируется: log_file = '/opt/var/log/blocked.log' log_format = 'tsv Далее у меня прописан белый список доменных имен, которые не нужно блокировать никогда (привет РКН еще раз). На самом деле, данная опция появилась в последних версиях (кажется в 2.0.11) и ранее белый список обрабатывался скриптом генерации черного списка блокируемых адресов. То есть вхождения белого списка удалялись из черного при генерации. Теперь вот отдельная опция: whitelist_file = '/opt/etc/dnscrypt-proxy/generate-domains-blacklists/domains-whitelist.txt' Добавляем возможность разрешать домены в зоне *.lib Переходим к настройке dnscrypt серверов. И вот тут я очень рекомендую использовать серверы проекта OpenNIC. То есть настройка в конфигурационном файле у меня вот такая (закомментировал основной список публичных серверов и добавил только серверы проекта OpenNIC? #[sources.'public-resolvers'] #urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md'] #cache_file = '/opt/etc/dnscrypt/public-resolvers.md' #minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3' #refresh_delay = 72 #prefix = '' [sources.'opennic'] urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/opennic.md', 'https://download.dnscrypt.info/resolvers-list/v2/opennic.md'] minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3' cache_file = '/opt/etc/dnscrypt/opennic.md' refresh_delay = 72 prefix = '' Почему именно OpenNIC? Используя именно эти серверы получаем один замечательный бонус - разрешение EmerCoin доменных имен типа *.lib и других. Благодаря этому я пользуюсь одним популярным торрент трекером по его доменному имени в зоне *.lib не занимаясь постоянным поиском живых зеркал. Опять же, эти серверы вроде бы не вносят своих блокировок и не логгируют запросы. Хотя как знать. Так же я НЕ рекомендую использовать серверы проекта компании Cisco - OpenDNS. Недавно @Александр Рыжов в канале Keenetic в одном известном мессенджере сообщил, что Cisco заворачивала на себя трафик mail.ru подставляя при этом фейковый сертификат, так что будьте бдительны. Так же прошу обратить внимание, большинство серверов проекта OpenNIC с поддержкой dnscrypt находятся в Европе и Америке, так что моментальных ответов ждать не приходится. У меня самый быстрый сервер дает около 100 мс, и на том спасибо. Отсюда и увеличенный размер кэша, которым я пытаюсь эти задержки свести к минимуму. Перехват всех DNS запросов на роутере. "Приземление" DNS трафика Теперь переходим к очень важной теме, изучая которую я потратил много времени. А именно, речь пойдет об использовании только локального DNS сервера dnscryprt-proxy2 вместо провайдерских DNS серверов на всех устройствах сети. Суть здесь вот в чем. Начиная, кажется. с 6 версии ОС Андроид, видимо, для повышения стабильности (и, имхо, для утоления своей тотальной любознательности) параллельно посылает запросы и на тот сервер, что указан в сетевых настройках, которые получены устройством от DHCP сервера и на сервер 8.8.8.8 Я очень долго не мог понять, почему на всех устройствах я не вижу рекламу, так как она блокируется на роутере, но всегда вижу рекламу на своем Андроид смартфоне. Тогда я с помощью захвата пакетов все и обнаружил. Кстати, более простым способом было посмотреть трафик в Entware с помощью tcpdump. tcpdump -i br0 или tcpdump port 53 -n -nn -v Итак, для начала избавимся от провайдерских DNS серверов. В cli вводим вот эти 2 замечательные команды: interface ISP no ip dhcp client name-servers system configuration save Все эти моменты хорошо расписаны в статье Использование публичных DNS-серверов в интернет-центре, но лично мне их удалось найти тут, на форуме в ответе уважаемого @Le ecureuil От слежки провайдера избавились, осталось приземлить все DNS запросы в корпорацию добра на наш сервер dnscrypt-proxy2. Здесь мне так же помог @Александр Рыжов на канале Keenetic. У данного метода есть и плюсы - например, при подмене локального DNS сервера вирусом на компьютере с Windows запросы пойдут все равно на роутер, а не DNS сервер злоумышленников. Есть и минусы, например, не весь трафик, который идет по UDP\53 не обязательно DNS запросы, это вполне может быть портом для подключения к, положим, OpenVPN серверу. Но так или иначе, для многих домашних сетей данный способ приносит больше плюсов, имхо. В вашем любимом текстовом редакторе создаем файл скрипта /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh: #!/bin/sh [ "$type" == "ip6tables" ] && exit 0 [ "$table" != "nat" ] && exit 0 [ -z "$(iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 exit 0 Либо, если любимого редактора еще нет, можно воспользоваться вот такой длинной командой: echo -e '#!/bin/sh\n[ "$type" == "ip6tables" ] && exit 0\n[ "$table" != "nat" ] && exit 0\n[ -z "$(iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53\nexit 0' >> /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh Затем делаем созданный скрипт исполняемым: chmod +x /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh Вероятно, скрипт можно написать значительно изящнее и ловить не UDP, но и TCP трафик, но у меня получилось только вот так. В ответах, гуру баша могут подсказать как сделать правильнее, подправлю для общего блага. Мне "приземление" только UDP трафика на 53 порт роутера помогло полностью избавиться от рекламы на всех устройствах домашней сети. Так что TCP можно и не трогать. В итоге: Защитили весь свой DNS трафик от перехвата со стороны провайдера и Гугла Заблокировали рекламу на всех устройствах домашней сети (это наиболее актуально для всяких Смарт ТВ и других девайсов не нет возможности блокировать рекламу на самом устройстве) Получили разрешение имен *.lib и других, чем немного упростили себе жизнь в все более блокируемом интернете Диагностика проблем с запуском\работой. Рекомендую для диагностики запустить DNSCrypt из консоли строкой запуска из скрипта, то есть командой: dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml Путь до файла конфигурации при необходимости поправить, по-умолчанию будет вот такой -config /opt/etc/dnscrypt-proxy.toml Для начала посмотрим журнал dnscrypt-proxy2 в том месте, где вы его настроили. Я смотрю вот такой командой: # tail -f -n 30 /opt/var/log/dnscrypt-proxy-v2.log Либо если включили syslog, то события смотрим веб интерфейсе Кинетика на странице Диагностика - Системный журнал Следующая команда должна выдать PID процесса. Если ничего не выдала - DNSCrypt не запущен (возможно завершился с ошибкой) ~ # ps | grep dnscrypt 19766 root 655m S dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml 19792 nobody 655m S /opt/sbin/dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml -child 20271 root 4780 S grep dnscrypt ~ # Проверить, слушается ли порт 53. Обратите внимание, слушать должен именно процесс dnscrypt-proxy, а не ndmproxy ~ # netstat -tulnp | grep dnscrypt tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 19766/dnscrypt-prox tcp 0 0 ::1:53 :::* LISTEN 19766/dnscrypt-prox udp 0 0 192.168.1.1:53 0.0.0.0:* 19766/dnscrypt-prox udp 0 0 ::1:53 :::* 19766/dnscrypt-prox ~ # Опять же все ограничения, которые касались использования первой версии dnscrypt-proxy справедливы и для второй, ссылки на инструкции я приложил выше. Это моя первая инструкция в этом разделе, так что сильно не пинать, а конструктивная критика крайне приветствуется. Если есть, что нужно подправить\доработать - пишите, вместе сделаем использование данного пакета проще и эффективнее.

Давно не работает защита от брутфорса вебморды. В бете так и не заработала. С учётом того, что у многих вебморда выставлена наружу это не есть хорошо. Изменения параметров защиты ip http lockout-policy применяются, но сама защита так и не заводится.

Lite (KN-1310), 2.14.B.0.0-1, клиент Wi-Fi. На странице "Системный монитор" некорректно отображается уровень сигнала. Постоянно 100% При сканировании эфира, уровень сигнала похож на правду. В 2.13.C.0.0-3 было в порядке.

@Le ecureuil вы, кстати, обещали разобраться с этой проблемой. Реально неудобно смотреть на UUID вместо метки.

@TCH1960 проблему воспроизвел, спасибо. В следующем выпуске 2.14 будет исправлено

Сомнительный функционал, уж извините. Есть проблемы и поважнее.

У меня не Android 6, да и не вылетает он. А приложение не работает. После обновления прошивки до 2.14.B.1.0-2 на Ультра-2. PS. Xiaomi Redmi4A, Android 7.1.2

Предложение реализовать DNS-over-HTTPS от Google Public DNS по образу и подобию SkyDNS и Яндекс.DNS. Плюсы: 1) Аналог DNSCrypt, но реализация на уровне прошивки; 2) Запросы к DNS Гугла идут по HTTPS, снижая эффективность сниффинга, атак MITM итд.; 3) Отсутствие подмен резолвинга со стороны в т.ч. провайдеров и соответствующих последствий; 4) Поддержка философии открытого интернета и информационной целостности. Подробности и желательные настройки (для гибкости): https://developers.google.com/speed/public-dns/docs/dns-over-https Вариант реализации архитектуры DNSSEC через Google DNS-over-HTTPS (чтобы был опорный код для скорости реализации): https://github.com/behrooza/dnsd

@Padavan @ndm @Le ecureuil Extra II 2.14.B.0.0-1 (репитер) Giga II draft 2.14.B.0.0-1 (роутер). Заметил,что при включенном прямом mac на репитере когда клиент переключается на основной роутер при голосовом общении в What`s app и Signal наблюдается ухудшение качества связи и помехи. На связке Air 2.14.B.0.0-1 (репитер) KN-1010 2.14.B.0.0-1 (роутер) на сети 5Ггц происходит похожее. При отключении прямого мас на репитере качество связи на роутере почему-то улучшается и искажения практически полностью исчезают. Накатил на Giga II 2.11.D.0.0-1 (legacy) для сравнения. Что удивительно даже с включенным прямым mac на репитере качество голосовой связи в мессенджерах хорошее. В качестве клиента использовал Samsung GT-N7100. И еще подметил,что периодически бывает ,что клиент не может подключиться к репитеру из-за того,что не может получить IP. Стоит отключить прямой mac подключение происходит.

На этом ресурсе ответ будет только один - да, хороший выбор. Вы не то место выбрали задавать подобный вопрос. Спрашивать о таких вещах на этом ресурсе - моветон.