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

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

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

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

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

ния на подсети. Если применить описанную маску подсети к адресам

172.16.1.0 и 172.16.12.0, они будут интерпретированы не как адреса узлов

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

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

ществует два решения этой задачи: настроить сетевые интерфейсы вручную

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

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

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

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

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

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

Протоколы маршрутизации передают адресную маску для каждого получа-

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

сетей переменной длины (VLSM, variable-length subnet mask). Маски пере-

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

подсетей. Предположим, необходимо разделить сеть 192.168.5.0/24 на три

сети: сеть из 110 узлов, сеть из 50 узлов и сеть из 60 узлов. В случае традици-

онных масок подсетей все адресное пространство разбивается на сегменты

одной маской. В лучшем случае придется идти на компромисс. Маски подсе-

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

для создания крупных подсетей из 126 узлов и маской 255.255.255.192 для

создания подсетей поменьше - из 62 узлов. Однако применение масок VLSM

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

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

тизации. (Более подробно маршрутизация описана в главе 7.) Маршрутиза-

ция - важнейшая составляющая сети TCP/IP. Как и прочие ключевые ком-

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

чала настройки.

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

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

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

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

ществовать маршрут, пролегающий через шлюз. Существует два способа

определить такой маршрут:

• Посредством статической таблицы маршрутизации, создаваемой ад-

министратором системы. Статические таблицы маршрутизации оказыва-

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

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

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

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

требуют иного, гибкого подхода к маршрутизации.

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

• Посредством динамической таблицы маршрутизации, реагирующей на

изменения в сети. Динамические таблицы маршрутизации создаются

протоколами маршрутизации. Протоколы маршрутизации выполняют

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

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

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

ступен через несколько шлюзов.

Во многих сетях применяется сочетание статической и динамической марш-

рутизации. Одни системы сети работают со статическими таблицами, тогда

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

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

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

маршрутизации.

Администратор сети принимает решение о том, какой вид маршрутизации

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

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

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

ции. Если речь идет о:

Сети, не имеющей шлюзов в другие сети TCP/IP

Не требуется специальная настройка маршрутизации. В тексте книги под

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

В отсутствие связуемых сетей TCP/IP не нужны и IP-маршрутизаторы.

Таким образом, не нужна информация о шлюзах по умолчанию и прото-

колах маршрутизации.

Сети с единственным шлюзом

Не требуется использование протоколов маршрутизации. Указывайте

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

лице маршрутизации.

Сети, имеющей внутренние шлюзы в другие подсети и один внешний шлюз

В этой ситуации появляется возможность выбора: статически указать

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

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

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

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

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

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

трудоемким.

Сети с большим числом внешних шлюзов

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

пользуйте протокол маршрутизации. Это позволит шлюзам приспосабли-

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

внешние сети.

124

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

Рис. 4.1. Маршрутизация и подсети

На рис. 4.1 представлена разделенная на подсети сеть с пятью шлюзами, от

А до Е. Центральная подсеть (172.16.1.0) объединяет пять других подсетей.

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

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

ции в центральной подсети (172.16.1.0) и, возможно, в подсети 172.16.12.0,

связанной с внешней сетью. Динамическая маршрутизация в этих подсетях

уместна из-за многочисленных шлюзов. В отсутствие динамической марш-

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

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

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

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

подсетей является протокол маршрутизации.

С другой стороны, для остальных сетей (172.16.3.0, 172.16.6.0, 172.16.9.0)

администратор, скорее всего, применит статическую маршрутизацию. У

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

маршрутизация. Изменения, не затрагивающие эти подсети, такие как соз-

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

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

же шлюз в каждой из подсетей. Узлы этих подсетей считают шлюз подсети

маршрутом по умолчанию. Иными словами, узлы подсети 172.16.3.0 счита-

ют шлюзом по умолчанию шлюз В, тогда как узлы подсети 172.16.9.0 счита-

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

внешних сетях.

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

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

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

внешней сети, требующей применения протокола пограничных шлюзов (Bor-

der Gateway Protocol, BGP). Таким образом, на шлюзе Е должен работать

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

Получение номера автономной системы

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

го идентификатора, номера автономной системы (autonomous system num-

ber, ASN).

Большинству площадок протокол BGP не требуется. А если и

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

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

ного использования (номера с 64512 по 65535). Чтобы избежать конфликт-

ных ситуаций, скоординируйте выбор идентификатора ASN со стороной,

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

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

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

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

циального идентификатора ASN, обращайтесь в региональный реестр Ин-

тернета, обслуживающий вашу страну.

• Азиатский и тихоокеанский регионы обслуживаются организацией

APNIC. Заполните форму http://ftp.apnic.net/apnic/docs/asn-request и

отправьте ее по адресу электронной почты hostmaster@apnic.net.

• Обе Америки обслуживаются организацией ARIN. Заполните форму http:/

/www.arin.net/templates/asntemplate.txt и отправьте ее по адресу элект-

ронной почты hostmaster@arin.net.

• Европейские страны обслуживаются организацией RIPE. Заполните фор-

му ftp://ftp.ripe.net/ripe/docs/ripe-147.txt и отправьте ее по адресу элект-

ронной почты hostmaster@ripe.net.

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

мер автономной системы. Если вы не представляете организацию-поставщи-

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

многосетевой (multi-homed) площадки. Многосетевая площадка - это любая

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

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

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

полнении правил маршрутизации. Выделение площадке номера ASN делает

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

ственной информации достижимости. Это не предотвращает регистрацию

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

сведений и обратиться к ответственному техническому лицу. (Как только вы

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

Автономные системы представлены в разделе «Архитектура маршрутизации сети

Интернет» главы 2.

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

Регистрация в базе данных маршрутизации

После обретения официального номера ASN следует принять решение о ре-

гистрации в базе данных маршрутизации. Если номер ASN получен для мно-

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

ции. В разделе «Архитектура маршрутизации сети Интернет» главы 2 рас-

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

верки маршрутов сети Интернет сегодня, когда уже нет централизованного

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

чив официальный номер ASN, вы становитесь частью структуры равноправ-

ных доменов маршрутизации. Принятая ответственность за небольшую долю

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

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

тернет (Internet Routing Registry, IRR). Помимо базы данных RADB (Rou-

ting Arbiter Database, RADB), упоминавшейся в главе 2, существуют базы

данных RIPE, ANS, Bell Canada и Cable & Wireless. RIPE обслуживает кли-

ентов в регионе RIPE. ANS, Bell Canada и Cable & Wireless регистрируют

только своих коммерческих клиентов. RADB доступна всем.

Для регистрирации в базе данных RADB следует сначала зарегистрировать

объект службы технической поддержки (maintainer object). Служебный объ-

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

данных. Укажите соответствующую информацию и заплатите взнос $200.

Затем следует зарегистрировать автономную систему в качестве объекта AS.

Наконец, для каждого маршрута, декларируемого вашей системой, следует

создать объект маршрутизации Route. Подробная информация о регистра-

ции этих объектов базы данных доступна по адресу http://www.radb.net.

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

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

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

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

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

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

работу службы, выполняющей преобразование имен узлов в IP-адреса. Зада-

ча решается системой доменных имен (Domain Name System, DNS) и табли-

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

и другой технологии.

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

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

имен. Эта информация исходит от администратора сети.

Получение доменного имени

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

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

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

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

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

Купить официальное доменное имя можно у регистратора доменных имен.

Ваш домен не является частью официального пространства доменных имен,

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

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

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

ни. Можно начать с адреса http://www.icann.org или http://www.internic.net.

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

ICANN (Internet Corporation for Assigned Names and Numbers) - это неком-

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

ранее подрядчиками правительства США. ICANN осуществляет надзор за

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

наты различных международных регистраторов.

http://www.internic.net - веб-сайт правительства США, задача которого -

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

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

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

домене .сот. Сайт InterNIC - хорошая точка старта, если речь идет о регистра-

ции в доменах .org, .сот или .net. На рис. 4.2 отражена часть алфавитного

перечня уполномоченных регистраторов с сайта http://www.internic.net.

Рис. 4.2. Перечень регистраторов

128

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

Регистраторы мало чем различаются. Регистрация доменов стоит очень не-

дорого, обычно не более $50 в год, так что цена особой роли не играет. Ка-

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

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

предпочитают организации, близкие географически, но даже это не очень

важно в нашем мире, опутанном проводами. Руководствуйтесь собственным

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

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

примерах в качестве регистратора выступает компания Network Solutions -

отчасти потому, что она находится в двух шагах от моего дома. Читателям

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

Регистрация домена

Выбрав регистратора, отправляйтесь на сайт организации и прочитайте

инструкции по регистрации домена. Если вы находитесь на сайте http://

www.internic.net, то можете перейти на сайт конкретного регистратора,

щелкнув по его эмблеме. Большинство организаций-регистраторов предо-

ставляют веб-формы заявлений на регистрацию доменных имен.

Например, выбрав компанию Network Solutions из перечня на http://www.in-

ternic.net, мы попадаем на http://www.netsol.com. Здесь необходимо выбрать

доменное имя. Этот первый шаг обязателен - производится поиск в сущест-

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

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

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

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

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

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

hebook.com domain, то укажем информацию о собственных серверах.

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

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

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

цию по лицам, ответственным за домены. Если у вас уже есть запись в базе

данных whois, следует указать свой идентификатор NIC, связанный с этой

записью. Мой идентификатор NIC - cwh3.

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

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

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

ти от того, как организовано предприятие.

Затем система запрашивает имена и IP-адреса двух серверов, которые явля-

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

ного серверов, которые настроены на обслуживание нового домена. На момент

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

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

нии Network Solutions, пока серверы не заработают. Не следует вводить имена

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

129

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

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

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

тельности компетентными. Поэтому либо заранее настройте серверы, пусть

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

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

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

собственным доменом.

Выбор имени узла

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

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

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

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

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

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

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

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

В RFC 1178 содержатся превосходные руководящие указания по выбору

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

• Используйте реально существующие слова, краткие, легко запоминае-

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

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

писании и запоминании, противоречат самой цели их создания.

• Используйте тематические имена. К примеру, узлам одной группы можно

дать имена, соответствующие человеческим движениям: fall, jump, hop,

skip, walk, run, stagger, wiggle, stumble, trip, limp, lurch, hobble и т. д. Те-

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

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

телей сети.

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

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

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

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

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

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

мы) для указания на серверную функциональность системы: www, ftp,

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

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

жится в главе 8 (записи CNAME).

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

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

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

комфортной.

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

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

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

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

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

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

ры печати и почтовые серверы. В главе 3 говорилось о назначении этих

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

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

успешной настройки клиентских систем и как эту информацию получает ад-

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

Файловые серверы

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

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

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

ния и кому разрешено с ними работать.

Не имея в своем распоряжении точ-

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

совместного доступа к файлам.

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

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

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

(man) Unix доступны для чтения на центральном сервере, следует сообщить

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

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

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

Серверы печати

Независимо от способа организации совместного доступа к принтерам (1р,

lpd, Samba), основная информация, необходимая для настройки клиентов

службы печати, остается той же: имя узла и IP-адрес сервера печати, а так-

же имя печатающего устройства. В случае принтера, не поддерживающего

PostScript, может понадобиться информация о производителе и модели. Из

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

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

Другая информация для настройки клиентских машин не требуется. Но ве-

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

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

вместного доступа.

Команда showmount описана в главе 9.

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

Планирование почтовой системы

TCP/IP предоставляет возможности создания надежной и гибкой системы

электронной почты. Одной из функций серверов является повышение на-

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

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

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

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

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

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

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

почтовой службы небольшим числом систем.

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

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

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

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

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

под управлением sendmail. Итак, термины имеют следующие значения:

Почтовый сервер (Mail server)

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

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

POP и IMAP, так что пользователи имеют возможность работать со своей

почтой так, как им удобно.

Почтовый ретранслятор (Mail relay)

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

ми системами и от внутренних систем внешним узлам. Почтовые ретран-

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

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

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

Почтовый шлюз (Mail gateway )

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

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

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

Шлюз нужен для осуществления перехода от SMTP к Х.400 или к фир-

менной почтовой программе. В однородной сети TCP/IP подобная функ-

циональность не требуется.

I {аиболее важной составляющей надежной системы является почтовый сер-

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

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

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

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

трансляторах. Если узел-ретранслятор по каким-то причинам не может до-

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

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