ankar84

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

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

Доброго всем дня! Наконец-то я нашел более-менее воспроизводимый способ демонстрации своей проблемы. У пользователя daria_trrrr у которой открытый профиль есть сохраненные сторис. Я взял для примера вот этот набор, а точнее 2 первых видео сторис в данном наборе. 1. Подключаемся к сети giga (2.4ГГц) KN-10102. Выгружаем из памяти приложение Инстаграм (обычно это делается свайпом на списке запущенных приложений) 3. Удаляем папку с кэшем сторис /Android/data/com.instagram.android/cache/ExoPlayerCacheDir/videocache/ 4. Запускаем сохраненный сторис sp (два первых видео сторис) 5. Смотрим результат. У меня дома нашелся старенький китайский телефон из ноунеймов Neken N6 на MTK Так вот на нем изучаемой проблемы нет. Сам он подвисает и нагревается при просмотре видео сторис в Инстаграм, но не зависает так как наши с супругой смартфоны - по 3-4 раза (а то и больше) за сторис на 5 и более секунд. Сегодня около часа смотрел разные сторис на Neken N6 и именно таких зависаний не заметил. Были фризы при первоначальной загрузке сториса, были микрофризы (видно что железо уже не очень справляется), но таких жестких зависаний не было. Ролик сравнения воспроизведения видео сторис по описанному выше алгоритму на смартфонах Neken N6 (слева) и Xiaomi Redmi Note 4 Snapdragon (справа). Так же сейчас записал очень, на мой взгляд, наглядный ролик на своем Xiaomi Redmi Note 4 Snapdragon демонстрирующий мою проблему. Сначала подключился к точке giga5 - это KN-1010 5ГГц, затем к точке ultra - это Zyxel Keenetic Ultra (для которой сеть giga это WISP) и затем к сети giga - это KN-1010 2.4ГГц. Перед запуском сторис чистил кэш /Android/data/com.instagram.android/cache/ExoPlayerCacheDir/videocache/ Исходя из всего изложенного, можно сделать вывод - есть проблема взаимодействия некоторых клиентских устройств (SoC, прошивка - в данном случае MIUI9 или еще что-то) на определенном трафике (некоторые видео сторис) с точкой доступа 2.4ГГц Интернет-центра Keenetic Giga (KN-1010) Пользователей форума - владельцев смартфонов Xiaomi на SoC Snapdragon и KN-1010 прошу проверить воспроизведение проблемы по описанному мной алгоритму. Большое спасибо!

@Вежливый Снайпер, все ответы даны вот тут 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'] Но данный способ получается статическим, то есть при добавлении новых серверов в список, они не будут задействованы, но работать должно.

Если задача это заблокировать, то можно просто блокировать все IPv6 запросы в dnscrypt-proxy ######################### # Filters # ######################### ## Immediately respond to IPv6-related queries with an empty response ## This makes things faster when there is no IPv6 connectivity, but can ## also cause reliability issues with some stub resolvers. ## Do not enable if you added a validating resolver such as dnsmasq in front ## of the proxy. block_ipv6 = true Если задача все же пользоваться разрешением имен с помощью IPv6 DNS серверов, то еще нужно подумать. Хотя ведь это заблокирует запросы. что пришли на DNSCrypt, а тут явно указан внешний DNS сервер. Тогда все же нужно перехватывать. Либо отключать IPv6 совсем.

Ура! В прошивке 2.13.B.1.0-1 починили! Большое спасибо!

Возможно всё блокируется именно там. P.S. Завидую вашим пингам до серверов.

Гугла не видно, значит хорошо, если у вас в настройках DNSCrypt выбраны Яндекс и Cloudflare. Откройте, пожалуйста, страничку 2ip.ru У меня с приземлением вот так: А без приземления вот так:

@Вежливый Снайпер @vasek00 кстати, только что обнаружил, что вот такая настройка локального DNS сервера на странице Интернет-фильтр кажется приземляет все запросы на указанный сервер: Ранее у меня в поле Подключение всегда было явно выбрано подключение к провайдеру. И тогда как раз пролетали DNS запросы на серверы Гугла с телефонов на Андроид без скрипта "приземления". А вот когда ставишь значение Любой - в dnsleaktest я вижу только "нужные" серверы (без Гугла). Правда, исходя из того, что рекламу на том же 2ip.ru я при такой настройке все же вижу, я могу и ошибаться и скрипт "приземления" все равно нужен. Обновлено: Отбой, не знаю как эта настройка влияет на dnsleaktest, но проверил с помощью tcpdump -i br0 port 53 и вижу вот это: Итог: приземлять запросы нужно. P.S. Если кому интересно, вот фрагмент дампа во время расширенного теста dnsleaktest без скрипта приземления при настройке на любое подключение DNS сервера. Выделил запросы к серверам Гугла, не знаю почему dnsleaktest не выдал их в результате теста.

Если вы не пользуетесь серверами Google в общем списке всех DNSCrypt резолверов, то для максимальной наглядности могу порекомендовать пройти со смартфона на Андроиде расширенный тест на dnsleaktest с приземлением запросов и без него. У меня с приземлением только выбранные мной серверы (OpenNIC и сейчас еще Quad9 тестирую), а если без приземления добавляется целая куча серверов Google из Финляндии.

@Вежливый Снайпер, отличные исследования! Кроме всего прочего в инструкции я написал: Этим я как раз и хотел сказать, что не силен в баше и делал по аналогии с уже имеющимися в интерете скриптами. В этой теме помощи от более опытных пользователей баша пока не было, так что будем пробовать разобраться сами. Строчка [ "$type" == "ip6tables" ] && exit 0 явно как раз призвана пропускать обработку правил для IPv6, тут вам правильно подсказали. Вот тут совсем не уверен. Делал подобным образом для создания 2 правил UDP и TCP, так второе не работало. Об этом я писал в первом посте. Здесь, думаю, нам что-то прояснить может только @Le ecureuil Я настроил dnscrypt-proxy на Link-Local IPv6 адрес роутера, так как именно к нему обращались клиенты на Windows 7-10. Это работает стабильно, хотя, вероятно, и [::1]:53 должно работать. P.S. Quad9 добавляют поддержку DNSCrypt-proxy на свои anycast серверы. Чтобы их потестировать можно добавить их список вставкой в конфиг вот этого текста [sources.'quad9-resolvers'] urls = ['https://www.quad9.net/quad9-resolvers.md'] minisign_key = 'RWQBphd2+f6eiAqBsvDZEBXBGHQBJfeG6G+wJPPKxCZMoEQYpmoysKUN' cache_file = 'quad9-resolvers.md' refresh_delay = 72 prefix = ''

По ресурсам согласен, очень требователен и прожорлив (хотя не по CPU). Про отказоустойчивость я имею ввиду работу с несколькими серверами из коробки (в 1 версии, если не изменяет память, была возможность работы только с одним сервером и приходилось запускать 2 инстанса сервиса на разных портах + dnsmasq для хоть какой-то отказоустойчивости). По надежности 2 версии у меня претензий нет, не замечал падений. Первая версия падала иногда, да. Даже скриптик городил, который проверяет запущен ли демон и запускает в случае необходимости.

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

Доброго дня! Как известно, начиная с Версия NDMS 2.12.C0 в прошивку добавлен SSH сервер. Но для пользователей ОС Windows это особо ничего не меняет, так как что в telnet нужно вводить логин\пароль, что по SSH. Пользователям Linux стало чуть проще, так как SSH там родное, из коробки. Так вот, чтобы у SSH было реальное преимущество, очень хотелось бы реализовать доступ по ключам (сертификатам), как это, например, реализовано с dropbear в Entware. То есть в webgui есть поле для ввода, куда нужно внести свой публичный ключ, а он уже записывается в authorized_keys сервера SSH NDMS При наличии технической возможности, конечно же. @ndm @eralde Предлагаю проголосовать кого данная возможность заинтересовала. P.S. Ошибся форумом, просьба перенести в Развитие

В Entware с установленным tcpdump попробуйте посмотреть вот такой командой трафик во время работы в интернете на смартфоне с Андроидом (взял эту команду, кстати, из первого сообщения данной темы) tcpdump port 53 -n -nn -v

Да, это верное утверждение. То есть все запросы, которые явно идут на dns роутера будут в ответе без рекламы. Нет, здесь не так. Когда клиент отправляет запрос на dns Гугла никакой блокировки рекламных доменов не происходит совсем. То есть когда клиент пытается разрешить dns имя рекламного домена, google dns даст в ответ правильный адрес рекламного сервера. И реклама google тут не исключение. Клиент все запросы отправляет параллельно на google dns. И никакая реклама не блокируется совсем. Поэтому приходится приземлять эти запросы на проход через список блокировки в dnscrypt-proxy2. В общем, на Андроид устройствах DNS сервер 8.8.8.8 используется параллельно с основным сервером из сетевых настроек на устройстве. Итого, клиент когда делает запрос на разрешение имени, по факту делает 2 запроса - на 192.168.1.1 (условно) и на 8.8.8.8. Притом рекламный сервер в ответе от 192.168.1.1 будет заблокирован (127.0.0.1 или 0.0.0.0 или как там dnscrypt блокирует), а в ответе от 8.8.8.8 будет его IP адрес рекламного сервера и клиент откроет рекламу. Можете проверить рекламу не в приложениях, а на любом бесплатном сайте с большим количеством рекламы (я проверяю на rutor.lib, где без блокировки рекламы очень много, а с блокировкой получается как на десктопе в Хроме с uBlock)

В блокировке рекламы по черному списку заблокированных доменных имён в "черном ящике". Всё это очень подробно описано в первом сообщении данной темы

Всё дело в том, что с смартфоны на свежих Андроид параллельно указанному в сетевых настройках серверу отправляют dns запрос на 8.8.8.8. Можете проверить это tcpdump или wireshark, если есть девайсы на Андроиде.

Дело в том, что и в инструкции и у обратившегося @Вежливый Снайпер это так и сделано: dnscrypt-proxy2 слушает на 53 порту адреса роутера. Но что мешает любому клиенту вашей локальной сети, да хоть самому роутеру отправить запрос не на 192.168.1.1 (беру дефолтовый адрес кинетиков), а напрямую на 8.8.8.8? Ваша конфигурация с dnsmasq+dnscrypt этот запрос как-то обработает? Я думаю, что нет. Именно поэтому был написан скрипт, который перехватывает вообще все проходящие (или лучше скажем "пролетающие" через роутер) UDP пакеты на 53 порт и "приземляет" на тот адрес, где слушает dnscrypt-proxy2. И я выразил предположение, что IPv6 запросы тот скрипт не приземлит, для него нужно, вероятно, использовать iptables6

@Вежливый Снайпер, тут нужно понять, что именно подразумевается под перехватом. Если клиент явно обращается к какому-либо dns серверу, в общем случае dnscrypt не причём, ведь не к нему идёт обращение. Когда настроен скрипт, который добавляет правило в iptables, которое "приземляет" или можно сказать перехватывает пакеты на 53 порт udp, как это описано в инструкции, то стоит учитывать, что данное правило задано именно в iptables и распространяется на ipv4 трафик. Я не уверен, но возможно, что нечто подобное нужно делать для ipv6 версии iptables. Тогда ipv6 пакеты, которые проходят через роутер будут перехватываться и обрабатываться в dnscrypt-proxy2. Но я не сетевик, и может быть более квалифицированные специалисты подскажут, прав я или нет и как нужно сделать, чтобы реализовать ваше пожелание.