ankar84
-
Постов
407 -
Зарегистрирован
-
Посещение
-
Победитель дней
3
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент ankar84
-
Если задача это заблокировать, то можно просто блокировать все 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 починили! Большое спасибо!
- 23 ответа
-
- 1
-
-
- 802.11b
- data rates
- (и ещё 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 = ''
- 235 ответов
-
- 1
-
-
- dnscrypt-proxy2
- защита dns трафика
- (и ещё 1 )
-
По ресурсам согласен, очень требователен и прожорлив (хотя не по 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. Ошибся форумом, просьба перенести в Развитие
- 4 ответа
-
- 7
-
-
В 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. Но я не сетевик, и может быть более квалифицированные специалисты подскажут, прав я или нет и как нужно сделать, чтобы реализовать ваше пожелание.
-
Да, действительно всё верно. Я пример с Lite только в подтверждение его слов и написал.
-
Кстати, настраивал знакомому Zyxel Keenetic Lite III. Сначала обновил с 2.05 до релизной 2.08 кажется, чтобы появился выбор стандарта 802.11gn, который и выставили в настройках. Вот результат: Итого - на 2.08 все штатно и стандартно работало как ожидалось (низкие рейты отключались из webgui)
-
@eralde @Le ecureuil Кажется, что мне удалось формализовать проблему: 1. Перезагружаем роутер (для чистоты эксперимента) 2. Подключаемся на точку доступа 5Ггц 3. Входим в webgui по fqdn KeenDNS https://keendnsname.keenetic.pro, логинимся под admin 4. Идем на страницу Диагностика, жмем Показать журнал, оставляем его открытым 5. Подключаемся на точку доступа 2 Ггц 6. Через меню открываем, например, Системный монитор 7. Страница не доступна – ERR_TIMED_OUT Все это проверялось только на смартфоне в мобильном Google Chrome 68.0.3440.91, точки настроена с разными именами для сетей 2.4ГГц и 5ГГц, учетные данные для входа сохранены в Хроме, использую домен KeenDNS именно keenetic.pro Отладку, запущенную в момент первого входа (до показа журнала в пункте 4) прикладываю в следующем скрытом сообщении. Так же в тикет 400857
-
Не буду ? да и прав на него нет. Да, в поддержке сообщили, что исправления стоит ждать в ближайшем драфте. Что же, будем ждать и надеяться!
-
Вероятно, для реализации данного функционала необходимо посредством cli или webgui править вот этот файл (или подобный) Красным выделил то, что нужно удалить. По этому файлу видно, что 5Ггц сеть такие низкие рейты не использует.
-
Совершенно верно! И очень хочется их отключить полностью, особенно рейты 802.11b Upd. Вообще, исходя из этого (понимаю, что это не самая авторитетная cсылка, но написано доступно): Мне необходимо отключить именно 802.11b data rates, так как без них у стандартов 802.11g и 802.11n остаются одни data rates 6, 9, 12, 18, 24, 36, 48 и 54 Мб/с Сейчас включил 2.4Ггц точку вот в таком режиме: И все равно рейты от 802.11b остались:
-
В cisco можно отключить, притом в webgui. Хочется, чтобы и у пользователей Keenetic была такая возможность, пусть даже только через cli.
-
Вот это уже интересно! Как эту информацию получили? Как отключить вот эти: Именно они считаются низкими data rates (802.11b)
-
Мне бы не хотелось этого делать покупая не самый дешевый роутер бренда которому давно доверяю.
