Содержание

Вопрос или проблема
Итог:
Ответ или решение
Почему DNS-серверы не обрабатывают запросы от клиентов
1. Понимание конфигурации и работы DNS
1.1. Проблемы с сетью
1.2. Конфигурация Unbound
1.3. Программное обеспечение
2. Проверка клиентских запросов
2.1. Использование Wireshark
2.2. Проверка с клиентской стороны
3. Заключение

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

Обновление: Я узнал, что это ненормально, что я не могу найти IP моего собственного маршрутизатора, используя свое доменное имя, если устройство, которое ищет мой порт-проброшенный сервер, также находится за маршрутизатором. Это влияет на текущую ситуацию?

Я использую unbound на Raspberry Pi. Я пробовал dnsmasq, чтобы посмотреть, не в приложении ли дело, но он тоже не работал.

Я вижу с помощью wireshark, что мой запрос идет с моего компьютера на Raspberry.
Я запускаю tcpdump на сервере, он сразу показывает обратный запрос для IP клиента.
Я пытаюсь включить логирование verbose:5 для сервиса unbound, но, похоже, он не осведомлен о запросах, которые пришли через локальную сеть.
Тем не менее, когда я выполняю dig mollevi.test @pi.lan.ip.address на самом сервере, ответ правильный.

Я пробовал

включать и отключать мой vpn tailscale
использовать настройку unbound с полным доступом и нацеленную на конкретные адреса
без межсетевых экранов в локальной сети
клиенты как на Linux, так и на Windows (не VM)
как в локальной сети, так и по мобильным данным

Я мог пинговать порт 80 в любом направлении с каждой упомянутой настройкой, но в логах unbound всё еще нет информации о DNS запросах, которые не идут от Raspberry к самому себе. Dnsmasq делал то же самое, но мне хотелось бы использовать unbound, если это возможно. Вот мои конфигурации:

server:
verbosity: 5
interface: pi.lan.ip.address
port: 53
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
access-control: 192.168.1.0/24 allow
root-hints: "/etc/unbound/root.hints"

local-zone: "mollevi.test." static
local-data: "mollevi.test. 10800 IN A 127.0.0.1"
logfile: "/etc/unbound/unbound.log"

Когда я использовал tailscale, я изменил IP адреса соответственно.*

sudo netstat -ptuln | grep :53 – Я немного изменил конфигурацию и отключил ipv6, но вот обновление.

tcp  0  0  pi.lan.ip.address:53  0.0.0.0:*  LISTEN  27927/unbound
udp  0  0  pi.lan.ip.address:53  0.0.0.0:*          27927/unbound

это произошло на машине под управлением Windows:

PS> nslookup mollevi.test pi.lan.ip.address
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  pi.lan.ip.address

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Итог:

Windows/Linux -> netstat/dig -> wireshark(client->server) ☑ -> Raspberry PI -> tcpdump☑ -> unbound.log☒ -> wireshark(server->client) ☒ -> запрос истек
Raspberry -> dig mollevi.test @pi.lan.ip.address -> правильный ответ

Спасибо за любые советы.

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

Почему DNS-серверы не обрабатывают запросы от клиентов

Ваша ситуация с DNS-сервером на Raspberry Pi, который не получает запросы от клиентов, имеет несколько возможных причин. Давайте подробно рассмотрим возможные проблемы и их решения, основываясь на предоставленной вами информации.

1. Понимание конфигурации и работы DNS

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

1.1. Проблемы с сетью

Локальные запросы: Вы отметили, что если устройство, которое ищет IP-адрес вашего сервера за NAT, тоже находится за роутером, это может повлиять на ситуацию. DNS-запросы, исходящие из локальной сети, иногда блокируются маршрутизатором.
Проверка подключения: Убедитесь, что клиенты в вашей локальной сети действительно могут "увидеть" Raspberry Pi. Попробуйте выполнить ping pi.lan.ip.address с клиентов. Если ICMP-пинг успешен, сайт возможен дальнейший анализ.

1.2. Конфигурация Unbound

Interface настройки: Убедитесь, что через unbound настроено правильное значение для параметра interface:. Он должен указывать на IP-адрес, по которому ваш Raspberry Pi доступен в локальной сети.
Control access: Ваша директива access-control выглядит правильно и разрешает запросы из диапазона 192.168.1.0/24. Однако убедитесь, что IP-адреса клиентов действительно попадают в этот диапазон.
Логи Unbound: Степень детализации логирования можно увеличить для диагностики, установив verbosity: 5 — это хорошо, но стоит проверить, не фильтруется ли вывод логов.

1.3. Программное обеспечение

Вы упомянули, что тестировали dnsmasq, но это не решило проблему. Если вы хотите использовать unbound, попробуйте следующее:

Перезапуск Unbound: Иногда достаточно перезапустить сервис после изменения конфигурации.
Зависимости: Убедитесь, что все необходимые зависимости для unbound установлены и актуализированы на Raspberry Pi.

2. Проверка клиентских запросов

2.1. Использование Wireshark

Вы использовали Wireshark для отслеживания пакетов и заметили, что запросы от клиентов до Raspberry Pi проходят. Однако, если на уровне unbound запросы не фиксируются, проблема может быть в его недоступности или в неправильной маршрутизации.

2.2. Проверка с клиентской стороны

nslookup: Команда nslookup mollevi.test pi.lan.ip.address возвращает таймауты, что указывает на возможные проблемы с доступностью DNS-сервера. Убедитесь, что Windows-клиенты настроены на использование нужного DNS-сервера.
Проверка настроек DNS: Убедитесь, что на клиентских устройствах в настройках сети указан ваш Raspberry Pi в качестве DNS-сервера.

3. Заключение

Ваши шаги по устранению неполадок уже довольно обширные, включая тестирование различных клиентов и отключение межсетевых экранов. Убедитесь, что Raspberry Pi доступен и правильно конфигурирован для обработки клиентских запросов. Проблемы с NAT и маршрутизацией могут также оказывать влияние. Даже если вы переходите на tailscale, убедитесь, что все необходимые порты открыты и правильно направлены.

Если все вышеперечисленное не решает проблему, желательно проверить другие механизмы диагностики, такие как наложение на маршрутизаторы или использование альтернативных DNS-серверов, чтобы изолировать источник проблемы.

DNS-серверы не получают никаких запросов, инициированных клиентом.