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

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

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

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

чистыми DNS-клиентами оказываются однопользовательские системы.

В более крупных Unix-системах обычно существует локальный процесс сер-

вера имен.

Сервер имен BIND представлен самостоятельным процессом демона named

(произносится «нэйм-ди»). Классификация серверов имен основана на спо-

собах их настройки. Вот три главных категории серверов имен:

Основной (Master)

Основной сервер (также известный как первичный (primary) сервер) - это

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

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

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

(authoritative), то есть обладают полной информацией по обслуживаемым

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

один основной сервер для домена.

Подчиненный (Slave )

Подчиненные серверы (также известные как вторичные) получают пол-

ную базу данных домена от основного сервера. База данных для отдельно-

го домена называется файлом зоны; копирование этого файла на подчи-

ненный сервер называется передачей зоны. Подчиненный сервер гаран-

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

мена. Подчиненные серверы также являются компетентными для

обслуживаемых доменов.

Специальный кэширующий (Caching-only)

Специальные кэширующие серверы получают ответы на все запросы от

других серверов имен. Получив ответ на запрос, сервер кэширует инфор-

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

на запросы. Большинство серверов имен практикуют кэширование. Спе-

циальные кэширующие серверы используют исключительно этот метод

для построения базы данных домена. Кэширующие серверы являются

некомпетентными (non-authoritative), их информация получена из вто-

рых рук и неполна, хотя обычно точна.

Взаимоотношения различных типов серверов - это преимущество DNS пе-

ред таблицами узлов, которое ощутимо для большинства сетей, даже очень

маленьких. В DNS каждому домену требуется лишь один первичный сервер

имен. Данные DNS вводятся в базу данных первичного сервера администра-

тором домена. Следовательно, централизованное управление информацией

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

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

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

ходимости редактировать файлы /etc/hosts на всех узлах сети; достаточно

изменить базу данных DNS на первичном сервере. Информация автомати-

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

ностью либо кэшируют отдельные ответы.

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

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

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

) - это

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

rosystems. Она предоставляет централизованное управление и автоматичес-

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

няться совместно с DNS либо в качестве альтернативы.

NIS и DNS обладают как сходствами, так и различиями. Подобно DNS, сис-

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

но, в отличие от DNS, является решением лишь для локальных сетей. NIS не

предназначается для сети Интернет в целом. Еще одно отличие - NIS предо-

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

выходит далеко за рамки простого преобразования «имя-адрес». NIS преоб-

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

сов по сети. Такие базы данных получили название карт NIS.

NIS преобразует в карты такие файлы, как /etc/hosts и /etc/networks. Карты

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

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

ванное сопровождение в сочетании с автоматическим распространением поз-

воляет NIS восполнить один из крупных недостатков таблицы узлов. Однако

NIS не является альтернативой DNS для сети Интернет, поскольку таблицы

узлов, а следовательно, и карты NIS содержат лишь часть информации, ко-

торой владеет DNS. По этой причине DNS и NIS обычно применяются в паре.

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

тодов преобразования имен узлов в адреса IP. Разумеется, это лишь фраг-

мент картины. Назначение имен узлов и управление службой имен - важ-

ные задачи сетевого администратора, и эти темы будут еще не раз подняты в

книге. Подробные же сведения приводятся в главе 8.

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

Наверняка пригодится и еще одна - служба электронной почты.

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

Пользователи считают электронную почту важнейшей из сетевых служб,

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

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

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

для непрерывной работы в сети. Электронная почта - приложение для обще-

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

и не очень изысканной.

TCP/IP обеспечивает надежную, гибкую систему электронной почты, постро-

енную на ряде базовых протоколов. Речь идет о протоколах SMTP (Simple Ma-'

Исходное название NIS - «Желтые страницы» (Yellow Pages, или ур). Несмотря

на смену имени, сокращение ур по-прежнему в ходу.

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

it Transfer Protocol, простой протокол передачи почты), POP (Post Office Pro-

tocol, протокол почтовой службы), IMAP (Internet Message Access Protocol,

Интернет-протокол доступа к сообщениям), а также MIME (Multipurpose In-

ternet Mail Extensions, многоцелевые расширения почтовой службы в Ин-

тернете). Прочие почтовые протоколы TCP/IP, обладающие привлекатель-

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

Ниже мы поговорим о четырех протоколах, которые почти наверняка при-

меняются в любой локальной сети: SMTP, POP, IMAP и MIME. Начнем ис-

следования с протокола SMTP, фундамента всех систем электронной почты

TCP/IP.

Простой протокол передачи почты (SMTP)

SMTP - это TCP/IP-протокол доставки электронных сообщений. Он перено-

сит почту по сети Интернет и по локальным сетям. Определение SMTP дает-

ся в документе RFC 821, A Simple Mail Transfer Protocol. Протокол функци-

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

ления передачей (Transmission Control Protocol, TCP) и работает через порт с

широко известным номером 25.

В табл. 3.1 перечислены некоторые из прос-

тых команд SMTP, вполне пригодных для восприятия человеком.

Таблица 3.1. Команды SMTP

Команда

Синтаксис Назначение

Hello

HELO <узел-отправитель>

EHLO <узел-отправитель>

Источник SMTP-отправки

From

MAIL FROM:<исходный адрес> Адрес отправителя

Recipient RCPT TOКконечный адрес>

Адрес получателя

Data

DATA

Начать сообщение

Reset

RSET

Прервать сообщение

Verify

VRFY <строка>

Проверить имя пользователя

Expand

EXPN <строка>

Раскрыть список рассылки

Help

HELP [строка]

Запросить справку

Quit

QUIT

Завершить сеанс SMTP

SMTP - протокол настолько простой, что работу по этому протоколу пользо-

ватель может в буквальном смысле осуществлять самостоятельно. Подклю-

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

сообщение в командной строке при помощи команд SMTP. Этот способ иног-

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

Большинству стандартных приложений TCP/IP назначены широко известные но-

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

ленной службе.

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

его помощью проиллюстрируем процесс передачи почты между системами.

В приводимом ниже примере пользователь Daniel с узла rodent.wrotethebo-

ok.com вручную набрал и отправил письмо пользователю Tyler узла crab.wro-

tethebook.com.

Ввод пользователя выделен жирным шрифтом. Остальные строки представ-

ляют вывод системы. Как видите, все очень просто. Открывается ТСР-соеди-

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

Передача сообщения начинается командой DATA и заканчивается строкой,

содержащей только точку (.). Сеанс завершается по команде QUIT. Очень

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

В RFC 821 определены и другие команды (SEND, SOML, SAML, TURN), ко-

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

ния в реализациях SMTP. Даже некоторые из реализованных команд не на-

ходят широкого применения. Команды HELP, VRFY и EXPN предназначе-

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

двух систем по протоколу SMTP. Следующий фрагмент сеанса SMTP демон-

стрирует работу этих дополнительных команд.

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

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

Команда HELP RSET запрашивает информацию по команде RSET. Откро-

венно говоря, эта справочная система не очень-то полезна!

Команды VRFY и EXPN более полезны, но часто блокируются из соображе-

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

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

систему. Команда EXPN <admin> запрашивает перечень адресов электронной

почты из списка рассылки admin, и система услужливо возвращает такой

список. Команда VRFY запрашивает информацию не о списке рассылки, но

о конкретном пользователе. В случае команды VRFY <mac>, mac оказывается

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

определенная информация. В случае VRFY <jane>, jane - это псевдоним из

файла /etc/aliases. Возвращаемое значение - электронный адрес jane, ука-

занный в этом файле. Три команды последнего примера интересны, но редко

используются. Свою работу SMTP выполняет при помощи других команд.

SMTP обеспечивает прямую сквозную доставку почты. Прочие почтовые

системы, такие как UUCP и X. 400, используют протоколы передачи с про-

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

пункту назначения - следующей системе. Каждая из систем в конце тран-

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

ющей системе. Сообщение путешествует таким образом, пока не попадет в

пункт назначения. Рисунок 3.3 иллюстрирует почтовые системы с промежу-

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

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

разумевает прямую доставку.

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

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

этом немедленно. Она может уведомить пользователя, что сообщение от-

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

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

она требует от обеих систем полной готовности к работе с почтовыми сообще-

ниями. Некоторые системы не пособны работать с почтой напрямую, в осо-

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

так получилось, что адрес в UUCP дополнительно иллюстрирует контекст.

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

Рис. 3.3. Системы доставки почтовых сообщений

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

Такие системы часто выключаются в конце рабочего дня и могут большую

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

узла дает сбой и завершается сообщением о том, что невозможно установить

соединение, если локальная система выключена или не находится в сети. С

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

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

вый сервер. Затем, когда система-клиент вновь устанавливает соединение с

сетью, почта попадает к ней уже с почтового сервера. Один из протоколов,

применяемых в сетях TCP/IP с этой целью, носит название протокола почто-

вой службы (Post Office Protocol, POP).

Протокол почтовой службы (POP)

Существует два варианта протокола почтовой службы: РОР2 и РОРЗ. РОР2,

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

а РОРЗ, определенный в документе RFC 1725, через порт 110. Несмотря на

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

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

регистрационное имя пользователя и пароль, а затем перемещают почту

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

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

поэтому наше внимание будет сосредоточено на РОРЗ.

Проиллюстрируем работу POP-протокола на примере сеанса РОРЗ. РОРЗ -

это простой протокол запросов/ответов; как и в случае SMTP, команды

РОРЗ можно передавать напрямую через широко известный порт (110) и не-

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

Команда USER позволяет указать имя пользователя, а команда PASS - па-

роль для учетной записи, связанной с почтовым ящиком. (Это те же самые

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

серверу.) В ответ на команду STAT сервер передает число сообщений в поч-

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

В данном примере сервер хранит три сообщения общим объемом в 459 байт.

RETR 1 позволяет получить полный текст первого сообщения. DELE 1 удаляет

это сообщение с сервера. После извлечения с сервера каждое из сообщений

удаляется. Клиент завершает сеанс командой QUIT. Проще некуда! В

табл. 3.2 перечислены все команды РОРЗ.

Таблица 3.2. Команды РОРЗ

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

лен жирным шрифтом:

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

Аргументом команды извлечения (RETR) или удаления (DELE) служит но-

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

рядке. Кроме того, нет прямой связи между извлечением и удалением сооб-

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

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

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

содержимое почтового ящика полностью переносится с сервера на клиент-

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

честве непрочитанного. Удаление отдельных сообщений на клиентской ма-

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

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

сохраняется после передачи клиенту. Клиенты электронной почты, испыты-

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

вере, скорее будут использовать протокол IMAP.

Интернет-протокол доступа к сообщениям (IMAP)

Интернет-протокол доступа к сообщениям (Internet Message Access Protocol,

IMAP) является альтернативой протоколу POP. Он содержит те же базовые

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

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

ентской машине, так и прямо на сервере, обеспечивая при этом актуаль-

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

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

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

Для надежной, последовательной передачи данных IMAP использует TCP.

Порт протокола IMAP - TCP 143.

Подобно протоколу POP, IMAP работает по

модели запрос/ответ и содержит небольшое число команд. Набор команд

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

В файле /etc/services присутствует два определения портов для IMAP: 143 и 220.

Порт 220 используется в IMAP 3, а 143 - в IMAP 4 и IMAP 2.

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

совершенной функциональностью. При этом число команд IMAP не превыша-

ет двадцати пяти. Основные команды IMAP, определенные документом RFC

2060, Internet Message Access Protocol - Version 4revl, приведены в табл. 3.3.

Таблица 3.3. Команды IMAP4

Команда Действие

CAPABILITY Перечисляет возможности, поддерживаемые сервером

NOOP

Буквально означает «нет действия»

LOGOUT

Закрывает соединение

AUTHENTICATE Запрашивает альтернативный метод проверки аутентичности

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

редачей открытым текстом

SELECT

Открывает почтовый ящик

EXAMINE Открывает почтовый ящик в режиме «только для чтения»

CREATE Создает новый почтовый ящик

DELETE

Удаляет почтовый ящик

RENAME Изменяет имя почтового ящика

Добавляет почтовый ящик в перечень активных

UNSUBSCRIBE Удаляет почтовый ящик из перечня активных

LIST

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

ного набора имен

LSUB

Отображает указанные имена почтовых ящиков, выбирая из на-

бора активных

STATUS Отображает состояние почтового ящика

APPEND

Добавляет сообщение в конец указанного почтового ящика

CHECK

Принудительное создание контрольной точки для текущего поч-

тового ящика

Закрывает почтовый ящик и стирает все сообщения, отмеченные

для удаления

EXPUNGE Стирает из текущего почтового ящика все сообщения, отмечен-

ные для удаления

Отображает все сообщения почтового ящика, соответствующие

критерию поиска

FETCH

Извлекает сообщение из почтового ящика

STORE Изменяет сообщение в почтовом ящике

COPY

Копирует указанные сообщения в конец указанного почтового

ящика

UID

Находит сообщение по уникальному идентификатору

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

Первые три и последняя строки исходят от программы telnet; все прочие со-

общения принадлежат IMAP. Первая введенная пользователем команда

IMAP - это LOGIN; она указывает имя пользователя и пароль из файла /etc/

passwd для его аутентификации. Обратите внимание, команду предваряет

строка А0001. Это тег, представляющий собой уникальный идентификатор,

создаваемый клиентом для каждой команды. Каждая команда должна начи-

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

Протокол IMAP ориентирован на работу с почтовыми ящиками. Команда

SELECT выбирает почтовый ящик, с которым происходит работа. В данном

примере пользователь выбрал почтовый ящик с именем «inbox». Сервер

IMAP отображает состояние ящика. Можно видеть, что ящик содержит три

Приведенный набор команд четко отражает ориентированность протокола

IMAP на работу с почтовыми ящиками. Протокол проектировался в качест-

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

что видно по командам протокола. Несмотря на возросшую сложность про-

токола работу сервера IMAP все так же можно проверить при помощи telnet

и небольшого числа команд.