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

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

102

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

ляет гораздо больший объем информации и потенциально позволяет этот

объем наращивать. В исходную спецификацию был заложен механизм раз-

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

ний. Определение подобных расширений впервые было формализовано в

RFC 1048, с ходом времени обновлялось, и на сегодняшний день в наиболее

полном виде содержится в RFC 2132. Протокол ВООТР и его расширения

стали фундаментом протокола динамической настройки узлов DHCP (Dyna-

mic Host Configuration Protocol). Протокол DHCP пришел на смену ВООТР,

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

Протокол динамической настройки узлов (DHCP)

Протокол динамической настройки узлов (Dynamic Host Configuration Pro-

tocol, DHCP) определен в документах RFC 2131 и RFC 2132. Архитектура

DHCP делает его совместимым с ВООТР. Взаимодействие между клиентами

ВООТР и серверами DHCP, а также клиентами DHCP и серверами ВООТР

описано в документе RFC 1534. DHCP - это верный выбор, если говорить о

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

можностям, сохраняя при этом поддержку существующих ВООТР-клиентов.

В DHCP применяются те же номера UDP-портов, что и в ВООТР (67 и 68), и

тот же базовый формат пакетов. При этом протокол DHCP является не прос-

то обновлением ВООТР. Он расширяет функциональность ВООТР в двух ас-

пектах:

• Параметры настройки, распространяемые сервером DHCP, включают все

значения, перечисленные в документе RFC Requirements for Internet

Hosts (Требования для узлов сетей Интернет). DHCP обеспечивает клиен-

та полным набором значений настройки TCP/IP.

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

Изначальный пакет ВООТР в DHCP расширен и включает указание типа па-

кета DHCP, а также полный набор данных настройки. Значения этой части

пакета в DHCP называются параметрами (options). В целях охвата всего на-

бора параметров настройки из RFC Requirements for Internet Hosts поле Op-

tions имеет довольно большой размер и переменный формат.

Как правило, не возникает потребности в полном наборе значений настрой-

ки. Но речь не о том, что без каких-то значений можно обойтись - все пара-

метры участвуют в процессе настройки TCP/IP. Просто не для каждого па-

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

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

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

этот протокол более совершенным, чем ВООТР, но не этот аспект оказывает-

ся самым привлекательным среди нововведений в DHCP.

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

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

ресов четырьмя путями:

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

103

Фиксированные постоянные адреса

Как и ранее, администратор может назначать адреса без помощи системы

DHCP. При том, что подобное назначение происходит вне ведома DHCP,

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

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

встречаются в большинстве сетей.

Выделение вручную

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

конкретные адреса конкретным клиентам при настройке DHCP. Точно

так же управление адресами происходит в ВООТР. Выделение вручную

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

боваться для обслуживания клиентов ВООТР.

Автоматическое выделение

Сервер DHCP назначает постоянный адрес, выделяя его из резерва адре-

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

Этот способ не позволяет применить способность сервера DHCP собирать

и повторно использовать адреса.

Динамическое выделение

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

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

(lease). Клиент может вернуть адрес серверу в любой момент, но обязан

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

писанного времени жизни. Если клиент не запросил продление, сервер

автоматически отбирает адрес. Динамическое выделение адресов - на-

иболее эффективное из применений DHCP.

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

деленной сети с флуктуацией (добавлением и удалением) узлов. Невостребо-

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

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

Динамическое выделение позволяет максимально эффективно использовать

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

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

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

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

администратора.

Динамическое выделение адресов действует не для всех систем. Серверы

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

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

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

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

ные фиксированные адреса.

Динамическое назначение адресов оказывает существенное влияние на сис-

тему DNS. Смысл DNS - в отображении имен узлов в адреса IP. Если 1Р-ад-

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

реса постоянно изменяются, а система доменных имен об этом не узнает, она

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

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

ки обновляемая сервером DHCP. Существует система Dynamic DNS (DDNS),

но пока еще она не получила широкого распространения.

В должное время

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

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

Вследствие природы динамической адресации, в большинстве локальных

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

Это делается путем обычного администрирования, и DHCP в этом процессе

не участвует. По сути дела, администратор такого сервера получает адрес и

использует этот адрес при настройке. Использование DHCP для настройки

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

стройки всех систем без исключения.

Серверы DHCP могут осуществлять поддержку клиентов ВООТР. Но чтобы

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

Клиенты ВООТР не умеют работать с динамической арендой адресов. Они не

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

продлению. Клиентам ВООТР должны назначаться постоянные фиксиро-

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

значение адресов - привилегия клиентов DHCP.

Итак, для большинства локальных сетей, в которых применяется DHCP,

верны следующие пункты:

• Постоянные адреса назначаются системам, которые не могут работать

с DHCP

• Клиентам ВООТР адреса назначаются вручную

• Всем клиентам DHCP адреса назначаются динамически

В результате встает вопрос: каким образом клиент, не знающий собственно-

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

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

стройки.

Принципы работы DHCP

Клиент DHCP посылает широковещательный пакет (сообщение DHCPDIS-

COVER), содержащий как минимум идентификатор транзакции и DHCP-

идентификатор клиента - обычно его адрес в физической сети. В качестве

адреса отравки широковещательного пакета выступает ограниченный широ-

ковещательный адрес 255.255.255.255.

Клиент ожидает ответ сервера. Ес-

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

Дополнительная информация о DDNS содержится в главе 8.

Данный адрес полезен по той причине, что, в отличие от стандартного широкове-

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

она расположена.

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

105

DHCP использует в качестве транспортного протокола UDP, так что, в отли-

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

тупа к сети.

Сервер отвечает на сообщение клиента пакетом DHCPOFFER. В работе DHCP

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

зуется сервером, а порт UDP 68 - клиентом. Такое положение дел необычно.

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

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

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

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

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

Однако клиент DHCP находится в процессе загрузки и, вероятнее всего, не

знает своего IP-адреса. Даже если клиент сгенерирует исходный порт для

пакета DHCPDISCOVER, ответ сервера, адресованный на этот порт и IP-ад-

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

DHCP посылает ответ на конкретный порт для всех узлов. Широковеща-

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

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

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

тор транзакции и физический адрес, содержащиеся в пакете ответа.

Сервер заполняет пакет DHCPOFFER данными настройки для клиента.

Корректно настроенный сервер DHCP способен предоставить клиенту любое

требуемое значение настройки TCP/IP. Глава 9 является руководством по

установке сервера DHCP, а приложение D содержит полный перечень пара-

метров настройки DHCP.

Как следует из названия, пакет DHCPOFFER - это предложение данных на-

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

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

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

DHCPDISCOVER от клиента и ответить пакетом DHCPOFFER могут сразу

несколько серверов. Если бы сервер не требовал ответа от клиента, могла

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

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

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

клиент реагирует лишь на один из них.

На пакет DHCPOFFER клиент отвечает сообщением DHCPREQUEST. Сооб-

щение DHCPREQUEST говорит серверу, что клиент согласен на использова-

ние предложенных настроек. Сервер проверяет информацию в DHCPREQ-

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

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

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

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

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

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

Рис. 3.5. Клиент-серверный протокол DHCP

Резюме

TCP/IP содержит отдельные сетевые службы, упрощающие создание, на-

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

применяемая во всех сетях TCP/IP.

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

ных имен DNS (Domain Name System) либо сетевой информационной систе-

мы NIS (Network Information Service). Таблица узлов - это простой набор за-

писей, хранимых в текстовом файле /etc/hosts. В большинстве систем су-

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

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

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

страниц» от Sun, решает проблему автоматического распространения для

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

пришедшая на смену таблицам узлов в качестве стандарта TCP/IP, замеча-

тельно масштабируется. DNS - это иерархическая система распределенной

базы данных, обеспечивающая доступ к информации по именам и адресам

для всех систем сети Интернет.

Структурными элементами системы электронной почты в TCP/IP являются

протоколы SMTP (Simple Mail Transfer Protocol, простой протокол передачи

почты), POP (Post Office Protocol, протокол почтовой службы), IMAP (Inter-

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

а также MIME (Multipurpose Internet Mail Extensions, многоцелевые расши-

рения почтовой службы в Интернете). Простой протокол SMTP работает по

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

Резюме

107

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

та передается по определенному маршруту почтовому серверу. Для переноса

сообщений с сервера на систему пользователя в TCP/IP применяются прото-

колы POP и IMAP. SMTP позволяет пересылать только 7-битные ASCII-дан-

ные. MIME расширяет почтовую систему TCP/IP, делая возможной переда-

чу самых разнообразных видов данных.

Сетевая файловая система NFS (Network File System) - основной протокол

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

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

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

ми. Для организации совместного доступа к принтерам в сети TCP/IP может

применяться протокол Unix LPD/LPR. Система Samba предоставляет сход-

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

клиентов Windows.

Установка TCP/IP требует присутствия многих значений настройки. Эти

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

настроечной информации в TCP/IP используются следующие протоколы:

RARP

Протокол обратного разрешения адресов (Reverse Address Resolution Pro-

tocol) сообщает клиенту его адрес IP. Сервер RARP решает эту задачу пу-

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

ресов Ethernet в адреса IP хранятся на сервере в файле /etc/ethers.

ВООТР

Протокол инициализации позволяет получать целый ряд значений на-

стройки.

DHCP

Протокол динамической настройки узлов (Dynamic Host Configuration

Protocol) заменяет ВООТР службой, предоставляющей полный набор па-

раметров настройки, описанный в документе RFC Requirements for Inter-

net Hosts. Кроме того, DHCP реализует динамическое выделение адресов,

что позволяет эффективно распределять ограниченные наборы адресов.

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

TCP/IP. В следующей главе мы займемся созданием сети TCP/IP и начнем с

процесса планирования установки.

Начинаем работу

• Связанные и не связанные

с Интернетом сети

• Базовые сведения

• Планирование: маршрутизация

• Планирование: служба имен

• Прочие службы

• Что сообщить пользователям

В этой главе мы переходим от механизмов TCP/IP к вопросам настройки.

Первые три главы содержали описание протоколов TCP/IP и принципов их

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

шаг этого процесса - планирование. Настройка узла для работы с TCP/IP

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

должен иметь имя и уникальный IP-адрес. Кроме того, следует уточнить

следующие параметры:

Адрес шлюза по умолчанию

Если предполагается обмен данными по TCP/IP с системами, располо-

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

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

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

Адреса серверов имен

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

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

Имя домена

Узлы, работающие с системой доменных имен, должны знать свое домен-

ное имя.

Маска подсети

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

зовать корректную сетевую маску.

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

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

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

тие и распространение решений, касающихся настройки и конфигурации

Связанные и не связанные с Интернетом сети

109

сети в целом. В случае существующей сети TCP/IP читатели могут смело

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

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

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

данных сетей.

Если речь идет о создании сети TCP/IP с нуля, необходимо принять ряд стар-

товых решений. Будет ли новая сеть связана с Интернетом? Если так, то по-

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

ровать доменное имя? Как выбирать имена узлов? В последующих разделах

мы изучим информацию, необходимую для принятия таких решения.

Связанные и не связанные с Интернетом сети

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

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

полностью доступна для других сетей. Несвязанная сеть напрямую не под-

ключена к сети Интернет, и доступ из нее в Интернет ограничен. Примером

несвязанной сети может служить сеть TCP/IP, в которой сообщение с внеш-

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

ствляющий преобразование сетевых адресов (NAT). Пользователи несвязан-

ной сети могут работать с внешними системами, узлами сети Интернет, но

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

ми несвязанной сети. Несвязанные сети не предоставляют внешнему миру

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

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

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

жения информационных служб, основанные на TCP/IP (в частности, веб-сер-

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

ции, называются интрасетями (intranets), или корпоративными сетями.

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

лишь частично подключенными к сети Интернет. Первая из таких причин -

безопасность. Подключение к любой сети увеличивает число людей, имею-

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

пользователей способно напугать любого специалиста по безопасности. Вне

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

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

противостояния этой угрозе.

Второй момент - затраты. Многие организации не видят особой пользы в

том, что каждая настольная система обретет полное подключение к Интер-

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

ченные запросы (например, использование только электронной почты) не

оправдывают затрат на подключение к Интернету целой сети. Иногда основ-

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

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

110 Глава 4. Начинаем работу

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

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

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

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

мации на веб-узлах.

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

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

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

Интернет - это средство предоставления услуг и поддержки клиентов.

Оба типа сети могут присутствовать одновременно: несвязанная сеть пред-

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

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

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

Без точного определения потребностей и затрат на подключение к сети Ин-

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

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

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

и услугами. Некоторые из подобных организаций специализируются на

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

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

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

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

ности, в которых может нуждаться ваша сеть.

Базовые сведения

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

предприятия будет построена на протоколах TCP/IP. Все сети TCP/IP, под-

ключенные и не подключенные к сети Интернет, требуют присутствия одних

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

терфейсы. Как мы увидим в главе 6, сетевому интерфейсу требуется IP-адрес,

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

шение о подключении к сети Интернет влияет на способ получения значе-

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

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

Определение адреса IP

Каждый интерфейс сети TCP/IP должен иметь уникальный адрес IP. Если

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

для всей сети Интернет. Если общение узла по протоколам TCP/IP ограни-

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

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

администраторы могут выбирать адреса из документа RFC 1918, Address Al-

location for Private Intranets (Выделение адресов для частных интрасетей),

Базовые сведения 111

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

пользования.

Номера частных сетей:

• Сеть 10.0.0.0 (с префиксом 10/8) - это 24-битный блок адресов.

• Сети с 172.16.0.0 по 172.31.0.0 (с префиксом 172.16/12) - 20-битные бло-

ки адресов.

• Сети с 192.168.0.0 по 192.168.255.0 (с префиксом 192.168/16) - 16-бит-

ные блоки адресов.

Недостаток сетевых адресов из документа RFC 1918 в том, что может воз-

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

тернет. Частные сетевые адреса обладают следующими преимуществами:

• Простота. Нет необходимости обращаться в инстанции и получать офи-

циальные адреса, равно как и одобрение.

• Вежливость. Адресное пространство сохраняется для тех сетей, которым

действительно необходимо подключение к сети Интернет.

• Цена. Адреса RFC 1918 бесплатны, тогда как официально полученные ад-

реса стоят денег.

При использовании адресов из RFC 1918 узлы локальной сети имеют возмож-

ность обращаться к системам сети Интернет, пусть на практике это и потребу-

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

вания сетевых адресов (NAT). NAT существует в виде самостоятельных

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

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

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

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

ществ:

• Экономит адреса IP. Большинство сетевых соединений происходит меж-

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

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

Следовательно, число необходимых официальных адресов IP значитель-

но меньше, чем общее число систем в сети предприятия. NAT позволяет

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

ти предприятия и максимально сократить официальное адресное прост-

ранство Интернет-соединений.

• Сокращает риск подделки адресов («спуфинга»), то есть атак злоумыш-

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

Адреса, перечисленные в RFC 1918, не могут участвовать в маршрутиза-

ции в сети Интернет. Таким образом, дейтаграммы из локальной сети мо-

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

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

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

ных сетях предприятий. Спокойно используйте этот адрес в своей сети, если не

планируется подключение к сети Интернет.