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

[Александр Рыжов]

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

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

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

[Boomer]

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

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

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

[vasek00]

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

Edited June 21, 2018 by vasek00

[SigmaPlus]

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

[Вежливый Снайпер]

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

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

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

[vasek00]

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]

Подскажите пожалуйста, сегодня перестал запускаться 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]

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

[rotor]

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

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

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

Цитата

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

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

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

 

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

 

Edited July 2, 2018 by rotor
Добавил ссылку

[Вежливый Снайпер]

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

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

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

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

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

[rotor]

Решил добавить свои правила блокировки в настройки. Но при контрольном запуске 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]

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

В 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")" ] && \

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

Edited July 24, 2018 by rotor

[Вежливый Снайпер]

А у меня перестали резолвиться все домены после автоматического обновления прошивки йотовского модема до 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]

Вчера поставил 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

Edited August 11, 2018 by ankar84
Скрин

[Вежливый Снайпер]

А это нормально, что 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]

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

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

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

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

[vasek00]

Ни куда не чего не добавлял из правил 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]

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]

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

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

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

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

[vasek00]

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

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

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

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

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

[ankar84]

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

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

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

[vasek00]

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]

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

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

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

[vasek00]

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

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

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

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

 

 

[ankar84]

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)

Edited September 13, 2018 by ankar84

[vasek00]

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

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

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

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

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

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

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

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

[ankar84]

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

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

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

tcpdump port 53 -n -nn -v

 

[vasek00]

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

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

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

[vasek00]

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