Утечки DNS в OpenWRT с использованием dnsmasq и https-dns-proxy

Вопрос или проблема

list server '/mask.icloud.com/'
list server '/mask-h2.icloud.com/'
list server '/use-application-dns.net/'
list server '127.0.0.1#5054'
list doh_server '127.0.0.1#5054'

option bootstrap_dns '8.8.8.8,8.8.4.4'
option resolver_url 'https://dns.google/dns-query'
option listen_addr '127.0.0.1'
option listen_port '5054'
option user 'nobody'
option group 'nogroup'

option device 'eth1'
option proto 'dhcp'
option peerdns '0'
list dns '127.0.0.1'

dnsmasq: 192.168.1.193/52741 query[A] ip-api.com from 192.168.1.193
dnsmasq: 192.168.1.193/52741 forwarded ip-api.com to 127.0.0.1#5054
dnsmasq: 192.168.1.193/52741 reply ip-api.com is 208.95.112.1
dnsmasq: 192.168.1.193/56741 query[A] pis7wvy7iuum7lmpv0htbq447wy4zwib.edns.ip-api.com from 192.168.1.193
dnsmasq: 192.168.1.193/56741 forwarded pis7wvy7iuum7lmpv0htbq447wy4zwib.edns.ip-api.com to 127.0.0.1#5054
dnsmasq: 192.168.1.193/56741 reply pis7wvy7iuum7lmpv0htbq447wy4zwib.edns.ip-api.com is 85.10.196.124

Ответ или решение

Теория

DNS-протоколы играют ключевую роль в интернета взаимодействиях, переадресуя доменные имена в IP-адреса. OpenWRT — это мощная прошивка на основе Linux для маршрутизаторов, которая позволяет гибко настраивать маршрутизацию и сетевые утилиты. В контексте OpenWRT, dnsmasq и https-dns-proxy используются для управления DNS-запросами, обеспечивая более защищенные и приватные соединения.

DNS-утечки представляют собой случаи, когда DNS-запросы выходят за рамки настроенной безопасной конфигурации, раскрывая информации провайдеру или другим нежелательным сторонам. Утечки могут произойти, если DNS-запросы обходят прокси-сервера HTTPS или если используется запасной DNS-сервер, который раскрывает информацию.

Пример

В данной ситуации, вы используете OpenWRT с dnsmasq и https-dns-proxy для безопасной маршрутизации DNS-запросов через зашифрованный канал к серверу Google. Однако результаты запуска команды curl показывают, что происходит DNS-утечка — DNS-запросы некоторое время уходят к вашему провайдеру, а не через настроенное https-dns-proxy.

Конфигурации

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

1. dnsmasq:

   list server '/mask.icloud.com/'
   list server '/mask-h2.icloud.com/'
   list server '/use-application-dns.net/'
   list server '127.0.0.1#5054'
   list doh_server '127.0.0.1#5054'

   Здесь важно убедиться, что все запросы действительно уходят на локальный сервер 127.0.0.1 по порту 5054, который обрабатывается https-dns-proxy.

2. https-dns-proxy:

   option bootstrap_dns '8.8.8.8,8.8.4.4'
   option resolver_url 'https://dns.google/dns-query'
   option listen_addr '127.0.0.1'
   option listen_port '5054'
   option user 'nobody'
   option group 'nogroup'

   Возможно, стоит проверить, будь открыт или заблокирован доступа для https-dns-proxy, а также нет ли других программ, которые могут переопределить стандартное DNS-поведение.

3. WAN-интерфейс:

   option device 'eth1'
   option proto 'dhcp'
   option peerdns '0'
   list dns '127.0.0.1'

   Опция peerdns '0' указывает не использовать DNS от провайдера, однако важно удостовериться, что другие настройки на роутере не внесят изменений.

Применение

Чтобы предотвратить утечки, выполните следующие шаги:

• Перепроверьте конфигурацию OpenWRT, убедитесь, что все другие кеши или системы DNS отключены, которые могут отправлять запросы минуя https-dns-proxy.
• Подумайте об обновлении прошивки маршрутизатора, чтобы убедиться в наличии всех последних исправлений безопасности.
• Убедитесь, что файрволл OpenWRT настроен так, чтобы блокировать выходные запросы на все прочие DNS-сервера, за исключением определенных через https-dns-proxy.
• Рассмотрите возможность использования WireGuard или OpenVPN для дальнейшего шифрования вашего интернет-трафика.

Заключение

Решение проблемы DNS-утечек в OpenWRT требует комплексного подхода — корректной конфигурации dnsmasq и https-dns-proxy, а также тщательного анализа всех сетевых потоков. После внесения всех изменений обязательно проведите тщательные тесты, чтобы убедиться, что ни один запрос не обходит настроенные правила. Это позволит вам держать ваш сетевой трафик под контролем и защищать конфиденциальность.