Для Pi-hole на Ubuntu Server 24.04 перенаправьте его запросы к вышестоящему серверу через dnscrypt-proxyи укажите Pi-hole на локальный прослушиватель по адресу 127.0.0.1#5053. Это шифрует DNS-трафик между вашим сервером и выбранным вышестоящим резолвером с помощью DNS-over-HTTPS (DoH), в то время как Pi-hole продолжает отвечать клиентам вашей локальной сети и применять свои списки блокировки. Сам Pi-hole по умолчанию не обеспечивает передачу DoH-трафика к своему вышестоящему серверу; локальный прокси-сервер предоставляет это зашифрованное соединение.
Сначала нужно знать одну важную деталь, касающуюся текущей версии: cloudflared proxy-dnsначиная со 2 февраля 2026 года Cloudflare удалила эту команду из новых релизов. Более старые инструкции, в которых используется эта команда, могут не работать с текущей cloudflaredверсией. В описанных ниже шагах используется dnscrypt-proxyкоманда, соответствующая текущему руководству Pi-hole по DoH. Эта настройка подходит, когда Pi-hole и прокси работают на одном хосте Ubuntu. Для Docker или многохостовой конфигурации требуются разные адреса прослушивателей и правила брандмауэра.
Что делает эта система и чего она не делает.
Обычно стандартный DNS отправляет запросы от вашего резолвера к вышестоящему DNS-провайдеру без шифрования при передаче. DoH передает DNS-запросы по протоколу HTTPS, что затрудняет чтение или изменение этих запросов для сетевого наблюдателя между вашим сервером Pi-hole и резолвером. Pi-hole остается DNS-сервером, анонсируемым устройствам в вашей локальной сети; изменяется только его путь к вышестоящему серверу.
DoH не делает DNS-активность невидимой для выбранного вами резолвера. Поставщик услуг по-прежнему получает запросы от вашего сервера, и Pi-hole может сохранять историю запросов клиентов в соответствии со своими настройками конфиденциальности и ведения журналов. HTTPS также не шифрует несвязанный веб-трафик. Если ваша цель — использовать определенный резолвер, проверьте его политику конфиденциальности и выберите его запись DoH из списка поддерживаемых резолверов.
Прежде чем начать
- Убедитесь, что Pi-hole уже установлен и работает на Ubuntu Server 24.04. В этом пошаговом руководстве выполняется настройка существующего Pi-hole, а не его установка.
- Убедитесь, что сервер имеет стабильный адрес в локальной сети. Если адрес изменится, клиенты DHCP маршрутизатора могут потерять свой DNS-сервер.
- Необходимо иметь права администратора и способ связи с хостом Pi-hole в случае временного сбоя DNS. Избегайте внесения этих изменений удаленно через соединение, зависящее от того же Pi-hole для разрешения имен.
- Запишите текущие настройки подключения Pi-hole, чтобы вы могли восстановить их при откате.
Прокси-сервер будет привязываться только к локальному порту 5053, оставляя порт 53 для Pi-hole. Это позволяет избежать конкуренции с DNS-сервисом Pi-hole и локальным резолвером Ubuntu. Не стоит отключать эту функцию systemd-resolvedтолько для обеспечения работы данной схемы; отдельный локальный порт прокси-сервера позволяет избежать этого конфликта.
1. Установите dnscrypt-proxy из репозиториев пакетов Ubuntu.
В проекте dnscrypt-proxy описан способ установки пакетов Ubuntu. Перед установкой убедитесь, что в настроенных вами репозиториях Ubuntu есть подходящий пакет:
sudo apt update
apt-cache policy dnscrypt-proxy
Если в выводе отображается потенциальная версия, установите её:
sudo apt install dnscrypt-proxy
Если подходящего варианта не найдено, не добавляйте сторонний репозиторий, не имеющий отношения к проекту, просто чтобы продолжить. Используйте метод установки, указанный в официальном руководстве по Linux для проекта dnscrypt-proxy, проверьте версию и архитектуру и адаптируйте настройку службы к этой установке. Приведенные ниже пути к модулю сокета systemd и конфигурации относятся к настройке пакетов Ubuntu, описанной Pi-hole.
2. Переместите прокси-сервер на localhost, порт 5053.
Pi-hole уже использует стандартный DNS-порт 53. Настройте сокет прокси-сервера для прослушивания TCP и UDP-трафика по адресу 127.0.0.1:5053, доступному только с того же хоста. Создайте интеграцию systemd:
sudo systemctl edit dnscrypt-proxy.socket
Введите эти строки в редактор и сохраните:
[Socket]
ListenStream=
ListenDatagram=
ListenStream=127.0.0.1:5053
ListenDatagram=127.0.0.1:5053
Пустые ListenStream=строки ListenDatagram=очищают значения по умолчанию для пакета перед установкой адресов замены. Не опускайте их: в противном случае systemd сможет сохранить порт по умолчанию в дополнение к пользовательскому прослушивателю.
3. Выберите средство разрешения DoH.
Откройте файл конфигурации пакета:
sudoedit /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Для активации сокета systemd используйте пустой список прослушивателей в конфигурации прокси. Выберите имя резолвера из текущего списка подписанных публичных резолверов. Например, следующий код выбирает стандартный резолвер Cloudflare; в руководстве Pi-hole также приводится cloudflare-securityпример, когда требуется фильтрация вредоносного ПО на уровне вышестоящего резолвера:
listen_addresses = []
server_names = ['cloudflare']
Остальную конфигурацию пакета следует оставить без изменений. Указанные имена server_namesявляются идентификаторами реестра, а не произвольными именами хостов или путями URL. Если вы предпочитаете другого поставщика, убедитесь, что его текущая запись в резолвере поддерживает DoH, и скопируйте его точное имя. Резолвер, фильтрующий вредоносное ПО или другие категории, может давать результаты, отличные от результатов нефильтрованного резолвера.
4. Направьте Pi-hole на локальный прокси-сервер.
Установите DNS-адрес вышестоящего сервера Pi-hole на адрес локального слушателя:
sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5053"]'
Суффикс #5053— это обозначение Pi-hole для нестандартного DNS-порта. Вы также можете проверить это в административном интерфейсе Pi-hole в разделе «Настройки» > «DNS» . Снимите флажки с предварительно заданных общедоступных серверов и оставьте пользовательский сервер 127.0.0.1#5053в качестве основного. Если вы оставите выбранный общедоступный резолвер в качестве дополнительного сервера, это позволит запросам обходить зашифрованный прокси, поэтому удалите эти записи, если вам необходимо, чтобы все запросы Pi-hole использовали DoH.
5. Перезапустите службы и проверьте, устранена ли проблема.
Перезапустите сокет, службу прокси и демон Pi-hole FTL, чтобы они загрузили новую конфигурацию:
sudo systemctl restart dnscrypt-proxy.socket
sudo systemctl restart dnscrypt-proxy.service
sudo systemctl restart pihole-FTL.service
Проверить статус обслуживания:
sudo systemctl status dnscrypt-proxy.socket
sudo systemctl status dnscrypt-proxy.service
sudo systemctl status pihole-FTL.service
Каждый из них должен быть активен без ошибок привязки или сбоев при запуске резолвера. Проверьте работу прокси-сервера непосредственно через его локальный DNS-сервер:
dig @127.0.0.1 -p 5053 example.com
DNS-ответ указывает на то, что локальный прокси-сервер отвечает. Затем проверьте работу Pi-hole на порту 53:
dig @127.0.0.1 example.com
Проверьте журнал запросов Pi-hole или панель управления, чтобы подтвердить, что запрос достиг Pi-hole, и просмотрите журнал прокси-сервера, если проверка не удалась:
sudo journalctl -u dnscrypt-proxy.service -b --no-pager
Для дополнительной проверки посмотрите в выводе запуска прокси или журнала выбранный резолвер и статус протокола DoH. Успешный результат digсам по себе доказывает работоспособность разрешения DNS; он сам по себе не доказывает, что запрос использовал HTTPS.
Типичные проблемы и безопасное восстановление
- «Адрес уже используется»: возможно, другой процесс уже занимает порт 5053, или не загружен механизм переопределения сокета. Проверьте обработчики событий с помощью команды `npm run src`
sudo ss -lntup, просмотрите вставку с помощью команды ` systemctl cat dnscrypt-proxy.socketnpm run src` и убедитесь, что пустые строки сброса предшествуют записям для порта 5053.
- Прокси активен, но запросы завершаются по таймауту: проверьте исходящий доступ по HTTPS, имя резолвера и журналы прокси. Некоторые сети блокируют соединения DNS-over-HTTPS или ограничивают доступ к TCP-порту 443.
- Проверка прокси работает, но Pi-hole не получает ответа от вышестоящего сервера: убедитесь, что Pi-hole настроен точно на
127.0.0.1#5053, затем перезапустите pihole-FTL. Убедитесь, что стандартные флажки для проверки вышестоящего сервера не предоставляют автоматически альтернативный маршрут.
- После внесения изменений сама Ubuntu не сможет разрешать имена: эта настройка изменяет исходный код Pi-hole, а не код хоста
/etc/resolv.conf. Избегайте замены этого файла или отключения systemd-resolvedв качестве быстрого способа устранения неполадок.
Для отката восстановите настройки DNS-сервера, записанные в Pi-hole, и перезапустите систему pihole-FTL. Как только Pi-hole перестанет указывать на прокси, вы можете отключить или удалить его dnscrypt-proxyс помощью менеджера пакетов. Если этот сервер также разрешает свои собственные DNS-запросы через Pi-hole, сохраните локальный путь восстановления, прежде чем переключаться между службами.
Какой вариант подходит для вашей сети?
Используйте эту конфигурацию с одним хостом-прокси, если вам нужна централизованная фильтрация DNS в Pi-hole и зашифрованный трафик от Pi-hole к одному выбранному резолверу. Проверить это относительно легко, поскольку у прокси один локальный адрес и порт. Если вы запускаете Pi-hole в Docker, на другом сервере или в нескольких сетях, вам может потребоваться адрес контейнерной сети, а не адрес обратной связи, и вы должны ограничить доступ прослушивателя прокси, чтобы он не был доступен как открытый резолвер. Если вам нужна фильтрация на основе политик, идентификация для каждого устройства или зашифрованный DNS для роуминговых устройств вне дома, настройте эти клиенты или управляемый шлюз отдельно; восходящее соединение DoH в Pi-hole не шифрует автоматически путь каждого клиента к Pi-hole.
Наконец, помните, что маршрутизатор или клиент могут обойти Pi-hole, если он объявляет второй DNS-сервер. Для фильтрации в масштабах всей сети предоставляйте клиентам только адрес Pi-hole через DHCP и учитывайте как объявления DNS IPv6, так и IPv4. Проверьте это на нескольких устройствах после изменения настроек маршрутизатора, поскольку правильная настройка прокси на сервере не может предотвратить прямое использование клиентом другого DNS-сервера.
Официальные ссылки