Search the Community

Данная тема создана по следам инструкций по использованию предыдущих версий первой ветки замечательного приложения dnscrypt-proxy, которое автор вернул к плотной разработке, правда, сменив язык на Go. Для начала рекомендую ознакомиться с первыми статьями: Сразу уточню, вторая версия dnscrypt-proxy подойдет скорее тем пользователям, у кого роутер с достаточным количеством оперативной памяти, так как приложения на go довольно требовательны к ресурсам. Например, на моей Keenetic Ultra проблем с памятью нет, поэтому я и перешел на вторую ветку dnscrypt-proxy не особо раздумывая. Ознакомиться со всеми преимуществами dnscrypt-proxy2 перед первой веткой можно на странице проекта на GitHub. Хочу заметить, что при использовании dnscrypt-proxy2 уже нет необходимости в связке с dnsmasq или чем-то еще. dnscrypt-proxy2 сам умеет и кэшировать запросы и работать с несколькими серверами сразу, выбирая наиболее быстрый и ещё много чего. На момент написания данной статьи актуальной версией является dnscrypt-proxy 2.0.14 Итак, начиная с версии 2.0.8 (кажется) dnscrypt-proxy2 собрана уважаемым @zyxmon в тестовой ветке репозитория Entware. Пользователям Entware-3x и Entware-NG нужно перейти на репозиторий Entware с помощью следующих команд, введенных 2 раза подряд (за подробностями и решением проблем нужно пройти в соответствующую тему) иначе будете получать ошибку, что пакет dnscrypt-proxy2 не найден. opkg update opkg upgrade Установка Начиная с 2.0.11 пакет dnscrypt-proxy2 доступен для обычной установки из репозитория Entware следующей командой: # opkg install dnscrypt-proxy2 Далее установим вспомогательные пакеты: iptables для того, чтобы "приземлить" все DNS запросы наших клиентов на наш dnscrypt-proxy2 cron для того, чтобы обновлять список блокируемых адресов в автоматическом режиме на регулярной основе. # opkg install cron iptables Стандартный конфигурационный файл достаточно полно документирован комментариями по той или иной настройке, да и в целом по-умолчанию всё должно запуститься успешно командой: # /opt/etc/init.d/S09dnscrypt-proxy2 start Хранение файлов DNSCrypt По-умолчанию, файл конфигурации создается в папке /opt/etc/dnscrypt-proxy.toml но лично мне гораздо удобнее все файлы (а их у меня набирается около 10ти) держать в отдельной папке, например, /opt/etc/dnscrypt/ Во-первых, когда все файлы, с которыми DNSCrypt работает располагаются рядом, под рукой, это удобно. Во-вторых, не создается лишнего беспорядка в корне папки конфигурации - /opt/etc/ Но, если вы, как и я решите перенести файл конфигурации и другие сопутствующие DNSCrypt файлы, необходимо учитывать, что при каждом обновлении нужно будет править скрипт запуска /opt/etc/init.d/S09dnscrypt-proxy2 указывая фактическое расположение файла. Для ознакомления приведу полный листинг своего файла конфигурации: Приведу некоторые отличия моего конфигурационного файла от стандартного. listen_addresses = ['192.168.1.1:53', '[::1]:53'] В отличии от дефолтовой строчки, где сервер будет слушать на 127.0.0.1 мне было необходимо, чтобы сервер "слушал" на 192.168.1.1, чтобы я мог прописать данный сервер в настройках DHCP как сервер DNS для всех устройств моей домашней сети. Кстати, так как будем использовать dnscrypt-proxy2 как единственный DNS сервер на роутере, необходимо отключить (а точнее перевести в специальный режим работы при котором компоненты прошивки все равно смогут обращаться к DNS резолверу прошивки через RPC оставив порт 53 свободным) основной DNS сервер NDMS. Сделаем это следующими командами в Cli (не в Entware): opkg dns-override system configuration save Включать только на устройствах с функционирующим IPv6. На самом деле я особой скорости у серверов IPv6 не увидел, так что можно и не включать. ipv6_servers = true Я сейчас вообще рекомендую включить опцию use_syslog и смотреть события DNSCrypt в веб интерфейсе Кинетика на странице Диагностика - Системный журнал use_syslog = true Но если все же привычно работать с логами в виде фалов, то Когда все работает хорошо и стабильно, уровень логгирования нужно вернуть на исходный - 2 (можно и выше) log_level = 0 Далее идет fallback_resolver. Вообще его можно не менять, но мне захотелось поставить популярный ныне CloudFlare DNS с его красивым адресом. fallback_resolver = '1.1.1.1:53' Размер кэша я ставлю в 4 раза больше, чем по умолчанию. Можно не менять. Кстати, в ответах просьба высказаться, какой размер кэша оптимальный по вашему? cache_size = 2048 Блокировка рекламы Далее идет раздел блокировки. В качестве значения параметра blacklist_file указываем полный путь до вашего файла с блокируемыми доменными именами. UPD. Можно воспользоваться скриптом от @TheBB вот из этого поста Я свой файл получаю скриптом автора dnscrypt-proxy blacklist_file = '/opt/etc/dnscrypt/dnscrypt-blacklist-domains.txt' А обновляю этот список еженедельно с помощью cron: Создаем файл скрипта /opt/etc/cron.weekly/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 И не забываем сделать его исполняемым: chmod +x /opt/etc/cron.weekly/generate-blacklist Можно в принципе логи не зачищать, тогда строчку с rm нужно закомментировать или удалить. Для нормальной работы скрипта генерации blacklist-domains.txt необходимо установить еще 2 пакета: opkg install python ca-certificates После того, как пакеты будут установлены, переходим в папку, где расположен скрипт генерации и проверяем его работу (ошибок быть не должно.? python generate-domains-blacklist.py -i > list.txt.tmp && mv -f list.txt.tmp list Для диагностики корректности блокировки того или иного ресурса или для отлова false positive блокировок рекомендую включить журнал того, что блокируется: log_file = '/opt/var/log/blocked.log' log_format = 'tsv Далее у меня прописан белый список доменных имен, которые не нужно блокировать никогда (привет РКН еще раз). На самом деле, данная опция появилась в последних версиях (кажется в 2.0.11) и ранее белый список обрабатывался скриптом генерации черного списка блокируемых адресов. То есть вхождения белого списка удалялись из черного при генерации. Теперь вот отдельная опция: whitelist_file = '/opt/etc/dnscrypt-proxy/generate-domains-blacklists/domains-whitelist.txt' Добавляем возможность разрешать домены в зоне *.lib Переходим к настройке dnscrypt серверов. И вот тут я очень рекомендую использовать серверы проекта OpenNIC. То есть настройка в конфигурационном файле у меня вот такая (закомментировал основной список публичных серверов и добавил только серверы проекта OpenNIC? #[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'] #cache_file = '/opt/etc/dnscrypt/public-resolvers.md' #minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3' #refresh_delay = 72 #prefix = '' [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 = '/opt/etc/dnscrypt/opennic.md' refresh_delay = 72 prefix = '' Почему именно OpenNIC? Используя именно эти серверы получаем один замечательный бонус - разрешение EmerCoin доменных имен типа *.lib и других. Благодаря этому я пользуюсь одним популярным торрент трекером по его доменному имени в зоне *.lib не занимаясь постоянным поиском живых зеркал. Опять же, эти серверы вроде бы не вносят своих блокировок и не логгируют запросы. Хотя как знать. Так же я НЕ рекомендую использовать серверы проекта компании Cisco - OpenDNS. Недавно @Александр Рыжов в канале Keenetic в одном известном мессенджере сообщил, что Cisco заворачивала на себя трафик mail.ru подставляя при этом фейковый сертификат, так что будьте бдительны. Так же прошу обратить внимание, большинство серверов проекта OpenNIC с поддержкой dnscrypt находятся в Европе и Америке, так что моментальных ответов ждать не приходится. У меня самый быстрый сервер дает около 100 мс, и на том спасибо. Отсюда и увеличенный размер кэша, которым я пытаюсь эти задержки свести к минимуму. Перехват всех DNS запросов на роутере. "Приземление" DNS трафика Теперь переходим к очень важной теме, изучая которую я потратил много времени. А именно, речь пойдет об использовании только локального DNS сервера dnscryprt-proxy2 вместо провайдерских DNS серверов на всех устройствах сети. Суть здесь вот в чем. Начиная, кажется. с 6 версии ОС Андроид, видимо, для повышения стабильности (и, имхо, для утоления своей тотальной любознательности) параллельно посылает запросы и на тот сервер, что указан в сетевых настройках, которые получены устройством от DHCP сервера и на сервер 8.8.8.8 Я очень долго не мог понять, почему на всех устройствах я не вижу рекламу, так как она блокируется на роутере, но всегда вижу рекламу на своем Андроид смартфоне. Тогда я с помощью захвата пакетов все и обнаружил. Кстати, более простым способом было посмотреть трафик в Entware с помощью tcpdump. tcpdump -i br0 или посмотрим только трафик на сетевой порт 53 tcpdump port 53 -n -nn -v Итак, для начала избавимся от провайдерских DNS серверов. В cli вводим вот эти 2 замечательные команды: interface ISP no ip dhcp client name-servers system configuration save Все эти моменты хорошо расписаны в статье Использование публичных DNS-серверов в интернет-центре, но лично мне их удалось найти тут, на форуме в ответе уважаемого @Le ecureuil От слежки провайдера избавились, осталось приземлить все DNS запросы в корпорацию добра на наш сервер dnscrypt-proxy2. Здесь мне так же помог @Александр Рыжов на канале Keenetic. У данного метода есть и плюсы - например, при подмене локального DNS сервера вирусом на компьютере с Windows запросы пойдут все равно на роутер, а не DNS сервер злоумышленников. Есть и минусы, например, не весь трафик, который идет по UDP\53 это обязательно DNS запросы, это вполне может быть портом для подключения к, положим, OpenVPN серверу. Но так или иначе, для большинства домашних сетей данный способ приносит больше плюсов, имхо. В вашем любимом текстовом редакторе создаем файл скрипта /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh: #!/bin/sh [ "$type" == "ip6tables" ] && exit 0 [ "$table" != "nat" ] && exit 0 [ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 exit 0 Либо, если любимого редактора еще нет, можно воспользоваться вот такой длинной командой: echo -e '#!/bin/sh\n[ "$type" == "ip6tables" ] && exit 0\n[ "$table" != "nat" ] && exit 0\n[ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53\nexit 0' >> /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh Ранее использовалась конструкция "$(iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1")" но из-за некоторых ошибок она была заменена конструкцией "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" которая должна отрабатывать быстрее. Далее делаем созданный скрипт исполняемым: chmod +x /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh Вероятно, скрипт можно написать значительно изящнее и ловить не только UDP, но и TCP трафик, но у меня получилось только вот так. В ответах, гуру баша могут подсказать как сделать правильнее, подправлю для общего блага. Мне "приземление" только UDP трафика на 53 порт роутера помогло полностью избавиться от рекламы на всех устройствах домашней сети. Так что TCP можно и не трогать. В итоге: Защитили весь свой DNS трафик от перехвата со стороны провайдера и Гугла Заблокировали рекламу на всех устройствах домашней сети (это наиболее актуально для всяких Смарт ТВ и других девайсов не нет возможности блокировать рекламу на самом устройстве) Получили разрешение имен *.lib и других, чем немного упростили себе жизнь в все более блокируемом интернете Диагностика проблем с запуском\работой. Рекомендую для диагностики запустить DNSCrypt из консоли строкой запуска из скрипта, то есть командой: dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml Путь до файла конфигурации при необходимости поправить, по-умолчанию будет вот такой -config /opt/etc/dnscrypt-proxy.toml Для начала посмотрим журнал dnscrypt-proxy2 в том месте, где вы его настроили. Я смотрю вот такой командой: # tail -f -n 30 /opt/var/log/dnscrypt-proxy-v2.log Либо если включили syslog, то события смотрим веб интерфейсе Кинетика на странице Диагностика - Системный журнал Следующая команда должна выдать PID процесса. Если ничего не выдала - DNSCrypt не запущен (возможно завершился с ошибкой) ~ # ps | grep dnscrypt 19766 root 655m S dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml 19792 nobody 655m S /opt/sbin/dnscrypt-proxy -config /opt/etc/dnscrypt/dnscrypt-proxy.toml -child 20271 root 4780 S grep dnscrypt ~ # Проверить, слушается ли порт 53. Обратите внимание, слушать должен именно процесс dnscrypt-proxy, а не ndmproxy ~ # netstat -tulnp | grep dnscrypt tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 19766/dnscrypt-prox tcp 0 0 ::1:53 :::* LISTEN 19766/dnscrypt-prox udp 0 0 192.168.1.1:53 0.0.0.0:* 19766/dnscrypt-prox udp 0 0 ::1:53 :::* 19766/dnscrypt-prox ~ # Опять же все ограничения, которые касались использования первой версии dnscrypt-proxy справедливы и для второй, ссылки на инструкции я приложил выше. Это моя первая инструкция в этом разделе, так что сильно не пинать, а конструктивная критика крайне приветствуется. Если есть, что нужно подправить\доработать - пишите, вместе сделаем использование данного пакета проще и эффективнее.