После сравнительно недавнего анонса компанией Mozilla запуска поддержки DNS-over-HTTPS (DoH) в продакшн в сети не утихают споры, зло это или благо. По моим ощущениям, позиция "зло" базируется в основном на том, что при этом манипуляция вашими DNS-запросами даже в полезных для вас целях будет затруднена, поэтому я пока что остаюсь на позиции "благо".
В Российской Федерации операторы связи, поставленные в очень жесткие условия нашим законодательством, вынуждены строить изощренные многоуровневые системы блокировок доступа к запрещенному Роскомнадзором на территории РФ контенту, на одном из уровней которых более-менее успешно работает перехват DNS-запросов. Использование DoH позволит обойти этот уровень, что в совокупности с использованием VPN может несколько облегчить вам жизнь. Обратите внимание, само по себе решение не может избавить вас от блокировок, потому что вряд ли в России есть провайдер, полагающийся только на фильтрацию через DNS. Вам нужен еще какой-то вариант обойти блокировки, например VPN, один из описанных в моих предыдущих статьях.
Парадоксально, но в текущем паноптикуме оператору связи ничем не грозит ваш обход его блокировок (с использованием специальных средств для этого), поэтому если вы опасаетесь навредить ему таким образом — эти опасения напрасны.
Но переходить на специальный браузер, чтобы обойти перехват DNS — не наш путь. Наш путь — перевести все устройства домашней сети на DoH, быстро, эффективно и без лишних трудозатрат.
Disclaimer
Поскольку публиковать способы обхода блокировок доступа к информации, запрещенной на территории Российской Федерации, не очень законно, целью этой статьи будет рассказать о методе, позволяющем автоматизировать получение доступа к ресурсам, разрешенным на территории Российской Федерации, но из-за чьих-то действий недоступным напрямую через вашего провайдера. А доступ к другим ресурсам, получаемый в результате действий из статьи, является досадным побочным эффектом и целью статьи ни в коем случае не является.
TL;DR
Разворачиваем собственный DNS-сервер на базе Pi-Hole, использующий Cloudflare DoH для запросов в мир. Цель — зашифровать все DNS-запросы и обойти таким образом операторскую фильтрацию через перехват DNS. Полезный бонус — фильтрация рекламы.
Никаких волшебных know-how не открывается, простая пошаговая инструкция для тех, кому не хочется разбираться во всех хитросплетениях самому.
Что вам для этого потребуется
- Доверять Cloudflare. На самом деле это очень важный пункт, поскольку в описываемой реализации все ваши DNS-запросы обрабатываются сервисом Cloudflare. Если вы ему не доверяете — вам придется внедрить другое решение (и это немногим сложнее, чем описанное, но целью этой статьи не является).
- Иметь возможность поддерживать в домашней сети постоянно работающий сервер с Linux, который будет обслуживать DNS-запросы ваших устройств. Требование Pi-Hole — от 512M оперативной памяти (впрочем, работу с меньшим объемом сам не проверял). Если ваш роутер или NAS умеют виртуальные машины — это прекрасный вариант, если на полке где-то завалялась Raspberry Pi или другой микрокомпьютер на ARM — не менее хорошо, если на антресолях в коридоре жужжит виртуальная ферма на ESXi — то что я вам рассказываю, вы и сами всё знаете. Если у вас ничего из этого нет — самые младшие решения, типа Orange Pi Zero, на вторичном рынке можно найти за единицы сотен рублей либо привезти из Али за плюс-минус те же деньги. Но выбор платформы сильно выходит за рамки этой статьи, поэтому считаем, что у вас что-то есть. Впрочем, вопросы на этот счет можно задавать в комментариях.
- Вы должны иметь представление о использовании Linux и сетевых технологиях. Или хотя бы хотеть получить такое представление. Поскольку объять необъятное в этот раз я не готов, некоторые непонятные для вас моменты вам придется изучить самостоятельно. Впрочем, на конкретные вопросы, конечно же, отвечу в комментариях и вряд ли окажусь единственным отвечающим, так что не стесняйтесь спрашивать.
Исходные данные
IPv4-адрес нашего сервера в домашней сети: 192.168.1.10 и он назначен как статический.
Настройки на Linux выполняем от root (т.е. перед началом настройки выполняем команду sudo su -).
Кратко — логика решения
- Устанавливаем и настраиваем Pi-Hole
- Устанавливаем и настраиваем cloudflared
- Настраиваем ваш домашний роутер
- Решаем проблемы
Собственно решение
1. Устанавливаем и настраиваем Pi-Hole
Pi-Hole — это известная домашняя платформа, предназначенная прежде всего для борьбы с рекламой через блокирование запросов к доменам из централизованно обновляемого списка. Не то чтобы это был необходимый компонент решения, но если начал собирать домашний DNS, становится трудно остановиться. А если серьезно — Pi-Hole, возможно, и не идеален, но снимает большой объем головной боли с человека, которому надо "чтобы работало".
Чтобы установить Pi-Hole на уже имеющийся у нас запущенный Linux-сервер, нам достаточно выполнить одну команду:
curl -sSL https://install.pi-hole.net | bashИ далее запущенный скрипт проведет вас по шагам установки.
В момент, когда он спросит вас про выбор Upstream DNS Provider, вы можете выбрать любой, поскольку на следующем шаге мы всё равно будем его менять. Все остальные параметры можно смело оставлять по умолчанию.
В конце инсталляции скрипт покажет вам сгенерированный случайным образом пароль от веб-интерфейса, который вам было бы полезно записать.
Если что-то при установке пошло не так — можно использовать альтернативные способы, описанные тут.
2. Устанавливаем и настраиваем cloudflared
Для того, чтобы перейти на DNS over HTTPS мы используем типовое решение от Cloudflare. Изначально демон cloudflared был создан для поднятия со стороны абонента туннеля Argo, позволяющего опубликовать в Cloudflare CDN ваш веб-сервер, даже если он размещен на приватном IP-адресе за NAT. Но очень полезным свойством этого демона является работа в качестве DoH-proxy, и это свойство мы здесь используем.
Тут для установки нам потребуется приложить немного больше усилий, но тоже ничего особо сложного.
Выбираем и загружаем инсталлятор для нашей платформы.
# For amd64 Debian/Ubuntu
cd /tmp
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb
apt-get install ./cloudflared-stable-linux-amd64.deb
cloudflared -v
# For amd64 CentOS/RHEL/Fedora
cd /tmp
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.rpm
yum install ./cloudflared-stable-linux-amd64.rpm
cloudflared -v
# For ARM
cd /tmp
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
tar -xvzf cloudflared-stable-linux-arm.tgz
cp ./cloudflared /usr/local/bin
chmod +x /usr/local/bin/cloudflared
cloudflared -vПосле выполнения последней команды мы должны получить вывод, подобный следующему:
cloudflared version 2019.9.0 (built 2019-09-06-0333 UTC)Если он у вас такой (естественно, номер версии и билда может отличаться) — то поздравляю, установка прошла успешно. Теперь дело за настройкой.
Создаем пользователя для работы сервиса:
useradd -s /usr/sbin/nologin -r -M cloudflaredСоздаем файл конфигурации сервиса /etc/default/cloudflared:
# Commandline args for cloudflared
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-queryИ даем на него и на исполняемый файл права свежесозданному пользователю:
chown cloudflared:cloudflared /etc/default/cloudflared
chown cloudflared:cloudflared /usr/local/bin/cloudflaredДалее создаем файл /lib/systemd/system/cloudflared.service, который даст нам возможность интеграции сервиса в systemd:
[Unit]
Description=cloudflared DNS over HTTPS proxy
After=syslog.target network-online.target
[Service]
Type=simple
User=cloudflared
EnvironmentFile=/etc/default/cloudflared
ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.targetАктивируем сервис и запускаем его:
systemctl enable cloudflared
systemctl start cloudflared
systemctl status cloudflaredЕсли всё получилось — вы увидите, что сервис в состоянии active (running).
Вы можете проверить работу сервиса, например командой dig:
dig @127.0.0.1 -p 5053 google.comВ answer section ответа вы увидите IP-адрес, который ваш сервис получил для google.com через DoH, что-то типа:
google.com. 217 IN A 172.217.6.142Осталось только подключить сервис к Pi-Hole. Для этого вы заходите в веб-интерфейс Pi-Hole (тут вам пригодится записанный в первом этапе пароль), идете в пункт меню Settings — DNS и делаете его выглядящим приблизительно вот так:
Главное — заполнить поле Custom записью 127.0.0.1#5053 и оставить галку у него, убрав ее со всех остальных. После этого не забудьте промотать страницу вниз и нажать Save.
Если вы забыли записать пароль — ничего страшного, заходите на сервер через ssh и исполняете команду pihole -a -p, она позволит задать новый пароль. Ну и в целом посмотрите ключи команды pihole, там много интересного. Например, обновление системы делается одной командой pihole -up.
3. Настраиваем ваш домашний роутер
Всё многообразие роутеров я, конечно, закрыть этим текстом не могу. Но для большинства домашних роутеров справедливы следующие моменты:
1) У роутера можно задать кастомный DNS-сервер в настройках WAN-интерфейса, даже если IP-адрес получается от провайдера динамически
2) Роутер выдает внутренним клиентам свой адрес в качестве DNS и переправляет их запросы на тот сервер, который указан в настройках WAN
Соответственно, в этом случае нам необходимо и достаточно прописать адрес нашего Pi-Hole в качестве DNS-сервера в настройках WAN-интерфейса домашнего роутера. Важно, чтобы он был единственным DNS-сервером в настройках, если будет указан какой-то еще — роутер будет балансировать запросы между ними по только ему известному принципу и такая ситуация крайне неудобна для отладки проблем в сети.
Если вдруг что-то пошло не так и сервис перестал работать, указанную выше настройку достаточно поменять на адрес DNS-сервера вашего провайдера или, например, 8.8.8.8, а уже потом начинать разбираться.
Если у вас роутер более умный и, например, имеет возможность указать в DHCP, какой адрес раздавать клиентам в качестве DNS-сервера, можете пойти по альтернативному пути и настроить раздачу адреса Pi-Hole клиентам напрямую. Это немного разгрузит роутер, но зато усложнит вышеописанный откат с использования сервиса.
В случае, если что-то не будет получаться — спрашивайте в комментариях, найдем решение.
4. Решаем проблемы
В целом после выполнения вышеописанных пунктов у вас уже всё должно быть хорошо, но бывают нюансы, с которыми я и мои клиенты иногда сталкивались.
После начала использования Pi-Hole вы можете ощутить необычные чувства уменьшения объемов рекламы в ваших устройствах (особенно мобильных). Не пугайтесь, это так и задумано. Также некоторые сервисы могут перестать работать привычным вам путем и это потребует вашего участия в настройках. Например, сайт Aliexpress периодически пытается переадресовать вас на адрес best.aliexpress.com, который находится в списке рекламных, и это блокирует весь доступ к Али.
Обнаружить такую проблему достаточно просто — если вы пытаетесь зайти на заблокированный сервер, ваш браузер показывает вам ошибку ERR_NAME_NOT_RESOLVED или подобную, а проверка в командной строке через nslookup <имя сервера> в ответ выдает 0.0.0.0.
Решить проблему для конкретного сервера тоже несложно — достаточно добавить его в whitelist. Для этого заходим на http://pi.hole/admin, логинимся, в левом меню выбираем Whitelist и добавляем нужный нам сервер. Мне, например, пришлось открывать кроме упомянутого best.aliexpress.com еще и s.click.aliexpress.com, а также группу сайтов в домене miui.com для работы сервисов Xiaomi. Вам, вероятно, потребуется что-то своё. Но отследить, что именно надо открыть, не так и сложно — на главной странице Dashboard сервиса и в Query Logs вы всегда можете посмотреть, запросы на какие домены были заблокированы, и добавить их в whitelist.
Также регулярно бывает, что Pi-Hole инсталлируют на сервер, на котором уже работает какой-то веб-сервис. В этом случае вы не получите доступа к веб-интерфейсу управления. Как разруливать такой конфликт — зависит от конкретной ситуации, но основные пути решения — это:
- Если веб-сервер не использовался, а просто стоял по умолчанию — найти и отключить
- Если веб-сервер используется и вы умеете с ним работать — добавьте Pi-Hole веб-интерфейс отдельным ресурсом в ваш веб-сервер.
- Также вы можете посадить веб-интерфейс Pi-Hole на другой порт, исправив параметр server.port в файле /etc/lighttpd/lighttpd.conf. Но это потребует помнить, на каком порту работает сервер, поэтому я такие схемы не приветствую.
Заключение
Как и обещал, не написал ничего нового. Для многих читателей эта схема понятна и очевидна, и или уже внедрена, или не внедрена за ненадобностью. Многие другие построили что-то подобное по-другому, с использованием тех же или иных компонентов. Предлагаю рассматривать этот пост скорее как заготовку для вашего собственного решения, если оно вам когда-либо потребуется. Но, выполнив его как пошаговую инструкцию, вы уже получите сервис, закрывающий ваши базовые потребности в фильтрации рекламы и использовании DoH.
На вопросы, традиционно, отвечу и с настройками помогу.
P.S. Замечание от GennPen — при использовании DoH вы становитесь зависимыми от наличия у вас интернета и если на счету закончились деньги — то даже в личный кабинет провайдера зайти не сможете, чтобы их заплатить. Поэтому для таких сайтов в этом решении желательно прописать статические записи в Pi-Hole — это можно сделать в консоли командой pihole -a -r или просто вручную в файле /etc/hosts. В веб-интерфейсе для этого инструмент, к сожалению, не заложен.
Комментарии (47)
Javian
24.09.2019 09:28Нет варианта «уже внедрил». Pi-hole — эта та вещь, которую уже пора иметь в любой домашней сети по умолчанию. И периодически смотреть Dashboard, Query Logs и пресекать деятельность слишком умных устройств.
GennPen
24.09.2019 10:00Дома на pfSense хватает встроенного DNS over TLS.
Все прекрасно, но если внезапно заканчиваются деньги на интернете, то личный кабинет перестает работать. Обычно решается назначением нужных IP адресов на домены личного кабинета в DNS сервере.
Furriest Автор
24.09.2019 10:41Ценное замечание, спасибо. Добавлю в статью.
Meklon
24.09.2019 17:21Добавь ещё рекомендацию иметь несколько инстансов pi-hole. Если сервер выключен или обслуживается, то DNS должен продолжать работать.
У меня резерв — сервера у родственников. VPN не требует DNS и поэтому они доступны. Если упал интернет и нет к ним доступа, то DNS уже сильно меньше нужен.Furriest Автор
24.09.2019 19:31На maintenance time можно переводить сеть на использование гугла или cf напрямую через смену DNS на роутере. Для домашней сети вряд ли это приведет к существенным проблемам, а вот два инстанса держать — это в два раза больше геморроя.
Meklon
24.09.2019 20:07Синхронизация списков автоматом идёт. Hosts разве что. Если резервный находится в другой локации, то он отвечает медленнее и относительно пофиг на hosts. В штатном варианте, он всегда вторичный.
В итоге все родственники рады и одновременно обеспечивают резерв.
dsrk_dev
24.09.2019 11:20а Pi-hole в сеть может раздавать DoH?
Furriest Автор
24.09.2019 11:45Ну тут не очень понятна формулировка. Что значит «раздавать»? Собственно, предлагаемое решение и позволяет «раздать» в сеть DoH, т.е. предоставить клиентам внутри сети проксирование их DNS-запросов в мир через DoH.
Если имеется в виду «предоставить DoH-сервер для DoH-клиентов внутри сети» — то эта задача решается не очень просто, но решается. Например, буквально две недели назад была статья об этом. Но если у вас DoH-клиенты — то зачем для них ставить сервер внутри, там весь смысл в защите от анализа запросов через внешние каналы связи.
fur_habr
24.09.2019 11:54+11) На некоторые устройства(вроде тот же OrangePi Zero) можно было поставить только старый пакет cloudflare. Точнее заработает только старый(старый — не значит неработающий).
2) Про статический адрес — Вы написали что он у вас был изначально. Надо сильней на этом сделать акцент. У кого не статический адрес — тому придётся делать его статическим во внутренней сети и лучше настроить его так, чтобы он не конфликтовал потом с другими адресами. Ну например забиндить адрес 192.168.1.5, а раздачу адресов на рутере поставить начиная с 192.168.1.50.
3) Raspberry Pi не тянет много подписок. Вы какие подписки подбирали для России? Там же изначальные подписки вообще не учитывают российских реалий. Пробовали примерное такие списки?
4) Насколько я помню — в PiHole можно немного задавать правила wildcard и regex. Вы тестировали их? Я пару раз попробовала, у меня не сработала фильтрация. Я не сильно вдавалась в детали, так как у меня в принципе всё порезано на уровне браузера. Но было бы полезно знать про опыт других.
5)
# Commandline args for cloudflared
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query
Если не ошибаюсь сюда можно подставить другие поддерживающие данную функцию DoH сервера и не надо будет доверять именно Cloudflare
6) Привели бы ссылки на проекты, на инструкцииFurriest Автор
24.09.2019 12:21По всем пунктам в целом согласен.
1. На младших апельсинах не тестировал, поверил на слово, что работает. На третьей малинке проблем с выкачанным с сайта не было.
2. Если адрес у сервера не статический — Pi-Hole при установке будет настойчиво предлагать поменять его на статический. А разведение диапазонов в целом полезно, но в большинстве случаев избыточно, я давно не встречал устройств, не умеющих проверить занятость адреса.
3. За линк на списки спасибо, внедряющим будет интересно. Жалоб на работу на RPi3 с этими списками не возникало, но нет пределов совершенству.
4. По wildcard записи есть, я тоже в какой-то из старых версий натыкался на проблемы, но в 4.3.2 работают. Сложные регулярки не пробовал за неимением необходимости.
5. Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.
6. Систематизация ссылок — самая трудная работа в любой документации, всегда лень. Когда-нибудь я достигну совершенства и буду делать статьи идеально :)fur_habr
24.09.2019 13:40но в 4.3.2 работают.
Спасибо за информацию. Ещё раз попробую.
Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.
Просто Вы написали в статье что надо доверять Cloudflare. Некоторые могут отказаться от этой идеи из-за этого замечания, даже не дочитав до комментариев. Можно же поставить сноску/примечание в статье, что и этот пункт можно обойти.
swelf
24.09.2019 12:04Самый главный то вопрос, с какими провайдерами помогает? по-моему все лезут в http, если это http, или блокируют ip, если это https
Furriest Автор
24.09.2019 12:27Как я и говорил, есть провайдеры, которые лезут сначала в DNS-запрос. Это разгружает другие уровни фильтрации. В таких случаях даже если у вас есть VPN, но ваш DNS-запрос проходит через такого провайдера (не обязательно российского, кстати) — вы не сможете воспользоваться VPN, потому что домен отрезолвится или в адрес заглушки, или в локалхост.
Использование DoH исключает манипуляции вашим резолвингом в транзите и раскрытие информации о том, куда именно вы в интернете ходите.
Не у всех востребовано, безусловно.
mxms
24.09.2019 12:42При такой схеме с наличием локального DNS ресольвера DoH вообще не нужен, ни при обращении к внешним серверам, ни, тем более, внутри сети.
Вы можете совершенно спокойно обращаться к нему традиционными (нешифрованными) запросами внутри сети что, заметьте, не требует ни специального софта ни каких-то специфичных настроек, за исключением выдачи IP клиентам DNS сервера по DHCP. Внешние запросы же можно форвардить через DNS-over-TLS к любому из поддерживающим его внешним публичными, или, лучше, вашему личному, DNS серверам.Furriest Автор
24.09.2019 13:02Ну так, собственно, этот резольвер и занимается форвардингом запросов к публичным серверам. А внутри сети вы традиционными запросами к нему и обращаетесь, и специфичных настроек вам не надо. Вы точно статью читали?
DoT детектируется и, соответственно, блокируется легче, чем DoH, поэтому DoH для меня интереснее. У вас, конечно, может быть другой набор критериев, по которому DoT побеждает.mxms
24.09.2019 13:11DoT детектируется и, соответственно, блокируется легче чем DoH
Это не соответствует действительности. Если вы об использовании порта 853 для DNS-over-TLS, то ничто вам не мешает использовать тот же 443 взамен. Более того, некоторые публичные DoT серверы так и делают. Блокировка по имени хоста или IP вообще ничем не отличается в обоих случаях.
В итоге получается, что DoH за счёт инкапсуляции в HTTP даёт лишь дополнительный оверхед но никак не повышает доступность из-за блокировок.Furriest Автор
24.09.2019 14:00Используя DoH, вы имеете гораздо больший пул публично доступных на порту 443/tcp серверов, чем используя DoT.
Но я не планирую устраивать тут холивар DoT vs DoH в сверкающих доспехах. Считаете, что DoT лучше — пользуйтесь, конечно же. Рынок устаканится, крупнейшие игроки договорятся и какой-то из этих вариантов выдавит другой без нашего участия.
armid
24.09.2019 13:04Советы в статье полезны и необходимы, но я бы начинал с конкретных устройств. Толку мне от DoH, DoT, VPNs дома, если как только я возьму ноут и пойду в коворкинг, кафе, поеду в отпуск, все сразу отвалится. Поэтому как по мне каждое устройство дома, должно быть самодостаточным (в плане защиты, блокировки реклам, обход блокировок), а не полагаться на роутер, который с собой на улицу не возьмешь.
mxms
24.09.2019 13:13Для браузера DoH поможет, а вообще для этого случая лучше поднять локальный Unbound с форвадингом через DoT.
Furriest Автор
24.09.2019 14:32Ну, например, домашнему NASу, стационарному компьютеру или телевизору совершенно не обязательно решать вопросы мобильного доступа. У меня квартире сейчас 27 устройств с выделенным IP-адресом, я бы не хотел их все настраивать и особенно переконфигурировать в каком-то случае.
А в целом модели доступа могут быть разнообразны. У меня, например, тот же сервер с Pi-Hole еще и терминирует wireguard-туннели с ноутбука и телефона, поэтому задача обеспечения доступа в таких случаях «сводится к предыдущей» одним кликом в интерфейсе.
Сложно придумать и описать все возможные кейсы использования, обычно имеет смысл дать какую-то канву решения в заданных граничных условиях, а дальше уже помогать с конкретикой отдельным людям.
dartraiden
24.09.2019 15:18У меня квартире сейчас 27 устройств с выделенным IP-адресом, я бы не хотел их все настраивать и особенно переконфигурировать в каком-то случае.
eSNI-то всё равно придётся включать на конечном устройстве…Furriest Автор
24.09.2019 19:29eSNI — это отдельная песня и на самом деле, к сожалению, не поможет. Тут дело в том, что требует от операторов РКН и как это контролирует РЧЦ. С включением eSNI блокировки https просто перейдут в режим «по IP».
Hardened
25.09.2019 09:38Вот интересно будет за этим понаблюдать, когда в суды пойдут IP соседи. Провайдерам точно геморроя прибавится...
Furriest Автор
25.09.2019 10:19По моим ощущениям, сейчас успешных кейсов в судах у «заблокированных за компанию» нет.
А провайдерский геморрой — он, разумеется, усиливается с каждым часом. Поэтому рынок коллапсирует, мелкие не выдерживают. Движемся строевым шагом к концепции Ein Reich, ein Fuhrer, ein Internetdienstanbieter.
konchok
24.09.2019 21:021. Доверять Cloudflare.
Кроме того должен быть низкий пинг до 1.1.1.1, иначе и смысла нет — надолго нервов не хватит. Обычно у провайдеров для DNS трафика выставлен высокий приоритет в QoS, а DoH будет идти в категории «всё остальное» вместе с торрентами итд.
Kyrie1965
24.09.2019 21:06Для справки (может кто не знает), актуальные маршрутизаторы Keenetic, даже самый простой за 1500 рублей, поддерживают DNS-over-TLS и DNS-over-HTTPS с прошивкой KeeneticOS 3.1. Конструировать паровоз для "домашних" пользователей не нужно.
unwrecker
25.09.2019 19:26А нет ли решения для локального bind?
Furriest Автор
26.09.2019 03:18Можно легко переделать это, пропустив первый шаг, а во втором привязать cloudflared к bind вместо pihole через опцию в конфигурационном файле bind:
forwarders {
127.0.0.1 port 5053;
}unwrecker
26.09.2019 23:13Спасибо, но не хочется завязываться на cloudflare. Нельзя ли иметь несколько независимых шифрованных каналов до разных корневых DNS?
Furriest Автор
27.09.2019 09:40Как уже упомянули в комментариях, в настройках cloudflared можно указать несколько разных провайдеров DoH и тогда будет несколько независимых шифрованных каналов. Разве что не до корневых, а до гугла и подобных (мне неизвестны корневые серверы, предоставляющие DoH).
Meridian2012
27.09.2019 09:41Коллеги, пните, пожалуйста, «чайника линукс» в правильном направлении копания:
— Виртуалка 2Gb, чистая установка последней Cent OS 7;
— по шагам все прохожу до пункта «Осталось только подключить сервис к Pi-Hole. Для этого вы заходите в веб-интерфейс Pi-Hole (тут вам пригодится записанный в первом этапе пароль)»
— получаю экран вида
drive.google.com/file/d/1ZsY_tC5fnMs54pIHqmD4QkwIGoE_pnbr/view?usp=sharingFurriest Автор
27.09.2019 09:42Вам нужно перейти по ссылке внизу экрана и там уже авторизоваться.
Meridian2012
27.09.2019 10:36Увы, это выводится вместо диалога авторизации. Сколько не нажимай на ссылку (там /admin) — картинка одна и та же.
Meridian2012
27.09.2019 14:12+1Победил. Умные люди отключили firewall и selinux — картинка появилась.
Файервалл позже буду настраивать. А вот selinux этому решению, надеюсь не нужен.
MedicusAmicus
Раз уж how-to.
На пакетах openwrt такое реализуется?
Городить отдельный сервер для меня как-то избыточно, а вот приличный роутер — самое оно, имхо.
Furriest Автор
Точно не на этом наборе софта.
На OpenWrt есть свой ad-block, могущий заменить Pi-Hole.
И DoH-proxy тоже есть.
Но с высокой вероятностью полноценная фильтрация рекламы упрется в нехватку оперативной памяти на устройстве. Надо экспериментировать.
Javian
Есть важное условие для adblock — требуется от OpenWrt-18.06.0. Личные впечатления — сложнее исключать из блокировки сайты, кое-что нужное отвалилось. У pi-hole интерфейс намного проще.
Вчера DoH запустил на своем роутере. Пока заметил только, что aliexpress автоматически включает французский язык.
dartraiden
Для более старых версий OpenWrt, где пакета в репозиториях ещё не было, есть самописный вариант.
Под популярную прошивку Padavan я костылил себе вот так.
Рекомендую simple-adblock. Он полегче (у adblock чуть больше фич, но они далеко не всем нужны), а исключения добавляются через веб-интерфейс, куда уж проше.
xdimquax
Проблема в том, что мониторинга никакого нет, и непонятно, попал домен в чёрный список или нет.
ElvenSailor
Тут ещё немаловажно железо, на котором крутится OpenWrt.
Можно легко ушатать роутер, если там слабый проц. (относится не только к этим пакетам, а вообще)
А потом думаешь — а чегой-то у меня тариф 100 Мбит/с, а закачки 2.5-3 МБ/с вместо 10-11?
а это бедный роутер не тащит всю петрушку, которую на него понаставили :)
eps
Всё делается, dnscrypt настраивается за полчаса-час на свежих версиях OpenWRT. DoH proxy, вероятно, тоже.
Ещё из прелестей OpenWRT:
ksenobayt
openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_stubby
openwrt.org/docs/guide-user/services/dns/doh_dnsmasq_https-dns-proxy
На ваш вкус и цвет, как говорится.
В случае DoT можно вообще не залезать в консоль, см. forum.openwrt.org/t/tutorial-no-cli-configuring-dns-over-tls-with-luci-using-stubby-and-dnsmasq/29143/17