Как узнать, какой процесс на самом деле отвечает за разрешение DNS-имен?

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

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

Я использую OpenWrt на маршрутизаторе GL-MT6000. У меня установлены AdGuardHome и VPN-клиент V2rayA/Xray. V2rayA подключается к моему VPS-серверу с Xray, он использует разделение трафика и настроен для работы в режиме tproxy, что предположительно означает, что как TCP, так и UDP трафик должны транслироваться через туннель. AGH настроен для использования https://dns.quad9.net/dns-query для разрешения доменов, в то время как 8.8.8.8 и 8.8.4.4 используются как начальные DNS-серверы.

Сначала я установил AGH, и он работал нормально. Когда я установил VPN-клиент, он работал около 15 минут, затем разрешение DNS перестало работать на всех рабочих станциях в локальной сети (192.168.1.1 — это их DNS-сервер). Nslookup на самом маршрутизаторе через 127.0.0.1 тоже не работал. Я перезапустил v2rayA, и это сразу исправило проблему. Затем через некоторое время проблема возникла снова.

Поэтому я изменил настройки AdGuardHome, чтобы использовать https://9.9.9.9/dns-query как DOH (по-видимому, Quad9 удалось настроить https без доменного имени), и это полностью исправило проблему. AGH и v2rayA работают без перерывов уже 2 дня. Однако я не уверен, как именно работает разрешение DNS на моем маршрутизаторе в данный момент. Перехватывает ли v2rayA его и передает на AGH, или AGH обрабатывает его полностью? У меня отключена опция Prevent DNS Spoofing в настройках v2rayA. Вот результат выполнения netstat -tunlp | grep :53:

tcp        0      0 :::53                   :::*                    LISTEN      2532/AdGuardHome
udp        0      0 :::53079                :::*                                16385/xray
udp        0      0 :::53                   :::*                                2532/AdGuardHome
udp        0      0 :::53852                :::*                                16385/xray

Похоже, что AGH слушает только на ipv6 порту 53. Но все мои рабочие станции в локальной сети используют ipv4, и 192.168.1.1 настроен как DNS-сервер, и разрешение имен работает! Я знаю, что DNS может использовать UDP, но я могу telnet 192.168.1.1 53 с моего ПК, и соединение устанавливается. Как это вообще возможно? Можете кто-нибудь объяснить, что здесь происходит?

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

Поиск процесса, ответственного за разрешение DNS, требует глубокого понимания вашей сетевой инфраструктуры и работы различных сетевых приложений. Рассмотрим вашу ситуацию в контексте работы OpenWrt, AdGuardHome и V2rayA/Xray VPN.

Теория

Адресное разрешение DNS является ключевой частью работы любой сети, и для его корректной настройки необходимо понимать, как взаимодействуют между собой различные сетевые сервисы и приложения. В вашем случае, вы используете несколько сложных инструментов: OpenWrt, AdGuardHome (AGH) и V2rayA вместе с Xray. Каждый из этих компонентов может влиять на процесс DNS-разрешения следующим образом:

AdGuardHome: Это средство блокировки рекламы и трекинг-сервисов, работающее как DNS-прокси. В вашем случае, оно настроено для работы с DoH (DNS over HTTPS), используя Quad9 в качестве основного DNS-сервиса и Google DNS в качестве резервного. Обычно AGH перенаправляет все запросы сети на свои собственные DNS-серверы, выполняя предварительную фильтрацию.
V2rayA/Xray VPN: Это VPN-клиент, предоставляющий функции прокси-сервера и транспортного туннелирования (tproxy), что позволяет туннелировать и TCP, и UDP трафик. В контексте работы VPN, разрешение DNS может происходить на стороне VPN-сервера, который в свою очередь может использовать свои собственные DNS-настройки.
OpenWrt: Это модифицированная операционная система для маршрутизаторов, обеспечивающая гибкость в настройке сетевых сервисов, включая DNS.

Пример

На практике, вы столкнулись с ситуацией, когда после установки V2rayA, DNS-разрешение перестало работать на всех устройствах в локальной сети через 15 минут. Однако перезапуск V2rayA временно решал проблему. Затем, после изменения DoH-сервиса на Quad9, проблема исчезла. Ваш вывод netstat показывает следующие процессы, работающие на порту 53:

2532/AdGuardHome слушает трафик как TCP, так и UDP на порту 53.
Xray (16385/xray) также слушает UDP трафик, но на произвольных портах 53079 и 53852.

Таким образом, AdGuardHome отвечает за обработку DNS-запросов через порт 53, несмотря на то что он настроен на работу с IPv6, а ваши устройства используют IPv4.

Применение

Для выяснения того, какой процесс обрабатывает разрешение DNS, и как было решено вашу проблему, выполните следующие шаги:

Лог-файлы: Проверьте журналы обоих сервисов (AdGuardHome и V2rayA/Xray), чтобы увидеть, какие DNS-запросы обрабатываются и предотвращаются. Логи помогут выяснить, перехватывает ли V2rayA DNS-запросы перед их отправкой в AdGuardHome.
Настройки VPN: Убедитесь, что настройка VPN корректно настроена для работы с вашим DNS-сервером. Если в настройках VPN включено перенаправление всех DNS-запросов через туннель, на стороне VPN-сервера могут использоваться собственные DNS-настройки.
Проверка сетевых обращений: Вы можете использовать инструменты мониторинга (такие как tcpdump или Wireshark), чтобы отследить реальные запросы DNS и маршруты, по которым они проходят, от вашего устройства до целевого DNS-сервера.
Консистентность конфигурации: Проверьте, чтобы все настройки DNS были последовательны и не конфликтовали друг с другом. Например, убедитесь, что AdGuardHome и VPN клиент работают в согласованном режиме, не перекрывают ли их конфигурации друг друга.

В вашей архитектуре AGH вероятнее всего является конечной точкой обработки DNS-запросов, благодаря добавлению поддержки DoH с Quad9. V2rayA могли временно блокировать запросы или перенаправлять их неверно, что было решено путем изменения на DNS-сервера Quad9. Это свидетельствует о важности правильной настройки DNS в сложной сетевой инфраструктуре.

Это объяснение поможет вам лучше понять взаимодействие ваших сетевых приложений и выявить корректные процессы для разрешения DNS в будущем.