Переводим на DoH домашнюю сеть, или еще один щелчок по носу фильтрации

  • Tutorial

После сравнительно недавнего анонса компанией Mozilla запуска поддержки DNS-over-HTTPS (DoH) в продакшн в сети не утихают споры, зло это или благо. По моим ощущениям, позиция "зло" базируется в основном на том, что при этом манипуляция вашими DNS-запросами даже в полезных для вас целях будет затруднена, поэтому я пока что остаюсь на позиции "благо".
image


В Российской Федерации операторы связи, поставленные в очень жесткие условия нашим законодательством, вынуждены строить изощренные многоуровневые системы блокировок доступа к запрещенному Роскомнадзором на территории РФ контенту, на одном из уровней которых более-менее успешно работает перехват DNS-запросов. Использование DoH позволит обойти этот уровень, что в совокупности с использованием VPN может несколько облегчить вам жизнь. Обратите внимание, само по себе решение не может избавить вас от блокировок, потому что вряд ли в России есть провайдер, полагающийся только на фильтрацию через DNS. Вам нужен еще какой-то вариант обойти блокировки, например VPN, один из описанных в моих предыдущих статьях.


Парадоксально, но в текущем паноптикуме оператору связи ничем не грозит ваш обход его блокировок (с использованием специальных средств для этого), поэтому если вы опасаетесь навредить ему таким образом — эти опасения напрасны.


Но переходить на специальный браузер, чтобы обойти перехват DNS — не наш путь. Наш путь — перевести все устройства домашней сети на DoH, быстро, эффективно и без лишних трудозатрат.


Disclaimer


Поскольку публиковать способы обхода блокировок доступа к информации, запрещенной на территории Российской Федерации, не очень законно, целью этой статьи будет рассказать о методе, позволяющем автоматизировать получение доступа к ресурсам, разрешенным на территории Российской Федерации, но из-за чьих-то действий недоступным напрямую через вашего провайдера. А доступ к другим ресурсам, получаемый в результате действий из статьи, является досадным побочным эффектом и целью статьи ни в коем случае не является.


TL;DR


Разворачиваем собственный DNS-сервер на базе Pi-Hole, использующий Cloudflare DoH для запросов в мир. Цель — зашифровать все DNS-запросы и обойти таким образом операторскую фильтрацию через перехват DNS. Полезный бонус — фильтрация рекламы.


Никаких волшебных know-how не открывается, простая пошаговая инструкция для тех, кому не хочется разбираться во всех хитросплетениях самому.


Что вам для этого потребуется


  1. Доверять Cloudflare. На самом деле это очень важный пункт, поскольку в описываемой реализации все ваши DNS-запросы обрабатываются сервисом Cloudflare. Если вы ему не доверяете — вам придется внедрить другое решение (и это немногим сложнее, чем описанное, но целью этой статьи не является).
  2. Иметь возможность поддерживать в домашней сети постоянно работающий сервер с Linux, который будет обслуживать DNS-запросы ваших устройств. Требование Pi-Hole — от 512M оперативной памяти (впрочем, работу с меньшим объемом сам не проверял). Если ваш роутер или NAS умеют виртуальные машины — это прекрасный вариант, если на полке где-то завалялась Raspberry Pi или другой микрокомпьютер на ARM — не менее хорошо, если на антресолях в коридоре жужжит виртуальная ферма на ESXi — то что я вам рассказываю, вы и сами всё знаете. Если у вас ничего из этого нет — самые младшие решения, типа Orange Pi Zero, на вторичном рынке можно найти за единицы сотен рублей либо привезти из Али за плюс-минус те же деньги. Но выбор платформы сильно выходит за рамки этой статьи, поэтому считаем, что у вас что-то есть. Впрочем, вопросы на этот счет можно задавать в комментариях.
  3. Вы должны иметь представление о использовании Linux и сетевых технологиях. Или хотя бы хотеть получить такое представление. Поскольку объять необъятное в этот раз я не готов, некоторые непонятные для вас моменты вам придется изучить самостоятельно. Впрочем, на конкретные вопросы, конечно же, отвечу в комментариях и вряд ли окажусь единственным отвечающим, так что не стесняйтесь спрашивать.

Исходные данные


IPv4-адрес нашего сервера в домашней сети: 192.168.1.10 и он назначен как статический.


Настройки на Linux выполняем от root (т.е. перед началом настройки выполняем команду sudo su -).


Кратко — логика решения


  1. Устанавливаем и настраиваем Pi-Hole
  2. Устанавливаем и настраиваем cloudflared
  3. Настраиваем ваш домашний роутер
  4. Решаем проблемы

Собственно решение


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 и делаете его выглядящим приблизительно вот так:


Screenshot of Pi-hole configuration


Главное — заполнить поле 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 инсталлируют на сервер, на котором уже работает какой-то веб-сервис. В этом случае вы не получите доступа к веб-интерфейсу управления. Как разруливать такой конфликт — зависит от конкретной ситуации, но основные пути решения — это:


  1. Если веб-сервер не использовался, а просто стоял по умолчанию — найти и отключить
  2. Если веб-сервер используется и вы умеете с ним работать — добавьте Pi-Hole веб-интерфейс отдельным ресурсом в ваш веб-сервер.
  3. Также вы можете посадить веб-интерфейс Pi-Hole на другой порт, исправив параметр server.port в файле /etc/lighttpd/lighttpd.conf. Но это потребует помнить, на каком порту работает сервер, поэтому я такие схемы не приветствую.

Заключение


Как и обещал, не написал ничего нового. Для многих читателей эта схема понятна и очевидна, и или уже внедрена, или не внедрена за ненадобностью. Многие другие построили что-то подобное по-другому, с использованием тех же или иных компонентов. Предлагаю рассматривать этот пост скорее как заготовку для вашего собственного решения, если оно вам когда-либо потребуется. Но, выполнив его как пошаговую инструкцию, вы уже получите сервис, закрывающий ваши базовые потребности в фильтрации рекламы и использовании DoH.


На вопросы, традиционно, отвечу и с настройками помогу.


P.S. Замечание от GennPen — при использовании DoH вы становитесь зависимыми от наличия у вас интернета и если на счету закончились деньги — то даже в личный кабинет провайдера зайти не сможете, чтобы их заплатить. Поэтому для таких сайтов в этом решении желательно прописать статические записи в Pi-Hole — это можно сделать в консоли командой pihole -a -r или просто вручную в файле /etc/hosts. В веб-интерфейсе для этого инструмент, к сожалению, не заложен.

Only registered users can participate in poll. Log in, please.

Что скажете про статью?

Support the author
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 59

    +3

    Раз уж how-to.
    На пакетах openwrt такое реализуется?
    Городить отдельный сервер для меня как-то избыточно, а вот приличный роутер — самое оно, имхо.

      +1
      Точно не на этом наборе софта.
      На OpenWrt есть свой ad-block, могущий заменить Pi-Hole.
      И DoH-proxy тоже есть.
      Но с высокой вероятностью полноценная фильтрация рекламы упрется в нехватку оперативной памяти на устройстве. Надо экспериментировать.
        +1
        Есть важное условие для adblock — требуется от OpenWrt-18.06.0. Личные впечатления — сложнее исключать из блокировки сайты, кое-что нужное отвалилось. У pi-hole интерфейс намного проще.

        Вчера DoH запустил на своем роутере. Пока заметил только, что aliexpress автоматически включает французский язык.
          +1
          Есть важное условие для adblock — требуется от OpenWrt-18.06.0.
          Нет, adblock уже был в 17.01, а может и раньше.

          Для более старых версий OpenWrt, где пакета в репозиториях ещё не было, есть самописный вариант.

          Под популярную прошивку Padavan я костылил себе вот так.

          сложнее исключать из блокировки сайты
          Рекомендую simple-adblock. Он полегче (у adblock чуть больше фич, но они далеко не всем нужны), а исключения добавляются через веб-интерфейс, куда уж проше.
            0

            Проблема в том, что мониторинга никакого нет, и непонятно, попал домен в чёрный список или нет.

          0
          Тут ещё немаловажно железо, на котором крутится OpenWrt.
          Можно легко ушатать роутер, если там слабый проц. (относится не только к этим пакетам, а вообще)
          А потом думаешь — а чегой-то у меня тариф 100 Мбит/с, а закачки 2.5-3 МБ/с вместо 10-11?
          а это бедный роутер не тащит всю петрушку, которую на него понаставили :)
          +2

          Всё делается, dnscrypt настраивается за полчаса-час на свежих версиях OpenWRT. DoH proxy, вероятно, тоже.


          Ещё из прелестей OpenWRT:


          • Прозрачная маршрутизация в сети Tor и i2p для всей локалки
          • Маршрутизация IPv6 для всей локалки, в том числе через внешние шлюзы
          • Блокировка рекламы (adblock, simple-adblock), если вам это интересно
          • У вас только одна железка, от которой это всё зависит, а не две (плюс связность между ними), как в случае с Pi-Hole
            0
            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
            0
            Нет варианта «уже внедрил». Pi-hole — эта та вещь, которую уже пора иметь в любой домашней сети по умолчанию. И периодически смотреть Dashboard, Query Logs и пресекать деятельность слишком умных устройств.
              0
              Есть, он называется «Всё очевидно, уже сделано» :)
                0
                off с утра слишком сложно для восприятия :)
              +2
              У Zyxel в текущем большом обновлении ОСи для всех поддерживаемых роутеров прилетело и DNSoverTLS и DNSoverHTTPS
                0
                Хотел написать о том же, но вовремя прочитал комментарий. Даже накатил их, но пока не настраивал.
                0
                Дома на pfSense хватает встроенного DNS over TLS.
                Все прекрасно, но если внезапно заканчиваются деньги на интернете, то личный кабинет перестает работать. Обычно решается назначением нужных IP адресов на домены личного кабинета в DNS сервере.
                  0
                  Ценное замечание, спасибо. Добавлю в статью.
                    0

                    Добавь ещё рекомендацию иметь несколько инстансов pi-hole. Если сервер выключен или обслуживается, то DNS должен продолжать работать.
                    У меня резерв — сервера у родственников. VPN не требует DNS и поэтому они доступны. Если упал интернет и нет к ним доступа, то DNS уже сильно меньше нужен.

                      0
                      На maintenance time можно переводить сеть на использование гугла или cf напрямую через смену DNS на роутере. Для домашней сети вряд ли это приведет к существенным проблемам, а вот два инстанса держать — это в два раза больше геморроя.
                        0

                        Синхронизация списков автоматом идёт. Hosts разве что. Если резервный находится в другой локации, то он отвечает медленнее и относительно пофиг на hosts. В штатном варианте, он всегда вторичный.


                        В итоге все родственники рады и одновременно обеспечивают резерв.

                  0
                  а Pi-hole в сеть может раздавать DoH?
                    0
                    Ну тут не очень понятна формулировка. Что значит «раздавать»? Собственно, предлагаемое решение и позволяет «раздать» в сеть DoH, т.е. предоставить клиентам внутри сети проксирование их DNS-запросов в мир через DoH.
                    Если имеется в виду «предоставить DoH-сервер для DoH-клиентов внутри сети» — то эта задача решается не очень просто, но решается. Например, буквально две недели назад была статья об этом. Но если у вас DoH-клиенты — то зачем для них ставить сервер внутри, там весь смысл в защите от анализа запросов через внешние каналы связи.
                      0
                      в firefox esni без DoH не работает например
                    +2
                    1) На некоторые устройства(вроде тот же 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) Привели бы ссылки на проекты, на инструкции
                    7) И да, есть подводные камни, которые касаются Raspberry Pi и cloudflare. Например в части создания файлов по рутом. На raspbian от debian 9 надо было сначала проставить пароль на root. С одной стороны это не статья про Raspberry Pi, но с другой стороны Pi-Hole в основном на этой плате и устанавливается. И неплохо было бы для новичков хотя бы пройти простеший путь. Статья то в любом случае для них.

                    UPD: Добавила пункт 7
                      0
                      По всем пунктам в целом согласен.
                      1. На младших апельсинах не тестировал, поверил на слово, что работает. На третьей малинке проблем с выкачанным с сайта не было.
                      2. Если адрес у сервера не статический — Pi-Hole при установке будет настойчиво предлагать поменять его на статический. А разведение диапазонов в целом полезно, но в большинстве случаев избыточно, я давно не встречал устройств, не умеющих проверить занятость адреса.
                      3. За линк на списки спасибо, внедряющим будет интересно. Жалоб на работу на RPi3 с этими списками не возникало, но нет пределов совершенству.
                      4. По wildcard записи есть, я тоже в какой-то из старых версий натыкался на проблемы, но в 4.3.2 работают. Сложные регулярки не пробовал за неимением необходимости.
                      5. Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.
                      6. Систематизация ссылок — самая трудная работа в любой документации, всегда лень. Когда-нибудь я достигну совершенства и буду делать статьи идеально :)
                        0
                        но в 4.3.2 работают.
                        Спасибо за информацию. Ещё раз попробую.
                        Да, безусловно, можно перейти на другие серверы. У меня когда-то были проблемы с совместимостью с гугловым сервисом, что-то там различалось в форматах. Любой желающий может протестировать и использовать с теми серверами, которые ему ближе. Как я и говорил, пост — скорее заготовка.
                        Просто Вы написали в статье что надо доверять Cloudflare. Некоторые могут отказаться от этой идеи из-за этого замечания, даже не дочитав до комментариев. Можно же поставить сноску/примечание в статье, что и этот пункт можно обойти.
                      0
                      Самый главный то вопрос, с какими провайдерами помогает? по-моему все лезут в http, если это http, или блокируют ip, если это https
                        0
                        Как я и говорил, есть провайдеры, которые лезут сначала в DNS-запрос. Это разгружает другие уровни фильтрации. В таких случаях даже если у вас есть VPN, но ваш DNS-запрос проходит через такого провайдера (не обязательно российского, кстати) — вы не сможете воспользоваться VPN, потому что домен отрезолвится или в адрес заглушки, или в локалхост.
                        Использование DoH исключает манипуляции вашим резолвингом в транзите и раскрытие информации о том, куда именно вы в интернете ходите.
                        Не у всех востребовано, безусловно.
                        0

                        При такой схеме с наличием локального DNS ресольвера DoH вообще не нужен, ни при обращении к внешним серверам, ни, тем более, внутри сети.
                        Вы можете совершенно спокойно обращаться к нему традиционными (нешифрованными) запросами внутри сети что, заметьте, не требует ни специального софта ни каких-то специфичных настроек, за исключением выдачи IP клиентам DNS сервера по DHCP. Внешние запросы же можно форвардить через DNS-over-TLS к любому из поддерживающим его внешним публичными, или, лучше, вашему личному, DNS серверам.

                          0
                          Ну так, собственно, этот резольвер и занимается форвардингом запросов к публичным серверам. А внутри сети вы традиционными запросами к нему и обращаетесь, и специфичных настроек вам не надо. Вы точно статью читали?

                          DoT детектируется и, соответственно, блокируется легче, чем DoH, поэтому DoH для меня интереснее. У вас, конечно, может быть другой набор критериев, по которому DoT побеждает.
                            0
                            DoT детектируется и, соответственно, блокируется легче чем DoH

                            Это не соответствует действительности. Если вы об использовании порта 853 для DNS-over-TLS, то ничто вам не мешает использовать тот же 443 взамен. Более того, некоторые публичные DoT серверы так и делают. Блокировка по имени хоста или IP вообще ничем не отличается в обоих случаях.
                            В итоге получается, что DoH за счёт инкапсуляции в HTTP даёт лишь дополнительный оверхед но никак не повышает доступность из-за блокировок.

                              0
                              Используя DoH, вы имеете гораздо больший пул публично доступных на порту 443/tcp серверов, чем используя DoT.

                              Но я не планирую устраивать тут холивар DoT vs DoH в сверкающих доспехах. Считаете, что DoT лучше — пользуйтесь, конечно же. Рынок устаканится, крупнейшие игроки договорятся и какой-то из этих вариантов выдавит другой без нашего участия.
                          0
                          Советы в статье полезны и необходимы, но я бы начинал с конкретных устройств. Толку мне от DoH, DoT, VPNs дома, если как только я возьму ноут и пойду в коворкинг, кафе, поеду в отпуск, все сразу отвалится. Поэтому как по мне каждое устройство дома, должно быть самодостаточным (в плане защиты, блокировки реклам, обход блокировок), а не полагаться на роутер, который с собой на улицу не возьмешь.
                            0

                            Для браузера DoH поможет, а вообще для этого случая лучше поднять локальный Unbound с форвадингом через DoT.

                              0
                              Ну, например, домашнему NASу, стационарному компьютеру или телевизору совершенно не обязательно решать вопросы мобильного доступа. У меня квартире сейчас 27 устройств с выделенным IP-адресом, я бы не хотел их все настраивать и особенно переконфигурировать в каком-то случае.

                              А в целом модели доступа могут быть разнообразны. У меня, например, тот же сервер с Pi-Hole еще и терминирует wireguard-туннели с ноутбука и телефона, поэтому задача обеспечения доступа в таких случаях «сводится к предыдущей» одним кликом в интерфейсе.

                              Сложно придумать и описать все возможные кейсы использования, обычно имеет смысл дать какую-то канву решения в заданных граничных условиях, а дальше уже помогать с конкретикой отдельным людям.
                                0
                                У меня квартире сейчас 27 устройств с выделенным IP-адресом, я бы не хотел их все настраивать и особенно переконфигурировать в каком-то случае.
                                eSNI-то всё равно придётся включать на конечном устройстве…
                                  0
                                  eSNI — это отдельная песня и на самом деле, к сожалению, не поможет. Тут дело в том, что требует от операторов РКН и как это контролирует РЧЦ. С включением eSNI блокировки https просто перейдут в режим «по IP».
                                    0

                                    Вот интересно будет за этим понаблюдать, когда в суды пойдут IP соседи. Провайдерам точно геморроя прибавится...

                                      0
                                      По моим ощущениям, сейчас успешных кейсов в судах у «заблокированных за компанию» нет.
                                      А провайдерский геморрой — он, разумеется, усиливается с каждым часом. Поэтому рынок коллапсирует, мелкие не выдерживают. Движемся строевым шагом к концепции Ein Reich, ein Führer, ein Internetdienstanbieter.
                              0
                              1. Доверять Cloudflare.

                              Кроме того должен быть низкий пинг до 1.1.1.1, иначе и смысла нет — надолго нервов не хватит. Обычно у провайдеров для DNS трафика выставлен высокий приоритет в QoS, а DoH будет идти в категории «всё остальное» вместе с торрентами итд.
                                +1

                                Для справки (может кто не знает), актуальные маршрутизаторы Keenetic, даже самый простой за 1500 рублей, поддерживают DNS-over-TLS и DNS-over-HTTPS с прошивкой KeeneticOS 3.1. Конструировать паровоз для "домашних" пользователей не нужно.


                                  0
                                  А нет ли решения для локального bind?
                                    0
                                    Можно легко переделать это, пропустив первый шаг, а во втором привязать cloudflared к bind вместо pihole через опцию в конфигурационном файле bind:
                                    forwarders {
                                    127.0.0.1 port 5053;
                                    }
                                      0
                                      Спасибо, но не хочется завязываться на cloudflare. Нельзя ли иметь несколько независимых шифрованных каналов до разных корневых DNS?
                                        0
                                        Как уже упомянули в комментариях, в настройках cloudflared можно указать несколько разных провайдеров DoH и тогда будет несколько независимых шифрованных каналов. Разве что не до корневых, а до гугла и подобных (мне неизвестны корневые серверы, предоставляющие DoH).
                                    0
                                    Коллеги, пните, пожалуйста, «чайника линукс» в правильном направлении копания:
                                    — Виртуалка 2Gb, чистая установка последней Cent OS 7;
                                    — по шагам все прохожу до пункта «Осталось только подключить сервис к Pi-Hole. Для этого вы заходите в веб-интерфейс Pi-Hole (тут вам пригодится записанный в первом этапе пароль)»
                                    — получаю экран вида
                                    drive.google.com/file/d/1ZsY_tC5fnMs54pIHqmD4QkwIGoE_pnbr/view?usp=sharing
                                      0
                                      Вам нужно перейти по ссылке внизу экрана и там уже авторизоваться.
                                        0
                                        Увы, это выводится вместо диалога авторизации. Сколько не нажимай на ссылку (там /admin) — картинка одна и та же.
                                          +1
                                          Победил. Умные люди отключили firewall и selinux — картинка появилась.
                                          Файервалл позже буду настраивать. А вот selinux этому решению, надеюсь не нужен.
                                      0

                                      Статья интересная. Спасибо. Было бы ещё интересно почитать внятную инструкцию настройки mikrotik+vps +pihole +dnscrypt

                                        +1
                                        На базе mikrotik нельзя поставить pihole и dnscrypt не организуешь — нет функционала.

                                        Столкнулся с определенной неприятностью в реализации DNS-сервера mikrotik. Прописал первым адресом IP виртуалки с DoH и PiHole, вторым — 8.8.8.8 и наивно предполагал, что запросы пойдут через DoH в качестве основного канала, а «восьмерки» будут резервным. С удивлением обнаружил весь трафик DNS на «восьмерках». Полагаю, что mikrotik как-то оценивает сервера DNS по качеству (скорости ответа?) и потом весь трафик гонит в лучший.

                                        В моей ситуации виртуалка с DoH лежит не в домашней сети, а доступна через vpn с офисом, поэтому неудивительно, что прямые запросы на «восьмерки» оказались эффективнее. Выкрутился пока через netwatch — пингую DoH и в зависимости от доступности меняю там DNS-сервера на mikrotik.
                                          0
                                          Нет, просто с pi-hole не должно быть обычных DNS. Только один или лучше несколько инстансов pi-hole. Иначе при пустом ответе от pi-hole клиент пробует альтернативный DNS и получает нужный IP.

                                          У меня как раз Mikrotik и виртуальная машина с pi-hole. Резервные ноды у родственников через VPN. Если у меня сервер прилег, то DNS запросы идут к родителям.
                                            0
                                            Нет, просто с pi-hole не должно быть обычных DNS

                                            Ага, у меня именно так. А в микротике в качестве DNS изначально было прописано 192.168.142.2, 8.8.8.8 (192.168.142.2 — виртуалка с DoH и PiHole). И в такой ситуации у меня DNS-запросы шли через «восьмерки».
                                              0
                                              Беда-печаль в том, что выбор, через какой сервер резолвить, никоим образом не стандартизован. Например, XP вообще не умела соскакивать с первого сервера, если он недоступен — то ничего не работает (ну или таймаут измеряется десятками минут, никогда сильно долго не ждал). Именно поэтому смешивать DNS-сервисы, предоставляющие услугу по-разному, не надо.
                                                0
                                                Да, Вы правы в отношении (отсутствия) стандартизации. Однако хочется неких очевидных вещей по управлению DNS, по крайней мере, от микротика — приоретизация серверов — штука очень ценная.

                                                В микротике есть еще одна «не очень хорошесть» — все исходящие DNS-запросы маскарадятся и повлиять на это никак нельзя. В результате на PiHole-сервер приходят запросы с из другой подсети с одного адреса и это «режет» статистику.
                                                  0
                                                  Повлиять на это просто, если вам это необходимо. Раздавайте по DHCP не адрес микротика, а адрес PiHole. Имея в голове описанную в статье лишнюю сложность отката в этом случае. Хотя альтернативно можно просто в случае аварии PiHole повесить его адрес на интерфейс микротика.
                                                    0
                                                    Не нравится так — в случае аварии PiHole сеть (клиенты) остается без ДНС. То, как сейчас (в DNS микротика прописан адрес PiHole, по netwatch мониторится его доступность и в случае проблем переключается на «восьмерки») — обеспечивает резервирование в случае сбоя. За исключением варианта, когда PiHole-машина пингуется, а резолвы в ней не идут — надеюсь, что такие вещи будут очень редки.
                                                      0
                                                      У меня именно такой вариант. Раздается по DHCP. Просто резерв нужен. Еще одна малина/сервер дома/сервер у соседей. Я не зря упомянул про них.
                                                        0
                                                        Согласен — два Pihole лучше, чем один. Со временем разверну.

                                                        0
                                                        Вы так же можете сделать и в этой схеме, просто при недоступности PiHole нужно не только переключиться на восьмерки, но и поднять интерфейс с адресом PiHole на микротике. И проверять PiHole тоже можно, в общем-то, не пингами, а DNS-запросами.

                                                        В целом в домашней сети отказоустойчивость строится не очень легко, в описанной схеме сам микротик у вас единая точка отказа. Если, конечно, у вас не установлен второй такой же на другого провайдера, запитанный от другого ввода электропитания и входящий в vrrp-группу с первым.
                                                          0
                                                          Тут, на мой взгляд, нужно соблюдать принцип разумной достаточности. Все навороты мною сделаны из-за невозможности прописать в микротике резервный (в практическом понимании этого слова) DNS.

                                                          Проверять PiHole DNS-запросами — правильней, но ваять специальный скрипт не вижу смысла. Пока. Если столкнусь с отказами в этой конструкции — обязательно сделаю.

                                                          А что касается единой точки отказа — у меня есть (на полке) запасной микротик :)

                                        Only users with full accounts can post comments. Log in, please.