Вопрос или проблема
Я пытаюсь запустить две инстанции dnsmasq на Raspberry Pi, я уже довольно далеко продвинулся. В данный момент я пытаюсь настроить так, чтобы первый сервер dnsmasq перенаправлял любые запросы, на которые не знает ответа, ко второму серверу, но это работает только если я использую dig <адрес> @127.0.0.1
. Использование внешних адресов любого интерфейса или запрос с другой машины не дает результата.
Запрос к любому из серверов напрямую дает нужный результат, но попытки заставить первый сервер перенаправлять результаты со второго… не удались.
Конфигурация для инстанции A (lan):
root@Raspberry-server:~# cat /etc/dnsmasq/dnsmasq.conf
port=53
except-interface=eth0.1
bind-interfaces
no-hosts
# изменение размера кеша не имеет значения
# cache-size=5000
cache-size=0
# раскомментируйте, чтобы забыть о ответах 404
# no-negcache
# resolv-file=/etc/dnsmasq/resolv.lan.conf
# no-poll
no-resolv
strict-order
server=192.168.1.13
auth-server=raspberry.lan,eth0
auth-zone=lan,192.168.1.0/24
host-record=raspberry.lan,192.168.1.11
host-record=htpc.lan,192.168.1.10
host-record=tom.lan,192.168.1.12
Конфигурация для инстанции B (глобальная):
root@Raspberry-server:~# cat /etc/dnsmasq/dnsmasq.blocker.conf
port=53
bind-interfaces
listen-address=192.168.1.13
no-hosts
addn-hosts=/etc/dnsmasq/blocked.host
cache-size=100000
# раскомментируйте, чтобы забыть о ответах 404
# no-negcache
resolv-file=/etc/dnsmasq/resolv.blocker.conf
# no-poll
strict-order
Статусный лог инстанции A:
systemd[1]: Запуск легковесного DNS-сервера DNSMasq...
dnsmasq[1651]: dnsmasq: проверка синтаксиса ОК.
dnsmasq[1656]: запущен, версия 2.76 кеш отключен
dnsmasq[1656]: параметры времени компиляции: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
systemd[1]: Запущен легковесный DNS-сервер DNSMasq.
dnsmasq[1656]: использует nameserver 192.168.1.13#53
Включите логирование запросов (log-queries
) и используйте dig/nslookup против каждого сервера по очереди.
В вашей текущей настройке сервер B, похоже, никогда не будет запрашивать информацию у другого сервера. Сервер A должен передавать запросы серверу B, когда сам не может на них ответить.
Серверы dnsmasq пытаются разрешить запрос локально, перенаправляя только если это необходимо. Включение логирования запросов должно показать, к какому серверу вы обращаетесь и когда, а также что они делают с этим запросом.
Посмотрите на /etc/default/dnsmasq
. В некоторых дистрибутивах этот файл запрещает чтение файлов “resolv.conf” кроме /etc/resolv.conf
.
Ответ или решение
Для решения проблемы с перенаправлением запросов DNS между двумя экземплярами dnsmasq на Raspberry Pi, более подробно рассмотрим настройки конфигурации и возможные ошибки.
Шаги для решения проблемы
-
Проверка конфигурации dnsmasq:
Убедитесь, что в конфигурационном файле для экземпляра A (локальный) правильно указаны настройки перенаправления на экземпляр B (глобальный).В конфигурации для экземпляра A (
/etc/dnsmasq/dnsmasq.conf
) у вас указано:server=192.168.1.13
Это означает, что экземпляр A будет перенаправлять запросы на ваш экземпляр B, который слушает на адресе
192.168.1.13
. Убедитесь, что экземпляр B активно работает и принимает запросы. -
Включение логирования запросов:
Для диагностики проблемы полезно включить логирование запросов в конфигурации каждого экземпляра, добавив строку:log-queries
Это позволит вам увидеть, какие запросы обрабатываются, и куда они направляются. Логи можно просмотреть для выявления проблем с маршрутизацией запросов.
-
Проверка интерфейсов и привязки:
Убедитесь, чтоdnsmasq
правильно привязан к сетевым интерфейсам. Используйте параметрbind-interfaces
, но также проверьте, слушает ли экземпляр A на корректном интерфейсе. -
Проверка статуса экземпляров:
Используйте командуsystemctl status dnsmasq
для проверки статуса обоих экземпляров. Убедитесь, что они запущены без ошибок. -
Проверка файла /etc/default/dnsmasq:
На некоторых системах файл/etc/default/dnsmasq
управляет поведением dnsmasq. Убедитесь, что он не ограничивает чтение файлаresolv.conf
, и проверьте его настройки, которые могут влиять на работу dnsmasq. -
Тестирование с использованием dig:
При тестировании используйте командуdig
для проверки запросов:dig @<IP_экземпляра_A> <имя_домена>
и затем
dig @192.168.1.13 <имя_домена>
Сравните результаты запросов, чтобы убедиться, что экземпляр A корректно перенаправляет запросы на экземпляр B.
-
Проверка правил NAT и брандмауэра:
Убедитесь, что между экземплярами A и B нет правил NAT или блокировок на уровне брандмауэра, которые могут помешать передаче запросов. Проверьте настройки iptables или ufw, если они включены.
Заключение
Если после всех вышеперечисленных действий проблема не устранена, приведенные выше шаги и логи должны помочь вам в диагностике. Например, если экземпляр A обращается к экземпляру B, но не получает ответа, это может свидетельствовать о проблеме в конфигурации самого экземпляра B, либо о том, что обработка запросов идет некорректно из-за локальных кешей или других настроек.
Обязательно проверьте документацию по dnsmasq и сопутствующие материалы, чтобы удостовериться, что вы используете актуальные параметры и конфигурации.