Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

312

Глава 9. Локальные службы сети

172.16.12.2 rodent

172.16.12.4 jerboas

В соответствии с этим файлом Imhosts имя NetBIOS rodent отображается в

адрес IP 172.16.12.2. Обратите внимание, что эти имена NetBIOS совпадают

с именами узлов TCP/IP, назначенными клиентам. Используйте одинако-

вые имена в NetBIOS и TCP/IP. Иная политика выбора имен ограничивает

возможности настройки и создает путаницу.

Сетевая информационная служба (NIS)

Сетевая информационная служба NIS (Network Information Service)

- это

административная база данных, реализующая централизованное сопровож-

дение и автоматическое распространение важных административных фай-

лов. NIS позволяет преобразовать ряд стандартных файлов Unix в базы дан-

ных, к которым можно обращаться по сети. Такие базы данных называются

картами NIS. Некоторые карты создаются из файлов, с которыми вы знако-

мы по системному администрированию, - в частности, из файла паролей

(/etc/passwd) и файла групп (/etc/group). Прочие являются производными

от файлов, связанных с сетевым администрированием:

/etc/ethers

Источник NIS-карт ethers.byaddr и ethers.by пате. Файл /etc/ethers ис-

пользуется в работе RARP (см. главу 2).

/etc/hosts

Источник карт hosts.byname и hosts.byaddr (см. главу 3).

/etc / networks

Источник карт networks.byname и networks.byaddr (см. главу 3).

/etc/protocols

Источник карт protocols.by пате и protocols.byaddr (см. главу 2).

/ etc / services

Источник одной карты - services.byname (см. главу 2).

/etc/aliases

Определяет псевдонимы для адресов электронной почты и служит источ-

ником карт mail.aliases и mailbyaddr (см. главу 10).

Определить, какие карты доступны на сервере, можно при помощи команды

ypcat

-х.

Данная команда выводит одинаковый список для наших тестовых

систем Solaris и Linux. Список для вашего сервера может отличаться. Вот

список, полученный в системе Linux:

% ypcat -х

Use "passwd" for map "passwd.byname"

Изначально NIS носила название «Желтые страницы» (Yellow Pages, или yp). На-

звание изменилось, но аббревиатура ур по-прежнему в ходу.

Сетевая информационная служба (NIS)

313

Use "group" for map "group.byname"

Use "networks" for map "networks.byaddr"

Use "hosts" for map "hosts.byname"

Use "protocols" for map "protocols.bynumber"

Use "services" for map "services.byname"

Use "aliases" for map "mail.aliases"

Use "ethers" for map "ethers.byname"

MIS позволяет централизованно хранить на сервере важные административ-

ные файлы, предоставляя доступ к ним всем рабочим станциям сети. Все

карты хранятся на головном сервере, выполняющем серверный процесс

NIS - ypserv. Клиентские системы обращаются к картам по сети. Клиенты

используют ypbind для обнаружения сервера.

Сервер NIS и его клиенты составляют домен NIS. Этот термин NIS делит с

DNS. Домен NIS обозначается доменным именем NIS. Единственное предъ-

являемое к именам требование заключается в том, что в пределах одной ло-

кальной сети различные домены NIS должны иметь разные имена. Хотя до-

мены NIS и DNS - различные сущности, но Sun рекомендует использовать в

качестве имен NIS-доменов имена DNS-доменов, чтобы упростить админист-

рирование и избежать путаницы.

NIS использует имя своего домена при создании подкаталога в иерархии /var/

ур для хранения карт. Например, домен DNS нашей воображаемой сети носит

имя wrotethebook.com, и такое же имя мы используем для нашего домена NIS.

NIS создает каталог /var/ур/wrotethebook.com и хранит в нем карты NIS.

Протоколы и команды NIS изначально были определены компанией Sun

Microsystems, однако сама служба в настоящее время получила широкое

распространение в различных реализациях. Многочисленные примеры это-

го раздела относятся к системе Linux, а не Solaris, и замечательно иллюстри-

руют этот факт. Синтаксис команд в различных системах весьма схож.

Команда domainname позволяет узнать либо задать имя домена NIS. Супер-

пользователь может сделать wrotethebook.com именем домена NIS, выполнив

следующую команду:

# domainname wrotethebook.com

Имя домена NIS обычно указывается в процессе загрузки системы - с этой

целью команда domainname помещается в один из загрузочных сценариев. Во

многих системах имя домена NIS, выступающее в качестве аргумента ко-

манды domainname, хранится в отдельном файле. Так, в системах Solaris зна-

чение имени домена NIS извлекается из файла /etc/defaultdomain. Как вид-

но из следующего примера, defaultdomain содержит только имя домена NIS:

% cat /etc/defaultdomain

wrotethebook.com

В системах Red Hat Linux имя домена NIS - лишь одно из значений, храня-

щихся в файле /etc/sysconfig/network:

$ cat /etc/sysconfig/network

NETWORKING=yes

314 Глава 9. Локальные службы сети

HOSTNAME=jerboas.wrotethebook.com

NISDOMAIN=wrotethebook.com

Инициализация сервера NIS и создание первых вариантов карт выполняет-

ся при помощи make. Файл /var/ур/Makefile содержит инструкции, необхо-

димые для сборки карт. Как уже говорилось, каталог для карт получает

имя, совпадающее с именем домена NIS. Makefile читает файлы из каталога

/etc и сохраняет созданные на их основе карты в новом каталоге. Чтобы ини-

циализировать систему Linux в качестве сервера NIS, выполните подобную

последовательность команд:

# domainname wrotethebook.com

# cd /var/ур

# make

make[1]: Entering directory '/var/yp/wrotethebook.com'

Updating hosts.byname...

Updating hosts.byaddr...

Updating networks.byaddr...

Updating networks.byname...

Updating protocols.bynumber...

Updating protocols.byname...

Updating rpc.byname...

Updating rpc.bynumber...

Updating services.byname...

Updating passwd.byname..,

Updating passwd.byuid...

Updating group.byname...

Updating group.bygid...

Updating netid.byname...

make[1]: Leaving directory '/var/yp/wrotethebook.com'

После инициализации карт запустите процесс сервера NIS ypse rv и связую-

щий процесс NIS - ypbind:

# ypserv

# ypbind

Наша система теперь выступает в роли как NIS-сервера, так и NIS-клиента.

Быстрая проверка при помощи ypwhich показывает, что мы связаны с нуж-

ным сервером. Воспользуйтесь ypcat или ypmatch, чтобы убедиться, что дан-

ные с сервера действительно доступны. В следующем примере мы использу-

ем ypcat:

. # ypwhich

localhost

# ypcat hosts

172.16.55.105 cow cow.wrotethebook.com

172.16.55.106 pig pig.wrotethebook.com

Если в процессе первой сборки карт NIS make сообщит, что сервер ypserv не зареги-

стрирован, запустите ypserv, прежде чем выполнять make.

Сетевая информационная служба (NIS)

315

172.16.26.36 island.wrotethebook.com island

127.0.0.1 localhost

Клиентам остается только указать корректное доменное имя и выполнить

приложение связующего модуля - ypbind:

# domainname wrotethebook.com

# ypbind

Большинство клиентов NIS для обнаружения сервера используют ypbind.

Исходя из имени домена NIS, ypbind передает широковещательный запрос к

серверу этого домена. К первому из ответивших серверов и «привязывается»

клиент. Теория гласит, что сервер, ответивший быстрее прочих, имеет наи-

меньшую загрузку. Как правило, гипотеза работает хорошо. Тем не менее

существует вероятность привязки клиента к неподходящей системе, а имен-

но к системе, на которой случайно оказался установлен сервер

ypserv,

либо к

системе, которую специально настроили в качестве ложного сервера. При-

нимая во внимание такую возможность, некоторые системы позволяют яв-

ным образом указать сервер, с которым общается клиент. Этой цели в Linux

служит файл /etc/yp.conf. Синтаксис записей файла варьируется от версии к

версии, поэтому обратитесь к документации по своей системе, прежде чем

использовать файл.

Поместите имя домена NIS в подходящий загрузочный файл, чтобы на-

стройки NIS продолжали действовать и после перезагрузки. Команды ypbind

и ypserv, вероятно, уже присутствуют в одном из загрузочных сценариев.

В системе Red Hat Linux программам ypbind и ypserv соответствуют специ-

альные сценарии в каталоге /etc/init.d. Поместив значение NISDOMAIN в /etc/

sysconfig/network, не забудьте при помощи команды chkconfig убедиться,

что сценарии ypbind и ypserv выполняются в процессе загрузки системы.

NIS является возможной альтернативой DNS, однако в большинстве систем

применяется как NIS, так и DNS. Преобразование имен узлов в IP-адреса мо-

жет быть возложено на DNS, NIS и таблицу узлов. Порядок опроса различ-

ных источников определяется в файле nsswitch.conf.

Файл nsswitch.conf

Файл коммутации службы имен (Name Service Switch) nsswitch.conf опреде-

ляет порядок поиска информации в различных источниках. Вопреки назва-

нию, действие файла распространяется не только на службу имен, nss-

witch.conf позволяет работать с любыми базами данных NIS, как можно ви-

деть из следующего примера:

hosts: dns nis files

networks: nis [N0TF0UND=return] files

services: nis files

protocols: nis files

Первая запись файла гласит, что поиск информации по имени узла выпол-

няется прежде всего в DNS; если DNS не находит соответствия, поисковый

316

Глава 9. Локальные службы сети

запрос передается NIS, и только в последнюю очередь выполняется поиск в

файле hosts. Вторая запись предписывает осуществлять поиск сетевых имен

в NIS. Строка [NOTFOUND=return] предписывает использовать файл networks

только в случае, если служба NIS недоступна. В случае когда NIS не может

найти имени указанной сети, поиск завершается. Последние две записи ор-

ганизуют поиск портов служб и номеров протоколов в NIS, а затем в файлах

каталога /etc.

NIS+

Прежде чем завершить рассказ о NIS, следует упомянуть NIS+. Этот раздел

будет коротким, потому что я не использую NIS+ и знаю об этой системе не

очень много.

NIS+ приходит на смену NIS в системах от Sun. NIS+ является не новой вер-

сией NIS, но совершенно самостоятельным программным продуктом, предо-

ставляющим полноценную функциональность NIS плюс некоторые новые

возможности. Вот эти возможности:

• Повышенная безопасность. NIS не позволяет проверять подлинность сер-

веров (как отмечалось в разговоре об ypbind) или клиентов. В NIS+ суще-

ствует механизм авторизации пользователей, работающий на базе шиф-

рования DES. Кроме того, NIS+ реализует различные уровни доступа,

позволяющие дифференцировать доступ пользователей к данным. NIS

позволяет предоставить всем пользователям домена NIS только одинако-

вые права доступа.

• Иерархическая, децентрализованная архитектура. Подобно DNS, NIS+

является распределенной, иерархической системой баз данных. Это поз-

воляет создавать очень вместительные пространства имен, а также рас-

пределить управление информационными структурами, сохраняя согла-

сованность доступа к данным. NIS имеет линейную структуру. Вся ин-

формация о домене NIS поступает от единственного головного сервера,

и домены NIS никак не связаны между собой.

• Более совершенные структуры данных. NIS преобразует ASCII-файлы в

простые ассоциативные массивы, которые в документации NIS+ названы

«картами в две колонки». Таблицы, баз данных NIS+ состоят из многих

колонок и позволяют производить поиск самой разнообразной информа-

ции по записи. Кроме того, для таблиц NIS+ может выполняться связы-

вание с целью обеспечения дополнительной информации по определен-

ной записи.

Очевидно, NIS+ имеет ряд превосходных новых возможностей и преимуществ

перед NIS. Почему же я не использую NIS+? Хороший вопрос! Иерархическая

архитектура и более совершенные структуры данных - важные элементы для

большой сети, хранящей серьезные объемы данных в своем сегменте про-

странства имен. Однако многие сетевые площадки развивались с применени-

ем NIS в локальных подсетях и не испытывают необходимости в переводе

предприятия в целом под управление NIS+. Улучшенная безопасность - аргу-

DHCP 317

мент, похоже, железный, однако площадки с низкими требованиями к безо-

пасности опять же не испытывают необходимости в ее улучшении, а площад-

ки с высокими требованиями к безопасности, скорее всего, уже защищены

брандмауэром, блокирующим внешние запросы к NIS. Кроме того, реализа-

ции NIS охватывают большее число операционных систем, нежели реализа-

ции NIS+. И наконец, вместо NIS+ все чаще используются другие службы ка-

талогов, предоставляющие подобный уровень обслуживания и более доступ-

ные, например LDAP. Сумма этих причин замедлила переход на NIS+.

Чтобы узнать больше о NIS+ и ее установке в своей системе, прочтите доку-

менты NIS+ Transition Guide (Руководство по переходу на NIS+), Name Ser-

vice Configuration Guide (Руководство по настройке службы имен) и Name

Service Administration Guide (Руководство администратора службы имен).

Все они доступны в составе набора руководств Solaris System and Network

Administration (Системное и сетевое администрирование Solaris) от Sun.

NIS и NIS+ обеспечивают своих клиентов широким диапазоном сведений,

относящихся к настройке системы. При этом они не позволяют получать ин-

формацию, необходимую для настройки подсистемы TCP/IP. В следующих

двух разделах мы изучим серверы настройки, позволяющие решать эту за-

дачу в комплексе.

DHCP

Протокол инициализации ВООТР (Bootstrap Protocol) стал первым всесто-

ронним протоколом настройки. Он предоставляет всю информацию, обычно

необходимую для настройки TCP/IP, начиная с адреса IP клиента и закан-

чивая сервером печати. ВООТР оказался настолько простым и эффективным

протоколом, что лег в основу протокола динамической настройки узлов DHCP

(Dynamic Host Configuration Protocol). DHCP работает через те же порты

UDP, 67 и 68, что и ВООТР. Этот протокол предоставляет все возможности

ВООТР, а также включает важные расширения. Три главные особенности

протокола DHCP:

Обратная совместимость с протоколом инициализации ВООТР

Сервер DHCP способен поддерживать клиентов ВООТР. Правильно на-

строенный сервер DHCP может обслуживать всех ваших клиентов.

Полноценная настройка

Сервер DHCP предоставляет клиентам полный набор параметров на-

стройки TCP/IP. (Полный перечень содержится в приложении D.) Адми-

нистратор сети получает возможность управлять всеми настройками

пользователей.

Динамическое назначение адресов

Сервер DHCP позволяет выделять постоянные адреса вручную либо авто-

матически, а временные адреса - динамически. Администратор сети вы-

бирает механизм назначения адресов, исходя из нужд сети и систем кли-

ентов.

318 Глава 9. Локальные службы сети

В этом разделе мы создадим сервер DHCP, который поддерживает клиентов

ВООТР, динамически выделяет адреса, а также представляет клиентам ши-

рокий диапазон параметров настройки.

Для систем Unix существует несколько реализаций DHCP. Одни пакеты яв-

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

Unix. Мы воспользуемся демоном dhcpd, разработанным консорциумом ISC

(Internet Software Consortium). Он свободно доступен в Интернете и работает

с широким спектром систем Unix, включая наши тестовые системы Linux и

Solaris. (Приложение D содержит информацию о том, где взять и как ском-

пилировать dhcpd.) Обратившись к другому серверному модулю DHCP, вы,

вероятнее всего, столкнетесь с иным набором команд настройки, однако ос-

новная функциональность отличаться не будет.

dhcpd.conf

Настройки dhcpd хранятся в файле /etc/dhcpd.conf. Файл настройки содер-

жит инструкции, которые определяют, какие подсети и узлы обслуживает

сервер и какую информацию настройки он им предоставляет, dhcpd.conf -

обычный текстовый файл, сходный с файлом исходного текста на языке С.

Проще всего изучить файл dhcpd.conf на примере:

DHCP

319

Это пример настройки сервера, объединяющего и обслуживающего две раз-

личные подсети. Сервер динамически назначает IP-адреса DHCP-клиентам

обеих подсетей и осуществляет поддержку нескольких клиентов ВООТР.

Все строки, начинающиеся символом решетки (#), являются комментария-

ми. Первые несколько активных строк файла определяют ряд параметров и

режимов, действующих для всех обслуживаемых сервером подсетей и кли-

ентов. Первые три строки содержат параметры для сервера. Каждый из трех

параметров в данном примере определяет один из аспектов работы dhcpd при

динамическом назначении адресов.

default-lease-time

Указывает серверу длительность аренды адреса по умолчанию (в секун-

дах). Клиент может запросить аренду адреса на определенный период

времени, и в этом случае его запрос выполняется. Однако могут действо-

вать определенные ограничения. Часто клиенты не указывают конкрет-

ную длительность аренды при получении адреса. В такой ситуации ис-

пользуется параметр default-lease-time. В нашем примере длительность

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

max-lease-time

Определяет максимально допустимое время аренды. Независимо от дли-

тельности аренды, фигурирующей в запросе клиента, это самый длитель-

ный срок, на который dhcpd выдаст клиенту адрес. Время аренды опреде-

ляется в секундах. В данном примере максимальное время аренды со-

ставляет одну неделю.

get-lease-hostnames

Предписывает dhcpd предоставлять каждому клиенту наряду с динами-

чески назначенным адресом имя узла. Имя узла должно быть получено в

DNS. Данный параметр - логический. При значении false (принятом по

умолчанию) клиенту назначается адрес, но не имя узла. Поиск имен уз-

лов для всех динамически выделяемых адресов значительно увеличивает

время, требуемое на запуск демона. Присваивайте этому параметру зна-

чение false. Значение true используйте, только если сервер работает с

очень небольшим количеством адресов, назначаемых динамически.

320 Глава 9. Локальные службы сети

В файле настройки содержатся и другие параметры - их мы изучим в ходе

дальнейшего изложения. Полный перечень всех параметров DHCP приведен

в приложении D.

Следующие четыре строки представляют ключи настройки. Они начинают-

ся с ключевого слова option. За ним следует имя ключа и назначенное ему

значение. Ключи определяют значения настройки, используемые клиентом.

О назначении ключей из примера легко догадаться, поскольку их имена но-

сят описательный характер. Мы передаем клиентам маску подсети, имя до-

мена, адреса сервера доменных имен, а также адрес сервера печати. Эти зна-

чения аналогичны тем, что могли распространяться посредством более ста-

рой службы ВООТР.

Однако возможности DHCP шире, чем у ВООТР. Чтобы проиллюстрировать

это утверждение примером, мы также указали максимальную длину переда-

ваемого блока - MTU (maximum transmission unit). В примере ключ interface-

mtu уведомляет клиента, что значение MTU равно 1500 байт. В данном случае

это избыточное действие (поскольку значение 1500 принимается по умолча-

нию для интерфейсов Ethernet), но оно ясно показывает, что DCHP позволяет

передавать клиентам самую разнообразную информацию о настройках.

Операторы subnet определяют подсети, обслуживаемые dhcpd. Идентифика-

ция сетей выполняется на основе адреса и адресной маски - оба элемента яв-

ляются обязательными для оператора subnet, dhcpd передает информацию о

настройках только клиентам этих сетей. Для каждой подсети, с которой фи-

зически связан сервер, должен присутствовать отдельный оператор subnet,

даже если в некоторых из подсетей нет клиентов. Информация о подсетях

требуется dhcpd при запуске.

Действие ключей и параметров внутри оператора subnet распространяется

только на эту подсеть и находящиеся в ней клиенты. Назначение ключей в

примере понятно. Они указывают клиентам, какой маршрутизатор и широ-

ковещательный адрес использовать. Параметр range более интересен, по-

скольку напрямую связан с одной из ключевых возможностей DHCP.

Параметр range определяет диапазон адресов для динамического выделения.

Он всегда существует в контексте оператора subnet, и диапазон адресов дол-

жен принадлежать адресному пространству этой подсети. Диапазон в пара-

метре range определяется парой указанных адресов. Первый адрес определя-

ет наименьший адрес, который может быть назначен автоматически, а вто-

рой - наибольший из таких адресов. Первый параметр range нашего примера

обозначает непрерывную группу адресов с 172.16.12.50 по 172.16.12.250,

доступных для динамического назначения. Обратите внимание, что во вто-

ром операторе subnet два параметра range. Так создаются раздельные после-

довательности динамически выделяемых адресов. Когда это может приго-

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

ную до установки сервера DHCP. Главное, что независимо от причин можно

определять области динамически выделяемых адресов, содержащие разры-

вы, при помощи нескольких операторов range.

DHCP 321

Если параметр range фигурирует в операторе subnet, любой клиент DHCP из

этой подсети, запросивший адрес, получит один из адресов диапазона, если

свободные адреса есть. В отсутствие параметра range механизм динамическо-

го назначения адресов не действует.

Чтобы включить автоматическое назначение адресов клиентам ВООТР, до-

бавьте аргумент dynamic-bootp в параметр range. Например, так:

range dynamic-bootp 172.16.8.10 172.16.8.50;

По умолчанию клиентам ВООТР назначаются постоянные адреса. Поведе-

ние системы можно изменить при помощи параметра dynamic-bootp-lease-cu-

I toff либо при помощи параметра dynamic-bootp-lease-length. Однако клиенты

ВООТР не умеют арендовать адреса и не знают, что должны их обновлять.

Поэтому параметры dynamic-bootp-lease-cutoff и dynamic-bootp-lease-length

используются только в особых обстоятельствах. Если вам нужны именно эти

параметры, обратитесь к приложению D.

Каждому из клиентов ВООТР должен быть сопоставлен оператор

host,

позво-

ляющий указать параметры и ключи настройки для клиента. Он может ис-

пользоваться для назначения клиентам постоянных, фиксированных адре-

сов. Приведенный выше файл настройки заканчивается тремя операторами

I host - для узлов 24seven, rodent и ring соответственно. Каждый оператор host

содержит параметр hardware, определяющий тип сетевого аппаратного обеспе-

чения (ethernet) и физический сетевой адрес (например, 08:80:20:01:59:сЗ),

используемый клиентом. Параметр hardware является обязательным для опе-

раторов host клиентов ВООТР. Адрес Ethernet используется dhcpd для иден-

тификации клиентов ВООТР. Клиентам DHCP также могут соответствовать

операторы host. Для клиентов DHCP параметр hardware является необяза-

тельным, поскольку идентификацию клиента DHCP можно осуществить по

значению dhcp-client-identifier. Однако клиент DHCP, подключенный по

интерфейсу Ethernet, проще идентифицировать по его адресу Ethernet.

Оператор host может содержать широкий спектр различных параметров и

ключей. Например, добавление в каждый оператор host ключа следующего

типа назначает каждому клиенту определенное имя узла:

option host-name 24seven;

Часто оказывается проще определять значения параметров и ключей на бо-

лее высоком уровне. Глобальные настройки действуют для всех систем. На-

стройки подсети действуют для всех ее клиентов, а настройки, принадлежа-

щие оператору

host,

действуют лишь для одного узла. Ключ

host-name,

приве-

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

дом операторе host. Проще определить параметр или ключ для группы

узлов, воспользовавшись оператором group.

Оператор group группирует любые другие операторы. Единственным назна-

чением оператора group является распространение действия параметров и

ключей на всех участников группы. Именно это мы сделали в примере. Опе-

ратор group объединил все операторы host. Параметр use-host-decl-names в