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

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

• Имена и адреса

• Таблица узлов

• DNS

Сетевые службы

• Почтовые службы

• Серверы файлов и печати

• Серверы настройки

Некоторые серверы сети предоставляют доступ к важным службам уровня

взаимодействия машин сети. Такие службы не эквивалентны прикладным

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

Напротив, эти службы задействуются сетевыми компьютерами и упрощают

создание, настройку и работу сети.

Функции серверов, описываемые в этой главе, весьма разнообразны:

• Службы имен для преобразования IP-адресов в имена узлов

• Серверы настройки, упрощающие добавление узлов сети, частично или

полностью выполняя настройку TCP/IP

• Службы электронной почты, осуществляющие перемещение сообщений

по сети от автора к адресату

• Файловые серверы, организующие прозрачный совместный доступ кли-

ентов к файлам

• Серверы печати, централизующие управление печатающими устройства-

ми и обеспечивающие совместный доступ к ним многих пользователей

Серверы сети TCP/IP не следует путать с традиционными PC-серверами ло-

кальной сети. Любой узел сети под управлением Unix-системы может быть

как сервером, так и клиентом. Узлы сети TCP/IP являются «равноправны-

ми». Все системы равны, и сеть не зависит от работы единственного сервера.

Службы, о которых пойдет речь далее, могут устанавливаться на одной или

нескольких системах сети.

Наш рассказ начинается со службы имен. Эта жизненно необходимая служ-

ба обязательно пригодится вам в работе.

Имена и адреса

Документ, посвященный протоколу Internet

, определяет имена, адреса и

маршруты следующим образом:

Имя показывает искомый нами объект. Адрес показывает его местонахожде-

ние. Маршрут определяет способ попасть в нужную точку.

Имена, адреса и маршруты в равной степени требуют внимания сетевого ад-

министратора. Маршрутам и адресам мы посвятили предыдущую главу.

В этом разделе пойдет речь об именах и их распространении по сети. Каж-

дый сетевой интерфейс в сети TCP/IP определяется уникальным 32-битным

адресом IP. Любому устройству с IP-адресом может быть назначено имя (из-

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

ройствам заключена в том, что имена, в сравнении с числовыми адресами

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

программ, но они облегчают людям работу с сетью.

В большинстве случаев имена узлов и числовые адреса взаимозаменяемы.

Чтобы обратиться посредством telnet к рабочей станции с IP-адресом

172.16.12.2, пользователь может набрать:

RFC 791, Internet Protocol, Jon Postel, ISI, 1981, c. 7.

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

ная Sun, представляет собой более совершенный механизм доступа к таблице уз-

лов. Речь о NIS пойдет далее в этой главе.

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

брать эквивалентную команду:

И в том и в другом случае сетевое подключение выполняется на основе адре-

са IP. Система преобразует имя узла в адрес перед открытием соединения.

Сетевой администратор отвечает за назначение имен и адресов, сохраняя их

в базах данных, используемых для преобразования.

Перевод имен в адреса нельзя назвать «частной» проблемой. Команда telnet

rodent.wrotethebook.com должна работать корректно с любого узла, подклю-

ченного к сети. Если узел rodent.wrotethebook.com входит в сеть Интернет,

узлы во всем мире должны иметь возможность преобразовать имя ro-

dent.wrotethebook.com в соответствующий адрес. Очевидно, необходимы ме-

ханизмы распространения информации по именам узлов и обеспечения этой

информацией всех узлов сети.

Широкое распространение получили два метода перевода имен в адреса. Бо-

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

таблицы узлов.

Более современный связан с применением механизма рас-

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

(Domain Name System, DNS). Сначала мы рассмотрим таблицу узлов.

Глава 3. Сетевые службы

Таблица узлов

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

dent. IP-адресу 172.16.12.2 поставлено в соответствие имя узла rodent.wro-

tethebook.com и альтернативное имя узла (псевдоним) rodent. Имя узла и все

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

172.16.12.2.

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

вать сокращенные варианты. Кроме того, псевдонимы позволяют создавать

«обобщенные имена узлов». Обратите внимание на запись для адреса

172.16.12.1. Один из псевдонимов адреса - loghost. loghost - это особое имя

узла, используемое в файле настройки syslog.conf систем Solaris. В дистри-

бутивах некоторых систем программы, подобные

syslogd,

настраиваются та-

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

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

щенное имя в качестве псевдонима. Среди обобщенных имен встречаются

такие, как Iprhost, mailhost и dumphost.

Вторая запись из файла назначает адрес 127.0.0.1 узлу с именем localhost. Как

говорилось ранее, сетевой адрес 127.0.0.0/8 зарезервирован под кольцевую

сеть. Адрес узла 127.0.0.1 - это специальный адрес, назначаемый в качестве

кольцевого локальному узлу (отсюда имя localhost). Такое специальное согла-

шение об адресации позволяет узлу обмениваться данными с самим собой та-

ким же способом, как и с удаленными узлами. Кольцевой адрес упрощает соз-

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

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

описанное соглашение сокращает сетевой трафик: адрес узла localhost связан

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

На смену таблице узлов пришли механизмы DNS, но она по-прежнему ши-

роко применяется по следующим причинам:

Таблица узлов - это обычный текстовый файл, сопоставляющий IP-адреса с

именами узлов. В большинстве Unix-систем таблица хранится в файле /etc/

hosts. Каждая строка таблицы /etc/hosts содержит адрес IP, отделенный

пробелом от перечня имен узлов, связанных с этим адресом. Символ # отме-

чает начало комментария.

Таблица узлов системы rodent может содержать такие записи:

DNS

• В большинстве систем есть небольшие файлы с таблицами узлов, содер-

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

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

процессе начальной загрузки машины. Даже при наличии DNS следует

создавать файлы /etc/hosts, содержащие записи для самого узла, узла lo-

calhost, шлюзов и серверов локальной сети.

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

ходных данных для баз данных NIS. NIS может использоваться в сочета-

нии с DNS, но даже в этом случае на большинстве NIS-площадок создают-

ся таблицы узлов, содержащие записи для всех узлов локальной сети. Со-

вместное использование NIS и DNS описано в главе 9.

• Таблицы узлов иногда применяют в очень маленьких, не связанных с

сетью Интернет, сетях. Если узлов в сети мало, информация об узлах из-

меняется редко, и нет необходимости во взаимодействии с внешним ми-

ром по TCP/IP, особых преимуществ использование DNS не даст.

Устаревший метод таблицы узлов не отвечает потребностям глобальной сети

Интернет по двум причинам: из-за невозможности масштабирования и от-

сутствия автоматизированного процесса обновления. До появления DNS ор-

ганизация под названием NIC (Network Information Center, Сетевой инфор-

мационный центр) занималась сопровождением огромной таблицы узлов се-

ти Интернет (таблица узлов NIC). Включенные в эту таблицу узлы носили

название зарегистрированных. Организация NIC добавляла в таблицу име-

на и адреса узлов для всех площадок сети Интернет.

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

имен узлов в IP-адреса, большинство подсетей регистрировали в таблице

лишь самые важные системы. Но даже при таком ограничении таблица вы-

росла до размеров, которые исключали эффективное преобразование имен в

IP-адреса. Невозможно использовать простую таблицу для обслуживания

огромного числа узлов, составляющих сегодняшний Интернет.

Вторая проблема, связанная с таблицей узлов, - отсутствие механизма авто-

матического распространения информации о новых узлах. К новым, заре-

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

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

тировать, что таблица узлов достигнет той или иной локальной сети, и нет

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

вие гарантированного единообразного распространения информации - серь-

езный недостаток системы таблиц узлов.

DNS

DNS исключает оба крупных недостатка таблиц узлов:

• DNS хорошо масштабируется. Система не зависит от единственной боль-

шой таблицы, в основе ее работы лежит распределенная база данных,

рост объема которой практически не сказывается на эффективности. На

Глава 3. Сетевые службы

сегодня DNS снабжает сеть информацией о примерно 100 ООО ООО узлов,

тогда как таблица NIC включала не более 10 ООО узлов.

• DNS гарантирует распространение информации о новых узлах по мере

необходимости.

Информация распространяется автоматически и только по необходимости.

Система доменных имен работает следующим образом. Сервер DNS, получив

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

(авторитативному) серверу (authoritative server). Компетентный сервер -

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

мену, о котором идет речь в запросе. Локальный сервер, получив от компе-

тентного сервера ответ, сохраняет, или кэширует, его для последующего ис-

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

вер отвечает на запрос самостоятельно. Способность получать информацию

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

ные сведения дает DNS значительное преимущество перед таблицами узлов,

даже в случае сетей, не подключенных к сети Интернет.

Система DNS пришла на смену не только таблице узлов, но и более старому

варианту службы имен. Так сложилось, что обе службы называют службой

имен. Обе упоминаются в файле /etc/services. Более старой системе назначен

UDP-порт 42 и имя nameserver, либо пате; служба имен DNS использует

порт 53 и носит имя domain. Естественно, это может послужить источником

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

ла. В тексте книги речь идет только о DNS, и, говоря «служба имен», мы бу-

дем иметь в виду именно ее.

Иерархия доменов

DNS - это распределенная иерархическая система, предназначенная для

преобразования имен узлов в адреса IP. В DNS не существует централизован-

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

формация распределена между многими тысячами серверов имен, связан-

ных в единую иерархию, схожую с иерархией файловой системы Unix. Вер-

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

торого занимается группа серверов имен, известных как корневые серверы.

Аналогично тому как каталоги файловой системы Unix описываются с по-

мощью путей, пролегающих от корневого каталога через промежуточные,

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

лям: от корневого домена - через промежуточные - к целевому.

Непосредственно под корневым доменом располагаются домены верхнего

уровня. Существует две основные категории доменов верхнего уровня - геог-

рафические и организационные. Каждая страна мира получила географи-

ческий домен с двухбуквенным именем-кодом. Поэтому данный тип доме-

нов называется доменом верхнего уровня с кодом страны, (ccTLD, country co-

de top-level domain). Например, ccTLD для Великобритании - .uk, для Япо-

нии - .jp, а для США - .us. Обычно для домена высшего уровня .us доменом

DNS

второго уровня служит почтовый код штата США (к примеру, .wy.us, если

речь идет о штате Вайоминг). Географические домены в США обычно ис-

пользуются администрациями штатов и образовательными учреждениями

уровня школ, но редко когда узлами иного рода.

В пределах США наиболее популярные домены верхнего уровня - это органи-

зационные домены, членство в которых основано на типе организации (ком-

мерческая, военная и т. д.), к которой принадлежит компьютерная система.

Такие домены называются родовыми доменами верхнего уровня, или универ-

сальными доменами верхнего уровня (gTLDs, generic top-level domains).

Ниже перечислены официально зарегистрированные родовые домены верх-

него уровня:

сот

Коммерческие организации

edu

Образовательные учреждения

gov

Правительственные организации

mil

Военные организации

net

Организации, обеспечивающие работу сетевой инфраструктуры

int

Международные правительственные или околоправительственные орга-

низации

org

Организации, не попадающие ни в одну из перечисленных выше катего-

рий, в частности некоммерческие предприятия

aero

Организации авиационной промышленности

biz

Предприятия

coop

Совместные предприятия

museum

Музеи

В США структурные и географические домены никак не связаны. Каждая систе-

ма принадлежит только к структурному либо только к географическому домену,

но не к тому и другому одновременно.

Глава 3. Сетевые службы

pro

Профессионалы, такие как медики и адвокаты

info

Сайты, предоставляющие информацию

пате

Физические лица

Итого, в настоящее время существует четырнадцать родовых доменов верх-

него уровня. Первые семь доменов списка (com, edu, gov, mil, net, int и org)

существовали в доменной системе изначально. Еще семь доменов (aero, biz,

coop, museum, pro, info и name) были созданы в 2000 году с целью увеличе-

ния числа доменов верхнего уровня. Одной из причин для создания допол-

нительных gTLD послужил гигантский размер домена .com. Домен настоль-

ко велик, что его размеры осложняют эффективное ведение базы данных

.com. Вопрос о том, смогут ли новые домены уменьшить регистрацию в .com,

остается открытым.

На рис. 3.1 приводится иерархия доменов, включающая шесть изначальных

организационных доменов верхнего уровня. Вершина дерева называется

корнем. Непосредственно под корневым доменом располагаются домены

верхнего уровня. Корневые серверы обладают полной информацией лишь о

доменах верхнего уровня. Полной информацией по всем доменам не облада-

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

указатели на серверы доменов второго уровня.

Так что корневые серверы,

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

Рис. 3.1. Иерархия доменов

На рис. 3.1 присутствует пара доменов второго уровня: nih в домене gov и wrotet-

hebook в домене сот.

DNS

Создание доменов и поддоменов

Некоммерческая организация ICANN (Internet Corporation for Assigned Na-

mes and Numbers), созданная в целях сопровождения процесса выделения

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

низаций-регистраторов. (Прежде процесс находился в ведении правительст-

ва США.) Регистраторы, авторизованные ICANN, имеют право выделять до-

мены. Чтобы получить домен, необходимо обратиться к регистратору, чтобы

получить право создать домен в одном из доменов верхнего уровня. (Подроб-

ности процесса получения доменного имени рассмотрены в главе 4.) Полу-

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

ны - поддомены - в пределах созданного. Рассмотрим процедуру на примере

нашей воображаемой компании.

Наша компания - это коммерческое, приносящее прибыль (хотелось бы на-

деяться) предприятие. Очевидно, оно должно располагаться в домене сот.

Мы обращаемся в уполномоченную организацию, чтобы создать домен wro-

tethebook в домене сот. Запрос нового домена содержит имена и адреса сер-

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

прос, регистратор помещает в домен сот указатели на серверы имен нового

домена. Теперь корневые серверы, получая запросы по домену wrotethebo-

ok.com, будут перенаправлять их к новым серверам имен.

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

лец любого зарегистрированного домена имеет право делить домен на поддо-

мены. Наша воображаемая компания может разбить домен на раздел, отве-

чающий за специальные события (events.wrotethebook.com), и раздел, коор-

динирующий подготовку журнальных статей (articles.wrotethebook.com), не

обращаясь при этом к регистратору или в иные «вышестоящие инстанции».

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

министратора домена. Регистраторы делегируют полномочия и распределя-

ют управление именами между отдельными организациями. Делегирование

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

ление выделенными ей именами.

Новый поддомен становится доступен, когда указатели на серверы нового

домена размещаются в домене уровнем выше (рис. 3.1). Удаленные серверы

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

этого домена не будет размещен в домене сот. Точно так же нельзя обратить-

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

мене wrotethebook.com. На серверы имен домена указывает запись в базе дан-

ных DNS, имеющая тип NS (name server). Запись этого типа содержит имя

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

примеры для базы данных DNS приводятся в главе 8. Пока что условимся

считать эти записи просто указателями.

Применение NS-записей в качестве указателей отражено на рис. 3.2. Ло-

кальному серверу необходимо преобразовать имя linuxuser.articles.wrotethe-

book.com в адрес IP. В кэше сервера отсутствуют сведения о домене wrotethe-

Глава 3. Сетевые службы

Рис. 3.2. DNS-запрос

book.com, поэтому происходит обращение к корневому серверу имен (в на-

шем примере a.root-servers.net) с запросом искомого адреса. Корневой сервер

отвечает NS-записыо, указывающей на узел crab.wrotethebook.com в качест-

ве источника информации по wrotethebook.com. Локальный сервер посылает

запрос узлу crab, который перенаправляет его к узлу linuxmag.articles.wro-

tethebook.com, серверу домена articles.wrotethebook.com. Локальный сервер

обращается к linuxmag.articles.wrotethebook.com и получает, наконец, иско-

мый адрес IP. Локальный сервер кэширует полученную А-запись (адресную

запись) и все NS-записи. Получив следующий запрос адреса linuxuser.artic-

les. wrotethebook.com, локальный сервер сможет ответить на него самостоя-

тельно. Получив следующий запрос, связанный с доменом wrotethebook.com,

локальный сервер обратится напрямую к узлу crab, не вовлекая в процесс

корневой сервер.

Рисунок 3.2 содержит примеры как рекурсивного, так и нерекурсивного по-

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

зывают локальному серверу, к кому обращаться далее. Локальный сервер

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

В случае рекурсивного поиска сервер следует по указателям и возвращает

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

только нерекурсивный поиск. Большинство других серверов выполняют ре-

курсивный поиск.

Доменные имена

Доменные имена отражают иерархию доменов. Запись доменных имен про-

изводится в направлении от частного (имени узла) к общему (домену верхне-

го уровня) и разделяется точками.

Абсолютное, или полностью определен-

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

пустой меткой, а потому записывается как «.».

DNS

кое, доменное имя (FQDN, fully qualified domain name) начинается с имени

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

ня. roaeit.wrotethebook.com - это абсолютное доменное имя (FQDN) рабочей

станции rodent, расположенной в поддомене wrotethebook домена сот.

Имена доменов не всегда записываются в абсолютной форме. Они могут за-

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

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

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

на по умолчанию. Например, если доменом по умолчанию является wrotet-

hebook.com, пользователь может опускать расширение wrotethebook.com для

всех узлов этого домена. Обращаться к узлу crab.wrotethebook.com можно бу-

дет по имени crab; DNS самостоятельно добавит к имени домен по умолча-

нию, wrotethebook.com.

В большинстве систем доменное имя по умолчанию добавляется только в

том случае, если в имени искомого узла отсутствуют точки. Так, имя linuxu-

ser.articles не подвергнется расширению, а значит, и не будет найдено серве-

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

les. Но имя узла crab, не содержащее точки, будет дополнено именем wrotet-

hebook.com, что даст в результате корректное доменное имя crab.wrotethebo-

ok.com. Как читатели узнают из главы 8, поведение DNS в данном аспекте

поддается настройке, что весьма в духе Unix-систем.

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

ты, зависящие от настройки программного обеспечения. По этой причине

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

Только абсолютные доменные имена и IP-адреса полностью защищены от

изменений в ПО сервера имен.

BIND, анализаторы и named

Самой распространенной реализацией DNS для систем Unix является пакет

Berkeley Internet Name Domain (BIND). Описания в тексте основаны на ре-

ализации сервера имен из пакета BIND.

Концептуально программное обеспечение DNS делится на две категории -

поисковые анализаторы (resolvers) и серверы имен. Анализатор (или кли-

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

просы. Сервер имен - это процесс, реагирующий на запросы; он дает ответы.

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

компьютере. Это библиотека подпрограмм (код поискового анализатора),

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

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

информации об узлах.

В случае BIND все машины используют код поискового анализатора, но не

на каждой работает процесс сервера имен. Компьютер, на котором не работа-

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