☰

DNSMASQ не отвечает на запросы DNS из маршрутизируемой подсети

tag-icon • tag-icon networking dnsmasq
DNSMASQ не отвечает на запросы DNS из маршрутизируемой подсети

У меня есть две подсети, соединенные вместе с помощью двух точек доступа DD-WRT - Удаленная точка доступа находится в режиме Client-Routed, поэтому у нее есть отдельная подсеть, ее IP-адреса - 192.168.2.1/24 и 192.168.0.5/24. Локальная точка доступа находится в режиме AP. Настройки DHCP DD-WRT находятся в режиме пересылки для удаленной точки доступа.

У меня есть настройка DNSMASQ в первой подсети на IP 192.168.0.2/24, он также является DHCP-сервером для второй подсети — это работает, и мои удаленные клиенты получают правильный маршрутизатор. Машина DNSMasq может пинговать ПК во второй подсети, и обратное тоже верно. Я также могу RDP с ПК в первой подсети на ПК во второй подсети — так что мне кажется, что большинство коммуникаций между первой и второй подсетями работают.

Моя проблема в том, что DNSMasq не отправляет DNS-ответы во вторую подсеть - в первую подсеть он работает. Может кто-нибудь подсказать, почему?

Следует отметить, что маршрут для второй сети находился на шлюзовом устройстве (192.168.0.1), но я обнаружил, что это приводило к потере большого количества пакетов, поэтому к каждому устройству первой подсети был добавлен локальный статический маршрут для второй подсети.

route add 192.168.2.0 mask 255.255.255.0 192.168.0.5

На данный момент мне еще предстоит проверить назначенный DHCP-маршрут из-за моей текущей проблемы.

Это набросок того, что у меня есть.Эскиз сети

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

# Configuration file for dnsmasq.
domain-needed
bogus-priv
addn-hosts=/etc/dnsmasq.hosts
# so don't use it if you use eg Kerberos, SIP, XMMP or Google-talk. This option only affects forwarding, SRV records originating for dnsmasq (via srv-host= lines) are not
# suppressed by it.
filterwin2k

dhcp-range=set:house,192.168.0.1,192.168.0.254,infinite
dhcp-range=set:backyard,192.168.2.1,192.168.2.254,infinite

# Change this line if you want dns to get its upstream servers from somewhere other that /etc/resolv.conf
resolv-file=/var/run/dnsmasq/resolv.conf
# server=61.9.134.49
# server=61.9.133.193 setup the default gateway
dhcp-option=tag:house,option:router,192.168.0.1
dhcp-option=tag:backyard,option:router,192.168.2.1

# option 42?
dhcp-option=option:ntp-server,192.168.0.2
expand-hosts
domain=wilson.lan
dhcp-range=192.168.0.100,192.168.0.150,12h
dhcp-range=192.168.2.100,192.168.2.150,255.255.255.0,12h


# DO NOT Set The route to that network Done on Gateway
#dhcp-option=121,192.168.2.0/24,192.168.0.5
#Send microsoft-specific option to tell windows to release the DHCP lease when it shuts down. Note the "i" flag,
#  to tell dnsmasq to send the value as a four-byte integer - that's what microsoft wants. See
# http://technet2.microsoft.com/WindowsServer/en/library/a70f1bb7-d2d4-49f0-96d6-4b7414ecfaae1033.mspx?mfr=true
dhcp-option=vendor:MSFT,2,1i
# Set the DHCP server to authoritative mode. In this mode it will barge in and take over the lease for any client
# which broadcasts on the network, whether it has a record
# of the lease or not. This avoids long timeouts when a machine wakes up on a new network.
# DO NOT enable this if there's the slightest chance that you might end up
# accidentally configuring a DHCP server for your campus/company accidentally.
# The ISC server uses the same option, and this URL provides more information:
# http://www.isc.org/files/auth.html
dhcp-authoritative
# Log lots of extra information about DHCP transactions.
log-dhcp

решение1

Итак, после прочтения руководства мне нужно добавить что-то, чтобы переопределить параметр по умолчанию, отвечающий только локальным подсетям (--local-service), параметр по умолчанию, который не имеет отрицания, поэтому, например, я попробовал

listen-address=192.168.0.2

Однако, как видно из строки resolve.conf

nameserver 127.0.0.1

мои изменения остановили DNSMASQ отвечать на запросы от самого себя - так что, как ни странно, DNS-сервер больше не мог разрешить ни одно DNS-имя, в то время как все другие машины успешно использовали его как DNS-сервер. Я исправил это, добавив следующую строку вместо этого

listen-address=192.168.0.2,127.0.0.1

так как я не смог придумать простого способа исправить то, что делал resolveconf

Связанный контент