entware Защищаем DNS запросы с помощью dnscrypt-proxy2. Бонусом блокировка рекламы.

Александр Рыжов · 20 июня, 2018

25 минут назад, Boomer сказал:

Доменное имя прописано, все работало до того как поставил DNSCrypt

«После» не значит «вследствие». Доменным именем заведует прошивочный функционал, никак не связанный с opkg.

Boomer · 20 июня, 2018

36 минут назад, Александр Рыжов сказал:

«После» не значит «вследствие».

ну так если ничего больше не менялось, а доступ пропал?

vasek00 · 21 июня, 2018

13 часа назад, Boomer сказал:

ну так если ничего больше не менялось, а доступ пропал?

В моих все работает настройках. Решил проверить. Включил Trans, разрешил доступ к нему, набираю на " ......i.keenetic.pro:8090 " просит ввести ИМЯ и Пароль, вошел в настройки по Network изменил параметр и сохранил. Проблем не возникло. При схеме :

Клиент --- Keenetic1 --PPPTP--- Инет ---PPPoE--- Keenetic2 (Trans)

На Keenetic2 доменное имя ....keenetic.pro . Дополнительно НЕЧЕГО не где не добавлял правил iptables. Когда удаленный клиент посылает данный запрос ИМЯ:порт, то он идет на адрес DNS сервера прописанного на Клиенте (например 8.8.8.8) и получает IP адрес для данной мнемонике от него 8.8.8.8, и уже по полученному адресу " IP:порт " попадает на Keenetic2.

Скрытый текст

На роутере Keenetic2 на котором Trans

/ # netstat -ntulp | grep dns
tcp        0      0 127.0.0.2:60053         0.0.0.0:*               LISTEN      2726/dnscrypt-proxy
tcp        0      0 192.168.1.100:53      0.0.0.0:*               LISTEN      3461/dnsmasq
udp        0      0 192.168.1.100:53      0.0.0.0:*                           3461/dnsmasq
udp        0      0 127.0.0.2:60053         0.0.0.0:*                           2726/dnscrypt-proxy
/ #

14983 root 8912 S /usr/sbin/transmissiond -f -a *.*.*.* -M -t -c /tmp/mnt/Data/test/watch -w /tmp/mnt/Data/test/download -g /tmp/mnt/Data/test -P 5

Изменено 21 июня, 2018 пользователем vasek00

SigmaPlus · 23 июня, 2018

Отличная тема, спасибо всем за инструкции и рецепты. Может подскажите как интегрировать с dnscrypt-proxy2 Cloudflare DNS-резолвер в форме скрытого сервиса Tor, возможно ли это на данный момент?

Вежливый Снайпер · 26 июня, 2018

В 16.06.2018 в 16:11, vasek00 сказал:

Без проблем все работает при описанном ниже, попробуйте через WEB прописать лок.IP своего роутера в "Интернет-прочие-Сервера DNS"

Подскажите пожалуйста, как это сделать в новом интерфейсе или через CLI?

vasek00 · 26 июня, 2018

47 минут назад, Вежливый Снайпер сказал:

Подскажите пожалуйста, как это сделать в новом интерфейсе или через CLI?

Все что написано выше и ранее это при настройках ниже и ПРИ связке :

Клиент ->- (192.168.130.100)DNSMasq:53 ->- (172.0.0.2)DNSCrypt:60053 ->- Интернет

никаких настроек/прокидок 54 порта не делалось, где "opkg dns-override"

DNSMasq
...
interface=br0
bind-interfaces
listen-address=192.168.130.100
server=127.0.0.2#60053
...

DNSCrypt-proxy
...
listen_addresses = ['127.0.0.2:60053']
...


По конфигу или CLI

ip name-server 192.168.130.100 ""

Marat0Sh · 27 июня, 2018

Подскажите пожалуйста, сегодня перестал запускаться dnscrypt-proxy, в логах выдаёт:

[CRITICAL] Unable to use source [public-resolvers]: [Get https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md: x509: failed to load system roots and no roots provided]

Гугл говорит, что это из-за отсутствия корневых сертификатов, нужно ставить ca-certificates и ca-bundle, установив их ничего не изменилось, та же ошибка.

Marat0Sh · 28 июня, 2018

В итоге поставил из репозитория entware версию 2.0.14 (просто скопировал в папку /opt/sbin с заменой) и заработало. До этого стояла версия 2.0.15 из официального репо, работала хорошо, почему вдруг перестало - не понятно, никакие настройки в роутере и в самом entware не менял. Тем не менее может кому пригодится.

rotor · 2 июля, 2018

В 05.06.2018 в 19:33, ankar84 сказал:

Я свой файл получаю скриптом автора dnscrypt-proxy

Подскажите, а дополнительный файл можно прикрутить? Или список только из этого файла берётся?

Цитата

Эти команды может быть и есть в документации по cli

Нашёл в справке каким образом на разных интерфейсах отключать и включать DNS провайдера. Может кому то пригодится.

https://help.keenetic.com/hc/ru/articles/213966649-Использование-публичных-DNS-серверов-в-интернет-центре

Спасибо за решение!

Изменено 2 июля, 2018 пользователем rotor
Добавил ссылку

Вежливый Снайпер · 3 июля, 2018

В 02.07.2018 в 07:36, rotor сказал:

Подскажите, а дополнительный файл можно прикрутить? Или список только из этого файла берётся?

Если речь идет о дополнительных правилах блокирования, то можно вставлять URL адреса списков в domains-blacklist.conf

Свои правила можно вставлять в domains-blacklist-local-additions.txt. Как их составлять можно глянуть в файле dnscrypt-proxy.toml (примерно в 300 строке описывается)

У меня сейчас блокируется около 130-150К доменов. в uBlock можно использовать только свои фильтры для скрытия пустых блоков ))

rotor · 5 июля, 2018

Решил добавить свои правила блокировки в настройки. Но при контрольном запуске nslookup заметил странность и попробовал варианты разных проверок. В итоге - правила блокировок не обновляются, сервер обновлений роутера также недоступен. В чём может быть проблема?

Скрытый текст

~ # nslookup t.me
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 't.me': Temporary failure in name resolution
~ # netstat -an | grep :53
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN
tcp        0      0 ::1:53                  :::*                    LISTEN
udp        0      0 192.168.1.1:53          0.0.0.0:*
udp        0      0 0.0.0.0:5355            0.0.0.0:*
udp        0      0 ::1:53                  :::*
~ #

root@ads:/opt/etc/cron.weekly# ./generate-blacklist
Loading data from [file:domains-blacklist-local-additions.txt]
Loading data from [https://osint.bambenekconsulting.com/feeds/c2-dommasterlist.txt]
[https://osint.bambenekconsulting.com/feeds/c2-dommasterlist.txt] could not be loaded: <urlopen error [Errno -3] Temporary failure in name resolution>

Loading data from [http://someonewhocares.org/hosts/hosts]
[http://someonewhocares.org/hosts/hosts] could not be loaded: <urlopen error [Errno -3] Temporary failure in name resolution>
Loading data from [https://raw.githubusercontent.com/notracking/hosts-blocklists/master/domains.txt]
[https://raw.githubusercontent.com/notracking/hosts-blocklists/master/domains.txt] could not be loaded: <urlopen error [Errno -3] Temporary failure in name resolution>
Loading data from [file:domains-time-restricted.txt]
Loading data from [file:domains-whitelist.txt]
Shutting down dnscrypt-proxy... done.
Starting dnscrypt-proxy... done.

~ #
[NOTICE] Source [public-resolvers.md] loaded
[2018-07-04 20:20:39] [NOTICE] dnscrypt-proxy 2.0.14
[2018-07-04 20:20:39] [NOTICE] Loading the set of whitelisting rules from [/opt/etc/dnscrypt-proxy/generate-domains-blacklists/domains-whitelist.txt]
[2018-07-04 20:20:39] [NOTICE] Loading the set of blocking rules from [/opt/etc/dnscrypt-proxy/dnscrypt-blacklist-domains.txt]
[2018-07-04 20:20:39] [NOTICE] Now listening to 192.168.1.1:53 [UDP]
[2018-07-04 20:20:39] [NOTICE] Now listening to 192.168.1.1:53 [TCP]
[2018-07-04 20:20:39] [NOTICE] Now listening to [::1]:53 [UDP]
[2018-07-04 20:20:39] [NOTICE] Now listening to [::1]:53 [TCP]
[2018-07-04 20:20:44] [INFO] [cloudflare] TLS version: 303 - Protocol: h2 - Cipher suite: 52393
[2018-07-04 20:20:48] [NOTICE] [cloudflare] OK (DoH) - rtt: 52ms
[2018-07-04 20:20:48] [INFO] [cloudflare-ipv6] TLS version: 303 - Protocol: h2 - Cipher suite: 52393
[2018-07-04 20:20:48] [NOTICE] [cloudflare-ipv6] OK (DoH) - rtt: 55ms
[2018-07-04 20:20:48] [INFO] [2.dnscrypt-cert.cypherpunks.ru.] the key validity period for this server is excessively long (365 days), significantly reducing reliability and forward security.
[2018-07-04 20:20:48] [NOTICE] [cpunks-ru] OK (crypto v1) - rtt: 25ms
[2018-07-04 20:20:49] [NOTICE] [d0wn-tz-ns1-ipv6] TIMEOUT
[2018-07-04 20:20:49] [NOTICE] [dnscrypt.ca-2-ipv6] TIMEOUT
[2018-07-04 20:20:49] [INFO] [2.dnscrypt-cert.resolver2.dnscrypt.eu.] the key validity period for this server is excessively long (365 days), significantly reducing reliability and forward security
[2018-07-04 20:20:49] [NOTICE] [dnscrypt.eu-dk] OK (crypto v1) - rtt: 63ms
[2018-07-04 20:20:49] [NOTICE] [dnscrypt.eu-dk-ipv6] TIMEOUT
[2018-07-04 20:20:49] [INFO] [2.dnscrypt-cert.resolver1.dnscrypt.eu.] the key validity period for this server is excessively long (365 days), significantly reducing reliability and forward security
[2018-07-04 20:20:49] [NOTICE] [dnscrypt.eu-nl] OK (crypto v1) - rtt: 80ms
[2018-07-04 20:20:50] [NOTICE] [dnscrypt.nl-ns0-ipv6] TIMEOUT
[2018-07-04 20:20:55] [NOTICE] [flatty.co] TIMEOUT
[2018-07-04 20:20:55] [INFO] [2.dnscrypt-cert.ipredator.se.] the key validity period for this server is excessively long (1095 days), significantly reducing reliability and forward security.
[2018-07-04 20:20:56] [NOTICE] [ipredator] OK (crypto v1) - rtt: 51ms
[2018-07-04 20:20:56] [INFO] [2.dnscrypt-cert.ns3.ca.luggs.co.] the key validity period for this server is excessively long (3650 days), significantly reducing reliability and forward security.
[2018-07-04 20:20:56] [NOTICE] [opennic-luggs] OK (crypto v1) - rtt: 146ms
[2018-07-04 20:20:56] [NOTICE] [opennic-luggs-ipv6] TIMEOUT
[2018-07-04 20:20:56] [INFO] [2.dnscrypt-cert.onic.csail.mit.edu.] the key validity period for this server is excessively long (365 days), significantly reducing reliability and forward security.
[2018-07-04 20:20:56] [NOTICE] [opennic-onic] OK (crypto v1) - rtt: 143ms
[2018-07-04 20:20:56] [INFO] [2.tumabox.org.] the key validity period for this server is excessively long (365 days), significantly reducing reliability and forward security.
[2018-07-04 20:20:56] [NOTICE] [opennic-tumabox] OK (crypto v1) - rtt: 63ms
[2018-07-04 20:20:56] [NOTICE] [opennic-tumabox-ipv6] TIMEOUT
[2018-07-04 20:20:59] [INFO] [publicarray-au-doh] TLS version: 303 - Protocol: h2 - Cipher suite: 49200
[2018-07-04 20:20:59] [NOTICE] [publicarray-au-doh] OK (DoH) - rtt: 345ms
[2018-07-04 20:21:00] [NOTICE] [securedns-ipv6] TIMEOUT
[2018-07-04 20:21:00] [NOTICE] [zeroaim-ipv6] TIMEOUT
[2018-07-04 20:21:00] [NOTICE] Server with the lowest initial latency: cpunks-ru (rtt: 25ms)
[2018-07-04 20:21:00] [NOTICE] dnscrypt-proxy is ready - live servers: 10

Dorik1972 · 5 июля, 2018

-bash-4.4# nslookup t.me
Server:    192.168.1.1
Address 1: 192.168.1.1

Name:      t.me
Address 1: 149.154.167.99
Address 2: 2001:67c:4e8:fa60:3:0:811:138
-bash-4.4#

Явно что-то "криво" настроено ...

rotor · 24 июля, 2018

В 05.07.2018 в 23:23, Dorik1972 сказал:

Явно что-то "криво" настроено ...

Разобрался в чём была проблема. Копипаст опять подвёл. В строке

Цитата

[ -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

инструкции не должно быть переноса после

Цитата

--to-destination 192.168.1.1")" ] && \

из за этого не шло перенаправление

Изменено 24 июля, 2018 пользователем rotor

Вежливый Снайпер · 27 июля, 2018

А у меня перестали резолвиться все домены после автоматического обновления прошивки йотовского модема до D07C_Yota_V040..

Помогло только:
no opkg dns-override
interface Yota0 ip dhcp client name-servers

Разбираться не стал особо, достало.. скоро перестану переезжать из квартиры в квартиру и нормального провайдера подключу, там все с 0 настрою.

p.s. Никакие настройки NDMS/Entware не трогались, а в логе было:

Цитата

[2018-07-24 10:48:02] [INFO] Loading from [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md] failed
[2018-07-24 10:48:02] [CRITICAL] Unable to use source [public-resolvers]: [read udp 192.168.7.1:58689->192.168.7.1:53: read: connection refused]

И до github'а соответственно тоже не мог достучаться.

ankar84 · 10 августа, 2018

Вчера поставил Entware на свой новый роутер Keenetic Giga (KN-1010) и решил ставить dnscrypt-proxy2 по своей же инструкции. И в процессе у меня появились некоторые замечания\исправления\дополнения, которыми и хочу поделиться.

Судя по обновлению в списке серверов его (список) теперь можно прописать с указанием 2 источников (видимо это сделано для отказоустройчивости)

    [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']
    minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
    cache_file = 'public-resolvers.md'

Я как обычно использую серверы OpenNIC, поэтому для себя список серверов задавал вот так:

    [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 = 'opennic.md'

Судя по отзывам в данной теме, в строчке с созданием файла /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh одной строкой у меня были допущены ошибки (которые, вероятно исправил @Александр Рыжов добавлением \n в нужных местах - сужу по дате редактирования поста)

Но вот с чем столкнулся вчера сам - при копировании из инструкции команды

chmod +x /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh

в консоль ssh она вставлялась с лишними знаками ? в некоторых местах, например, у меня точно было chmod +x /opt/e?tc/ndm/netfilter.d/10-ClientDNS-Redirect.sh по этому команда завершалась ошибкой о том, что такой файл не найден. Будьте внимательны!

Теперь ключевой момент, которого не хватает в моей инструкции - куда и как нужно прописать адрес на котором слушает dnscrypt-proxy2, чтобы и клиенты домашней локальной сети и сам роутер использовал его в качестве DNS сервера.

Начнем с клиентов.

Прописать нужно DNS сервер в настройках DHCP сервера на странице Мои сети и Wi-Fi - Домашняя сеть. После этого, при подключении клиенты будут явно получать адрес, на адрес на котором слушает dnscrypt-proxy2 (в моем случае это 192.168.1.1, как и у многих других пользователей) в качестве своего единственного DNS сервера. Хотя смартфоны на Android все равно будут пытаться посылать DNS запросы еще и на 8.8.8.8 параллельно с сервером, прописанным в сетевых настройках.

Скрытый текст

Теперь настроим сам роутер.

В моем случае подключение к провайдеру выполняется просто по MAC адресу, поэтому идем в настройки соединения в разделе Интернет Проводной. Там будет ссылка Дополнительные настройки IPoE, нажимаем ее и вписываем адрес, на адрес на котором слушает dnscrypt-proxy2 (у меня это 192.168.1.1) в поле DNS 1

Скрытый текст

Для других типов подключения, вероятно, прописать DNS сервер нужно будет в другом месте, но обычно именно там, где и настраивается провайдерское подключение.

Так же совсем не раскрытой осталась тема генерации списка блокируемых рекламных хостов\адресов.

Самостоятельно со скриптом и вспомогательными файлами можно ознакомиться вот тут

Основное - необходимо вручную (или по крону, например, раз в неделю) запускать скрипт generate-domains-blacklist.py (для его работы нужен python)

Установить python можно следующей командой (возможно можно обойтись и более урезанной установкой, например, возможно хватит пакета python-base или python-light. Я это не проверял)

opkg install python

Мне еще пришлось установить ca-certificates. Без них файлы с хостами не скачивались с HTTPS источников выдавая ошибку SSL

opkg install ca-certificates

Как запускать скрипт генерации описано в нем самом:

python generate-domains-blacklist.py > list.txt.tmp && mv -f list.txt.tmp list

Я рекомендую запускать его с параметром "-i" или в полной версии "--ignore-retrieval-failure" дабы избежать остановки работы скрипта при ошибке получения данных с одного из серверов (что у меня периодически случалось). Тогда команда будет вот такой:

python generate-domains-blacklist.py -i > list.txt.tmp && mv -f list.txt.tmp list

Как делать это периодически (по крону) я описал в первоначальной инструкции, но на всякий случай напомню и тут:

А обновляю этот список еженедельно с помощью cron: Создаем файл скрипта /opt/etc/cron.weekly/generate-blacklist для еженедельного обновления со следующим содержимым:

#!/opt/bin/sh
cd /opt/etc/dnscrypt-proxy/generate-domains-blacklists/
python generate-domains-blacklist.py -i > list.txt.tmp && mv -f list.txt.tmp /opt/etc/dnscrypt-proxy/dnscrypt-blacklist-domains.txt
rm -f /opt/var/log/*.log
/opt/etc/init.d/S09dnscrypt-proxy2 restart

И не забываем сделать его исполняемым:

chmod +x /opt/etc/cron.weekly/generate-blacklist

Можно в принципе логи не зачищать, тогда строчку с rm нужно закомментировать или удалить.

В моем случае все файлы отсюда расположены вот тут /opt/etc/dnscrypt-proxy/generate-domains-blacklists/

По итогу вечера опять смог пользоваться своим любимым теплым ламповым торрент трекером в зоне .lib

Изменено 11 августа, 2018 пользователем ankar84
Скрин

Вежливый Снайпер · 11 сентября, 2018

А это нормально, что dnscrypt не перехватывает запросы к IPv6 DNS серверам? К IPv4 серверам перехватывает.. Может быть я где-то накосячил, хотя все вроде по инструкции делал и воспользовался поправками в посте выше.
nslookup snippets.cdn.mozilla.net

Цитата

;; Got recursion not available from 192.168.79.1, trying next server
Server:       2606:4700:4700::1111
Address:   2606:4700:4700::1111#53

Non-authoritative answer:
snippets.cdn.mozilla.net   canonical name = drcwo519tnci7.cloudfront.net.
Name:   drcwo519tnci7.cloudfront.net
Address: 52.85.254.202

nslookup snippets.cdn.mozilla.net 8.8.8.8

Цитата

Server: 8.8.8.8
Address: 8.8.8.8#53

** server can't find snippets.cdn.mozilla.net: REFUSED

nslookup snippets.cdn.mozilla.net 2001:4860:4860::8888

Цитата

Server:       2001:4860:4860::8888
Address:   2001:4860:4860::8888#53

Non-authoritative answer:
snippets.cdn.mozilla.net   canonical name = drcwo519tnci7.cloudfront.net.
Name:   drcwo519tnci7.cloudfront.net
Address: 13.33.47.59

Домен snippets.cdn.mozilla.net блокируется правилами черного списка.

IPv6 работает через "прошивочный" 6to4. В dnscrypt-proxy.toml ipv6 servers = true и "listen_addresses = ['192.168.79.1:53', '[::1]:53']"

netstat -an | grep :53
tcp        0      0 192.168.79.1:53          0.0.0.0:*               LISTEN
tcp        0      0 ::1:53                  :::*                    LISTEN
udp        0      0 192.168.79.1:53          0.0.0.0:*
udp        0      0 77.57.75.10:50517      77.57.75.1:5351        ESTABLISHED
udp        0      0 192.168.79.1:5351        0.0.0.0:*
udp        0      0 0.0.0.0:5355            0.0.0.0:*
udp        0      0 ::1:53                  :::*

2606:4700:4700::1111 прописан в настройках подключения NetworkManager на Linux, Без подобной записи bind-tools совместно с NM ломают /etc/resolv.conf (вот тебе и rolling release). В любом случае, не важно какие NS'ки прописаны у клиентов, роутер ведь должен перехватывать запросы?!

ankar84 · 12 сентября, 2018

@Вежливый Снайпер, тут нужно понять, что именно подразумевается под перехватом.

Если клиент явно обращается к какому-либо dns серверу, в общем случае dnscrypt не причём, ведь не к нему идёт обращение.

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

Но я не сетевик, и может быть более квалифицированные специалисты подскажут, прав я или нет и как нужно сделать, чтобы реализовать ваше пожелание.

vasek00 · 12 сентября, 2018

Ни куда не чего не добавлял из правил iptables.

/ # netstat -ntulp | grep dns
tcp        0      0 127.0.0.2:65053         0.0.0.0:*               LISTEN      748/dnscrypt-proxy
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      744/dnsmasq
tcp        0      0 fe80::xxxx:xxxx:xxxx:xxxx:53 :::*               LISTEN      744/dnsmasq
udp        0      0 192.168.1.1:53          0.0.0.0:*                           744/dnsmasq
udp        0      0 127.0.0.2:65053         0.0.0.0:*                           748/dnscrypt-proxy
udp        0      0 fe80::xxxx:xxxx:xxxx:xxxx:53 :::*                           744/dnsmasq
/ #

В данном случае просто dnsmasq слушает все что летит на 53 порту.

Хорошо ну не используете dnsmasq тогда кто мешает запустить dnscrypt-proxy на прослушку 53 порта в конфе

## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6.
## To only use systemd activation sockets, use an empty set: []
listen_addresses = ['127.0.0.1:53']

ну или из команды запуска например для

dnscrypt-proxy --local-address=127.0.0.1:53

dnscrypt-proxy --local-address='[::1]:53'....

ankar84 · 12 сентября, 2018

54 минуты назад, vasek00 сказал:

Хорошо ну не используете dnsmasq тогда кто мешает запустить dnscrypt-proxy на прослушку 53 порта в конфе

Дело в том, что и в инструкции и у обратившегося @Вежливый Снайпер это так и сделано: dnscrypt-proxy2 слушает на 53 порту адреса роутера.

Но что мешает любому клиенту вашей локальной сети, да хоть самому роутеру отправить запрос не на 192.168.1.1 (беру дефолтовый адрес кинетиков), а напрямую на 8.8.8.8? Ваша конфигурация с dnsmasq+dnscrypt этот запрос как-то обработает? Я думаю, что нет.

Именно поэтому был написан скрипт, который перехватывает вообще все проходящие (или лучше скажем "пролетающие" через роутер) UDP пакеты на 53 порт и "приземляет" на тот адрес, где слушает dnscrypt-proxy2.

И я выразил предположение, что IPv6 запросы тот скрипт не приземлит, для него нужно, вероятно, использовать iptables6

vasek00 · 12 сентября, 2018

1 час назад, ankar84 сказал:

Но что мешает любому клиенту вашей локальной сети, да хоть самому роутеру отправить запрос не на 192.168.1.1 (беру дефолтовый адрес кинетиков), а напрямую на 8.8.8.8? Ваша конфигурация с dnsmasq+dnscrypt этот запрос как-то обработает? Я думаю, что нет.

Конечно нет, кто хочет из домашних пусть ставит хоть 8.8.8.8 хоть что угодно со всеми вытекающими, речь идет о домашней сети в настоящие время желающих нет пока.

Заблокировать публичные DNS без проблем в одно действие без iptables так же, только не вижу в этом смысла для домашних клиентов.

vasek00 · 12 сентября, 2018

1 час назад, ankar84 сказал:

Дело в том, что и в инструкции и у обратившегося @Вежливый Снайпер это так и сделано: dnscrypt-proxy2 слушает на 53 порту адреса роутера.

Для простоты кто мешает запустить второй сервис для IPv6

dnscrypt-proxy --local-address='[::1]:53'....

в итоге будут запущены два сервиса "dnscrypt-proxy"

ankar84 · 12 сентября, 2018

2 часа назад, vasek00 сказал:

Конечно нет, кто хочет из домашних пусть ставит хоть 8.8.8.8 хоть что угодно со всеми вытекающими, речь идет о домашней сети в настоящие время желающих нет пока.

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

vasek00 · 12 сентября, 2018

1 час назад, ankar84 сказал:

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

Наверное я чего-то не догоняю в чем фишка. Имеем Android клиента и на нем сервис один/два имеют запрос к 8.8.8.8:53 и 8.8.4.4:53, тогда имеем два варианта прохода данного запроса например "mtalk.google.com" или "mobile-gtalk.l.google.com" и т.д.:

Клиент Android -- запрос -->-- 8.8.8.8:53 -->-- Интернет

Клиент Android -- запрос -->-- 8.8.8.8:53 -->---Черный_ящик-->-- Интернет

Где черный ящик "отлавливает" запросы 53 порта и перенаправляет их на какой-то сервис для обработки и далее в интернет. Вопрос в чем разница прохождения данного запроса, если ответ будет получен клиентом в любом случае?

ankar84 · 13 сентября, 2018

11 час назад, vasek00 сказал:

Вопрос в чем разница прохождения данного запроса, если ответ будет получен клиентом в любом случае?

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

vasek00 · 13 сентября, 2018

6 минут назад, ankar84 сказал:

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

Блокировка по черному списку доменных имен и без направления на 53 порт происходит.

т.е. перехватом пакетов на 53 порт вы избавились от рекламы google в приложениях приложениях например которые ниже

ankar84 · 13 сентября, 2018

17 минут назад, vasek00 сказал:

Блокировка по черному списку доменных имен и без направления на 53 порт происходит

Да, это верное утверждение.

То есть все запросы, которые явно идут на dns роутера будут в ответе без рекламы.

17 минут назад, vasek00 сказал:

т.е. перехватом пакетов на 53 порт вы избавились от рекламы google в приложениях приложениях например которые ниже

Нет, здесь не так. Когда клиент отправляет запрос на 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)

Изменено 13 сентября, 2018 пользователем ankar84

vasek00 · 13 сентября, 2018

3 минуты назад, ankar84 сказал:

Да, это верное утверждение.

То есть все запросы, которые явно идут на dns роутера будут в ответе без рекламы.

Нет, здесь не так. Когда клиент отправляет запрос на dns Гугла никакой блокировки рекламных доменов не происходит совсем.

То есть когда клиент пытается разрешить dns имя рекламного домена, google dns даст в ответ правильный адрес рекламного сервера. И реклама google тут не исключение. Клиент все запросы отправляет параллельно на google dns. И никакая реклама не блокируется совсем. Поэтому приходится приземлять эти запросы на проход через список блокировки в dnscrypt-proxy2.

Клиент все запросы отправляет параллельно на google dns - это как это?

т.е. на реальном скрине экрана speedtest отправил два каких то запроса один по DNS роутера (так как клиент его получил) и параллельный на DNS Google для получения IP для рекламного блока.

Придется посмотреть про механизм - "AdMob реклама в Android приложение" и про "Google AdWords" и реально пощупать проход.

ankar84 · 13 сентября, 2018

1 час назад, vasek00 сказал:

Клиент все запросы отправляет параллельно на google dns - это как это?

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

tcpdump port 53 -n -nn -v

vasek00 · 13 сентября, 2018

Не знаю даже что и сказать запросы от клиента android 8.1 на прямую.

Либо у меня на телефоне уже многое отключено и плюсом "блокировщики" на нем или приложений мало, по запускал посмотрел не чего такого что привлекло бы внимания не заметил.

Вот полазить по настройкам IP6 надо бы.

vasek00 · 13 сентября, 2018

И с завернутым 53 портом

entware Защищаем DNS запросы с помощью dnscrypt-proxy2. Бонусом блокировка рекламы.

Рекомендуемые сообщения

Топ авторов темы

Популярные дни

Топ авторов темы

Популярные дни

Популярные посты

ankar84

ankar84

TheBB

Изображения в теме

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Важная информация