Правильная настройка системы разрешения имен в Ubuntu
Разрешение имен - преобразование имени компьютера, воспринимаемого человеком, в цифровой адрес компьютера.
Постоянно возникающая проблема разрешения имен в Ubuntu, из-за неполной конфигурации "из коробки", доставляет массу неудобств при взаимодействии в сетях, в частности с микросервером, с windows компьютерами.
1. Невозможность сделать "пинг" по имени хоста.
root@microserver#ping mir
ping: unknown host mir
root@mir: ping microserver
ping: unknown host microserver
2. Трудности просмотра через графические программы (Nautilus). Требуется указывать ip-адрес, что влечёт за собой его предварительное выяснение.
3. Неработающий просмотр сети в Nautilus.
Данная заметка написана для окончательного понимания процесса именования и разрешения имен в Ubuntu.
Правильная настройка включает в себя как настройку микросервера так и клиентов, т.к. многие возможности недоступны "из-коробки".
Что можно получить при правильной настройке разрешения имен в Ubuntu 12.04 микросервера
Автоматическую конфигурацию клиентов сети, проводных и беспроводных, с корректным заданием шлюза в сеть интернет.
Корректно работающий просмотр сетей в Windows и Ubuntu.
Автоматическую доступность всех компьютеров и устройств по их именам. по NetBIOS-именам в домашней локальной сети, домашней беспроводной сети.
Работающий кэширующий DNS сервер в домашней сети
Дополнительные возможности локальных соединений (link-local) точка-точка (ad-hoc) проводных клиентов без сервера в сети.
Сервисы обмена файлами, сетевые принтеры.
Автоматически публикуемые сервисы mDNS, что на пользовательском уровне обеспечивает удобство в разных программах, таких как eKiga, Nautilus.
Например:
 |
| Навигатор Avahi -SSH. Список устройств с доступом SSH |
 |
| Броузер Nautilus видит опубликованные сервисы Avahi |
Имя компьютера - Hostname
Имя компьютера(hostname) задается в файле /etc/hostname
Процесс разрешения имен в Ubuntu - name resolve order
Файл /etc/nssswitch.conf конфигурирует способ, которым следуют стандартные библиотечные процедуры разрешения имен, будь то имена компьютеров (hosts), пользователей (users), группы (groups).
Каждая база данных имен может иметь разнообразные источники - текстовые файлы (/etc/hosts), локальные базы данных, DNS, NIS, WINS, LDAP и пр.
Так сказать - исторические наслоения способов разрешения имен.
Посмотрим файл: /etc/nsswitch.conf подсистемы Name service switch
root@microserver#cat /etc/nsswitch.conf
При установленном сервере mDNS (avahi-daemon)
...
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
...
Минимальный порядок опроса:
...
hosts: files dns
...
Для разрешения windows-имен компьютеров:
...
hosts: files wins dns
...
Первое простейшее решение - /etc/hosts
Простой текстовый файл /etc/hosts сопоставляющий имя компьютера (hostname) и ip-адрес. Аналог листка бумаги с записанными ip-адресами и именем компьютера.
Если на микросервере внести запись в /etc/hosts и на настольном компьютере проделать тоже самое, то проблема решиться. Вот выдержка из файлов:
root@microserver#cat /etc/hosts
...
192.168.3.8 mir
...
root@mir#cat /etc/hosts
...
192.168.3.1 microserver
...
После этого, пинги по имени компьютера проходят в обе стороны.
root@microserver#ping mir
PING mir (192.168.3.8) 56(84) bytes of data.
64 bytes from mir (192.168.3.8): icmp_req=1 ttl=64 time=0.158 ms
...
root@mir: ping microserver
PING microserver (192.168.3.1) 56(84) bytes of data.
64 bytes from microserver (192.168.3.1): icmp_req=1 ttl=64 time=0.299 ms
...
Главный недостаток этого способа - это ip-адрес, который может меняться при каждой загрузке, если настроено динамическое получение, посредством dhcp. Исправляется это выделением постоянного ip-адреса настольному компьютеру на сервере dhcp, с помощью директивы host (dhcp-host) в конфигурационном файле.
Второй недостаток в том, что при увеличении сети, для нормального разрешения имен, надо на каждом компьютере добавлять информацию о каждом компьютере сети, что весьма трудоемко и чревато пропусками.
Что и ограничивает применение этого способа в небольших одноранговых сетях со статической ip-адресацией и в тестовых условиях недоступности динамических сервисов.
Конфигурация без усилий. Avahi - ZeroConf - mDNS - .local
Avahi - свободная реализация разделов "DNS Service Discovery" и "Multicast DNS" спецификации "Zeroconf Networking".
Multicast DNS (mDNS) - децентрализованная широковещательная доменная система имен. Была разработана в компании Apple, под кодовым именем Bonjour. Предназначена для автоматического конфигурирования сетевого интерфейса при соединениях без выделенного сервера, т.н. link-local. Например, соединение двух компьютеров посредством ehternet-интерфейса, простым ethernet-проводом, в результате произойдет автоконфигурация интерфейсов и компьютеры будут иметь dns имена вида host.local. Использование этой технологии позволит обойтись без ручного вмешательства в сетевые настройки.
Демон mDNS отвечает на порту 5353 на широковещательные сообщения по адресу 224.0.0.251. Если при установленном и настроенном демоне avahi-daemon, команды ping mir.local или microserver.local не работают, то возможно проблема в настройках брендмауэра.
Домен .local является доменом по умолчанию, для mDNS.
В настольной Ubuntu сервис avahi устанавливается по умолчанию и работает. Настольный компьютер отзывается по адресу: mir.local с любого компьютера оборудованного avahi.
В серверной версии Ubuntu требуется установка пакета avahi-daemon.
root@microserver# apt-get install avahi-daemon
После установки, микросервер также становиться доступным по адресу: microserver.local
Есть конфигурационный файл: /etc/default/avahi-daemon, но настроек в нём нет.
Основной конфигурационный файл: /etc/avahi/avahi-daemon.conf
Также доступны: /etc/avahi/hosts и папка для статически определимых сервисов /etc/avahi/services/
Для быстрой публикации сервисов роутеров и пр. оборудования, без поддержки avahi, надо создать xml-файл вида в папке /etc/avahi/services/.
root@microserver#cat /etc/avahi/services/bigpond.service
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">Bigpond router</name>
<service>
<type>_ssh._tcp</type>
<host-name>bigpond.local</host-name>
<port>22</port>
</service>
<service>
<type>_http._tcp</type>
<host-name>bigpond.local</host-name>
<port>80</port>
</service>
</service-group>
В данном случае, определены предоставляемые сервисы роутером Bigpond, т.к. он сам не может об этом рассказать. Также для роутера определено статически имя в домене .local в файле: /etc/avahi/hosts
root@microserver# cat /etc/avahi/hosts
10.0.0.138 bigpond.local
После этого роутер доступен по адресу bigpond.local. Особенность роутера bigpond в том, что он не имеет hostname.
Публикация разнообразных сервисов, посредством avahi позволяет домашней сети приобрести удобства управления разнообразным оборудованием, потому что обычно все сетевые устройства имеют тот или иной интерфейс настройки и знать о них в одном месте (avahi-discovery и т.п.) очень удобно.
В моих условиях, демон avahi-daemon обязателен к установке, т.к. это резко упрощает взаимодействие между компьютерами.
Повышается удобство работы по протоколу ssh - ssh microserver.local, что часто избавляет от выяснения текущего ip-адреса и через какой интерфейс идёт подключение к микросерверу. А интерфейсом может быть много и на всех на них работает сервис mDNS.
Единственный недостаток - это продолжающаяся недоступность компьютеров по именам(hostname). ping mir & ping microserver - всё ещё не работают "из коробки".
И эту проблему может автоматически решить DNS-сервер в локальной домашней сети.
Централизованная система доменных имен DNS - bind9
Domain Name Service (DNS) - сервис сети Интернет, отображающий (преобразующий) ip-адреса в доменные имена (также и в полностью уточнённые доменные имена FQDN) и обратно.
Микросервер с установленным сервисом DNS выступает в роли сервера имен (name server).
Если объяснить просто, то DNS сервер, это программа ведения списка имен компьютеров, с возможностью обращения к нему через локальную (глобальную) сеть по стандартному протоколу. В частности, список имен (база данных имен), доступен по протоколу UDP на порту 53. Обращаясь с ip-адресом, можно получить имя компьютера и наоборот.
Наиболее известный сервер DNS - BIND (Berkley Internet Naming Daemon).
Установка сервиса DNS bind9 и сопутствующих утилит.
root@microserver#apt-get install bind9
root@microserver#apt-get install dnsutils
Конфигурационные файлы BIND:
/etc/bind/named.conf
/etc/bind/named.conf.options
/etc/bind/named.conf.local
На сервере BIND существует возможность динамического обновления доменной зоны, информацией поставляемой DHCP сервером, о именах подключенных клиентов, что дает искомую возможность доступности по hostname.
Однако, конфигурацию BIND отложим на потом, т.к. есть более быстрый способ - DNSMasq.
DNSMasq - альтернатива связке BIND & DHCPd
DNSmasq - легкий DNS,DHCP,TFTP сервер, применим в небольших домашних сетях.
Возможности сервера позволяют автоматически вносить в список имен DNS, имена компьютеров обращающихся по протоколу DHCP. Это обеспечивает доступность нового компьютера всем компьютерам локальной сети по имени вида: mir, mir.home.
Один конфигурационный файл /etc/dnsmasq.conf
Установка сервера dnsmasq
root@microserver# apt-get install dnsmasq
Для того, чтобы новый сервер dnsmasq не конфликтовал с dhcpd сервером, тот надо остановить и исключить из автозагрузки, что можно сделать в файле: /etc/default/isc-dhcpd-server. Либо деинсталлировать, что менее полезно. Также, при использовании виртуализации, сервер dnsmasq используется в качестве dns-сервера для виртуальных машин и может вызывать конфликт с новой копией.
Остановка и запуск dnsmasq-сервера:
root@microserver#stop dnsmasq
root@microserver#start dnsmasq
Минимальная настройка конфигурации DNSMasq для микросервера:
root@microserver#nano /etc/dnsmasq.conf
# Конфигурация микросервера
# сервер: микросервер
# Определим интерфейсы на которых будет работать сервис DNS,DHCP
# проводная сеть home (eth0)
interface=home
# беспроводная сеть ap (wlan0)
interface=ap
#Определим домен для локальной сети
domain=home
# Определим диапазон выделяемых адресов для проводных клиентов
dhcp-range=192.168.3.11-192.168.3.111,12h
# Определим диапазон выделяемых адресов для беспроводных клиентов
dhcp-range=192.168.5.11-192.168.5.111,12h
no-hosts
# Определим конфигурацию для коммутатора cisco, заменить нули на нормальный MAC-адрес
dhcp-host=00:00:00:00:00:00, 192.168.3.2
Клиентский компьютер получивший настройки от микросервера:
 |
| Сетевые настройки проводной сети home |
Видно, что маршрут по-умолчанию проходит через микросервер (192.168.3.1). DNS-сервер, разрешающий имена в адреса, также микросервер. Однако, маршрут по-умолчанию может быть скорректирован следующими настройками:
 |
| Окно "Маршруты" |
Если опцию "Игнорировать автоматически полученные маршруты" отметить, то маршрут по-умолчанию не будет перенесен в таблицу маршрутов и команда ip route не покажет строку вида:
default via 192.168.3.1 dev home proto static
После настройки имеет смысл провести ряд тестов:
С микросервера:
root@microserver# ping mir
root@microserver# ping cisco
С настольного компьютера:
i@mir$ ping microserver
i@mir$ ping cisco
NetBIOS Name server - NMBD
NMBD сервер имен для SMB/CIFS клиентов (обычно Windows компьютеры). NMBD отвечает на запросы "NetBIOS over IP", задаваемые клиентами Samba, SMB/CIFS такими как Windows Vista, Windows 7.
NetBIOS over IP - специальная адаптация раннего протокола NetBIOS к сетям TCP/IP.
Протокол является обеспечивающим участником процесса "Сетевое окружение" в Windows, со стороны микросервера.
NMBD слушает такие широковещательные запросы на порту 137 по протоколу UDP и если встречает в запросе собственное NetBIOS-имя, то возвращает IP-адрес компьютера, на котором запущен. По умолчанию, NetBIOS имя компьютера совпадает с hostname, но может быть изменено в конфигурации smb.conf.
NetBIOS микросервера = microserver
Также могут быть добавлены дополнительные имена NetBIOS к компьютеру. Для чего это может быть понадобиться?
В многосетевых компьютерах NMBD демон запускается на каждом интерфейсе и по идее возвращает IP-адрес интерфейса.
NMBD следует порядку разрешения NetBIOS имен, указанному в конфигурации smb.conf, также и с привлечением файл /etc/samba/lmhosts.
Файл /etc/samba/lmhosts - подобен файлу /etc/hosts, но только для имен NetBIOS.
Синтаксис текстового файла lmhosts можно просмотреть подробно в man lmhosts, но для понимания достаточно:
192.168.3.1 MICROSERVER
Файл lmhosts может быть использован для указание NetBIOS имени различных статических устройств, присутствие которых в сети Windows желательно, но они сами не могут конфигурировать свое NetBIOS имя (отсутствующий nmbd-демон) и разумеется для тестирования протокола Samba.
Действие NMBD ограничивается сегментом сети, т.к. протокол широковещательный (multicast).
WINS - Windows Internet Name Service
NMBD может быть настроен как WINS сервер (Windows Internet Name Service) и как WINS proxy.
Преимущества WINS сервера в том, что этот сервер поддерживает динамическую базу данных NetBIOS-имен компьютеров, которые сами и регистрируют свои имена на WINS сервере, также поддерживает уникальность NetBIOS имен в локальной сети.
Рекомендуется использовать в сетях, состоящих из более чем одного сегмента (наш случай), что позволяет при правильно настроенной IP-маршрутизации, просматривать компьютеры другой подсети.
Функциональность WINS сервера запускается указанием директивы
wins support = yes в конфигурационном файле /etc/samba/smb.conf. База имен WINS сервера хранится в файле /var/locks/wins.dat.
Присутствует опция wins hook, позволяющая организовать связь посредством внешней программы, для обновления DNS, при появлении новой записи в базе имен WINS.
Опция wins server более подходит для клиентской настройки Samba (например на компьютере mir). Указывает, сервер wins.
Указание о том, на каком сервере регистрировать свое имя, клиентский компьютер может получить при динамической конфигурации по протоколу DHCP, для этого в используются опции в /etc/dhcp/dhcpd.conf (
при использовании isc-dhcp-server), на пример для микросервера:
...
option netbios-name-servers 192.168.3.1;
...
при использовании сервера DNSMasq в качестве DHCP:
...
dhcp-option=44,192.168.3.1
dhcp-option=44,192.168.5.1
dhcp-option=46,8
...
т.к. используется 2 интерфейса (home & ap). Опция dhcp-option=46,8 задает способ запроса NetBIOS имен, в данном случае - гибридный - через WINS-сервер и затем широковещательный.
Возможные значения опция 46:
1.B-node (Broadcast): Разрешение имен с помощью широковещательных запросов, WINS не используется.
2. P-node (Peer): Используется только WINS.
4. M-node (Mixed): Смешанный тип, сначала используется широковещательный запрос, затем в случае неудачи - WINS
8. H-node (Hybrid): WINS, а затем широковещательный запрос.
Вот вывод на стороне клиента, откуда видно что получен адрес wins сервера:
i@mir$ cat /var/log/syslog
Sep 4 11:03:34 mir dhclient: DHCPACK of 192.168.3.80 from 192.168.3.1
Sep 4 11:03:34 mir dhclient: bound to 192.168.3.80 -- renewal in 20410 seconds.
Sep 4 11:03:34 mir NetworkManager[1237]: <info> (home): DHCPv4 state changed preinit -> reboot
Sep 4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 4 of 5 (IP4 Configure Get) scheduled...
Sep 4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 4 of 5 (IP4 Configure Get) started...
Sep 4 11:03:34 mir NetworkManager[1237]: <info> address 192.168.3.80
Sep 4 11:03:34 mir NetworkManager[1237]: <info> prefix 24 (255.255.255.0)
Sep 4 11:03:34 mir NetworkManager[1237]: <info> gateway 192.168.3.1
Sep 4 11:03:34 mir NetworkManager[1237]: <info> hostname 'mir'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> nameserver '192.168.3.1'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> domain name 'home'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> wins '192.168.5.1'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 5 of 5 (IP Configure Commit) started...
...
А вот воспользуется ли какой-либо демон этой полученной информацией? Samba клиент по идее должен обновить опцию wins servers, но не факт. Ключевое слово по теме: dhcpcd-hook-samba. И да, в Ubuntu 12.04 эти изменения не вносятся, что и показывает содержимое клиентской конфигурации Samba:
i@mir$ cat /etc/samba/smb.conf | grep wins
Для исправления данной оплошности, надо сделать несколько изменений в клиентской конфигурации.
Существуют автоматически вызываемые скрипты, который выполняются, когда dhclient завершает работу, располагаются они в /etc/dhcp/dhclient-exit-hooks.d/. Там можно обнаружить скрипт обновления времени, например.
Достаточно создать скрипт,в этой папке, который будет автоматически редактировать файл /etc/samba/smb.conf на клиенте и вносить сведения о новом сервере wins:
Содержимое скрипта /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update
i@mir$ cat /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update
#!/bin/bash
/usr/bin/sed 's/\(wins server = \)\([0-9][\.0-9]*\)/\1'$new_netbios_name_servers'/' </etc/samba/smb.conf >/tmp/smb.temp
cp /tmp/smb.temp /etc/samba/smb.conf
Незабываем сделать скрипт исполняемым:
i@mir$ chmod +x /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update
Проверка - простым просмотром файла /etc/samba/smb.conf на клиенте, после подключения.
WINBIND
WINBIND демон (winbindd) для разрешения имен с помощью Windows NT серверов, а также информации о пользователях и группах. Входит в пакет Samba.
Winbind используется совместно с Name Service Switch (переключатель-диспетчер служб имен).
В файле /etc/nsswitch.conf можно указать:
hosts: files dns wins
и если имя не удалось разрешить стандартными средствами linux, то будет использован wins сервер.
А вот какой WINS сервер будет использован зависит от настроек сети Windows.
Конфигурация windbind сервера выполняется в файле /etc/samba/smb.conf
Для домашней сети, использование winbind - избыточно и этот сервис можно деактивировать. В больших сетях, управляемых доменной политикой, winbind поможет подключить микросервер к Active Directory и позволит пользователям зарегистрированным в домене получать доступ к ресурсам микросервера под своими именами.
Воспользуемся командой net (man net). Видим, что в домашней сети не обнаружено доменов Windows:
root@microserver# net ads info
ads_connect: No logon servers
ads_connect: No logon servers
Didn't find the ldap server!
Проверить наличие WINS сервера в локальной сети:
i@mir$ wbinfo -p
Ping to winbindd succeeded
При запущенному сервере WINBIND, работают команды разрешения имен на микросервере:
root@microserver# wbinfo -N MICROSERVER
root@microserver# wbinfo -N MIR
При остановленном сервере WINBIND не работают:
root@microserver# wbinfo -N MICROSERVER
failed to call wbcResolveWinsByName: WBC_ERR_WINBIND_NOT_AVAILABLE
Could not lookup WINS by name MICROSERVER
Команда smbclient не зависит от работы winbind и можно просмотреть ресурсы микросервера:
root@microserver# smbclient -N -L MICROSERVER
Anonymous login successful
Domain=[HOME] OS=[Unix] Server=[Samba 3.6.3]
Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC Service (hp proliant microserver)
avoska Disk авоська для обмена
Anonymous login successful
Domain=[HOME] OS=[Unix] Server=[Samba 3.6.3]
Server Comment
--------- -------
MICROSERVER hp proliant microserver
Workgroup Master
--------- -------
HOME MICROSERVER
Замеченные проблемы
Редактирование файла /etc/nsswitch.conf может повлечь за собой недоступность компьютеров по имени, а также неявную неработоспособность многих программ.
Существует проблема взаимодействия домена .local системы mDNS и домена .local системы обычной DNS.
При входе через ssh (ssh microserver) выдается сообщение о подмене хоста (DNS spoofing).
Ресурсы
https://help.ubuntu.com/community/HowToZeroconf
http://0pointer.de/lennart/projects/nss-mdns/
Обзор службы WINS. http://technet.microsoft.com/ru-ru/library/cc725802(v=ws.10).aspx
DHCP options. http://www.opennet.ru/man.shtml?topic=dhcp-options&category=5&russian=0
Настройка взаимодействия Linux с Windows. Samba.
http://pm4u.narod.ru/samba.htm
Порты протокола TCP/IP, используемые операционной системой Windows NT.
http://support.microsoft.com/kb/150543/ru
