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

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

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

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

включения. Почтовые серверы и ретрансляторы работают 24 часа в сутки.

Архитектура большинства почтовых сетей TCP/IP основана на следующих

руководящих принципах:

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

IMAP для доставки почты клиентам.

• Используйте почтовый ретранслятор для передачи почты. Выбирайте

упрощенные схемы адресации для узла ретранслятора.

• Стандартизируйте применение TCP/IP и SMTP. Пользователи, настаива-

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

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

• Стандартизируйте применение MIME для двоичных вложений. Избегай-

те фирменных вариантов прикрепления файлов к письмам; это приводит

к замешательству, поскольку пользователи почтовой системы фирмы X

не смогут прочесть вложения, полученные от системы фирмы Y.

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

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

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

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

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

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

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

пользователей.

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

по настройке. В главе 3 мы обсуждали NIS, NFS и серверы настройки. Все

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

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

ходимые для настройки клиентов TCP/IP. Все данные, о которых шла речь в

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

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

посредством DHCP. Конечный пользователь в процессе не участвует.

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

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

щей настройки клиента. В случае NIS и NFS клиент должен иметь полную

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

уровни поддержки процесса настройки. NIS организует доступ к ряду адми-

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

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

вовлекая в процесс пользователей настольных Unix-систем. NFS позволяет

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

кументацию.

Резюме

133

()днако даже в сочетании с другими серверами DHCP не является полноцен-

ным решением. DHCP требует от пользователя знаний о том, что DHCP вооб-

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

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

переда, при помощи печатной документации или среды Web.

Администраторы сетей часто решают задачу при помощи кратких справоч-

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

формация зачастую идентична для всех клиентов Unix и для всех клиентов

Windows. Например, клиенты Unix могут получить указание использовать

DHCP для настройки интерфейса, установить поддержку NIS и NFS, а кроме

того, смонтировать определенные файловые системы NFS. Клиенты Win-

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

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

Создание сети TCP/IP требует от администратора скрупулезного планирова-

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

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

Резюме

Планирование - первый шаг к настройке TCP/IP. В начале главы мы выяс-

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

этого решения для всего процесса планирования. Кроме того, мы рассмотре-

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

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

маршрутизации, обязательной для обмена данными между сетями TCP/IP.

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

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

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

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

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

настройки сетевого интерфейса (глава 6). Однако прежде мы обратимся к

строению ядра Unix и узнаем, каким образом протоколы TCP/IP внедряют-

ся в операционную систему.

• Настройка ядра

• Загрузочные файлы

• Демон Internet

• Расширенный демон Internet

Базовая настройка

Каждая машина под управлением Unix, работающая с TCP/IP, имеет воз-

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

ционную систему. В этой главе мы рассмотрим два метода базовой настрой-

ки TCP/IP в системе Unix: перекомпиляцию ядра и загрузку модулей ядра.

Мы поговорим о роли этих методов в интеграции TCP/IP и Unix. Получив

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

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

как изменять базовые настройки, решая собственные задачи.

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

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

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

системы либо по необходимости. Оба варианта описаны в этой главе. Приве-

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

Но сначала займемся интеграцией TCP/IP в операционную систему Unix.

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

это скорее одна из основных составляющих администрирования системы

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

сети. Однако сетевые возможности TCP/IP, подобно прочим системным

функциям, интегрируются в ядро системы.

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

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

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

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

Настройка ядра

135

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

чающие поставленным задачам. Примером первого подхода является систе-

ма Solaris.

Система Solaris поставляется с общим ядром, поддерживающим все основ-

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

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

с этими устройствами. Solaris может полагаться на этот метод лишь потому,

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

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

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

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

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

Динамически загружаемые модули

В большинстве вариантов системы Unix присутствует поддержка динами-

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

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

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

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

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

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

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

существует файл настройки ядра, а именно /etc/system, но этот файл весьма

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

нистратором напрямую. В процессе установки нового программного пакета

сценарий установки вносит все необходимые изменения в файл /etc/system.

И даже такая ситуация встречается нечасто. Большинство драйверов, по-

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

файлы настройки.

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

помощи команды

pkgadd.

Синтаксис команды следующий:

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

темы Solaris и по совместительству устройство Ethernet, которое мы используем

во всех примерах по Solaris.

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

ми драйверами.

Установка драйвера устройства приводит к созданию сопутствующей записи

в каталоге /dev, а также в каталоге /kernel/drv. В качестве примера рассмот-

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

схем DEC 21140. Имя драйвера - dnet.

В каталоге устройств существует

устройство с именем /dev/dnet. В каталоге драйверов ядра присутствует ди-

136

Глава 5. Базовая настройка

намически загружаемый модуль /kernel/drv/dnet, и, кроме того, существу-

ет файл настройки драйвера - /kernel/drv/dnet.conf. dnet является стан-

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

созданию похожих файлов.

Завершив установку нового драйвера, создайте пустой файл с именем /recon-

figure. Остановите работу системы и установите новое устройство. Переза-

пустите систему. Файл /reconfigure сигнализирует системе о необходимости

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

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

устройства.

Команда Solaris ifconfig, описанная во всех подробностях в главе 6, имеет

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

определенным сетевым интерфейсом TCP/IP. Например:

# ifconfig dnetO modlist

0 arp

1 ip

2 dnet

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

реализует протокол ARP для интерфейса Ethernet, ip реализует протоколы

TCP/IP, применяемые в этой сети. Каждому из модулей соответствует файл

настройки, хранящийся в каталоге /kernel/drv. Существуют файлы arp.conf,

ip.conf и dnet.conf. Однако эти файлы предоставляют весьма ограниченные

возможности настройки модулей. Для управления модулями система Sola-

ris предоставляет команду ndd.

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

пользуйтесь командой ndd с аргументом ?. Например, следующая команда

перечисляет переменные для модуля агр:

# ndd /dev/агр ?

Значение только для чтения, приводит к отображению данного списка.

arp_cache_report

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

сей из буфера ARP. Команда агр предоставляет более удобный доступ к

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

arp_cache_report

arp_debug

arp_cleanup_interval

arp_publish_interval

arp_publish_count

(read only)

(read and write)

Модуль arp предлагает шесть значений для настройки:

Настройка ядра

137

arp_debug

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

умолчанию имеет значение 0, отладка выключена. Значение 1 приводит

к включению отладки. Протокол ARP - очень старый и очень надежный,

так что отладка ARP никогда не требуется.

arp_cleanup_interval

Переменная, определяющая срок хранения в буфере временных записей.

arp_publish_interval

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

общений с опубликованными адресами Ethernet.

arp_publish_count

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

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

Стандартные значения переменных модуля агр замечательно работали для

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

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

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

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

ndd /dev/ip ?. Существует почти 60 параметров! Из всех этих параметров мне

приходилось настраивать лишь один: ip_forwarding.

Переменная ip_forwarding определяет, должен ли модуль ip считать, что сис-

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

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

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

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

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

терфейсами. Значение ip_forwarding, равное единице, включает пересылку

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

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

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

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

тором. Чтобы система не вела себя как маршрутизатор, вмешиваясь в функ-

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

сылку пакетов IP следующим образом:

# ndd /dev/ip ip_forwarding

# ndd -set /dev/ip ip_forwarding 0

# ndd /dev/ip ip_forwarding

этом примере первая команда ndd запрашивает значение переменной ip_for-

warding для модуля ip. Мы видим, что значение переменной равно 1 и пере-

сылка пакетов включена. Вторая команда ndd при помощи параметра -set

138

Глава 5. Базовая настройка

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

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

риться, что оно изменилось.

Команда

pkgadd,

параметр modlist команды

ifconfig,

а также команда ndd спе-

цифичны для системы Solaris. В других системах также существуют динами-

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

Так, поддержка загружаемых модулей присутствует в Linux. Linux получа-

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

столь же ограниченного вмешательства в работу этих модулей. Обычно сис-

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

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

темного администратора. Но это не всегда так. Устройства могут не опреде-

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

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

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

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

тесь командой

Ismod.

Вот пример для системы Red Hat:

Загружаемые модули решают широкий спектр задач. Некоторые реализуют

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

сетевой карты SMC Ultra Ethernet), другие обеспечивают поддержку много-

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

ловая система IS08859 для компакт-дисков или система DOS FAT с под-

держкой длинных имен файлов (vfat).

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

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

модули имеют небольшие размеры. Часто модули используют другие моду-

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

висимостей модулей, и эти зависимости отражены в перечне модулей. В на-

шем примере драйвер smc-ultra в своей работе полагается на модуль 8390,

как можно видеть из записи для 8390 - она заканчивается строкой «[smc-ul-

tra]». В записи для 8390 модули, зависящие от него, перечислены под заго-

ловком Used by. Можно наблюдать и другие зависимости: vfat зависит от

fat, a cdrom зависит от ide-cd.

Настройка ядра 139

Большинство записей примера содержит строку «(autoclean)». Строка озна-

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

действован. autoclean - это параметр. Параметры работы модулей можно

указывать, вручную загружая их при помощи команды insmod.

Модули загружаются вручную при помощи команды

insmod.

Команда очень

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

вер устройства Зс509, наберите команду insmod

Зс509.

В этом случае модуль

загружается без параметра autoclean. Чтобы драйвер удалялся из памяти ав-

томатически, добавьте ключ-к в команду insmod: insmod -k Зс509.

Серьезное ограничение команды insmod связано с тем, что она ничего не

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

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

мого модуля 8390. По этой причине для ручной загрузки модулей лучше ис-

пользовать команду modprobe. Синтаксис этой команды также очень прост.

Чтобы загрузить модуль smc-ultra, наберите просто modprobe smc-ultra.

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

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

depmod, чтобы создать новый файл зависимостей модулей. Команда depmod -а

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

вующий файл. По завершении этой операции воспользуйтесь modprobe для

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

Для удаления ненужных модулей применяется команда гmmod. Опять же, ее

синтаксис прост: rmmod appletalk удаляет из системы драйвер appletalk. Необ-

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

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

системой автоматически.

Модуль smc-ultra реализует драйвер устройства Ethernet. Именно этот драй-

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

нашего примера. Драйверы устройств могут встраиваться в ядро - такой ва-

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

Большинство драйверов устройств Ethernet используются в качестве загру-

жаемых модулей. Модули драйверов Ethernet расположены в каталоге /lib/

modules. В случае системы Red Hat 7.1 драйверы устройств Ethernet нахо-

дятся в каталоге /lib/modules/2.4.7-10/kernel/drivers/net, как можно видеть

из следующего фрагмента:

140 Глава 5. Базовая настройка

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

рые из них, например plip.o, относятся вовсе не к устройствам Ethernet.

Большинство модулей можно легко опознать по именам файлов, в частности

драйверы 3COM, SMC, NE2000, а также Ethernet Express.

Система Linux определяет наличие устройств Ethernet в процессе первона-

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

ливает его. Если карта Ethernet не определена при установке системы либо

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

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

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

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

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

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

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

но на целевой системе. Исходные тексты драйверов многих устройств Ether-

net доступны на сайте http://www.scyld.com, в замечательном хранилище се-

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

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

После компиляции модуля скопируйте полученный объектный файл в соот-

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

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

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

RPM, что позволяет обойтись без компиляции.

В системах Linux часто применяются динамически загружаемые модули

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

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

смотрим перекомпиляцию ядра системы Unix.

Перекомпиляция ядра

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

рассмотрим Linux и FreeBSD.

Примеры операторов настройки ядра отно-

Процесс настройки ядра для других систем BSD, таких как SunOS 4.1.3, схож с

процессом, описанным для системы FreeBSD.

Настройка ядра 141

оятся к этим двум системам. И хотя настройка ядра связана с каждым из ас-

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

напрямую влияющие на работу TCP/IP.

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

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

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

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

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

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

ло, при следующих обстоятельствах:

• Существует необходимость сократить размер ядра и повысить эффектив-

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

• Требуется добавить новое устройство

• Требуется изменить системный параметр

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

полезно понимать, что именно означают эти настройки. Файл настройки яд-

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

граммами сети.

Процедуры и файлы настройки ядра существенно различаются

для каждой реализации Unix. Следствием этого обстоятельства

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

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

ции по конкретной системе содержатся точные, подробные инст-

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

Настройка ядра Linux

Исходный текст ядра Linux обычно поставляется в составе дистрибутива

системы. Если в системе отсутствует исходный текст либо вы желаете вос-

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

http://www.kernel.org в виде сжатого tar-файла. Если каталог /usr/src/linux

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

# cd /usr/src

# tar -zxvf linux-2.1.14.tar.gz

Ядро Linux - это программа на языке С, которая компилируется и устанав-

ливается при помощи инструмента make. Команда make позволяет изменять

настройки ядра, а также генерирует файлы (включая файл сборки, Makefi-

le), необходимые для компиляции и связывания кода ядра. Существует три

варианта команды:

make config

Данный вариант команды - полностью текстовый. Он связан с прохожде-

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

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