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

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

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

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

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

ных (Seen), непрочитанных (Unseen), удаленных (Deleted) и т. д.

Команда FETCH позволяет получить сообщение из почтового ящика. В данном

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

ную часть. Однако можно загрузить только заголовки сообщений или флаги.

Приняв сообщение, пользователь удаляет его, записывая флаг Deleted при

помощи команды STORE. Команда DELETE используется не для удаления

сообщений, а для удаления почтовых ящиков. Отдельные сообщения отме-

чаются для удаления установкой флага Delete. Сообщения с флагом Delete

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

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

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

Очевидно, протокол IMAP сложнее протокола POP и вплотную подошел к

той границе, за которой набор команд вручную становится неэффективным.

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

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

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

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

верка факта работоспособности демона imapd. Чтобы выполнить такую про-

верку, нет необходимости даже регистрироваться на сервере; достаточно

увидеть, что сервер реагирует на соединение, установленное при помощи

telnet. Затем остается лишь набрать команду LOGOUT, чтобы мягко за-

крыть соединение.

Многоцелевые расширения почтовой службы

(MIME)

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

обзоре, - это протокол MIME (Multipurpose Internet Mail Extensions).

Как

следует из названия, MIME является расширением существующей почтовой

системы TCP/IP, а не заменой для нее. MIME больше заботит характер дан-

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

пытка заменить SMTP или TCP, но способ расширить определение «почтово-

го сообщения».

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

менте RFC 822, Standard for the Format of ARPA Internet Text Messages

(Стандарт формата текстовых сообщений сети ARPA Internet). RFC 822 со-

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

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

вых системах, никак не связанных с протоколом SMTP. Такое положение

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

ленное взаимопонимание систем в вопросах перевода сообщений и доставки

MIME также является составной частью среды Web и протокола HTTP.

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

через шлюзы в различные почтовые сети. MIME дополняет RFC 822 в двух

аспектах, не затронутых исходным документом:

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

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

ASCII-данные. Этого вполне достаточно для пересылки текстовых дан-

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

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

• Поддержка сложного наполнения сообщений. В RFC 822 нет подробного

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

состав заголовков сообщений.

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

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

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

ектов. Документ RFC 1521 Multipurpose Internet Mail Extensions Part One:

Format of Internet Message Bodies содержит два определения заголовков,

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

различные виды данных. Речь идет о заголовках Content-Type и Content-

Transfer-Encoding.

Как следует из названия, заголовок Content-Type определяет тип данных,

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

Многие подтипы появились уже после публикации исходного документа

RFC. Список типов MIME, имеющих хождение, можно найти в сети Интер-

нет.

Исходный документ RFC определяет семь базовых типов содержимого

и ряд подтипов:

text

Текстовые данные. В RFC 1521 определены текстовые подтипы plain и

richtext. Помимо определенных в стандарте, появилось еще более 30 под-

типов, включая enriched, xml и html.

application

Двоичные данные. Основной подтип, определенный в RFC 1521, - это oc-

tet-stream, указывающий на поток 8-битных байтов двоичных данных.

Второй определенный в стандарте подтип - PostScript. Помимо опреде-

ленных в стандарте, появилось еще более 200 подтипов. Они отмечают

двоичные данные в формате конкретных приложений. Так, например,

существует application-подтип msword.

image

Статичные изображения в графическом формате. RFC 1521 определяет

два подтипа: jpeg и gif. Помимо определенных, появилось еще более 20 до-

полнительных подтипов, отражающих широко распространенные стан-

дарты хранения изображений, такие как tiff, cgm и g3fax.

Медиа-типы файлов доступны по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/

media-types.

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

video

Анимированные изображения. Изначально был определен подтип mpeg,

обозначающий распространенный стандарт хранения видеоданных на

компьютере. Помимо этого появилось еще несколько подтипов, включая

quicktime.

audio

Звуковые данные. Изначально был определен только один подтип - basic,

обозначавший кодирование звука в формате PCM (pulse code modulation,

импульсно-кодовая модуляция сигнала). В настоящее время существует

еще около 20 дополнительных audio-типов, таких как MP4A-LATM.

multipart

Данные, состоящие из нескольких независимых разделов. Тело multipart -

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

ляет четыре подтипа. Основной подтип, mixed, означает, что каждая

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

жимого. Прочие подтипы: alternative, обозначающий повторение данных

в различных форматах; parallel, означающий, что данные из различных

частей должны просматриваться единовременно; digest, означающий, что

данные разделов имеют тип message. В настоящее время уже существует

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

лосовых сообщений (voice-message) и зашифрованных сообщений.

message

Данные, инкапсулирующие почтовое сообщение. RFC 1521 определяет

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

ющие полное сообщение RFC 822. Подтипы partial и External-body пред-

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

капсуляции разбивать большие сообщения на ряд MIME-сообщений. Ex-

ternal-body указывает на внешний источник содержимого большого сооб-

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

а не само сообщение. Два дополнительных подтипа, news и http, позволя-

ют передавать соответственно сетевые новости и HTTP-трафик, отформа-

тированный по требованиям типизации содержимого MIME.

Заголовок Content-Transfer-Encoding определяет тип кодирования данных.

Консервативные SMTP-системы передают только 7-битные ASCII-данные с

длиной строки не более 1000 байт. Поскольку данные, исходящие от MIME-

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

ASCII-символы, возникает необходимость подвергать данные кодированию.

RFC 1521 определяет шесть типов кодирования. Некоторые из них позволя-

ют указывать кодировку, присущую данным. Лишь два типа связаны с кон-

кретными методами кодирования, определенными в RFC. Шесть типов ко-

дирования следующие:

7bit

Данные в формате ASCII. Семибитные ASCII-данные не подвергаются ко-

дированию.

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

8bit

Восьмибитные данные. Кодированию не подвергаются. Данные двоич-

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

есть не превышают в длину 1000 байт.

binary

Двоичные данные. Кодированию не подвергаются. Данные двоичные, а

длина строки может превышать 1000 байт. Между данными типа binary и

8bit нет разницы, кроме ограничения на длину строки; оба типа данных

представляют незакодированные потоки 8-битных байтов. MIME не из-

меняет незакодированные потоковые данные.

quoted-printable

Закодированные текстовые данные. Этот метод кодирования применяется

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

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

со значениями больше 127 или меньше 33 передаются закодированными в

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

вательность состоит из знака равенства и шестнадцатеричного значения

байта. Например, ASCII-символ прогона страницы, имеющий шестнадца-

теричное значение ОС, передается в виде =0С. Естественно, есть и другие

тонкости - так, знак равенства приходится передавать в виде =3D, а сим-

вол новой строки в конце строки не кодируется. Тем не менее описанный

метод дает представление о передаче данных в кодировке quoted-printable.

base64

Закодированные двоичные данные. Данный метод кодирования может

применяться для любого байтового потока данных. Три октета (8-битных

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

чивает размер файла на треть. 6-битные символы являются подмножест-

вом ASCII и выбранны так, чтобы проходить через почтовую систему про-

извольного типа. Максимальная длина строки для данных в формате Ъа-

se64 - 76 символов. Рис. 3.4 иллюстрирует кодирование символов З-в-4.

Рис. 3.4. Кодирование base64

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

x-token

Данные в специальной кодировке. Разработчики программного обеспече-

ния могут создавать собственные методы кодирования. Имена таких ме-

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

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

Число применяемых типов данных и методов кодирования растет с появле-

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

ментах RFC постоянно определяются дополнительные типы данных и коди-

ровки. В поисках самой свежей информации по возможностям MIME обра-

щайтесь к последним версиям документов RFC.

MIME определяет т гаы данных, перенос которых не планировался при раз-

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

определен метод расширения SMTP - в документе RFC 1869, SMTP Service

Extensions. RFC 1869 не определяет новых служб для SMTP; более того, в

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

других RFC. RFC 1869 определяет простой механизм, позволяющий систе-

мам SMTP согласовывать использование расширений. В документе опреде-

лена новая команда приветствия (EHLO) и приемлемые ответы на эту ко-

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

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

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

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

мой. Реализации SMTP, понимающие команду EHLO, известны в качестве

систем ESMTP (Extended SMTP).

Для почтовых программ MIME определен ряд дополнительных служб ESMTP.

Отдельные расширения перечислены в табл. 3.4. Первая колонка таблицы

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

вторая - номер руководящего документа RFC, третья - назначение расши-

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

тина включает и другие усовершенствованные аспекты SMTP.

Таблица 3.4. Расширения служб SMTP

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

Ключевое слово

RFC Функциональность

STARTTLS

2487

Использует механизм Transport Layer Security для шифро-

вания почтового обмена

AUTH

2554

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

источника почтовых сообщений

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

манды EHLO. Следующий пример относится к стандартной системе

Solaris 8, в состав которой входит sendmail 8.9.3:

Перечень ключей и аргументов командной строки sendmail приводится в прило-

жении Е.

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

манд. Две из них, EXPN и HELP, являются стандартными командами

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

лены в табл. 3.1). 8BITMIME, SIZE, DSN и ETRN - расширения ESMTP, опи-

санные в табл. 3.4. Еще три ключевых слова из ответа- VERB, ONEX и

XUSR. Эти команды специфичны для sendmail версии 8. Их определений

нет в документах RFC. VERB предписывает серверу sendmail работать в ре-

жиме подробной диагностики. ONEX ограничивает сеанс транзакциями для

отдельных сообщений. XUSR - это эквивалент ключа -U командной строки

sendmail.

Как видно по трем последним ключевым словам, документы RFC

допускают применение частных расширений ESMTP.

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

стандартной системы Solaris 2.5.1 в ответ на команду EHLO отображается

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

лишь три ключевых слова (EXPN, SIZE и HELP). То, какие расширения до-

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

Назначение команды EHLO - выявить конкретику расширений до начала

почтового обмена SMTP.

ESMTP и MIME - важные механизмы, позволяющие передавать посредст-

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

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

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

ным механизмом передачи таких файлов.

Протоколы SMTP, POP, IMAP и расширения MIME - это жизненно важные

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

протоколы электронной почты. Можно с уверенностью говорить лишь о том,

что сеть постоянно меняется. Необходимо следить за изменениями и не за-

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

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

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

чати.

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

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

зователей. Еще недавно дисковые накопители и высококачественные прин-

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

лись на каждом шагу. Сегодня в каждую систему устанавливается вмести-

тельный жесткий диск, а многие системы оснащены высококачественными

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

к ресурсам продолжает возрастать.

Совместный доступ к файлам

Совместный доступ к файлам - совсем не то же самое, что передача файлов;

это не просто способность систем обмениваться файлами. Корректно постро-

енная система совместного доступа к файлам не требует копирования фай-

лов по сети. Она организует доступ к файлам на уровне отдельных записей,

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

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

ликом с сервера на систему клиента и обратно.

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

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

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

они хранились локально. В идеальной среде совместного доступа к файлам

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

нятся файлы.

Подробности настройки sendmail приводятся в главе 10.

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

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

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

дисковых рабочих станций. Существует целый ряд протоколов TCP/IP для

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

львиная доля этого рынка:

NetBIOS / блок серверных сообщений (NetBIOS/Server Message Block )

Авторство системы NetBIOS принадлежит IBM. Это базовая сетевая сис-

тема ввода-вывода используется в ОС Microsoft Windows. Системы Unix

способны действовать в качестве файловых серверов и серверов печати

для клиентов Windows - при помощи программного пакета Samba, кото-

рый реализует протоколы NetBIOS и SMB (Server Message Block, блок

серверных сообщений).

Сетевая файловая система (Network File System )

Система NFS создана компанией Sun Microsystems в целях поддержки

производимых ею бездисковых рабочих станций. NFS спроектирована

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

ти, а реализации NFS существуют для всех ОС Unix и многих других опе-

рационных систем.

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

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

ного назначения. Поддержка Windows-клиентов серверами, работающими

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

этих инструментах содержится в главе 9.

Службы печати

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

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

ступ к файлам, но при этом остается полезной сетевой службой. Каковы же

преимущества совместного доступа к печатающим устройствам?

• Появляется возможность сократить число принтеров, объемы затрат на

приобретение собственно устройств и расходных материалов.

• Сокращение затрат на поддержку. Становится меньше машин и, соответ-

ственно, сокращается штат обслуживающего персонала.

• Доступ к особым принтерам. Устройства высококачественной цветной

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

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

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

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

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

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

тов Windows. Второй подход - использовать традиционную команду Unix

1 рг и демон печати Ipd. Настройка сервера печати также описана в главе 9.

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

Эта глава завершается рассказом о различных типах серверов настройки

TCP/IP. Серверы настройки, в отличие от электронной почты, совместного

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

дой сети. Однако потребность в упрощенной установке и повышенной мо-

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

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

Мощные возможности, повышающие практичность и гибкость TCP/IP, по-

вышают одновременно и его сложность. Система TCP/IP не столь проста в

настройке, как некоторые другие сетевые системы. TCP/IP требует наличия

информации по аппаратной части, по адресации и маршрутизации - в про-

цессе настройки. Система работает независимо от сетевого оборудования,

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

делается в других системах. Информация должна исходить от человека, от-

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

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

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

положение не всегда оправдано.

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

стройкой TCP/IP централизованно. Это частично освобождает конечного

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

настройке, повышается.

В TCP/IP существует три протокола, упрощающих задачу настройки: RARP,

ВООТР и DHCP. Прежде всего, обратимся к RARP, самому старому и самому

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

Протокол обратного разрешения адресов (RARP)

Протокол RARP (Reverse Address Resolution Protocol), определенный доку-

ментом RFC 903, позволяет выполнять преобразование физического сетево-

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

шения адресов (Address Resolution Protocol, ARP). Сервер RARP преобразу-

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

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

соответствующими службами физической сети.

Широковещательный па-

кет содержит адрес клиента в физической сети и запрашивает у любой ком-

петентной системы сети IP-адрес, связанный с данным физическим адресом.

Сервер RARP отвечает пакетом, содержащим IP-адрес клиента.

Клиент знает свой адрес в физической сети, поскольку этот адрес зашит в ин-

терфейсное устройство Ethernet. В большинстве систем есть команда, с по-

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

службы физической сети, расположенные под уровнем Internet. Уровни протоко-

лов TCP/IP описаны в главе 1.

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

Команда ifconfig позволяет устанавливать и отображать значения настрой-

ки сетевых интерфейсов.

dnetO - это имя устройства интерфейса Ethernet.

Адрес Ethernet отображается после метки ether. В приведенном примере это

адрес 0:0:c0:dd:d4:da.

Сервер RARP ищет IP-адрес для ответа клиенту в файле /etc/ethers. Файл

/etc/ethers содержит строки, состоящие из адресов Ethernet и имен узлов

клиентов. Например:

Имея эти файлы, сервер, получив RARP-запрос с адресом Ethernet

0:80:с7:аа:а8:04, сопоставляет адрес с именем 24seven из файла /etc/ethers.

Затем сервер ищет IP-адрес для имени 24seven и возвращает ответ ARP - ад-

рес IP 172.16.3.4.

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

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

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

ВООТР (Bootstrap Protocol), предоставляющий дополнительные значения,

помимо адреса IP, и позволяющий получать эти значения по сети.

Определение ВООТР дается документами RFC 951 и RFC 1532. Протокол

ВООТР описан в качестве альтернативы RARP: если используется ВООТР,

отпадает необходимость в применении RARP. При этом ВООТР - в качестве

протокола настройки - имеет ряд преимуществ перед RARP. Он предостав-

Команда ifconfig описана в главе 6.

Чтобы ответить на RARP-запрос, сервер должен также выполнить разреше-

ние имени узла из файла /etc/ethers в адрес IP. С этой целью используется

DNS или файл таблицы узлов. Вот такие записи файла hosts узлов могут со-

ответствовать приведенному выше файлу ethers:

мощью которой это значение можно с легкостью получить. Например, в сис-

теме Solaris 8 суперпользователь может набрать такую команду: