ankar84

А может быть уже есть готовая реализация? А то я далек от баша и iptables.

А у меня всё по прежнему, вывод с ошибкой. Пока вроде нечего не обновилось.

Вот прямо в моменте и не доступно. Возможно это связано, с тем, что KeenDNS FQDN разрешается как в мой белый IPv4 адрес, так и в облачный IPv6 адрес KeenDNS. Хотя только что поставил и затем снял галочку Режим работы (IPv6) на странице Доменное Имя и это имя стало разрешаться только в мой реальный IPv4 адрес. Но веб так и не доступен. Селф ниже как обычно.

Теперь понял где и что поправлено. Подожду штатного обновления, так как проблема не слишком критичная.

Что-то не пойму, куда именно добавлен патч. Установил самый свежий драфт 2.15.A.3.0-1, в Entware сделал update&&upgrade, а ошибка осталась.

Супер! Большое спасибо! Как сообщите, перейду на драфт и протестирую.

Доброго дня! Имею проблему с недоступностью webui по зарегистрированному имени KeenDNS с автоматическим получением сертификата Let's Encrypt. Так же по этой проблеме создан тикет #400857 в официальную поддержку, где коллеги уточнили, что с текущим уровнем журналирования происходящего с KeenDNS и в целом webui сложно диагностировать мою проблему и попросили обратится к разработчикам тут, на форуме, чтобы те добавили расширенную диагностику работы webui в том числе и по KeenDNS FQDN. От себя добавлю, что было бы очень здорово, если бы эта расширенная диагностика была опциональной, а не обязательной. То есть выполняешь в CLI что-то типа set http.debug=1 и у тебя включается эта самая расширенная диагностика. В целом, считаю данную функцию очень нужной. Притом и самим разработчикам для более точной диагностики возникающих проблем. Прошу поддержать голосованием. Спасибо!

Нужно проверить, работает ли приземление DNS запросов клиентов на роутер, например, командой ~ # iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1" Can't find library for target `CONNNDMMARK' -A PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 Так же с помощью tcpdump host IP_проверяемого_девайса посмотреть куда именно проходят запросы, на какой сервер.

Обновился до релиза 2.14 и проблема резко обострилась. Даже после перезагрузки роутер не доступен по KeenDNS FQDN. Напомню, Запрос #400857 Селф будет ниже. Большая просьба @Le ecureuil обратить внимание. Спасибо!

@vlad @rotor я сегодня обновился до 2.14 релиза и подтверждаю проблему со скриптом приземления всех DNS запросов на резолвер роутера: Дек 3 22:46:51 ndm Opkg::Manager: /opt/etc/ndm/netfilter.d/01-ClientDNS-Redirect.sh: Can't find library for target `CONNNDMMARK'. Взываю на помощь @Александр Рыжов и @Le ecureuil Каких-то библиотек не находит простой скрипт #!/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

@Le ecureuil @eralde ок, если это by design, то тему, думаю, можно закрывать. Спасибо за объяснения.

Действительно, начиная с версии 2.11.A.6.0-0 где явно указано, что защита от перебора https есть.

Тоже считаю, что защищать http, но не защищать https, который keenetic os даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно.

@rotor, @vlad у себя в логах такой записи не вижу. Давайте "сверять время", а точнее окружение. У меня сейчас 2.13.C.0.0-3 на Giga (KN-1010), Entware обновлял последний раз где-то с месяц или чуть больше назад. # dnscrypt-proxy --version 2.0.16 # iptables --version iptables v1.4.21

В общем, именно так реализовать вряд ли получится. Так как зону lib умеют разрешать ТОЛЬКО серверы проекта OpenNIC, то только у них и нужно спрашивать об этой зоне. Если использовать общий список серверов, который так же включает в себя серверы opennic, то разрешить узлы зоны lib скорее всего не получится, так как есть гораздо более быстрые серверы, которые и будут отвечать на ваши запросы, а они в свою очередь ничего не знают про зону lib. Поэтому решением в лоб будет использовать только серверы opennic (я именно так и делаю). Так же можно решить это проблему средствами dnsmasq (как вы и указали) или же средствами самого dnscrypt-proxy (я имею ввиду forwarding). Но в обоих случаях, насколько я понимаю, будут выполняться обычные dns запросы, а не dnscrypt шифрованные запросы.

На самом деле это странный баг/фича. Всегда использовал шифрование ещё с времён дефолтного интерфейса transmission, наверное, на 2.06 и всё качало/раздавало. Даже было видно, что все соединения с замочком (шифрованы). А сейчас при включении обязательного шифрования transmission просто не качает. Имхо, так быть не должно.

Подскажите, вот это выше ваш действительный Link-Local IPv6 адрес роутера? Могу ошибаться, но может быть имя интерфейса у вас не br0. Получается ли работать с IPv6, если указать сервер как было по-умолчанию в файле конфигурации [::1]:53?

Можно попробовать вот это решение, вообще средствами прошивки.

Доброго дня! Предлагаю совсем небольшую, но,на мой взгляд достаточно полезную доработку - поменять местами Проверка сетевого соединения и Системный журнал. За время пользования Кинетиками выполнял проверку сетевого соединения от силы раза 2, а вот логи смотреть приходится довольно часто. Да и здесь на форуме при оформлении любой проблемы проблемы требуются выдержки из журнала. А у меня и на ноутбуке и на смартфоне при открытии раздела Диагностика чтобы получить доступ к кнопке Показать журнал нужно воспользоваться прокруткой вниз. Дело секундное, конечно, но все же. Кому так же как мне хотелось бы получать доступ к кнопке Показать журнал сразу при открытии страницы Диагностика, прошу голосовать - нажимаем стрелочку вверх слева от заголовка темы.

@Вежливый Снайпер, все ответы даны вот тут Load-Balancing-Options

~ # ls -la /opt/etc/dnscrypt/ drwxr-xr-x 2 root root 4096 Sep 27 21:59 . drwxr-xr-x 19 root root 4096 Sep 14 10:16 .. -rw-r--r-- 1 root root 2138019 Sep 17 04:04 blacklist-domains.txt -rwxrw-rw- 1 root root 194 Sep 14 23:04 cloaking-rules.txt -rwxrw-rw- 1 root root 15433 Sep 16 17:56 dnscrypt-proxy.toml -rw-r--r-- 1 root root 3758 Aug 10 21:28 domains-blacklist-all.conf -rwxrw-rw- 1 root root 3070 Aug 10 21:31 domains-blacklist-local-additions.txt -rwxrw-rw- 1 root root 5147 Aug 10 21:34 domains-blacklist.conf -rw-r--r-- 1 root root 229 Aug 10 21:28 domains-time-restricted.txt -rwxrw-rw- 1 root root 381 Aug 28 23:16 domains-whitelist.txt -rwxrw-rw- 1 root root 165 Sep 15 11:06 forwarding-rules.txt -rwxr-xr-x 1 root root 5808 Aug 10 21:28 generate-domains-blacklist.py -rw-r--r-- 1 root root 4233 Sep 27 21:59 opennic.md -rw-r--r-- 1 root root 298 Sep 27 21:59 opennic.md.minisig -rw-r--r-- 1 root root 1809 Sep 16 15:28 quad9-resolvers.md -rw-r--r-- 1 root root 306 Sep 16 15:28 quad9-resolvers.md.minisig Скрипт запуска ~ # cat /opt/etc/init.d/S09dnscrypt-proxy2 #!/bin/sh ENABLED=yes PROCS=dnscrypt-proxy ARGS="-config /opt/etc/dnscrypt/dnscrypt-proxy.toml" PREARGS="" DESC=$PROCS PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin . /opt/etc/init.d/rc.func Конфиг Скрипт генерации блек листа в кроне ~ # cat /opt/etc/cron.daily/1-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 Скрипт приземления клиентских запросов ~ # cat /opt/etc/ndm/netfilter.d/01-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 Если нужны какие-то еще, пишите, дополню.

Подскажите, что у вас прописано в настройках DNS на клиенте? Может быть явно сервер Яндекса и прописан вручную? А то исходя из представленных скриншотов у вас запросы должны на DNS Гугла уходить (8.8.8.8)

Это именно И его нужно отредактировать, если для хранения файлов dnscrypt-proxy используется выделенная папка vi /opt/etc/init.d/S09dnscrypt-proxy2 Вместо vi можно использовать любой установленный текстовый редактор, или вообще отредактировать из Windows в Notepad++ (рекомендую именно его) через SMB шару.

Доброго дня, @vikrk Все верно, данная папка не создается автоматически. Все дело в том, что у меня в конфигурации для dnscrypt-proxy используется несколько сопутствующих файла (блеклис, вайтлист, cloacking правила, форварды, скрипт генерации блеклиста) поэтому я создал отдельную папку внутри /opt/etc/ и назвал ее dnscrypt-proxy (на самом деле сейчас для краткости переделал в /opt/etc/dnscrypt/). Сделал я это и с функциональной стороны - все файлы рядом и с эстетической - ну, не нравится мне когда куча файлов от DNSCrypt лежит в корне /op/etc/ А по умолчанию скрипт запуска в /opt/etc/init.d/ запускает демона dnscrypt-proxy с параметром dnscrypt-proxy -config /opt/etc/dnscrypt-proxy.toml В моем случае это нужно исправить на dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml Прошу обратить внимание - это нужно будет делать каждый раз при обновлении пакета dnscrypt-proxy2 если вы так же перенесете все данные в одну папку. Буду из дома, поделюсь, но в теме уже кажется если листинги моих файлов. Единственно, что я обычно все переделывал под дефолтное расположение конфига. Да, совершенно верно. Все эти моменты хорошо расписаны в статье Использование публичных DNS-серверов в интернет-центре

Файл opennic.md создался рядом с файлом конфига? Если ранее работало с общим списком серверов, то там где уже расположен файл public-resolvers.md Если просто запустить командой из скрипта /opt/etc/init.d/S09dnscrypt-proxy2 как это сделано вот тут ? Что-то типа # dnscrypt-proxy -config /opt/etc/dnscrypt-proxy.toml Таким образом можно отловить синтаксические ошибки файла конфигурации - в ошибке, если она есть, будет указан ее номер строки в конфиге. Или еще вариант - можно использовать общий список public-resolvers.md, но нужные (серверы проекта OpenNIC) указать вот так: server_names = ['doh-ibksturm', 'fvz-anyone', 'fvz-anytwo', 'ibksturm', 'opennic-ethservices', 'opennic-famicoman', 'opennic-tumabox', 'opennic-luggs', 'opennic-luggs2', 'opennic-onic', 'publicarray-au', 'publicarray-au2', 'publicarray-au-doh'] Но данный способ получается статическим, то есть при добавлении новых серверов в список, они не будут задействованы, но работать должно.