8.7. Разрешение возможной проблемы c DNS

Допустим, мы все сделали по рецепту, но результатов нет. Попробуем представить примерный сценарий поиска и устранения ошибки.

Исходной точкой здесь является ситуация, когда по IP-адресам компьютеры можно найти, а по именам — нет. Например, команда ping с рабочей станции успешно тестирует адрес 192.168.1.2, а для имени server1 выдает сообщение «unknown host server1».

Проведем еще один тест с программой nslookup:

# nslookup server1

Ответ программы:

Server: 212.48.000.00

Address: 212.48.000.00#53

** server can't find server1: NXDOMAIN

В данном случае 212.48.000.00 — адрес DNS провайдера. Значит, разрешение имен выполняется, но без нашего DNS. А чужой DNS сервер нам, разумеется, ни к чему, он нам помочь не может, потому что ничего не знает о нашей сети.

Может быть, проблема в клиенте? Проверим местный файл /etc/resolv.conf:

# Generated by dhcpcd for interface eth0

search ofis.local

nameserver 192.168.1.2

nameserver 212.48.000.00

nameserver 212.48.100.00

Нет, тут все нормально. Во-первых, мы получили настройки по DHCP.

Во вторых, все адреса DNS имеются. Как мы уже знаем, первый же DNS провайдера ответил нам с полным основанием, что он ничего не знает о хосте server1 — претензий быть не может. Это еще одно подтверждение, что местный DNS не работает.

Тут уместно вспомнить о порте 53. Именно через него идут DNS-запросы. Может быть, порт закрыт? Для проверки нам потребуется программа nmap (которая есть в дистрибутиве).

Тестируем порт сервера со станции:

# nmap -p 53 192.168.1.2

Ответ:

Interesting ports on 192.168.1.2:

PORT STATE SERVICE

53/tcp closed domain

Ну вот, мы уже приблизились к проблеме. Порт закрыт. Правда, причин для такого сообщения может быть несколько, например:

1. Обмен по этому порту запрещен в настройках сервера.

2. Обмен по порту разрешен, но ни одна программа с портом не работает.

Для выяснения окончательной причины надо подключаться в консоль сервера по SSH или пересесть к монитору сервера (кому как удобнее).

Режим работы портов описан в файле /etc/sysconfig/iptables.

Разобраться в записях несложно, указаны порты, сетевые протоколы, режимы. Опция ACCEPT разрешает работу через порт, опции DROP или REJECT — запрещают. Соответственно, нам надо проследить, чтобы в строках с портом 53 не стояло REJECT. После редактирования файла службу iptables надо перезапустить.

Включить порт можно и командно. Включим его по максимуму, хотя многие серверы DNS протокол tcp не используют и он отключается.

#iptables -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT

#iptables -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT

#iptables -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

#iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT

#service iptables save

#service iptables restart

Мы должны убедиться, что теперь порт на сервере открыт. Даем команду в консоли сервера:

# nmap -p 53 127.0.0.1

Получаем ответ:

Interesting ports on server1.ofis.local (127.0.0.1):

PORT STATE SERVICE

53/tcp open domain

Порт открыт, но ничего не работает. Значит, дело в самом dnsmasq или его настройках. То, что мы могли набрать с ошибкой имя server1 — можно исключить, ведь отклика от сервера нет вообще.

Остается обратиться к настройкам dnsmasq и внимательно их изучить. И тут уместно вспомнить о таком параметре, как interface. По умолчанию dnsmasq работает только с одним ethernet-интерфейсом (eth0). Существуют параметры для выбора интерфейса. Это разумно, потому что один из интерфейсов может «смотреть наружу», а другой — в локальную сеть. А у нас (к примеру) сетевой кабель подключен к интерфейсу eth1. Значит, надо добавить в файл /etc/dnsmasq.conf параметр:

interface=eth1

Перезапускаем службу dnsmasq.

Открываем на клиентском компьютере Konqueror и набираем адрес интерфейса сервера https://server1:8080. Web-интерфейс запустился — значит, мы решили проблему.

Из этого, кстати, следует, что если на сервере есть два разъема для подключения сетевого кабеля, нельзя отключить кабель от одного интерфейса, подключить к другому и не потерять функциональность сервера. Некоторые возможности без дополнительной настройки перестанут работать, даже если оба интерфейса исправны.

© Алексей Гончаров, 2010