Настройка совместной работы stubby и https-dns-proxy в OpenWrt

Настройка совместной работы stubby и https-dns-proxy требует правильной конфигурации цепочки DNS-сервисов в OpenWrt. Ваша текущая настройка работает только с DoH, что указывает на проблему в последовательности обработки DNS-запросов между этими сервисами.

Содержание

• Основные принципы совместной работы stubby и https-dns-proxy
• Конфигурация stubby: необходимые изменения
• Конфигурация https-dns-proxy: правильные настройки
• Интеграция с dnsmasq в OpenWrt
• Проверка работы и устранение неполадок

Основные принципы совместной работы stubby и https-dns-proxy

Правильная настройка совместной работы stubby и https-dns-proxy в OpenWrt требует понимания правильной цепочки обработки DNS-запросов. Согласно официальной документации, правильная последовательность должна быть следующей: клиенты → dnsmasq → https-dns-proxy → stubby → внешние DNS-серверы.

В вашей текущей конфигурации проблема заключается в неправильной организации этой цепочки. Когда вы используете оба сервиса одновременно, они должны работать последовательно, а не параллельно. Stubby должен выступать в качестве upstream-сервера для https-dns-proxy, а не наоборот.

Для корректной работы обоих сервисов необходимо:

1. Настроить dnsmasq для перенаправления запросов на https-dns-proxy
2. Настроить https-dns-proxy для использования stubby в качестве upstream-сервера
3. Убедиться, что stubby правильно настроен для связи с внешними DNS-серверами через DoT

Такая конфигурация позволяет использовать преимущества обоих протоколов: DoH для шифрования трафика и DoT для дополнительной безопасности и совместимости.

Конфигурация stubby: необходимые изменения

Ваша текущая конфигурация stubby в целом правильна, но требует нескольких важных изменений для корректной работы с https-dns-proxy. Ключевое изменение касается настройки прослушивания адресов:

# Текущая конфигурация (частично корректна)
listen_addresses:
 - 127.0.0.1@5453
 - 0::1@5453

# Рекомендуемая конфигурация
listen_addresses:
 - 127.0.0.1@5453

Основное изменение - удаление IPv6-адреса, если он вам не требуется. Это упростит конфигурацию и избежит потенциальных проблем с IPv6.

Ваша настройка upstream_recursive_servers выглядит правильно и использует Cloudflare DoT-серверы, что является хорошим выбором для совместной работы:

upstream_recursive_servers:
 - address_data: 2606:4700:4700::1111
 tls_auth_name: "cloudflare-dns.com"
 - address_data: 2606:4700:4700::1001
 tls_auth_name: "cloudflare-dns.com"
 - address_data: 1.1.1.1
 tls_auth_name: "cloudflare-dns.com"
 - address_data: 1.0.0.1
 tls_auth_name: "cloudflare-dns.com"

Важно убедиться, что в файле /etc/config/stubby установлена опция option manual '1', чтобы stubby использовал именно этот файл конфигурации, а не UCI-систему.

Также проверьте, что сервис stubby запускается автоматически при загрузке системы. Для этого выполните команду:

/etc/init.d/stubby enable

Конфигурация https-dns-proxy: правильные настройки

Ваша конфигурация https-dns-proxy содержит несколько критических ошибок, которые мешают правильной работе с stubby. Основные проблемы:

1. Проблема с прослушиванием адресов
2. Некорректная настройка upstream-серверов
3. Отсутствие правильной интеграции

Вот как должна выглядеть исправленная конфигурация:

user=nobody
bogus-priv
no-negcache
clear-on-reload
bind-dynamic
listen-address=192.168.1.1
listen-address=127.0.0.1
min-port=4096
cache-size=1536
expand-hosts
edns-packet-max=1280

###use https
no-resolv
server=127.0.0.1#5453 # Используем stubby в качестве upstream

Ключевые изменения:

1. Строка server=127.0.0.1#5053 заменена на server=127.0.0.1#5453. Это самое важное изменение - https-dns-proxy должен перенаправлять запросы на stubby, который слушает порт 5453, а не на себя.

2. Удалена дублирующая настройка. В текущей конфигурации https-dns-proxy пытается использовать сам себя в качестве upstream-сервера, что создает бесконечный цикл.

3. Проверьте, что https-dns-proxy правильно настроен на использование только одного upstream-сервера. В этом случае им должен быть stubby.

После внесения изменений перезапустите оба сервиса:

/etc/init.d/stubby restart
/etc/init.d/https-dns-proxy restart

Проверьте, что оба сервиса работают без ошибок в логах:

logread | grep -E "stubby|https-dns-proxy"

Интеграция с dnsmasq в OpenWrt

Для полноценной работы цепочки dnsmasq → https-dns-proxy → stubby необходимо правильно настроить dnsmasq. Ваша текущая конфигурация не показывает настройки dnsmasq, но они критически важны.

Вот основные изменения, которые нужно внести в /etc/config/dhcp:

config dhcp 'dnsmasq'
 option server '127.0.0.1#5053' # Перенаправляем все запросы на https-dns-proxy
 option noresolv '1'
 option localservice '0'
 option filterwin2k '0'
 option localise_queries '1'

Ключевые моменты:

1. server '127.0.0.1#5053' - dnsmasq должен перенаправлять все DNS-запросы на https-dns-proxy, который слушает порт 5053.

2. noresolv '1' - отключаем использование стандартных DNS-серверов.

3. localservice '0' - разрешаем удаленным запросам использовать этот DNS-сервер.

4. localise_queries '1' - добавляем локальный домен к коротким именам.

Также убедитесь, что в /etc/config/network корректно настроен DNS для локальной сети:

config dhcp 'lan'
 option interface 'lan'
 option start '100'
 option limit '150'
 option leasetime '12h'
 option dhcpv6 'server'
 option ra 'server'
 option ra_management '1'
 option dns '127.0.0.1'

После внесения изменений перезапустите dnsmasq:

/etc/init.d/dnsmasq restart

Проверьте работу цепочки с помощью команды:

nslookup example.com 127.0.0.1

Запрос должен пройти через всю цепочку: dnsmasq → https-dns-proxy → stubby → внешний DNS-сервер.

Проверка работы и устранение неполадок

После внесения всех изменений необходимо тщательно проверить работу системы. Вот последовательность шагов для диагностики:

1. Проверка статуса сервисов

Убедитесь, что все сервисы работают:

/etc/init.d/stubby status
/etc/init.d/https-dns-proxy status
/etc/init.d/dnsmasq status

Все три сервиса должны быть в состоянии “running”.

2. Проверка логов

Проверьте логи на наличие ошибок:

logread -f | grep -E "stubby|https-dns-proxy|dnsmasq"

Ищите сообщения об ошибках, особенно связанные с портами или соединениями.

3. Тестирование цепочки

Проверьте работу каждого сервиса по отдельности:

Проверка stubby:

dig @127.0.0.1 -p 5453 example.com

Проверка https-dns-proxy:

dig @127.0.0.1 -p 5053 example.com

Проверка полной цепочки:

dig @127.0.0.1 example.com

4. Проверка DNSSEC

Убедитесь, что DNSSEC работает правильно:

dig @127.0.0.1 -p 5453 example.com DNSKEY
dig @127.0.0.1 -p 5053 example.com DNSKEY
dig @127.0.0.1 example.com DNSKEY

5. Распространенные проблемы и решения

Проблема: “Connection refused” при обращении к stubby

• Решение: Проверьте, что stubby слушает правильный порт (5453) и не блокирует подключения.

Проблема: Циклические перенаправления

• Решение: Убедитесь, что в конфигурации нет циклов (например, https-dns-proxy не перенаправляет на сам себя).

Проблема: Медленная работа

• Решение: Уменьшите количество upstream-серверов в stubby или попробуйте использовать только один тип протокола (DoT или DoH).

Проблема: IPv6 не работает

• Решение: Проверьте поддержку IPv6 в вашей сети и настройках интерфейсов.

6. Альтернативные подходы

Если совместная работа обоих сервисов вызывает сложности, рассмотрите альтернативные варианты:

1. Использовать только один сервис - либо stubby (DoT), либо https-dns-proxy (DoH). Это упростит настройку.

2. Использовать разные порты для разных протоколов - например, перенаправлять часть трафика на DoT, а часть на DoH.

3. Использовать балансировку нагрузки - если у вас несколько устройств, можно распределить нагрузку между ними.

Источники

1. Официальная документация https-dns-proxy — Руководство по правильной настройке цепочки сервисов в OpenWrt: https://docs.openwrt.melmac.ca/https-dns-proxy/

2. Обсуждение на форуме OpenWrt — Сравнение https-dns-proxy и stubby, преимущества каждого подхода: https://forum.openwrt.org/t/https-dns-proxy-vs-stubby/52446

3. Документация по stubby — Официальные рекомендации по настройке stubby с поддержкой DNSSEC: https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md

4. Настройка DNS-over-TLS на OpenWrt — Подробное руководство по настройке DNSSEC и интеграции с dnsmasq: https://candrews.integralblue.com/2018/08/dns-over-tls-on-openwrt-18-06/

5. Официальный репозиторий https-dns-proxy — Документация и примеры конфигурации: https://github.com/aarond10/https_dns_proxy

6. Пример рабочей конфигурации — Конкретный пример настройки stubby с работающими DoT-серверами: https://gist.github.com/Juul/8771c110c33fa24a2423e5087e6164fd

Заключение

Настройка совместной работы stubby и https-dns-proxy в OpenWrt требует тщательного соблюдения цепочки обработки DNS-запросов: клиенты → dnsmasq → https-dns-proxy → stubby → внешние серверы. Основные исправления в вашей конфигурации включают изменение upstream-сервера в https-dns-proxy на 127.0.0.1#5453 (stubby) и правильную настройку dnsmasq для перенаправления запросов на https-dns-proxy.

Хотя технически такая настройка возможна, многие пользователи предпочитают использовать только один тип DNS-протокола (либо DoT через stubby, либо DoH через https-dns-proxy) для упрощения администрирования и снижения нагрузки на систему. Выбор зависит от ваших конкретных требований к безопасности и совместимости с различными сетями.