ankar84

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

Что-то не пойму, куда именно добавлен патч. Установил самый свежий драфт 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 даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно.

Так как с недавних пор лежит зеркало rutor в зоне lib я начал искать способы простого обхода блокировки основного адреса в зоне info. Обход блокировок в данной теме это слегка оффтоп, но о нем чуть ниже. Так как критичность разрешения зоны lib уменьшилась, я оставил возможность разрешения данной зоны через фичу forwarding в dnscrypt-proxy2. В файле forwarding-rules.txt добавил нужные сайты в зоне lib и указал несколько серверов из России со страницы всех серверов проекта OpenNIC и начал использовать общий список [sources.'public-resolvers'] тем самым получил и максимальную скорость резолвинга всех адресов и возможность резолвинга адресов зоны lib. Теперь про обход. Пробовал красить пакеты из определенного ipset и отправлять их в таблицу маршрутизации, где шлюзом указан интерфейс OpenVPN подключения по инструкции @Александр Рыжов вот отсюда. Но сайты не открывались, хоть traceroute правильно показывал, что вторым хопом раскрашенные пакеты уходили в туннель. Сейчас рабочим решением оказалось просто по крону раз в час запускать скрипт, который берет построчно все адреса сайтов из заданного файла, с помощью nslookup разрешит их IP адреса, для которых с помощью route добавит статический маршрут через интерфейс ovpn_br0 в OpenVPN туннель. И данное решение у меня работает стабильно. Так же добавленные маршруты можно отследить на странице Маршрутизация в WebGui Кинетика. #!/bin/sh for i in `cat /opt/root/vpnsitelist.txt`; do #по каждой строке из файла с ресурсами (FQDN), на которые нужно подключаться через VPN сервер for j in `nslookup $i | egrep -v 192.168.1.1 | awk '/Addr/ {print $3}'`; do #получаем только результаты резолвинга и их добавляем в качестве статического маршрута через интерфейс ovpn_br0 #в данном случае, в качестве DNS сервера используется локальный адрес роутера - 192.168.1.1 #по IPv6 адресам из резолвинка получаем сообщение вида "route: resolving IPv6 address" route add -host $j dev ovpn_br0 done done

@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 шифрованные запросы.

По сообщению коллег из технической поддержки, на их экземпляре смартфона моей модели никаких проблем с воспроизведением видео историй в Инстаргам с включенным блютузом нет, что на самом деле очень странно, так как в гостях были друзья с таким же смартфоном и проблема проявлялась стабильно. Но тем не менее, было решено, что это у меня с женой такие не удачные образцы смартфонов и проблемы как таковой нет. Да и у меня за все время решения данной проблемы теперь есть, как говорят заокеанские коллеги, workaround в виде выключения блютуза дома для супруги и использования только 5ГГц точки для меня. На этом тему можно считать закрытой, хоть и не решенной. Если кто-то все же столкнется с такой же или подобной проблемой на своем девайсе, желаю удачи?

Сейчас по запросу ТП проверил воспроизведение проблемы по своему алгоритму на всех каналах 1-2-3-4-5-6-7-8-9-10-11-12-13 и абсолютно на всех были зависания более 5 секунд. Переключался на следующий тестируемый канал после того как "ловил" зависание секунд в 5-10. Кстати, начиная с 12 канала мой внешний адаптер Alfa AWUS036NH на роутбуке уже не мог подключиться к роутеру, поэтому с 12 на 13 канал пришлось менять на тестируемом смартфоне - Xiaomi Redmi Note 4X Snapdragon 4\64 через браузер. Так же еще по статистике данной проблемы, проверил лично у родственников на их роутере от Ростелекома Eltex NTU-RG-1402G-W - проблема воспроизводится. Ранее мне жена говорила, что не замечала на нем проблем. В посте со статистикой информация обновил.