Меню Networking Options содержит опции, влияющие на работу сетевых протоколов. Вы можете включить или исключить средства поддержки стека протоколов либо отдельных протоколов (в основном данные опции касаются семейства протоколов TCP/IP). Опции из этого меню позволяют также оптимизировать ядро для выполнения конкретных функций, например маршрутизации или фильтрации пакетов.

 

Опции для работы с пакетами и гнездами

Низкоуровневые сетевые средства Linux позволяют программам передавать и принимать фрагменты данных, называемые пакетами, посредством специальных структур, которые называются гнездами (socket). В большинстве случаев обмен данными через гнездо осуществляется по тому же принципу, что и обмен данными с файлом. Стек сетевых протоколов обеспечивает передачу информации по адресу назначения, где происходит ее интерпретация.

В некоторых случаях желательно и даже необходимо изменить принцип обработки данных; иногда приходится расширять стандартный набор операций над пакетами. Сделать это позволяют специальные опции, рассмотрению наиболее важных из них посвящены разделы данной главы. Некоторые из опций кратко описаны ниже.

• Packet Socket. Эта опция позволяет приложениям непосредственно обращаться к требуемому протоколу, минуя некоторые уровни стека протоколов. Для большинства программ такая возможность не нужна; ее используют лишь инструментальные средства сетевой диагностики и специальные утилиты, действующие на нижнем уровне. В качестве примера подобных программ можно привести утилиту tcpdump, которая выводит информацию о пакетах TCP и IP. Данная опция не обязательна. Она несколько увеличивает размер ядра и дает возможность злоумышленникам воспользоваться утилитами сетевой диагностики. С другой стороны, отключив данную опцию, вы не сможете воспользоваться целым рядом утилит.

• Packet Socket: Mapped IO. Если данная подопция Packet Socket включена, производительность инструментальных средств, использующих низкоуровневые соединения, повышается.

• Unix Domain Sockets. Некоторые важные программы Linux используют сетевые протоколы для обмена данными даже в том случае, если они выполняются на одном и том же компьютере. В качестве примеров можно привести средство протоколирования syslogd и программы, выполняющиеся в среде X-Window (X-программы используют сетевой протокол для взаимодействия с X-сервером, выполняющим отображение данных). Опция Unix Domain Sockets допускает взаимодействие в пределах одной системы даже в тех случаях, когда на компьютере не установлено сетевое оборудование. Даже если средства поддержки сетевого обмена присутствуют, опция Unix Domain Sockets обеспечивает более высокую скорость обмена по сравнению с обычными TCP-гнездами. Обычно данная опция устанавливается; без нее обходятся лишь системы, предназначенные для выполнения на специализированных устройствах.

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

 

Опции сетевой фильтрации

Опции сетевой фильтрации блокируют или преобразуют пакеты, поступающие на компьютер или покидающие его. Данные опции используются при создании брандмауэров и выполнении IP-маскировки (подробно эти вопросы будут обсуждаться в главе 25). Брандмауэры блокируют нежелательные обращения к компьютеру или сети, а IP-маскировка позволяет организовать работу в Internet пользователей всей локальной сети при наличии одного IP-адреса. Опции ядра системы, предназначенные для фильтрации, перечислены ниже.

• Socket Filtering. В обычных условиях ядро направляет все пакеты, полученные через некоторое гнездо, программе, которая создала это гнездо. Опция Socket Filtering позволяет указать ядру на то, что принятые пакеты должны быть сначала переданы небольшой программе (которая называется фильтром). Эта программа способна блокировать некоторые из пакетов. Как правило, программы могут работать без данной опции. Исключение составляют последние варианты серверов DHCP и клиентов DHCP. Если в вашей сети используются средства DHCP (Dynamic Host Configuration Protocol — протокол динамической конфигурации узла), данная опция должна быть установлена.

• Network Packet Filtering. Данная опция является наиболее важным средством фильтрации, так как именно она делает возможной работу брандмауэра и IP-маскировку. Обычно опция Network Packet Filtering устанавливается; при этом становится доступной опция Network Packet Filtering Debugging, которую можно использовать для решения возникающих проблем. Кроме того, становится также доступным подменю IP: Netfilter Configuration. В этом подменю отображаются описанные ниже опции.

• Connection Tracking. Эта опция обеспечивает более высокую степень контроля над сетевыми соединениями, чем это возможно в обычных условиях. Как правило, маршрутизаторы ограничиваются пересылкой информационных пакетов между сетевыми интерфейсами. Если опция Connection Tracking активна, система запоминает IP-адрес источника, IP-адрес назначения и порты для дальнейшего использования. Эта возможность необходима для реализации IP-маскировки. В других случаях опцию Connection Tracking можно отключить. Если данная опция установлена, доступны опции поддержки FTP, что позволяет обеспечить работу данного протокола при наличии IP-маскировки.

• IP Tables Support. Данная опция включает поддержку ядром утилиты iptables, используемой для реализации брандмауэров и осуществления IP-маскировки (эти вопросы будут подробно обсуждаться в главе 25). При установленной опции IP Tables Support становятся доступны подопции, позволяющие настроить средства поддержки iptables для выполнения конкретных задач. Многие из этих подопции задают соответствие ядра определенному типу, и их имена имеют вид Тип Match Support . Из них очень важна опция Connection State Match Support, которая позволяет осуществлять проверку пакетов с учетом состояния (stateful packet inspection). Эта операция применяется в брандмауэрах и подробно рассматривается в главе 25. Также важны опции Packet Filtering, Full NAT и LOG Target Support и их подопции. Установив данные опции, вы можете использовать ваш компьютер как брандмауэр или осуществлять IP-маскировку. Для независимой рабочей станции или сервера опцию Full NAT можно не указывать.

• ipchains (2.2-Style) Support . В некоторых случаях бывает необходимо обеспечить работу сценариев брандмауэра, ориентированных на использование утилиты ipchains (эта утилита применялась при работе с версиями ядра 2.2.x). Поддержку ipchains можно включить в том случае, если средства IP Tables Support не были скомпилированы непосредственно в ядро системы. (Средства iptables и ipchains выполняют приблизительно одинаковые действия, но они не совместимы друг с другом.) Если вы создаете брандмауэр с нуля, можете смело отключить поддержку ipchains.

• ipfwadm (2.0-Style) Support . При работе с версиями 2.0.x ядра для создания брандмауэров использовалось инструментальное средство ipfwadm. Чтобы использовать сценарии брандмауэра, ориентированные на ipfwadm, надо установить данную опцию. Следует помнить, что средства поддержки ipfwadm не совместимы ни с iptables, ни с ipchains. Если вы не используете ipfwadm-сценарии, либо твердо решили преобразовать их для работы с iptables, можете отказаться от установки данной опции.

По мере перехода от версий 2.0.x к версиям 2.4.x ядра Linux средства поддержки фильтрации пакетов становились все сложнее. В ядре 2.4.x предусмотрены многие дополнительные возможности; создавая брандмауэр, важно активизировать те опции, которые необходимы для решения конкретной задачи. Если вы сомневаетесь, нужна ли та или иная опция из меню IP: Netfilter Configuration, рекомендую вам установить ее. В этом случае объем ядра несколько возрастет, но вы получите возможность использовать различные правила брандмауэра.

Внимание

Вам может показаться, что использовать правила брандмауэра на машине под управлением Linux не обязательно, особенно если она находится в сети, которая защищена выделенным брандмауэром. К сожалению, в системе защиты многих сетей есть недостатки, поэтому дополнительные меры предосторожности не помешают. Возможно, вам потребуется установить на своем компьютере дополнительный простой брандмауэр.

 

Опции маршрутизации TCP/IP

Маршрутизатор — это компьютер, который непосредственно передает данные из одной сети в другую. Маршрутизаторы также часто называют шлюзами. Так, например, маршрутизатор может понадобиться для связи сети, принадлежащей отделу большой корпорации, с корпоративной сетью. Корпорация, в свою очередь, использует маршрутизатор для обеспечения связи своей сети с Internet. Рассмотрению опций маршрутизации посвящена глава 24. Сейчас вам достаточно знать лишь то, что для ядра Linux предусмотрен ряд опций, являющихся подопциями IP: Advanced Router.

 

Опции поддержки IPv6

Работа Internet обеспечивается за счет протоколов семейства TCP/IP, в частности, для передачи пакетов используется протокол IP (IPv4). К сожалению, на сегодняшний день уже невозможно игнорировать тот факт, что версия IPv4 устарела. Для представления IP-адреса в IPv4 используется 32-разрядное число, т.е. общее число адресов равно 2³², или 4294967296. Вследствие неэффективности механизма распределения адресов реальное их количество оказывается намного меньшим. В результате возникла проблема нехватки IP-адресов. Кроме того, недостатки в защите IPv4 позволяют злоумышленникам вмешиваться в сеансы сетевого взаимодействия. На момент написания данной книги, т.е. в 2002 г., с проблемами, связанными с использованием IPv4, еще можно мириться, но их придется решить в течение ближайшего десятилетия.

В настоящее время разрабатывается версия IPv6, призванная заменить IPv4. В IPv6 поддерживаются 128-разрядные IP-адреса. Общее число IP-адресов равно 2128, или 3,4×1038 — приблизительно 2,2×1018 адресов на квадратный миллиметр поверхности Земли. IPv6 также обеспечивает дополнительные средства защиты. В настоящее время число сетей, в которых используется IPv6, очень мало. Если ваш компьютер подключен к такой сети или если вы собираетесь в качестве эксперимента организовать обмен данными во внутренней сети предприятия посредством IPv6, вам надо активизировать средства поддержки IPv6, установив для этого опцию IPv6 Protocol (Experimental) в меню Networking Options. После установки данной опции вам станут доступны дополнительные опции, объединенные в подменю IPv6: Netfilter Configuration. В этом подменю также находятся описанные ранее опции фильтрации, но они ориентированы на работу с протоколом IPv6.

На заметку

Чтобы активизировать средства поддержки IPv6, надо установить значения Yes опции Prompt for Development или Incomplete Code/Drivers в меню Code Maturity Level Options . To же самое надо сделать при работе с любыми "экспериментальными" драйверами. Со временем эксперименты с IPv6 закончатся, и опция, включающая поддержку IPv6, будет относиться к числу основных опций. Пока это не произошло, при работе с IPv6, как и при использовании других "экспериментальных" средств, следует соблюдать осторожность.

 

Опции QoS

Предположим, что компьютер под управлением Linux действует как маршрутизатор в сети с напряженным трафиком или выполняет роль сервера и обрабатывает при этом большой объем данных. При этом может возникнуть ситуация, когда система будет в течение некоторого времени получать большее число пакетов, чем она может обработать. Очевидно, что в этом случае необходимы специальные средства планировки, которые устанавливали бы очередность передачи пакетов. Как правило, в системе Linux используется стратегия FIFO (first in/first out — "первый пришел — первый вышел"), согласно которой пакет, предназначенный для передачи, находится в очереди до тех пор, пока не будут переданы все пакеты, поставленные в очередь раньше него. Но в некоторых случаях необходимо предоставить пакетам определенного типа некоторые преимущества. Это могут быть пакеты, адресованные в конкретную сеть, или пакеты, которые содержат информацию, соответствующую определенному протоколу. Так, например, пакеты, содержащие информацию реального времени, например данные Internet-телефонии, целесообразно передавать вне очереди. Назначать приоритеты пакетам позволяют опции QoS (quality of service — качество сервиса). Эти опции доступны посредством подменю QoS and/or Fair Queuing меню Networking Options.

Для того чтобы реализовать систему QoS, необходимо выбрать опцию QoS and/or Fair Queuing в одноименном меню. В результате автоматически устанавливается ряд опций этого меню. Другие опции задаются отдельно. Основными из них являются опции планирования передачи пакетов и организации очереди, такие как CBQ Packet Scheduler и SFQ Queue. Эти опции позволяют ядру выполнять более сложную обработку пакетов по сравнению с традиционно используемым принципом FIFO. Опции QoS Support и Packet Classifier API, а также их подопции позволяют использовать Differentiated Services и Resource Reservation Protocol. При этом появляется возможность обмена QoS-приоритетами с другими маршрутизаторами. Если все маршрутизаторы на пути от одного узла к другому поддерживают совместимые между собой протоколы QoS, скорость передачи важных данных может быть увеличена за счет задержки информации, время доставки которой некритично.

Если система не выполняет функции маршрутизатора, опции QoS в ней, как правило, не используются. Если же вы создаете маршрутизатор, а в особенности, если он планируется для использования в сети с интенсивным обменом данными, желательно установить эти опции. Активизировав одну опцию, целесообразно активизировать и все остальные, в противном случае система не будет обладать должной гибкостью. Так, например, если вы не установите опцию U32 Classifier, то не сможете задавать приоритеты исходя из адресов назначения пакетов.

На практике использование средств QoS предполагает применение расширенных средств маршрутизации, таких как ip и tc. Об этих инструментах речь пойдет в главе 24, однако они слишком сложны, чтобы привести их исчерпывающее описание в рамках одной главы. Дополнительную информацию об ip и о tc можно найти в документах iproute2 + tc Notes (http://snafu.freedom.org/linux2.2/iproute-notes.html) и Differentiated Services on Linux (http://diffserv.sourceforge.net).

 

Поддержка протоколов высокого уровня

В ядре Linux предусмотрена поддержка нескольких протоколов высокого уровня. Благодаря этому коды, отвечающие за работу с этими протоколами, выполняются намного быстрее, чем соответствующие коды обычных пользовательских программ. Кроме того, поддержка высокоуровневых протоколов в ядре обеспечивает более тесную интеграцию этих протоколов с остальными компонентами операционной системы. Например, включение в состав ядра средств поддержки NFS позволяет монтировать удаленные ресурсы и использовать их так же, как и компоненты локальной файловой системы. В версиях 2.4.x ядра реализована поддержка трех важных высокоуровневых протоколов: HTTP, NFS и SBM/CIFS.

На заметку

В приведенном перечне содержатся не все протоколы, поддерживаемые ядром. Кроме указанных выше, ядро Linux позволяет работать и с другими протоколами, в частности, с различными протоколами, обеспечивающими разделение сетевых ресурсов.

 

Ускорение HTTP-обмена

Работа World Wide Web в основном базируется на использовании протокола HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовой информации). По сути, в ядре Linux реализован простой сервер HTTP, который включается при установке опции Kernel HTTPd Acceleration. Для настройки и активизации этого сервера в псевдофайлы, находящиеся в каталоге /proc/sys/net/khttpd, записываются специальные значения. Вопросы работы со встроенным сервером HTTP подробно рассматриваются в главе 20.

Реализовать сервер HTTP в составе ядра оказалось сравнительно не сложно, так как передача клиенту статических Web-страниц (документов, содержимое которых не изменяется при различных обращениях клиентов) мало отличается от копирования файлов с диска на удаленные компьютеры. Ядро может выполнять эту операцию гораздо эффективнее, чем пользовательские программы. Для обслуживания запросов, связанных с предоставлением динамических Web-страниц, а также запросов, предполагающих сложную обработку статических документов, ядро обращается к обычному Web-серверу, например Apache. При этом нет необходимости в специальных настройках Apache; этот сервер попросту "не видит" запросов на получение статических Web-страниц.

Опции для работы с NFS

NFS (Network Filesystem — сетевая файловая система), разработанная Sun, предназначена для организации совместного использования файлов несколькими компьютерами. Благодаря NFS обращение к удаленным файлам осуществляется так же, как и обращение к файлам на локальной машине. Поддержка NFS реализована в ядре Linux. Подробно вопросы работы с NFS рассматриваются в главе 8. Для того чтобы иметь возможность монтировать каталоги, экспортируемые другими компьютерами, надо установить опции, отвечающие за поддержку NFS. Опции, включающие средства клиента и сервера NFS, содержатся в подменю Network File Systems меню File Systems (а не в меню Networking Options, как это можно было бы ожидать). Опции для работы с NFS перечислены ниже.

• NFS File System Support. Эта опция включает базовые средства поддержки клиента NFS (т.е. средства, позволяющие монтировать удаленные каталоги NFS и пользоваться ими так же, как и фрагментами локальной файловой системы).

• Provide NFSv3 Client Support. За время своего развития система NFS претерпела многочисленные изменения. Последней была разработана версия 3 (NFSv3). Поддержку этой версии необходимо задавать явно, так как стандартные средства, включаемые с помощью NFS File System Support, не обеспечивают надежную работу NFSv3. Для поддержки NFSv3 опция NFS File System Support также должна быть установлена.

• Root File System on NFS. Чтобы эта опция стала доступной, надо установить опцию IP: Kernel Level Autoconfiguration в меню Networking Options. Опция Root File System on NFS позволяет монтировать внешний каталог как корневую файловую систему Linux. Эта возможность обычно используется только на бездисковых рабочих станциях.

• NFS Server Support. Чтобы компьютер под управлением Linux мог работать как сервер NFS (т.е. мог предоставлять свои каталоги другим компьютерам), желательно установить данную опцию. В большинстве случаев она позволяет ускорить работу сервера NFS.

• Provide NFSv3 Server Support. Если вы хотите обеспечить работу сервера NFS, ориентированного на использование средств ядра, установите данную опцию. Как и в случае NFSv3-клиента, для поддержки NFSv3 должны также быть включены базовые средства NFS.

На заметку

Чаще всего средства NFS используются в Linux и различных версиях UNIX. Обмен файлами с прочими системами реализуется другими средствами, одно из которых рассматривается ниже.

Опции для работы с SMB/CIFS

NFS — не единственный протокол, обеспечивающий разделение файлов. В Macintosh для этой цели используется AppleTalk; большой популярностью пользуются также протоколы IPX/SPX, разработанные Novell. В системе Linux, помимо NFS, часто применяется система Samba, которая реализует протокол SMB (Server Message Block — блок сообщений сервера). Эти средства известны также под названием CIFS (Common Internet Filesystem — общая межсетевая файловая система). Подробно настройка и использование Samba рассматриваются в главе 7.

Samba предоставляет средства, необходимые для того, чтобы система Linux функционировала как SMB/CIFS сервер; при этом специальная настройка ядра не требуется. Если вы хотите монтировать в Linux разделяемые каталоги SMB/CIFS, вам надо установить опцию File System Support, которая действует подобно опции NFS File System Support. Две подопции (Use a Default NLS и Default Remote NLS Option) обеспечивают преобразование имен файлов на основе NLS (National Language Support — поддержка национальных языков). Эти опции полезны при использовании алфавитов, отличных от латинского, например кириллицы, а также символов с дополнительными элементами.

На заметку

Чтобы обеспечить работу Linux как клиента SMB/CIFS, не обязательно устанавливать опции ядра SMB/CIFS. Это также позволяет сделать программа smbclient . Данная программа не монтирует ресурсы; для передачи разделяемых файлов предоставляется интерфейс, подобный интерфейсу клиентской программы FTP.

 

Поддержка альтернативных сетевых протоколов

Несмотря на то что семейство протоколов TCP/IP, обеспечивающее работу глобальной сети Internet, пользуется широкой популярностью, в системе Linux также реализованы другие стеки протоколов. Опции, включающие поддержку различных сетевых протоколов, представлены в меню Networking Options. Многие из опций, содержащихся в этом меню, на самом деле являются подопциями TCP/IP Networking. За ними следуют опции, соответствующие другим протоколам; некоторые из них перечислены ниже.

• Asynchronous Transfer Mode (ATM). Этот набор экспериментальных опций предназначен для поддержки аппаратных средств и протоколов ATM. Опции ATM в равной мере относятся как к аппаратным средствам, так и к сетевым протоколам, но в версии ядра 2.4.x они, как и другие опции поддержки сетевых протоколов, сосредоточены в меню Networking Options.

• The IPX Protocol. Семейство протоколов IPX (Internetwork Packet Exchange — межсетевой обмен пакетами), разработанное Novell, применяется во многих сетях, в частности в Netware. Для работы с этими протоколами вам потребуется дополнительное программное обеспечение, например Mars_nwe (дополнительную информацию о нем вы можете получить по адресу http://www.redhat.com/support/docs/tips/Netware/netware.html). Опция NCP File System Support, расположенная в подменю Network File Systems меню File Systems, дает возможность монтировать тома Netware, подобно тому, как опции NFS и SMB/CIFS позволяют монтировать фрагменты файловой системы Windows.

• AppleTalk Protocol Support. Компания Apple разработала стек протоколов АрpleTalk, предназначенный для разделения файлов и принтеров на компьютерах Macintosh. Для поддержки AppleTalk в Linux используются средства ядра, а также пакет Netatalk (http://netatalk.sourceforge.net/).

• DECnet Support. Корпорация DEC (Digital Equipment Corporation) разработала для своих компьютеров сетевую технологию под названием DECnet. Система Linux включает средства поддержки DECnet, но для работы с данным стеком протоколов необходимо установить специальный программный пакет. Дополнительную информацию об использовании DECnet можно получить, обратившись по адресу http://linux-decnet.sourceforge.net.

В системе Linux также предусмотрены опции поддержки менее популярных протоколов, например Acorn Econet. В большинстве случаев при установке системы достаточно включить поддержку TCP/IP и одного-двух дополнительных стеков протоколов. Вследствие бурного развития Internet производители, ранее использовавшие собственные стеки протоколов, модернизировали свои инструментальные средства для работы с TCP/IP. Так, например, несмотря на то, что Apple в течение длительного времени применяла AppleTalk, средства разделения файлов на компьютерах Macintosh сейчас используют как AppleTalk, так и TCP/IP.

На заметку

В ядре Linux отсутствуют средства поддержки стека протоколов NetBEUI. Для работы с разделяемыми файлами Windows в настоящее время с успехом применяются средства SMB/CIFS.

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

 

В меню Network Device Support содержатся опции, определяющие взаимодействие системы с различными сетевыми устройствами. Самые важные из этих опций управляют использованием драйверов сетевых карт. Несмотря на то что в настоящее время наиболее распространены Ethernet-карты, в меню Network Device Support содержатся опции для работы и с другими устройствами, предназначенными для создания локальных сетей. Кроме того, Linux предоставляет опции, включающие драйверы устройств дальней связи и драйверы беспроводных устройств. Устройства PC Card (применяющиеся в портативных компьютерах) описаны в отдельном подменю, которое входит в состав меню Network Device Support. Вы также можете выбрать устройства, позволяющие устанавливать соединения по телефонным линиям через модемы, и другие аппаратные средства.

Для того чтобы получить доступ к описанным выше опциям, надо установить опцию Network Device Support, которая находится в начале меню Network Device Support. Если вы не сделаете это, опции в данном меню будет не доступны.

 

Устройства Ethernet

На момент написания данной книги, т.е. в 2002 г., подавляющее большинство локальных сетей строились на базе Ethernet. Беспроводные технологии также пользуются определенной популярностью, но сети, созданные на их основе, проигрывают сетям Ethernet в скорости обмена. Одной из проблем, усложняющих процесс администрирования операционных систем, является тот факт, что число разновидностей Ethernet-карт исчисляется сотнями и даже тысячами.

К счастью, при построении Ethernet-карт применяется ограниченный набор микросхем, поэтому для поддержки подавляющего большинства таких устройств достаточно шестидесяти драйверов. Опции, управляющие использованием этих драйверов, сосредоточены в двух подменю: Ethernet (10 or 100Mbit) и Ethernet (1000 Mbit). Большинство опций находится в первом меню. Соответствующие им драйверы, как следует из названия подменю, ориентированы на устройства, обеспечивающие скорость обмена 10 и 100 Мбод. На момент написания этой книги наибольшей популярностью пользуются Ethernet-платы 100 Мбод (100-мегабитовая Ethernet), а в некоторых случаях применяются более новые платы 1000 Мбод (или гигабитовая Ethernet). Разрабатываются также Ethernet-карты 10 Гбод.

На заметку

Ethernet-сети различаются не только по скорости обмена данными, но и по типу кабеля. Для соединения устройств применяются коаксиальные кабели (в некоторых типах 10 мегабитовых Ethernet-сетей), витые пары (во всех 100-мегабитовых Ethernet-сетях, а также в некоторых типах 10-мегабитовых и гигабитовых Ethernet-сетей) и волоконно-оптические кабели (в некоторых типах гигабитовых Ethernet-сетей). Витые пары обеспечивают соединение на расстоянии до 100 метров (обычно такое соединение устанавливается между компьютером и концентратором либо коммутатором). Волоконно-оптические соединения допускают обмен данными на расстоянии до 5 километров.

Структура меню Ethernet (10 or 100 Mbit) далека от совершенства. В начале меню перечислены сетевые карты 3Com, SMC, Racal-Interlan и некоторых других производителей. За ними расположены устройства ISA (Industry Standard Architecture), затем следуют устройства EISA (Extended ISA), VLB (VESA Local Bus) и PCI (Peripheral Component Interconnect). Завершается список группой параллельных Ethernet-адаптеров. В результате для поиска требуемого устройства приходится просматривать две-три группы опций.

Существуют также Ethernet-устройства, драйверы которых не устанавливаются посредством опций меню Network Device Support или его подменю. Так, например, для устройств PC Card используются специальные драйверы, а адаптеры USB — Ethernet описаны в меню USB Support. Для того чтобы использовать устройство USB, вам надо, в зависимости от контроллера, присутствующего на материнской плате, установить либо опцию UHCI Support, либо OHCI Support, а также включить опцию, которая соответствует требуемому драйверу, например USB ADMtek Pegasus-Based Ethernet Device Support.

 

Альтернативные средства для создания локальных сетей

Несмотря на свою популярность, Ethernet — отнюдь не единственное устройство, позволяющее создать локальную сеть. В ядре Linux предусмотрена поддержка различных типов сетей. Число драйверов для устройств, отличных от Ethernet, невелико, но это не означает, что средства для организации соответствующих сетей разработаны недостаточно хорошо. Ниже приведены некоторые опции, присутствующие в меню Network Device Support.

• Token Ring. В течение многих лет технология Token Ring, разработанная IBM, была главным конкурентом Ethernet, однако начиная с 1990 г. преимущество Ethernet стало очевидным. Большинство карт Token Ring поддерживают скорость обмена до 16 Мбод, но в настоящее время появились модели 100 Мбод. Максимальное расстояние между устройствами в сети Token Ring составляет 150-300 метров. Средства поддержки устройств Token Ring сосредоточены в подменю Token Ring Devices меню Network Device Support.

• LocalTalk. Для компьютеров Macintosh компания Apple разработала сетевую технологию, включающую протоколы как аппаратного (LocalTalk), так и программного (AppleTalk) уровня. Для взаимодействия с сетями LocalTalk были разработаны устройства x86; некоторые из них поддерживает система Linux. Соответствующие опции находятся в меню AppleTalk Devices. Как ни странно, версия Linux, разработанная для Macintosh, не поддерживает LocalTalk. На момент написания данной книги максимальная скорость обмена данными в сети LocalTalk составляла 2 Мбод.

• ARCnet. Это сетевая технология, которая в основном используется в специальных целях, например, для подключения охранных устройств или для сбора результатов научных экспериментов. Устройства ARCnet обеспечивают скорость обмена от 19 Кбод до 10 Мбод. Соединение устройств осуществляется с помощью коаксиального кабеля, витой пары или волоконно-оптического кабеля. Опции поддержки ARCnet находятся в подменю ARCnet Devices. Помимо драйвера устройства, вам необходимо включить драйвер, предназначенный для поддержки формата ARCnet-пакетов (RFC 1051 или RFC 1201).

• FDDI и CDDI. FDDI (Fiber Distributed Data Interface — волоконно-оптический интерфейс распределенных данных) и CDDI (Copper Distributed Data Interface — "медный" интерфейс распределенных данных) предназначены для создания сетей со скоростью обмена информацией порядка 100 Мбод. Преимущество FDDI перед 10 мегабитовой Ethernet состоит в том, что данная технология обеспечивает связь на расстоянии до 2 километров. Следует заметить, что гигабитовая Ethernet с передачей данных по волоконно-оптическому кабелю обеспечивает дальность до 5 километров. Для того чтобы опции ядра 2.4.17, предназначенные для поддержки FDDI/CDDI, стали доступны, надо установить опцию FDDI Driver Support.

• HIPPI. HIPPI (High Performance Parallel Interface — высокопроизводительный параллельный интерфейс) обеспечивает скорость обмена данными 800 или 1600 Кбод. При соединении с помощью витой пары максимальная дальность составляет до 25 метров, многорежимное волоконно-оптическое соединение обеспечивает дальность до 300, а однорежимное волоконно-оптическое соединение — до 10 километров. Ядро 2.4.17 поддерживает единственное устройство HIPPI Essential RoadRunner. Заметьте, что драйвер данного устройства считается экспериментальным.

• Fiber Channel. Данный тип сетевого интерфейса поддерживает как волоконно-оптическое соединение, так и соединение с помощью обычного кабеля и обеспечивает скорость передачи данных 133-1062 Мбод. При использовании волоконно-оптического кабеля максимальная дальность составляет до 10 километров. Ядро поддерживает единственное устройство Fiber Channel Interphase 5526 Tachyon.

Некоторые из описанных выше сетевых сред, например Token Ring, используются для создания локальных сетей, компоненты которых размещаются в одном здании либо в нескольких зданиях, расположенных рядом. Другие, например FDDI и HIPPI, чаще применяются для организации соединения между компьютерами, расположенными на большом расстоянии, например, находящимися в различных помещениях на территории университетского городка. Поддержка этих технологий системой Linux означает, что компьютер под управлением Linux может выступать в роли маршрутизатора, связывающего между собой различные типы сетей.

На заметку

Далее в этой книге мы будем предполагать, что локальная сеть, к которой подключены компьютеры под управлением Linux, создана на базе технологии Ethernet. Если при решении конкретной задачи вам потребуется организовать поддержку других сетей, то единственное, что вам придется для этого сделать, — это изменить имя сетевого интерфейса. Устройствам Ethernet имена присваиваются следующим образом. Первое устройство имеет имя eth0 , второе — eth1 и т.д. Аналогично именуются другие устройства, например, первому устройству Token Ring присваивается имя tr0 , а второму устройству FDDI — имя fddi1 .

 

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

Термин "устройства с широкой полосой пропускания" имеет несколько значений. Во-первых, этот термин обозначает устройства, позволяющие одновременно передавать различные типы информации, например, видео, аудио и обычные цифровые данные. Во-вторых, устройствами с широкой полосой пропускания называют устройства с большой пропускной способностью, позволяющие увеличить скорость передачи данных по коммутируемым линиям (например, реализовать скорость обмена до 200 Кбод). Конечно, величина 200 Кбод выглядит более чем скромно по сравнению со скоростями, которые обеспечивает технология Ethernet, но все же 200 Кбод — это значительно больше, чем скорость 56 Кбод, которой позволяют добиться обычные телефонные линии.

Устройства с широкой полосой пропускания часто применяются в небольших компаниях для связи с серверами Internet-провайдеров или для организации взаимодействия компьютеров, расположенных далеко друг от друга. В большинстве случаев посредством устройств с широкой полосой пропускания пользователи подключают свои компьютеры к Internet. Этим данные устройства отличаются от других сетевых устройств, которые связывают несколько компьютеров в одну локальную сеть. Часто, подключая компьютеры пользователей через устройства с широкой полосой пропускания, провайдеры накладывают ограничения на их действия. Так, например, провайдер может запретить пользователю устанавливать на своем компьютере серверы.

На момент написания данной книги наиболее популярными из устройств с широкой полосой пропускания были DSL (Digital Subscribe Line — цифровая линия подписки) и кабельные модемы. Существует несколько разновидностей DSL, например ADSL (Asymmetric DSL — асимметричная DSL) и SDSL (Single-Line, или Symmetric DSL — одиночная линия, или асимметричная DSL). В процессе работы DSL-устройства передают высокочастотные сигналы по обычным телефонным линиям. Кабельные модемы пересылают данные по кабельным телевизионным сетям и используют полосу частот свободного телевизионного калана. Некоторые из устройств с широкой полосой пропускания передают данные через спутниковые системы, по радиоканалам и по волоконно-оптическим кабелям.

Большинство соединений с широкой полосой пропускания используют специальные внешние модемы, а подключение к локальным компьютерам производится через Ethernet-порты. Поэтому, для того, чтобы работа через такое соединение стала возможной, необходим Ethernet-адаптер, кроме того, надо обеспечить поддержку этого адаптера с помощью стандартного драйвера Linux. Сам по себе широкополосный модем может работать без специального драйвера, но некоторые провайдеры используют РРРоЕ (Point-to-Point Protocol over Ethernet — протокол межузлового взаимодействия через Ethernet). В этом случае необходимо обеспечить поддержку данного протокола в системе Linux, для чего надо установить опцию PPP over Ethernet в меню Network Device Support (эта опция считается экспериментальной). Для того чтобы опция PPP over Ethernet была доступна, необходимо включить опцию PPP. Средства РРРоЕ понадобятся также в том случае, если вы собираетесь запускать на вашем компьютере пакет Roaring Penguin РРРоЕ (этот пакет находится по адресу http://www.roaringpenguin.com/pppoe/).

Некоторые широкополосные модемы используют вместо Ethernet интерфейс USB. В ядре 2.4.17 поддержка данных устройств не предусмотрена, но Alcatel предоставляет Linux-драйверы для своего модема Speed Touch USB DSL (http://www.alcatel.com/consumer/dsl/supuser.htm). Информацию о других USB-продуктах можно найти по адресу http://www.linux-usb.org.

Ряд широкополосных модемов, особенно предназначенных для установления низкоуровневых ADSL-соединений, поставляются вместе с внутренними PCI-картами. Лишь немногие из этих устройств поддерживаются в системе Linux. В частности, в ядре 2.4.17 предусмотрена поддержка General Instruments Surfboard 1000 и некоторых односторонних модемов. Односторонними (one-way) называются модемы, которые могут только принимать данные. При работе с такими модемами для передачи данных используются обычные модемы, взаимодействующие по телефонным линиям. В настоящее время односторонние модемы встречаются очень редко. Драйверы для модема Diamond 1MM DSL можно найти по адресу http://www.rodsbooks.com/network/network-dsl.html, однако они являются модернизацией существующих Ethernet-драйверов и при использовании их в 2.4.x и более старших версиях ядра могут возникать проблемы.

Компьютеры, расположенные на большом расстоянии друг от друга, часто соединяют с помощью выделенных линий, которые часто называют арендованными линиями. Роль выделенной линии чаще всего выполняет обычная телефонная линия, арендованная у телефонной компании. По такой линии не передается тональный сигнал, все меры по организации взаимодействия модемов должны принять специалисты, занимающиеся созданием сети. Сети, созданные на базе выделенных линий, обычно называют региональными сетями, или WAN (Wide-Area Network). При организации региональных сетей часто используются специальные внешние устройства, называемые WAN-маршрутизаторами. Для создания региональных сетей могут также применяться специальные интерфейсные карты. В системе Linux предусмотрена поддержка таких устройств; соответствующие опции находятся в подменю Wan Interfaces меню Network Device Support. Как и при работе со многими другими подменю, для того, чтобы получить доступ к опциям, которые соответствуют конкретным устройствам, необходимо включить опцию Wan Interfaces Support, расположенную в начале данного подменю.

 

Беспроводные устройства

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

К сожалению, на момент написания данной книги беспроводные сети по многим характеристикам уступают Ethernet-сетям. Беспроводные сети гораздо дороже Ethernet-сетей, скорость передачи данных относительно мала, а разработка стандартов, регламентирующих структуру и работу таких сетей, еще продолжается. В настоящее время основными стандартами являются 802.11 и 802.11b. Стандарт 802.11 определяет скорость обмена 2 Мбод со снижением до 1 Мбод. Снижением называется повторный обмен инициализационными параметрами в случае, если уровень сигнала слишком низкий или если помехи искажают сигнал. Стандарт 802.11b определяет скорость 11 Мбод со снижением до 5,5, 2 и 1 Мбод. Существует также беспроводная технология Bluetooth, которая поддерживает скорость обмена до 1 Мбод. Основное направление развития беспроводных сетей связано с увеличением скорости передачи данных. Планируется разработать беспроводные версии ATM со скоростью обмена до 155 Мбод.

Как правило, беспроводные локальные сети создаются на базе беспроводных устройств PC Card, используемых в портативных компьютерах. В одних случаях эти устройства могут непосредственно обмениваться данными друг с другом, в других случаях для взаимодействия необходима базовая станция, которая может выполнять роль шлюза к сети, созданной традиционными средствами. С помощью базовой станции можно также организовать подключение к Internet. Существуют беспроводные ISA и PCI-карты, которые позволяют подключать к беспроводным сетям настольные компьютеры и рабочие станции. Для поддержки устройств PC Card, ISA и PCI в системе Linux необходимо установить соответствующие драйверы; для обеспечения работы базовой станции никакое специальное программное обеспечение не требуется.

Для включения средств поддержки беспроводных устройств в ядре Linux предусмотрены опции, которые содержатся в меню Wireless LAN (Non-Hamradio). Опции в данном меню расположены по типам устройств, а не по технологиям, используемым в них (например, 802.11b или Bluetooth). Кроме того, существуют пакеты Wireless Extensions и Wireless Tools, которые упрощают управление беспроводными сетями, созданными с помощью средств Linux. Информацию об этих пакетах можно найти по адресу http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html. Здесь же расположены дополнительные ссылки на документы, имеющие отношение к беспроводным сетям.

 

Устройства PC Card

Большинство портативных компьютеров имеют как минимум одно гнездо PC Card. (Часто в документации по системе Linux для обозначения устройств PC Card используется старый термин PCMCIA. Устройства PC Card можно подключать и удалять в процессе работы компьютера. Поскольку при разработке системы Linux предполагалось, что сетевые интерфейсы не должны исчезать без предупреждения, для работы с устройствами PC Card создан специальный пакет Card Services. При подключении или удалении устройств PC Card инструменты Card Services соответственно запускают или останавливают компоненты ядра, имеющие отношение к этим устройствам. Дополнительную информацию о Card Services можно получить, обратившись по адресу http://pcmcia-cs.sourceforge.net.

В ядре 2.4.17 опции поддержки многих устройств PC Card находятся в меню PCMCIA Network Device Support. Некоторые из опций, соответствующих беспроводным устройствам, находятся в меню Wireless LAN (Non-Hamradio). После того как вы включите соответствующую опцию и сконфигурируете карту, она будет работать как обычное устройство ISA или PCI. Так, например, Ethernet PC Card распознается системой как устройство eth0, а для его настройки используются стандартные инструменты, которые будут рассмотрены в главе 2.

Версии ядра, предшествующие 2.4.x, требуют для поддержки устройств PC Card специальный пакет драйверов. Следует также заметить, что многие устройства PC Card до сих пор не поддерживаются стандартным ядром Linux. Упомянутый выше пакет драйверов входит в набор Card Services. Если вы используете ядро 2.4.x, для работы с PC Card вам вряд ли придется устанавливать специальные драйверы; такие драйверы могут потребоваться для модемов, SCSI-адаптеров и других устройств.

 

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

Для установления связи по коммутируемой линии чаще всего используются обычные модемы. Чтобы обмен данными был возможен, необходимо также включить средства поддержки протокола PPP (Point-to-Point Protocol — протокол межузлового взаимодействия). Соединение по коммутируемой линии устанавливается из командной строки либо с помощью инструмента, предоставляющего графический пользовательский интерфейс. Подробно вопросы установления соединения будут рассматриваться в главе 2.

Для того чтобы активизировать средства поддержки PPP, надо установить опцию PPP (Point-to-Point Protocol) Support в меню Network Device Support. Если вы включите эту опцию, станут доступны некоторые дополнительные опции, например PPP Support for Async Serial Ports и PPP Deflate Compression. Эти опции не всегда необходимы, но в некоторых случаях они могут повысить эффективность обмена информацией за счет сжатия данных, передаваемых по линии связи. Если вы собираетесь использовать средства ядра PPPoE для работы через DSL-соединение, вам придется установить экспериментальную опцию PPP over Ethernet. Для некоторых дополнительных PPPoE-пакетов эта опция не нужна.

Протокол PPP часто используется при передаче информации через соединения, устанавливаемые без участия модема, например, при обмене данными между компьютерами, подключенными через последовательные порты. Следует заметить, что такое подключение применяется чрезвычайно редко, так как Ethernet-карты недорогие и обеспечивают гораздо более эффективное взаимодействие по сети. Соединение через последовательные порты обычно устанавливают на короткое время, когда нет смысла использовать сетевые карты.

PPP — не единственный протокол, посредством которого может осуществляться связь по коммутируемой линии. В ядре Linux поддерживается также протокол SLIP (Serial Line Internet Protocol — протокол Internet для обмена по последовательной линии), который выполняет практически те же функции, что и PPP. Особенности протокола SLIP таковы, что он плохо подходит для взаимодействия с Internet-провайдером, поэтому вам вряд ли придется использовать его. SLIP используется некоторыми инструментами Linux для выполнения действий на локальном компьютере. Например, утилита, поддерживающая dial-on-demand, т.е. устанавливающая PPP-соединение при обнаружении сетевой активности, использует SLIP для выявления попыток обращения к компьютерам за пределами локальной сети.

Помимо PPP и SLIP, для организации обмена данными между компьютерами может использоваться протокол PLIP (Parallel Line Internet Protocol — протокол Internet для обмена по параллельной линии). Как нетрудно догадаться, этот протокол применяется тогда, когда компьютеры соединены друг с другом через параллельный порт (порт принтера). Параллельный порт позволяет гораздо быстрее передавать данные, чем последовательный порт RS-232; несмотря на это, соединение через параллельный порт также применяется поскольку Ethernet обеспечивает более высокое быстродействие. Для того чтобы использовать протокол PLIP, надо установить опцию PLIP (Parallel Port) Support в меню Network Device Support; при этом предварительно следует активизировать опцию Parallel Port Support в одноименном меню, а при работе на x86 надо также выбрать опцию PC-Style Hardware. Информацию об организации сети PLIP можно получить в документе PLIP Mini-HOWTO (http://www.linuxdoc.org/HOWTO/mini/PLIP.html). Если вы не можете воспользоваться кабелем Turbo Laplink, то найдете в этом документе рекомендации по изготовлению кабеля для соединения компьютеров.

 

До сих пор мы рассматривали опции ядра, имеющие отношение к сетевым протоколам и аппаратным средствам, используемым для соединения вашего компьютера с сетью. Компиляция ядра непосредственно не связана с обеспечением сетевого взаимодействия, однако значение этой задачи нельзя недооценивать. Чтобы добавить или удалить некоторые сетевые средства, необходимо перекомпилировать ядро. В данном разделе рассматриваются основные вопросы компиляции и установки ядра системы.

Внимание

Если вы установили необходимые вам опции сетевого взаимодействия, это совсем не означает, что вы полностью выполнили настройку ядра. Существуют также опции, предназначенные для управления контроллерами EIDE, адаптерами SCSI, файловой системой на диске, а также многие другие опции. Несмотря на то что эти опции не рассматриваются в данной книге, они чрезвычайно важны для обеспечения нормальной работы операционной системы. Если вы неправильно установите значения соответствующих опций, система не будет загружаться либо будет работать некорректно (например, скорость обмена данными с диском может стать недопустимо низкой). Опции ядра подробно обсуждаются в документе Linux Kernel HOWTO , который находится по адресу http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html (и на многих других серверах). Вопросы настройки ядра также рассматриваются в ряде книг по Linux.

 

Драйверы, встроенные в ядро, и драйверы, реализуемые в виде модулей

Как вы уже знаете, при настройке ядра можно включить или отключить некоторые свойства ядра, например, вы можете разрешить или запретить использование конкретного Ethernet-адаптера. На рис. 1.1 видно, что существуют опции, значения которых можно выбирать более чем из двух возможных вариантов. В качестве примера рассмотрим опцию Packet Socket. Для этой опции могут быть заданы значения Y, M и N. Значение Y (Yes) указывает на то, что средства, соответствующие данной опции, должны быть включены в основной файл ядра, а значение N (No) запрещает использование этих средств. Значение M задает некоторое "промежуточное" решение. Если вы выберете значение M, то соответствующие средства будут скомпилированы, но не войдут в основной файл ядра. Вместо этого фрагмент кода будет реализован как отдельный модуль ядра, который по мере надобности загружается или удаляется из памяти. Для опций, являющихся подопциями других опций (например, Packet Socket: Mmapped IO, показанной на рис. 1.1), значение M обычно не предусмотрено. Решение о включении их в основной файл ядра или реализации в виде отдельного модуля принимается в зависимости от значения родительской опции.

Средства, включенные в основной файл ядра, доступны с момента загрузки системы и до окончания ее работы. Ситуация, при которой фрагмент кода будет удален из памяти, возникнуть не может. Существуют опции, для которых реализующий их программный код должен быть включен в основной файл ядра. Так, например, файловая система, в которой содержится корневой каталог системы, должна быть доступна с момента загрузки, поэтому соответствующий драйвер должен быть включен непосредственно в ядро. Если вы установили рассмотренную ранее опцию Root File System on NFS, вам придется скомпилировать средства поддержки сетевых устройств и включить их в ядро.

На первый взгляд может показаться, что все средства, которые будут использоваться при работе системы, следует включить в основной файл ядра, однако такой подход имеет серьезный недостаток: при этом увеличивается объем оперативной памяти, занимаемой ядром. Кроме того, размер файла ядра на диске также увеличивается, что может создавать трудности при загрузке системы. Поэтому в системе Linux предусмотрена возможность компилировать средства, соответствующие большей части опций, в виде модулей. Это позволяет работать с ядром небольшого размера и в то же время обеспечивает поддержку большого количества разнообразных устройств. В частности, в виде модулей могут быть скомпилированы средства для работы с большинством сетевых устройств, поэтому драйверы, включаемые в состав дистрибутивных пакетов, обычно подготавливаются именно в таком виде.

Если администрирование компьютера под управлением Linux является вашей обязанностью, то именно вам предстоит решить, следует ли использовать драйверы сетевых карт, реализованные в виде модулей, или их следует включить в состав ядра. Если вы включите драйвер сетевой карты непосредственно в ядро системы, вам не придется обеспечивать при настройке системы, чтобы перед началом сетевого обмена загружался требуемый модуль. (На самом деле система, поставляемая как дистрибутивный пакет, изначально сконфигурирована так, что данная задача решается корректно.) С другой стороны, если вы администрируете большое количество компьютеров, на которых установлена система Linux, то, возможно, предпочтете создать ядро и набор модулей, которые будете устанавливать на различные компьютеры. В этом случае целесообразно реализовать драйверы в виде модулей.

Программные средства поддержки стека протоколов также могут быть непосредственно включены в ядро или скомпилированы как модули. (Исключением являются протоколы TCP/IP; их можно либо включить в основной файл ядра, либо не использовать вовсе; в виде модулей можно реализовать лишь средства, соответствующие некоторым подопциям опции, управляющей использованием данного стека протоколов.) Так, например, если вы знаете, что каталоги в файловых системах других компьютеров, предоставляемые средствами NFS, будут использоваться лишь непродолжительное время, целесообразно реализовать средства поддержки клиента NFS как отдельный модуль. Поступив таким образом, вы сэкономите часть оперативной памяти в течение времени, когда средства NFS не используются, но монтирование внешних каталогов будет осуществляться несколько дольше, чем это было бы в том случае, если бы фрагмент кода, реализующий клиент NFS, был включен непосредственно в ядро.

Как вы, наверное, поняли, однозначного ответа на вопрос, надо ли включать коды поддержки опций непосредственно в ядро или их следует компилировать как отдельные модули, не существует. Я рекомендую вам сначала выяснить, насколько часто соответствующие средства будут использоваться в процессе работы системы. Если они должны использоваться постоянно, включайте их в основной файл ядра; если же они будут задействованы лишь эпизодически, компилируйте их в виде отдельных модулей. Если размер ядра становится слишком велик и при его загрузке средствами LOADLIN (DOS-утилита для загрузки Linux) возникают проблемы, следует отдать предпочтение модульной организации ядра. Возможность загрузки с помощью LOADLIN желательно сохранить, так как это поможет справиться с некоторыми проблемами.

 

Компиляция ядра

После того как вы сконфигурировали ядро системы, выполнив make xconfig или другую команду, приведенную в начале данной главы, вы должны скомпилировать ядро и установить его модули. Для этого необходимо выполнить следующие команды:

# make dep

# make bzImage

# make modules

# make modules_install

Первая из этих команд выполняет подготовительную работу. Слово dep сокращенно обозначает dependency, соответственно при выполнении команды make dep анализируются выбранные вами опции и определяется, какие исходные файлы зависят от других. Если вы пропустите этот шаг, компиляция будет выполнена некорректно.

В результате выполнения второй команды строится основной файл ядра, который имеет имя bzImage и обычно размещается в каталоге /usr/src/linux/arch/i386/boot. Существуют различные варианты данной команды. Например, при создании ядра небольшого размера можно использовать команду make zImage (ядро в формате bzImage дает возможность загрузчику, например LILO, обрабатывать ядро большего размера, чем это позволяет zImage). Как zImage, так и bzImage представляют собой сжатые варианты ядра. Они являются стандартом для компьютеров x86, но на других платформах вам придется вместо make bzImage вызвать команду make vmlinux. В результате выполнения данной команды строится несжатое ядро. Каталог, в который помещается основной файл ядра, может отличаться от приведенного выше. Если вы работаете на компьютере, отличном от x86, вместо каталога i386 будет использован каталог, имя которого соответствует текущей платформе. Так, например, на PowerPC этот каталог имеет имя ррс.

Команда make modules, как нетрудно догадаться, компилирует модули ядра. По команде make modules_install файлы, содержащие эти модули, копируются в соответствующие позиции в каталоге /lib/modules. В частности, в каталоге /lib/modules создается каталог, имя которого отражает версию ядра, а в нем, в свою очередь, — подкаталоги для конкретных классов драйверов.

На заметку

Команды make dep , make bzImage (или эквивалентную ей команду) и make modules может выполнить любой пользователь, при условии, что он обладает правами чтения и записи данных в каталогах, содержащих исходные коды ядра. Выполнить команду make modules_install может только пользователь root.

В зависимости от установленных опций и от быстродействия компьютера, процесс компиляции ядра может занять от нескольких минут до нескольких часов. Как правило, основной файл ядра создается дольше, чем модули, но если число модулей велико, для их создания может потребоваться больше времени, чем для создания ядра. При компиляции на экран монитора выводится большое число сообщений, описывающих ход обработки исходных файлов. Иногда отображаются предупреждающие сообщения, на которые можно не обращать внимание. При появлении сообщения об ошибке компиляция прерывается.

 

Проблемы, возникающие при компиляции ядра

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

• Ошибки в исходном коде или несовместимость кода. Иногда встречаются драйверы, которые содержат ошибки в исходном коде либо несовместимы с остальными компонентами ядра. Такая ситуация может возникнуть при работе с ядром, находящимся в процессе разработки, либо при попытке включить в состав ядра нестандартный драйвер. В этом случае при компиляции отображается одно или несколько сообщений об ошибке. Чтобы избавиться от ошибок, надо обновить версию ядра или, по крайней мере, заменить драйвер, который стал источником проблем. Если без этого драйвера можно обойтись, лучше вовсе отказаться от его использования.

• Отсутствие информации о зависимости файлов. Если работа драйвера зависит от другого драйвера, то первый драйвер должен выбираться лишь после того, как будет выбран второй. В некоторых случаях сценарий, посредством которого выполняется конфигурирование системы, работает некорректно. При компиляции ядра это проявляется следующим образом: каждый файл по отдельности компилируется нормально, но собрать файл ядра не удается. Если драйвер компилируется как отдельный модуль, то при попытке загрузить отображается сообщение об ошибке. Иногда в сообщении об ошибке содержится информация о том, какие действия надо предпринять, чтобы избавиться от нее. В некоторых случаях решить проблему удается, вызвав команду make dep, а затем повторно скомпилировав ядро. Иногда работоспособное ядро можно получить, отказавшись от включения драйвера непосредственно в основной файл и скомпилировав его в виде отдельного модуля (в некоторых случаях приходится принимать обратное решение, т.е. включать в ядро драйвер, который, будучи подготовленным в виде отдельного модуля, стал источником проблем).

• Устаревшие объектные файлы. Если вы компилируете ядро, а затем изменяете конфигурацию и компилируете его повторно, утилита make автоматически определяет, какие файлы затрагивают внесенные изменения, и повторно компилирует их. Если при работе данной утилиты возникает сбой, это может привести к ошибке при создании ядра. В одних случаях не удается собрать ядро из готовых компонентов, в других случаях ошибки возникают при компиляции отдельных файлов. Для того чтобы решить эту проблему, надо выполнить команду make clean, которая удалит существующие объектные файлы, а затем повторить компиляцию системы.

• Ошибка компилятора. GNU С Compiler (GCC) считается надежным компилятором, но бывают случаи, когда он становится источником проблем. Версия GCC, которая входит в состав Red Hat 7.0, не может скомпилировать ядро 2.2.x, но эта проблема устранена в версии ядра 2.4.x. (С Red Hat 7.0 поставляются две версии GCC; для того чтобы компиляция ядра была выполнена успешно, надо вместо gcc использовать kgcc.)

• Проблемы с использованием аппаратных средств. GCC более интенсивно использует ресурсы компьютера по сравнению с другими программами, поэтому сбои аппаратных средств чаще проявляются в процессе компиляции ядра системы. Такие ошибки называются ошибками signal 11, так как GCC возвращает именно такое сообщение. Причиной подобных ошибок, как правило, являются неисправности в процессоре и оперативной памяти. Дополнительную информацию об этих проблемах и способах их устранения можно найти по адресу http://www.bitwizard.nl/sig11.

Если вы не можете самостоятельно разрешить проблемы, возникающие при компиляции ядра, отправьте сообщение в одну из групп новостей, посвященных системе Linux, например в comp.os.linux.misc. Подробно опишите ваш дистрибутивный пакет, укажите версию ядра, которую вы пытаетесь скомпилировать, и сообщения об ошибках. (Сообщения компилятора, не связанные с возникновением ошибок, лучше не указывать.)

 

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

Чтобы готовое ядро можно было использовать, его необходимо инсталлировать. Как было сказано ранее, скомпилированное ядро помещается в каталог /usr/src/linux/arch/i386/boot (вместо i386 может присутствовать другой каталог, имя которого отражает название процессора). Файл ядра надо скопировать или переместить в каталог /boot. Желательно переименовать файл так, чтобы его имя отражало версию ядра и изменения, которые вы внесли в него. Например, вы можете назвать файл ядра bzImage-2.4.17 или bzImage-2.4.17-xfs. Если команда make modules_install до сих пор не выполнялась, надо вызвать ее, инсталлировав тем самым модули ядра в каталог /lib/modules/x.y.z, где x.y.z — это номер версии ядра.

Копирования файла ядра в каталог /boot недостаточно. Чтобы ядро можно было использовать, необходимо также модифицировать загрузчик. Большинство дистрибутивных пакетов содержит Linux Loader (LILO); настройка этого загрузчика на новое ядро осуществляется путем редактирования файла конфигурации /etc/lilo.conf. В листинге 1.1 показано содержимое файла lilo.conf, настроенного на загрузку одного ядра.

Листинг 1.1. Простой файл lilo.conf

boot=/dev/sda

map=/boot/map

install=/boot/boot.b

prompt

default=linux

timeout=50

image=/boot/vmlinuz

 label=linux

 root=/dev/sda6

 read-only

На заметку

LILO используется на компьютерах x86. Работая на других компьютерах, вам придется ориентироваться на другие типы загрузчиков. Эти загрузчики во многом напоминают LILO и отличаются от него лишь некоторыми деталями. Описания этих загрузчиков можно найти в документации на конкретные дистрибутивные пакеты.

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

1. Откройте файл /etc/lilo.conf в текстовом редакторе.

2. Продублируйте строки файла, описывающие текущее ядро, используемое по умолчанию. Первая из этих строк начинается символами image=. Описание ядра продолжается до конца файла либо до тех пор, пока не встретится выражение image= или other=. В листинге 1.1 ядро описывается в последних четырех строках.

3. Модифицируйте строку image= так, чтобы она указывала на новый файл ядра. Например, вместо выражения image=/boot/vmlinuz включите выражение image=/boot/bzImage-2.4.17. (Во многих дистрибутивных пакетах Linux по умолчанию загружается файл ядра

4. Измените строку label= для нового ядра, указав после символа = новое значение, например mykernel или 2417. Это значение позволит отличать новое ядро от прежнего. В процессе загрузки вам будет предложено выбрать имя требуемого ядра в меню или ввести его в командной строке.

5. Сохраните внесенные изменения.

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

Внимание

Приведенные выше инструкции предполагают, что файл /etc/lilo.conf не содержит ошибок. При наличии ошибок выполнение п. 6 может привести к повреждению данных на жестком диске. Включая информацию о новом ядре, не изменяйте и не удаляйте другие данные, содержащиеся в файле.

При следующей загрузке компьютера LILO предложит вам указать, какое ядро должно использоваться при работе системы. В зависимости от настройки, вы сможете либо выбрать ядро в меню, либо указать имя ядра в строке после символов lilo:.

Если качество нового ядра устраивает вас, модифицируйте файл /etc/lilo.conf так, что это ядро будет загружаться по умолчанию. Для этого надо изменить строку default=. Измените текст после знака =, указав имя нового ядра, которое вы присвоили ему в п. 4, а затем в командной строке снова вызовите lilo.

Ядро Linux можно загрузить без использования LILO. В некоторых дистрибутивных пакетах вместо LILO содержится загрузчик Grand Unified Boot Loader (GRUB). Особенности конфигурирования GRUB описаны в документации на этот загрузчик. Кроме того, для загрузки Linux также можно использовать DOS-программу LOADLIN. Чтобы такая загрузка стала возможной, надо скопировать ядро на диск, доступный из DOS, например, в раздел DOS или на гибкий диск. Для загрузки Linux надо ввести следующую команду:

С:> LOADLIN BZIMAGE root=/dev/sda6 ro

В данном примере BZIMAGE — это имя файла ядра, который доступен из DOS, a /dev/sda6 — идентификатор корневого раздела, используемый в Linux. Опция ro указывает на то, что данный раздел должен монтироваться в режиме, допускающем только чтение (впоследствии Linux повторно смонтирует этот раздел в режиме чтения и записи). LOADLIN — удобный инструмент, позволяющий тестировать новые версии ядра, не изменяя настройку LILO. Кроме того, LOADLIN дает возможность загрузить Linux, если LILO поврежден. Если на вашем компьютере отсутствует система DOS, вы можете воспользоваться системой FreeDOS (http://www.freedos.org), которая также позволяет выполнить данную задачу. Утилита LOADLIN входит в состав большинства дистрибутивных версий Linux. На компакт-диске она обычно располагается в каталоге dosutils.

 

Несмотря на то что система DHCP используется во многих сетях, в ряде случаев приходится выделять IP-адреса другими способами. Некоторым компьютерам (например, на которых выполняются серверы DHCP) чрезвычайно трудно присваивать адреса с помощью DHCP. Кроме того, сервер DHCP попросту может отсутствовать в сети. В подобных случаях приходится распределять IP-адреса вручную. Средства для решения данной задачи рассматриваются в данном разделе. Кроме того, далее в этой главе рассказывается, как настроить систему, чтобы ее конфигурация автоматически устанавливалась при загрузке.

На заметку

Как правило, компьютерам, на которых выполняются программы-серверы, присваивают статические IP-адреса; при этом адрес не изменяется с течением времени. Кроме того, связывание статических IP-адресов с доменными именами не вызывает трудностей. (Вопросы функционирования серверов DNS и установления соответствия между IP-адресами и доменными именами рассматриваются в главе 18.) Чтобы связать доменное имя с динамическим IP-адресом, вам надо обеспечить, чтобы сервер DHCP выделял компьютеру один и тот же адрес (как это сделать, вы узнаете в главе 5), либо использовать динамические средства DNS.

 

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

Загрузка драйвера — это лишь первое действие, которое надо выполнить, чтобы обеспечить доступ к сетевому интерфейсу. Для того чтобы интерфейс можно было использовать, ему необходимо присвоить IP-адрес и выполнить дополнительные настройки, например задать маску подсети. Для решения этой задачи используется утилита ifconfig, которая, в зависимости от способа ее вызова, либо отображает информацию об интерфейсе, либо изменяет его конфигурацию.

Использование ifconfig

Синтаксис ifconfig достаточно прост. Для вызова данной утилиты надо задать в командной строке следующее выражение:

ifconfig [ интерфейс ] [ опции ]

Набор передаваемых параметров определяет поведение ifconfig. Данная утилита может выполнять следующие действия.

• Если ifconfig вызывается без параметров, она возвращает информацию о состоянии всех активных сетевых интерфейсов, т.е. действует как инструмент диагностики.

• Если данной утилите передано только имя интерфейса (например, eth0 или tr1), то она возвращает информацию лишь о состоянии этого интерфейса.

• Если помимо имени интерфейса заданы некоторые опции, ifconfig модифицирует данный интерфейс в соответствии со значениями переданных опций. Чаще всего с помощью данной утилиты интерфейс активизируется либо переводится из активного в неактивное состояние.

Если вы собираетесь использовать ifconfig для настройки интерфейса, вам необходимо изучить назначение опций, которые передаются данной утилите. Список опций, которые приведены на страницах справочной системы, посвященных ifconfig, очень велик. Наиболее важные из них описаны ниже.

• up адрес . Данная опция активизирует интерфейс и связывает с новым интерфейсом указанный IP-адрес. Если в составе команды не указана маска подсети, используется маска, определяемая исходя из класса адреса (классы IP-адресов описаны в табл. 2.2). В большинстве случаев ключевое слово up можно не указывать; если при вызове ifconfig заданы имя интерфейса и IP-адрес, оно предполагается по умолчанию.

Таблица 2.2. Классы IP-адресов и соответствующие им маски подсети

• down. Эта опция противоположна опции up, т.е. она делает интерфейс неактивным ("закрывает" его).

• netmask nm . Данная опция устанавливает маску подсети для интерфейса. Маска подсети определяет, какое число битов в составе IP-адреса выделяется для представления адреса сети; остальные биты адреса идентифицируют компьютер в составе сети. Если данная опция не указана, по умолчанию принимается маска подсети, определяемая на основании адреса (табл. 2.2). Маску подсети можно также задать с помощью опции up адрес как число бит, соответствующих адресу сети.

• [-]promisc. По умолчанию сетевая карта принимает только те пакеты, которые непосредственно адресованы ей. Данная опция включает (promisc) или отключает (-promisc) так называемый режим сбора пакетов, или режим прослушивания (promiscuous mode), в котором карта принимает все пакеты, передаваемые по сети. Режим сбора пакетов применяется для диагностики сети. (Этот режим часто используют хакеры для перехвата паролей, передаваемых в незакодированном виде.) Некоторые программы также могут включать режим сбора данных.

• mtu n . Данная опция устанавливает значение MTU (Maximim Transfer Unit — максимальный размер передаваемого блока), т.е. максимальный размер пакета нижнего уровня. Для сетей Ethernet значение MTU обычно принимается равным 1500, но при необходимости вы можете изменить его. (Ряд маршрутизаторов использует меньшее значение MTU, кроме того, некоторые протоколы накладывают ограничения на величину MTU. Если установленный в системе максимальный размер пакета превышает предельно допустимое значение для сети, это приводит к снижению производительности, так как перед передачей пакет разбивается на кадры меньшего размера.)

• add адрес / длина_префикса . Данная опция выполняет те же действия, что и опции up и netmask, но она ориентирована на протокол IPv6. (Протокол IPv6 представляет собой новый стандарт обмена данными в Internet.) Как было сказано в главе 1, IPv6 поддерживает значительно больше адресов, чем IPv4. На момент написания данной книги, т.е. в 2002 г., этот протокол еще использовался очень редко.

• del адрес / длина_префикса . Эта опция противоположна опции add, т.е. она отменяет IPv6-адрес, присвоенный ранее интерфейсу.

• media тип . Некоторые сетевые карты допускают подключение нескольких разъемов (например, 10Base-2 и 10Base-T). Данная опция позволяет определить, какой разъем должен использоваться (например, media 10Base-T). Подробную информацию о поддерживаемых типах разъемов можно найти в описании конкретного драйвера.

• hw класс адрес . Данная опция позволяет задавать аппаратный адрес сетевой карты. Если вам потребовалось заменить сетевую карту, но вы хотите, чтобы сервер DHCP продолжал выделять тот же IP-адрес, вам надо воспользоваться данной опцией и задать для новой карты аппаратный адрес, использовавшийся ранее. Бывают также случаи, когда разные производители выпускают карты с одинаковыми адресами. Такие устройства нельзя использовать в рамках одной локальной сети; в этом случае опция hw также может оказаться полезной. Данная опция предполагает два значения: класс сетевого устройства (например, ether для Ethernet или ARCnet для ARCnet) и аппаратный адрес. Заметьте, что на некоторые сетевые карты данная опция не оказывает влияния.

• txqueulen длина . Эта опция задает длину очереди, т. е. число пакетов, ожидающих передачи через определенный интерфейс. По умолчанию принимается значение 100, что в большинстве случаев обеспечивает нормальную работу сети. Уменьшая длину очереди, можно несколько увеличить скорость обмена посредством таких протоколов, как Telnet и SSH.

В большинстве случаев выполнение команды ifconfig обеспечивает активизацию интерфейса. Ниже приведен пример команды, которая активизирует Ethernet-карту и присваивает ей адрес 172.23.45.67.

# ifconfig eth0 172.23.45.67

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

# ifconfig eth0 172.23.45.67 netmask 255.255.255.0 mtu 1420

Как было сказано выше, маска подсети определяет, какая часть IP-адреса должна представлять адрес сети, а какая — адрес компьютера в этой сети. Компьютер использует эту информацию для определения адресов назначения исходящих пакетов; если установить маску подсети неправильно, некоторые компьютеры будут не доступны. Если представить маску подсети в двоичном виде, нетрудно заметить, что она начинается последовательностью единиц, за которой следует последовательность нулей. Например, маска 255.255.255.0 состоит из 24 единиц и восьми нулей. Вместо указания маски можно задать в составе адреса число битов, используемых как адрес сети. Информация о числе битов, представляющих адрес подсети, отделяется от основной части IP-адреса косой чертой. Например, 172.23.45.67/24 соответствует адресу 172.23.45.67 и маске подсети 255.255.255.0. Такое выражение можно использовать при вызове утилиты ifconfig в составе опции up адрес ; в этом случае опцию netmask nm можно не указывать.

Классы IP-адресов

В качестве примеров IP-адресов в данной книге используются зарезервированные адреса. предназначенные для организации работы внутренних сетей. Сделано это для того, чтобы неопытные читатели случайно не использовали адреса существующих узлов глобальной сети. Для внутренних сетей зарезервированы адреса 192.168.x.x (класс С), 172.16.0.0-172.31.255.255 (класс В) и 10.x.x.x (класс А). Узлы с такими адресами гарантированно отсутствуют в Internet.

В дополнение к классам А, В и С, описанным в табл. 2.2 существуют также классы адресов D и E. Адреса класса D применяются для группового вешания (передаваемый пакет адресуется сразу нескольким узлам), а адреса класса E зарезервированы для дальнейшего использования.

В табл. 2.2 приведены маски подсетей для различных классов адресов. С начала 1990-х этот стандарт стал претерпевать некоторые изменения. Дело в том, что, согласно традиционной схеме распределения IP-адресов, предусмотрено слишком много сетей класса А, каждая из которых может насчитывать больше десяти миллионов компьютеров, в то время как число сетей класса С оказывается недостаточным. Спецификация CIDR (Classless Inter-Domain Routing — бесклассовая междоменная маршрутизация) позволяет задавать произвольные диапазоны IP-адресов, используя для этого маски подсетей. Так, например, организации, которой требуются две сети класса С, могут быть предоставлены адреса 10.34.56.0/24 и 10.34.57.0/24. Благодаря такому принципу распределения адреса используются гораздо эффективнее, чем это позволяет сделать традиционная схема, предусматривающая классы А, В и С. Однако при этом администраторы сетей и пользователи должны внимательно следить за назначением масок подсетей. Если, например, вы предоставите утилите ifconfig возможность самостоятельно. назначить маску подсети для компьютера 10.34.56.78, то по умолчанию будет использована маска 255.0.0.0 и маршрутизация будет выполняться некорректно. Очевидно, что для сети 10.34.56.0/24 маска подсети должна иметь значение 255.255.255.0.

Настройка нескольких сетевых интерфейсов

Если компьютер содержит несколько сетевых интерфейсов, утилиту ifconfig надо вызвать для каждого из интерфейсов. Рассмотрим следующие команды:

# ifconfig eth0 up 192.168.1.1

# ifconfig eth1 up 172.23.45.67/24

В результате их выполнения с интерфейсом eth0 связывается адрес 192.168.1.1, интерфейсом eth1 — адрес 172.23.45.67; для eth1 будет использоваться маска подсети 255.255.255.0. Оба интерфейса работоспособны. Но как определить, через какой интерфейс следует передавать тот или иной пакет? Предположим, что прикладная программа, выполняющаяся на этом компьютере, должна установить соединение с узлом, имеющим адрес 10.9.8.7. Как узнать, на какой интерфейс надо передать пакет, предназначенный этому узлу? Для решения этой задачи (задачи маршрутизации) используются таблицы маршрутизации. Как вы вскоре увидите, задачу маршрутизации приходится решать, даже если на компьютере присутствует лишь один сетевой интерфейс.

 

Заполнение таблицы маршрутизации

Таблица маршрутизации выполняет две задачи. Во-первых, она сообщает системе, на какой из интерфейсов следует передавать информационные пакеты. На первый взгляд может показаться, что если на компьютере установлен лишь один сетевой интерфейс, то ответ на этот вопрос очевиден. На самом деле это не так. Дело в том, что на каждом из компьютеров, работающих под управлением системы Linux, поддерживается интерфейс обратной петли. Этот интерфейс соответствует сети 127.0.0.0/8, но реально при работе с ним используется лишь один IP-адрес 127.0.0.1. Поскольку этот интерфейс присутствует на всех компьютерах, многие программы используют его для взаимодействия с другими локальными программами. При этом обеспечивается более высокая скорость обмена, чем при использовании традиционных сетевых интерфейсов. Для того чтобы распределять трафик между интерфейсом локальной петли и обычными сетевыми интерфейсами, существуют специальные правила. Вторая задача, которую выполняет таблица маршрутизации, состоит в управлении трафиком, предназначенным для компьютеров в локальной сети. Для маршрутизации в локальной сети используется протокол ARP (Address Resolution Protocol — протокол преобразования адресов). Пакеты, предназначенные узлам локальной сети, непосредственно передаются соответствующим компьютерам, а пакеты, адресованные удаленным узлам, передаются посредством маршрутизатора, или шлюза. В большинстве случаев в таблице маршрутизации Linux указывается лишь один шлюз, но встречаются также более сложные конфигурации с несколькими шлюзами. Для заполнения таблицы маршрутизации используется команда route.

На заметку

В Internet на пути от одного компьютера к другому может находиться большое число маршрутизаторов, но каждый компьютер должен знать адрес лишь одного маршрутизатора. Получив пакет, который должен быть передан по определенному адресу, маршрутизатор определяет адрес следующего маршрутизатора; этот процесс повторяется до тех пор, пока пакет не прибудет по назначению.

Структура таблицы маршрутизации

Таблица маршрутизации содержит набор записей, которые определяют, как должны обрабатываться пакеты, в зависимости от адреса их назначения. Когда программа передает пакет, предназначенный для передачи ядру, последнее сравнивает адрес назначения с адресами или диапазонами адресов, указанными в записях таблицы, начиная с наиболее конкретных адресов, т.е. с диапазона, определяющего сеть наименьшего размера. Если адрес назначения пакета соответствует очередному адресу или диапазону, для передачи пакета используется правило, указанное в таблице маршрутизации, в противном случае сравнение продолжается. Самое универсальное из правил носит название маршрута по умолчанию, оно определяет любой адрес Internet. Маршрут по умолчанию обычно направляет пакет через шлюз локальной сети.

Для чтобы лучше понять, как используется таблица маршрутизации, рассмотрим пример такой таблицы. На рис. 2.2 показана таблица маршрутизации, которая отображается в результате выполнения команды route -n (более подробно команда route будет рассмотрена в следующем разделе). Записи таблицы, изображенной на рисунке, упорядочены так, что в начале расположены записи, определяющие наиболее конкретные правила обработки, а в конце таблицы находятся наиболее универсальные правила. В первой записи указан адрес назначения 255.255.255.255, т. е. широковещательный адрес. Широковещательные пакеты передаются через интерфейс eth0, при этом шлюз не используется. В последующих двух записях содержатся адреса назначения 10.92.68.0 и 192.168.1.0, которые представляют собой адреса локальных сетей; им соответствует маска подсети 255.255.255.0, которая указана в столбце Genmask. Эти две записи направляют трафик соответственно через интерфейсы eth1 и eth0. Если компьютер содержит только один сетевой интерфейс, в таблице маршрутизации будет указана лишь одна подобная запись. Четвертая запись соответствует интерфейсу обратной петли (в некоторых разновидностях Linux, например в системе Debian, при выводе таблицы маршрутизации этот маршрут не отображается, но он учитывается при обработке пакетов). Обратите внимание, что этот интерфейс имеет имя lo (оно содержится в столбце Ifасе таблицы). Последняя запись, в которой указан адрес назначения 0.0.0.0, определяет маршрут по умолчанию. Этот адрес вместе с маской подсети 0.0.0.0 соответствует любому адресу, при сравнении которого с адресами, указанными в предыдущих правилах, был получен отрицательный результат. В этом случае трафик направляется через интерфейс eth1. Маршрут по умолчанию — единственный маршрут в таблице, для которого был указан шлюз (в данном случае 10.92.68.1).

Рис. 2.2. Для того чтобы определить маршрут пакета, надо сравнить его адрес назначения с адресом, указанным в столбце Destination, и учесть при этом маску подсети, значение которой отображается в столбце Genmask

При активизации интерфейса с помощью ifconfig эта утилита автоматически включает в таблицу маршрутизации запись, соответствующую активизированному интерфейсу. Эта запись определяет маршрут к сети, которая подключена через данный интерфейс. Сценарий, выполняющихся при загрузке Linux, добавляет в таблицу запись для интерфейса обратной петли. Запись, соответствующая широковещательному маршруту, не обязательна, но используется некоторыми утилитами. Во многих случаях единственной записью, которую приходится создавать вручную, остается маршрут по умолчанию.

Использование route

Если утилита route вызывается без параметров, она отображает текущее содержимое таблицы маршрутизации. Такой же результат будет получен при указании некоторых опций (например, опции -n, которая указывает на то, что при выводе содержимого таблицы вместо доменных имен должны отображаться числовые IP-адреса). Однако в основном route предназначена для добавления, удаления и изменения записей о маршрутах. Синтаксис route имеет следующий вид:

route add|del [-net|-host] target [netmask nm ] [gateway gw ] [metric m ] [mss m ] [window W ] [[dev] interface ]

Ниже перечислены опции данной утилиты и описано их назначение.

• add|del. Опция add задается тогда, когда необходимо добавить в таблицу запись о новом маршруте, а опция del позволяет удалить существующую запись. При добавлении нового маршрута необходимо задать дополнительную информацию. При удалении можно ограничиться указанием адреса назначения.

• [-net|-host]. В качестве адреса назначения вы можете задать либо адрес сети (-net), либо адрес конкретного компьютера (-host). В большинстве случаев route способна самостоятельно отличить адрес сети от адреса узла, но иногда необходимо явно указать тип адреса. Чаще всего данную опцию приходится задавать, определяя маршрут к небольшой сети, подключенной с помощью отдельного шлюза.

• адрес_назначения . Адрес назначения принадлежит сети или отдельному компьютеру, которому маршрутизатор должен передать пакет. Для маршрута по умолчанию используется адрес 0.0.0.0 либо эквивалентное ему ключевое слово default. Этот параметр необходимо указывать при добавлении или удалении маршрута.

• [netmask nm ] . Если адреса сети, которой должны быть переданы пакеты, соответствуют традиционной схеме распределения адресов, утилита route, пользуясь сетевыми средствами Linux, сама определит значение маски подсети. В противном случае вам необходимо явно задать маску подсети, указав при вызове route параметр netmask nm . (Вместо использования данного параметра вы можете указать число бит, выделяемых для представления адреса сети, в составе адреса назначения.)

• [gateway gw ] . Если вы определяете маршрут, который не проходит через шлюз, можете не указывать этот параметр. Если же целевой узел подключен через шлюз, необходимо задать адрес этого шлюза, указав при вызове route gateway gw . В частности, данный параметр используется при определении маршрута по умолчанию.

• [metric m ] . На рис. 2.2 среди прочих изображен столбец Metric. В нем отображается метрика маршрута, т.е. "стоимость" передачи пакета. Чаще всего за "стоимость" принимается время передачи пакета. Таким образом, маршрутам, на которых встречаются линии с низким быстродействием, соответствуют высокие значения метрики, а "быстрым" маршрутам — низкие значения метрики. Параметр metric m используется только в том случае, если компьютер выполняет роль маршрутизатора. Подробно вопросы настройки маршрутизаторов будут рассмотрены в главе 24.

• [mss m ] . Параметр mss m задает максимальный размер сегмента (MSS — Maximum Segment Size). Подобно metric m , данный параметр используется в основном в маршрутизаторах.

• [window W ] . Размер окна (TCP Window Size) — это объем данных, которые могут быть переданы передающим узлом, не дожидаясь получения подтверждения с принимающего узла. Если задано небольшое значение данного параметра, скорость обмена данными уменьшится, так как передающий компьютер будет простаивать, ожидая подтверждения приема пакета. Если указать слишком большой размер окна, повышается вероятность того, что вследствие возникновения ошибки передающему узлу придется повторять передачу большого объема информации. Поэтому наилучшее решение — использовать размер окна по умолчанию (в системе Linux он составляет 64 Кбайт). Если данные по линии передаются быстро, но с большой задержкой (например, если используется спутниковая связь), то целесообразно увеличить размер окна до 128 Кбайт.

• [[dev] имя_интерфейса ] . Как правило, система Linux по IP-адресу самостоятельно определяет используемый интерфейс. Однако в некоторых случаях необходимо указать интерфейс явно, задавая при вызове route параметр [dev] имя_интерфейса . (Ключевое слово dev указывать не обязательно, достаточно задать имя интерфейса, например eth0 или tr1.)

Наиболее часто с помощью утилиты route задается маршрут по умолчанию. Делается это после того, как посредством утилиты ifconfig был активизирован сетевой интерфейс. Пример определения маршрута по умолчанию с помощью route приведен ниже.

# route add 0.0.0.0 gw 10.92.68.1

Адрес 0.0.0.0 можно заменить ключевым словом default; результат выполнения команды от этого не изменится. Несколько реже при вызове route приходится указывать имя устройства, опцию -net и некоторые другие опции.

Использование нескольких интерфейсов и одного шлюза

Как было сказано ранее, при каждой активизации интерфейса посредством ifconfig данная утилита автоматически включает в таблицу маршрутизации запись для нового интерфейса. Однако при этом не добавляется информация о шлюзах. Поэтому настройка большинства компьютеров, содержащих несколько интерфейсов, включает следующие действия.

• Вызов ifconfig для каждого из интерфейсов компьютера.

• Одиночный вызов route для добавления в таблицу маршрутизации маршрута по умолчанию.

Эти действия типичны для компьютеров под управлением Linux, которые выполняют функции маршрутизаторов для сетей небольших отделов. Для того чтобы компьютер действовал как маршрутизатор, необходимо разрешить перенаправление IP-пакетов. Сделать это можно, выполнив следующую команду:

# echo "1" > /proc/sys/net/ipv4/ip_forward

На заметку

Если компьютер содержит два сетевых интерфейса (т.е. одновременно принадлежит двум сетям), но не должен выполнять функции маршрутизатора, не следует разрешать перенаправление IP-пакетов.

На заметку

Маршрутизатор не обязательно должен быть выделенным. Компьютер, выполняющий функции маршрутизатора, может одновременно решать другие задачи. Однако при этом необходимо учитывать, что действия, не связанные с маршрутизацией пакетов, занимают время процессора и создают дополнительную нагрузку на сетевые интерфейсы, в результате производительность маршрутизатора снижается, что может привести к уменьшению пропускной способности всей сети. Кроме того, подобное совмещение функций может создавать угрозу безопасности сети. В настоящее время маршрутизаторы выполняют также функции брандмауэров, и работа дополнительных программных продуктов на таком компьютере может открывать дополнительные возможности для атак, предпринимаемых злоумышленниками.

Если провайдер выделил для вашего компьютера лишь один IP-адрес, но вы хотите организовать доступ к Internet с нескольких компьютеров, подключенных к локальной сети, вам необходимо использовать специальный тип маршрутизатора, в котором используется технология NAT (Network Address Translation — преобразование сетевых адресов). Эта технология подробно описана в главе 25. Настройка системы NAT выполняется подобно настройке обычного маршрутизатора, кроме того, в этом случае приходится выполнять дополнительные команды, разрешающие преобразование адресов. В результате такого преобразования вся локальная сеть выглядит извне как один компьютер.

Использование нескольких интерфейсов и шлюзов

Если компьютер с несколькими интерфейсами должен передавать пакеты на различные шлюзы, его настройка несколько усложняется. Большинство систем работает с одним шлюзом, через который проходит маршрут по умолчанию. Такой шлюз соединяет локальную сеть с другой сетью, и в большинстве случаев посредством этого же шлюза осуществляется взаимодействие с Internet. Однако возможны и другие варианты конфигурации сети. Рассмотрим локальные сети, представленные на рис. 2.3. Как видно на рисунке, две локальные сети, принадлежащие различным подразделениям одной организации, соединены с помощью маршрутизаторов. Конфигурация обычных компьютеров, принадлежащих этим сетям, очень проста; в маршруте по умолчанию в качестве адреса шлюза указан адрес маршрутизатора, через который локальная сеть подключена к другой сети. Несмотря на то что маршрутизатор сети Office 2 имеет два интерфейса, в маршруте по умолчанию, заданном в его таблице маршрутизации, роль шлюза играет маршрутизатор сети Office Маршрутизатор сети Office 1 имеет более сложную конфигурацию. Его маршрут по умолчанию обеспечивает обмен пакетами с Internet, кроме того, трафик, предназначенный для сети 172.20.0.0/16, должен передаваться на маршрутизатор Office 2. Чтобы такая передача пакетов могла выполняться, необходимо вызвать следующую команду:

# route add -net 172.20.0.0 netmask 255.255.0.0 gw 172.21.1.1

Рис. 2.3. Чтобы маршрутизатор, содержащий больше двух интерфейсов, работал корректно, для него должны быть определены как минимум два шлюза

На заметку

Структура, показанная на рис. 2.3, имеет смысл только в том случае, если сети Office 1 и Office 2 расположены далеко друг от друга и для их взаимодействия используется один из протоколов поддержки удаленного соединения. Если же подразделения находятся рядом, например в одном здании, целесообразно подключить обе сети к одному концентратору или коммутатору. При этом обе сети могут обслуживаться одним маршрутизатором.

В данном случае предполагается, что маршрутизатор Office 2 использует для соединения с маршрутизатором Office 1 сетевой интерфейс с адресом 172.21.1.1. Заметьте, что этот адрес не принадлежит сети Office 2 (все компьютеры сети Office 2 соединены с маршрутизатором Office 2 через один интерфейс, а маршрутизатор Office 1 подключен к нему через другой интерфейс). Если кроме приведенной выше команды для маршрутизатора Office 1 также задать с помощью утилиты route маршрут по умолчанию, то в результате в таблице маршрутизации будут определены два шлюза: один в качестве маршрута по умолчанию, а другой — для управления трафиком, предназначенным для сети Office 2. Заметьте, что остальные компьютеры в сети Office 1 не обязаны знать об особенностях настройки маршрутизатора, в них должна содержаться лишь информация о маршруте по умолчанию, в котором роль шлюза выполняет маршрутизатор этой сети.

Подобная конфигурация маршрутизатора может потребоваться и в других случаях. Предположим, что в сети Office 1 присутствует второй маршрутизатор, посредством которого локальная сеть подключается к Internet. При этом для каждого компьютера сети Office 1 должны быть определены два шлюза: шлюз по умолчанию, т.е. компьютер, посредством которого осуществляется соединение сети с Internet, и второй шлюз, через который походит маршрут к компьютерам сети Office 2. (Компьютеры сети Office 1 могут быть сконфигурированы и по-другому, для них может быть определен только шлюз по умолчанию, который, в свою очередь, будет передавать пакеты на второй шлюз. Как нетрудно заметить, использование такой конфигурации увеличивает трафик локальной сети.) Поскольку использование двух маршрутизаторов затрудняет настройку компьютеров, желательно использовать в сети один маршрутизатор.

 

Настройка DNS

После активизации интерфейсов и установки маршрутов компьютер может обмениваться пакетами как с компьютерами локальной сети, так и с любыми другими компьютерами, с которыми он соединен системой шлюзов. Для указания адреса назначения пакета используются IP-адреса. Такая адресация естественна для маршрутизаторов, но чрезвычайно неудобна для пользователей. Преобразование символьных имен (например, www.awl.com) в IP-адреса, используемые при маршрутизации пакетов, осуществляет система доменных имен (DNS — Domain Name System). Кроме того, DNS может также осуществлять обратное преобразование.

DNS поддерживает глобальную распределенную базу данных, для работы с которой используется большое количество серверов. Для того чтобы пользоваться этой базой, компьютер должен знать адрес лишь одного сервера DNS. Большинство организаций и провайдеров Internet устанавливают у себя один или несколько серверов. Чтобы узнать адрес такого сервера, надо обратиться к администратору сети. Получив эти сведения, надо включить их в файл /etc/resolv.conf. В данном файле может содержаться до трех строк, начинающихся с ключевого слова nameserver, за которым следует IP-адрес сервера DNS. В этом файле также указывается домен по умолчанию (для этого используется ключевое слово domain) и произвольное число доменов, в которых выполняется поиск имени. Поиск проводится в том случае, если указано лишь имя компьютера, а имя домена пропущено (например, если вместо mail.threeroomco.com пользователь задал имя mail). Пример файла /etc/resolv.conf, содержащего все три типа записей, приведен в листинге 2.1.

Листинг 2.1. Пример файла /etc/resolv.conf

domain threeroomco.com

search tworoomco.comfourroomco.com

nameserver 10.98.17.34

nameserver 172.20.13.109

Внимание

Несмотря на то что запись search позволяет сэкономить время при вводе доменного имени, желательно воздержаться от ее использования. Предположим, что в обоих доменах, указанных в листинге 2.1 ( tworoomco.com и fourroomco.com ), содержится компьютер с именем www . Если, работая на компьютере, на котором находится приведенный выше файл /etc/resolv.conf , пользователь введет имя www , он может получить документ, содержащийся на сервере одного домена, и считать при этом, что он работает с другим доменом. Кроме того, при поиске затрачивается время, в течение которого обработка других запросов на преобразование адресов замедляется. Более того, даже если вы зададите полное имя, система сначала попытается найти в доменах, определенных посредством записей domain и search. Например, если на компьютере, на котором находится рассматриваемый файл /etc/resolv.conf , вы зададите имя www.awl.com , то сначала будет предпринята попытка найти имена www.awl.com.threeroomco.com , www.awl.com.tworoomco.com и www.awl.com.fourroomco.com и лишь затем начнется обработка имени www.awl.com . Успехом увенчается лишь попытка преобразования имени, в которое после домена com будет стоять точка.

После того как вы отредактируете файл /etc/resolv.conf в соответствии со своими потребностями, можете начинать работу в сети. Для активизации внесенных изменений не требуются никакие дополнительные команды. Linux автоматически начнет работать с указанным сервером имен и выполнять поиск в указанных доменах.

Если вы хотите, чтобы ваш компьютер под управлением Linux выполнял функции сервера DNS, вам надо выполнить специальные настройки. Сделать это поможет материал, изложенный в главе 18. В главе 18 приводятся сведения об особенностях работы сервера имен. В зависимости от конфигурации, к этому серверу могут обращаться как компьютеры, находящиеся в той же локальной сети, так и другие узлы Internet.

 

Определение имени узла

При использовании многих протоколов семейства TCP/IP необходимо, чтобы к компьютеру можно было обращаться по имени. Для того чтобы упростить настройку отдельных программ, в Linux содержится специальная утилита hostname, позволяющая определить имя узла. Если вызвать эту утилиту без параметров, она выведет текущее имя узла. Если за именем утилиты следует имя узла (например, hostname larch.threeroomco.com), это имя присваивается узлу. Имя узла можно хранить в файле и с помощью опции -f или -file передавать hostname имя того файла, например hostname -f /etc/HOSTNAME. В большинстве дистрибутивных пакетов предусмотрена автоматическая установка имени узла при загрузке системы, но имя узла в различных системах хранится в разных файлах. Это может быть файл /etc/hostname, /etc/HOSTNAME или файл, указанный в составе дополнительного конфигурационного файла (см. табл. 2.1).

Имя узла должно устанавливаться единожды, но это не всегда возможно. Некоторые прикладные программы, в частности почтовые клиенты и программы просмотра сообщений Usenet, позволяют пользователям переопределять имена, используемые по умолчанию. Задать имя узла можно также в файле /etc/hosts. Этот файл используется при работе системы преобразования имен, альтернативной DNS. В файле /etc/hosts содержатся строки, начинающиеся с IP-адреса, за которым следует набор имен узла. Чаще всего первым после IP-адреса указывается полностью определенное доменное имя, в его состав входит имя компьютера и домен, которому он принадлежит, например larch.threeroomco.com. За полностью определенным доменным именем следуют так называемые псевдонимы. Обычно они представляют собой сокращенную форму имени, например larch. Если ваш компьютер корректно настроен для работы с сервером DNS и если на этом сервере содержатся записи для вашего компьютера, нет необходимости определять имя узла в файле /etc/hosts. Если сервер DNS работает ненадежно или если в результате некорректной работы маршрутизаторов сервер DNS периодически становится недоступным, записи в /etc/hosts повысят надежность работы вашего компьютера в сети. Кроме того, вы, возможно, захотите поставить в соответствие адресу 127.0.0.1 имена localhost.localdomain и localhost. Примеры записей в файле /etc/hosts приведены ниже.

10.92.68.1 larch.threeroomco.com larch

127.0.0.1 localhost.localdomain localhost

Совет

Если в процессе загрузки системы возникает пауза в несколько секунд и даже несколько минут (в особенности такая пауза бывает заметной при запуске программы sendmail ), это может означать, что при соединении с сервером DNS возникают проблемы и вам желательно определить имя узла в файле /etc/hosts .

Если компьютер содержит несколько сетевых интерфейсов, вы можете задать одно имя узла посредством команды hostname или определить в файле /etc/hosts отдельное имя для каждого интерфейса. (Сервер DNS также позволяет задать для одного компьютера несколько имен.)

Совет

Настраивая небольшую сеть, вы можете указать имена всех компьютеров в файлах /etc/hosts ; при этом необходимость в использовании сервера DNS отпадает. Однако при увеличении размеров сети редактировать файлы /etc/hosts становится все труднее. В этом случае целесообразно перейти к использованию централизованного сервера DNS.

 

Сохранение внесенных изменений

Некоторые из описанных выше процедур настройки системы предполагают редактирование конфигурационных файлов. К таким процедурам относятся установка имени узла в файле /etc/hosts и указание адресов серверов DNS в файле /etc/resolv.conf. Установки, выполненные таким способом, продолжают действовать до тех пор, пока соответствующий файл не будет поврежден, либо до переинсталляции системы. Другие изменения конфигурации носят временный характер. Характеристики системы, установленные с помощью утилит ifconfig, route или hostname, действуют лишь до перезагрузки компьютера либо до тех пор, пока установки не будут изменены теми же средствами. Чтобы сохранить произведенные установки, надо внести соответствующие изменения в сценарий запуска системы либо отредактировать конфигурационный файл. Для этого используются текстовый редактор либо специальные инструментальные средства.

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

Один из самых простых способов сохранения внесенных изменений — использование инструментов с графическим пользовательским интерфейсом (если такие средства входят в состав дистрибутивного пакета; в Debian и Slackware, например, подобные инструменты отсутствуют).

• Red Hat и Mandrake. Эти системы содержат программу Linuxconf с графическим интерфейсом, предназначенную для настройки системы. Данная программа может также использоваться в других системах, например в LinuxPPC. Версии данной программы, поставляемые в составе разных дистрибутивных пакетов, предоставляют варианты интерфейса, несколько отличающиеся друг от друга. Чтобы запустить программу linuxconf, достаточно ввести в командной строке ее имя. Эта программа может работать в текстовом режиме (в этом случае меню создается алфавитно-цифровыми средствами), в графическом режиме, а также в режиме Web-сервера, позволяющем выполнять удаленное администрирование.

• SuSE. В системе SuSE содержатся инструменты YaST (Yet Another Setup Tool) и YaST2. YaST работает в текстовом режиме и формирует систему меню. YaST2 выполняет те же функции, что и YaST, но предоставляет графический пользовательский интерфейс. Окно YaST2 показано на рис. Для запуска этих программ используются соответственно команды yast и yast2.

• Caldera. В системе Caldera используется инструмент COAS (Caldera Open Administration System) с графическим интерфейсом. Для его запуска надо вызвать в окне xterm команду coastool.

• TurboLinuх. В TurboLinux для установки конфигурации применяется графическая программа TurboLinux Configuration Center. Для ее запуска используется команда turbocfgcenter.

• Все дистрибутивные пакеты. В рамках проекта Webmib (http://www.webmib.com/webmib/) создан инструмент администрирования, работающий на базе Web. Его можно использовать в различных разновидностях Linux, а также в системах, отличных от Linux, например в разных версиях UNIX. При установке Linux данный инструмент не инсталлируется, но если Webmib поддерживает конкретную систему, его установка не составляет труда.

Различные инструменты конфигурации реализованы по-разному, но все они позволяют устанавливать параметры системы посредством меню. Выбрав соответствующие пункты меню, можно выполнять установки, которые будут сохраняться постоянно. Например, в окне, показанном на рис. 2.1., можно щелчком мышью установить опцию Static Address Setup, ввести IP-адрес, а также активизировать кнопку Hostname and Nameserver или Routing и выполнить дополнительные установки.

Инструменты с графическим интерфейсом имеют один недостаток. Часто они не позволяют выполнить подробную настройку системы. Так, например, с помощью некоторых инструментов невозможно сконфигурировать систему для работы с несколькими интерфейсами и шлюзами. Как правило, подобные инструменты ориентированы на простые конфигурации. В таких случаях приходится вручную корректировать содержимое конфигурационных файлов.

Редактирование конфигурационных файлов

В табл. 2.1 показано расположение некоторых конфигурационных файлов, содержащих команды клиента DHCP и некоторую дополнительную информацию о настройках. В этих файлах также находится информация о статических IP-адресах. Перед тем как изменять настройки компьютера, следует внимательно просмотреть эти файлы и найти в них вызовы утилит ifconfig, route, hostname и другие подобные команды. Некоторые файлы не содержат команд, вместо этого в них присутствуют переменные окружения, которые представляют информацию о том, пользуется ли система услугами сервера DHCP или она настроена на работу со статическими IP-адресами. Как правило, проанализировав сценарии и конфигурационные файлы, можно получить информацию, достаточную для того, чтобы изменить настройку системы в соответствии со своими потребностями.

Если посредством редактирования конфигурационных сценариев и конфигурационных файлов не удается сделать необходимые установки, вам следует включить в сценарии запуска команды конфигурирования системы. В большинстве версий системы сценарий запуска содержится в файле /etc/rc.d/rc.local, а в системе SuSE используется сценарий, находящийся в файле/etc/rc.d/boot.local. В Debian локальный сценарий отсутствует, но вы можете создать собственный сценарий и поместить его в каталог /etc/rc.boot. В состав такого сценария можно включить любые команды, в том числе вызовы ifconfig и route. Этот сценарий получает управление после выполнения основных сценариев, используемых при запуске системы, таким образом, подобное расположение команд конфигурации сети нельзя признать идеальным. Тем не менее в таком сценарии удобно выполнять некоторые настройки, например добавлять новые маршруты.

 

При рассмотрении вопросов сетевого взаимодействия предполагается, что компьютер под управлением Linux подключен к обычной локальной сети, узлы которой соединены посредством сетевых кабелей (например, к сети Ethernet). В такой среде можно инсталлировать серверы (работа серверов рассматривается в части II и III). При организации работы серверов необходимо учитывать вопросы безопасности, которые обсуждаются в части IV. В реальных сетях не все узлы подключены посредством постоянных соединений. Некоторые компьютеры подключаются через коммутируемые линии с помощью модемов. В большинстве случаев устанавливать сервер на компьютере, подключаемом через телефонную линию, не имеет смысла, но иногда модемы используются для подключения небольших сетей к Internet; в такой сети могут присутствовать различные серверы. Возможно, что при подключении по коммутируемой линии возникнет необходимость обеспечить взаимодействия с Internet всех компьютеров локальной сети, имея в наличии лишь один IP-адрес. В этом случае придется воспользоваться средствами NAT, которые будут подробно обсуждаться в главе 25. Однако, для того чтобы средства NAT могли работать, необходимо сначала установить PPP-соединение. Вопросы PPP-взаимодействия обсуждаются в последующих разделах.

PPP через Ethernet

В некоторых низкоуровневых соединениях DSL используется разновидность протокола PPP, известная под названием PPPoE. Поддержка PPPoE реализована в ядре Linux, но соответствующие средства считаются экспериментальными. На момент написания данной книги для поддержки PPPoE чаще всего использовалась клиент-программа Roaring Penguin PPPoE ( http://www.roaringpenguin.com/pppoe/ ). Эта программа реализована для различных платформ и распространяется в исходных кодах либо как пакет RPM.

После инсталляции Roaring Penguin необходимо сконфигурировать эту программу, для чего надо выполнить команду asdl-setup либо tkpppoe ( asdl-setup соответствует алфавитно-цифровому варианту данной программы, а посредством команды tkpppoe выполняется настройка разновидности Roaring Penguin, предоставляющей графический пользовательский интерфейс). После запуска сценарий настройки запрашивает пользовательское имя и пароль и создает сценарий запуска с именем asdl-start . Сценарий asdl-start впоследствии используется для инициализации PPPoE-соединения.

Заметьте, что Roaring Penguin предполагает, что средства поддержки сетевых устройств сконфигурированы правильно. Linux обеспечивает обмен посредством модемов DSL, действующих на базе Ethernet; при этом очевидно, что в системе должна быть включена поддержка Ethernet-карты. Если же для взаимодействия с модемом DSL используется интерфейс USB либо если к компьютеру подключен внутренний модем, то для таких устройств надо установить специальные драйверы. На момент написания данной книги были доступны лишь экспериментальные варианты этих драйверов.

 

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

PPP — достаточно сложный протокол; при его настройке используется большое число различных опций. Если значения этих опций выбраны неправильно, взаимодействие посредством PPP может не состояться. По этой причине многие пользователи избегают работать с конфигурационными сценариями и предпочитают устанавливать PPP-соединение с помощью специальной программы с графическим интерфейсом. Программы, поддерживающие PPP-соединение в системе Linux, очень похожи на программы аналогичного назначения, используемые в других операционных системах, например в Windows. Поэтому для тех, кто имеет опыт в использовании PPP-соединений в других системах, не составит труда решить ту же задачу в Linux.

Разные программы установления соединений по коммутируемым линиям различаются между собой лишь в деталях. В данном разделе рассматривается популярная программа KPPP, которая входит в состав K Desktop Environment (KDE). С KPPP можно работать, даже не используя KDE. Кроме KDE для установления соединений по телефонным линиям можно применять программу GNOME PPP (она входит в состав GNU Network Object Model Environment, или GNOME), а также инструменты, не являющиеся частями интегрированных сред, например X-ISP (http://xisp.hellug.gr).

На заметку

Перед использованием KPPP необходимо получить учетную запись и протестировать модем. Чтобы убедиться в работоспособности модема, надо прежде всего подключить его к компьютеру и включить питание. Далее следует попытаться передать данные на /dev/ttyS0 , /dev/ttyS1 или какой-либо другой порт. Если файлы устройств автоматически создавались с помощью devfs ( http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html ), то вы можете использовать /dev/tts/0 , /dev/tts/1 и т.д. Для тестирования модема можно воспользоваться коммуникационными программами, такими как minicom или Seyon (обе они поставляются в составе большинства дистрибутивных пакетов Linux). Если вы получите от модема сообщение AT, это значит, что модем можно использовать в системе Linux.

Для того чтобы запустить KPPP, надо выбрать соответствующий пункт меню на рабочем столе либо ввести в окне xterm команду kppp. В результате на экране отобразится окно, показанное на рис. 2.4. Если вы запускаете KPPP впервые, в списке Connect to будет отсутствовать имя провайдера, а поле Login ID будет пустым. Для того чтобы настроить программу так, чтобы с ее помощью можно было пользоваться учетной записью, выполните следующие действия.

Рис. 2.4. Программы поддержки соединений по телефонным линиям с графическим интерфейсом предоставляют возможность выбрать учетную запись, задать пользовательское имя и пароль, а также инициировать соединение

1. Щелкните на кнопке Setup. В появившемся диалоговом окне KPPP Configuration (рис. 2.5) вам надо ввести основные параметры, определяющие особенности установления соединения.

Рис. 2.5. Диалоговое окно KPPP Configuration позволяет управлять аппаратными средствами, посредством которых устанавливается PPP-соединение, в частности, выбрать устройство, к которому подключен модем, и модифицировать данные об учетных записях

2. Для регистрации новой учетной записи щелкните на кнопке New. Программа спросит, хотите ли вы воспользоваться мастером или предпочитаете выполнять настройку с помощью диалоговых окон. Несмотря на то что использование мастера упрощает задачу, он начинает диалог с того, что предлагает выбрать страну, причем в перечне стран отсутствуют США. Поэтому я выбираю вариант настройки программы с помощью диалоговых окон, в результате чего отображается окно New Account, показанное на рис. 2.6

Рис. 2.6. Диалоговое окно New Account позволяет ввести информацию об учетной записи

3. Введите в поле Connection Name имя провайдера.

4. Щелкните на кнопке Add. В результате отобразится небольшое окно, в котором вы можете задать номер телефона вашего провайдера. После того, как вы щелкнете на кнопке OK, введенный вами номер отобразится в текстовой области Phone Number. Повторяя эту операцию, вы можете ввести несколько номеров. При попытке установления соединения программа будет набирать эти номера последовательно один за другим до тех пор, пока не обнаружит свободный номер.

5. В настоящее время большинство провайдеров используют протокол PAP (Password Authentication Protocol — протокол аутентификации с помощью пароля), поэтому целесообразно принять протокол PAP, выбранный в окне New Account по умолчанию. Вы можете изменить протокол, в частности, некоторые провайдеры используют вместо PAP протокол CHAP (Challenge Handshake Authentication Protocol — протокол аутентификации путем опроса при начальном обмене параметрами).

6. Если провайдер предоставит вам список адресов серверов DNS, активизируйте вкладку DNS в окне New Account и введите адрес каждого сервера в поле DNS IP Address, завершая ввод каждого адреса щелчком на кнопке Add.

7. Щелкните на кнопке OK в окне New Account. После этого вы увидите, что в списке учетных записей в окне KPPP Configuration появился новый пункт (см. рис. 2.5).

8. Выберите вкладку Device в диалоговом окне KPPP Configuration. В качестве значения Modem Device установите имя устройства, используемого в вашей системе для подключения модема. Чаще всего это устройство имеет имя /dev/modem, но могут также использоваться /dev/ttyS0, /dev/ttyS1 и некоторые другие устройства. На этой же вкладке вы можете задать значение опции Connection Speed. По умолчанию используется значение 57600, но скорость 115200 часто позволяет добиться лучших результатов. (Большинство аппаратных средств не поддерживает более высокие скорости.) Данная опция задает скорость обмена между вашим компьютером и модемом. Скорость обмена между вашим модемом и модемом провайдера скорее всего будет гораздо ниже. Если модемы используют сжатие данных, желательно установить скорость обмена между компьютером и модемом как минимум вдвое выше, чем скорость обмена между модемами.

9. Щелкните на кнопке OK в окне KPPP Configuration. Теперь новая учетная запись станет доступной в главном окне KPPP (см. рис. 2.4).

На заметку

Окно KPPP Configuration , как и New Account , содержит несколько вкладок. Опции, доступные посредством некоторых из вкладок, здесь не рассматривались. В большинстве случаев вы можете использовать значения по умолчанию, но иногда приходится явно задавать некоторые параметры. Если при попытке соединения с компьютером провайдера у вас возникли проблемы, просмотрите значения опций, расположенных на различных вкладках, и при необходимости измените их. В документе PPP HOWTO ( http://www.linuxdoc.org/HOWTO/PPP-HOWTO/ ) можно найти дополнительную информацию о PPP-соединении, в том числе об установлении PPP-соединения в режиме отладки.

С помощью программы с графическим интерфейсом PPP-соединение устанавливается чрезвычайно просто. После загрузки программы достаточно щелкнуть на кнопке Connect (в некоторых программах эта кнопка может иметь другое имя). Некоторые программы предоставляют пользователю сведения о ходе установления соединения, кроме того, модем может воспроизводить звуковой сигнал во время ведения "переговоров" о параметрах, которые будут использоваться при обмене данными. Работая с KPPP, вы можете щелкнуть на кнопке Show Log Window и получить дополнительную информацию о соединении. Некоторые программы, в том числе KPPP, требуют, чтобы перед активизацией кнопки Connect было введено пользовательское имя (поле Login ID) и пароль. Другие программы запрашивают эти сведения после щелчка на кнопке Connect. Кроме того, пользователь может сохранять пароль на диске (в KPPP для этого надо установить флажок опции Store Password в диалоговом окне New Account).

После установления соединения на кнопке Connect отобразится новая запись. С этого момента щелчок на данной кнопке приведет к разрыву соединения. (В некоторых программах для разрыва соединения используется другая кнопка, либо после установления соединения отображается новое диалоговое окно.) Не забывайте о том, что после окончания работы соединение необходимо разорвать, в особенности, если телефонная компания или провайдер предоставляет вам услуги на условиях поминутной оплаты. В противном случае вы рискуете получить счет, в котором будет указана крупная сумма.

Внимание

Сохраняя пароль на диске, вы создаете угрозу безопасности системы. Если к вашему компьютеру никто другой не имеет доступа, риск невелик. Если же на этом компьютере работают и другие пользователи, при этом некоторые из них не имеют учетных записей и не могут устанавливать PPP-соединения, опасность существенно увеличится. В любом случае желательно, чтобы пароль, применяемый для установления PPP-соединения, не использовался в других целях (например, для входа в систему или для доступа к защищенным данным). И даже если этот пароль будет похищен, вам достаточно будет задать для PPP-взаимодействия новый пароль.

 

Редактирование конфигурационных сценариев

Программы с графическим интерфейсом удобны для тех пользователей, которые не имеют достаточного опыта работы с PPP-соединениями, но в некоторых случаях эти инструменты оказываются непригодными. Например, если вы хотите, чтобы PPP-соединение устанавливалось автоматически, программа с графическим интерфейсом не позволит вам сделать это. В этом случае для инициализации соединения приходится использовать сценарии. Такие сценарии можно запускать либо вручную, либо как часть системы автоматического соединения. При этом необходимо установить опции аутентификации и задать конфигурацию самих сценариев.

Использование опций аутентификации

Как было сказано ранее, для аутентификации пользователей, обращающихся по коммутируемым линиям, большинство провайдеров применяет протокол PAR Для того чтобы сценарий, предназначенный для установления соединения, мог использовать этот протокол, необходимо отредактировать файл /etc/ppp/pap-secrets. (При работе с протоколом CHAP используется файл /etc/ppp/chap-secrets. Содержимое файла chap-secrets имеет тот же формат, что и данные в файле pap-secrets.) В файле /etc/ppp/pap-secrets содержится последовательность строк; каждая строка соответствует отдельной учетной записи PPP и имеет следующий формат:

имя_пользователя сервер пароль IP-адрес

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

• имя_пользователя . Имя, используемое для идентификации пользователя на компьютере провайдера. Это имя никак не связано с именем пользователя, которое указывается при регистрации в системе Linux; оно проверяется только при попытке зарегистрироваться на сервере провайдера.

• сервер . Имя компьютера, к которому обращается клиент при попытке установить PPP-соединение. Как правило, пользователь не обязан знать имя сервера, поэтому чаще всего в данном поле содержится символ *, который указывает на то, что PPP-соединение может быть установлено с любым узлом.

• пароль . Как нетрудно догадаться, в этом поле указывается пароль, используемый для регистрации на удаленном компьютере.

• IP-адрес . IP-адрес, который система предполагает получить. Большинство серверов не гарантирует, что при установлении PPP-соединения будет выделен конкретный IP-адрес, поэтому данное поле обычно оставляют пустым (т.е. строка содержит только три поля).

Внимание

В файле pap-secrets пароль хранится в незашифрованном виде. Это значит, что каждый, кто получит в свое распоряжение данный файл, сможет установить PPP-соединение под вашим именем. Поэтому данный пароль следует использовать только по его прямому назначению. Для получения почты, регистрации в сети и прочих подобных случаев надо применять другие пароли. Для повышения безопасности во многих дистрибутивных пакетах в качестве владельца файла pap-secrets указан пользователь root, и доступ к файлу имеет только он. Без крайней необходимости не следует изменять права доступа к файлу pap-secrets .

В большинстве случаев каждый конкретный компьютер настраивается для взаимодействия с единственным провайдером, поэтому в файле pap-secrets такого компьютера содержится только одна строка. Пример содержимого файла pap-secrets приведен ниже.

penguin * w8terfow1

Настройка сценариев

Отредактировав файл аутентификации, ориентированный на использование протокола PAP или CHAP, можно приступать к настройке сценария, предназначенного для установления соединения. Поскольку для взаимодействия посредством протокола PPP все чаще используются программы с графическим интерфейсом, сценарии размещаются в каталоге с документацией, например /usr/share/doc/ppp- версия /scripts ; где версия означает версию PPP, используемую в конкретном дистрибутивном пакете, например 2.4.0. Наибольший интерес представляют три сценария.

• ррр-on. Этот сценарий устанавливает основные переменные, в частности, задает номер телефона провайдера и вызывает Linux-программу поддержки протокола PPP (pppd).

• ppp-on-dialer. Сценарий ррр-on передает pрр-on-dialer программе pppd, которая использует ppp-on-dialer для управления начальными этапами взаимодействия с компьютером провайдера.

• ppp-off. Этот сценарий завершает сеанс PPP-взаимодействия.

Для того чтобы обеспечить взаимодействие с провайдером, необходимо отредактировать сценарий ррр-on, а в некоторых случаях и сценарий ppp-on-dialer. Кроме того, вы, вероятно, захотите переместить все три сценария в каталог, из которого их было бы удобно взывать, например в /usr/local/bin. В сценарий ррр-on надо внести следующие изменения.

• Найдите переменную TELEPHONE и задайте в качестве ее значения номер телефона провайдера. В результате соответствующая запись должна иметь вид TELEPHONE=123-4567.

• Задайте значения переменных ACCOUNT и PASSWORD. Если провайдер использует протокол PAP, данные переменные не будут использоваться; в этом случае вы можете оставить их значения без изменения.

• Если провайдер предоставляет вам фиксированный IP-адрес и если вы знаете IP-адрес сервера провайдера, можете указать эти адреса в переменных LOCAL_IP и REMOTE_IP. Аналогично, если вам известна маска подсети, вы можете задать ее в качестве значения переменной NETMASK. В противном случае все три переменные можно оставить без изменения.

• Найдите переменную DIALER_SCRIPT и задайте ее значение так, чтобы она ссылалась на сценарий ppp-on-dialer. (Понятно, что DIALER_SCRIPT должна указывать не на исходный вариант файла, содержащийся в каталоге с документами, а на файл, содержимое которого вы изменили в соответствии с вашими требованиями.) По умолчанию для этой переменной задано значение /etc/ppp/ppp-on-dialer, но, как было сказано выше, вы можете выбрать расположение файла ppp-on-dialer по своему усмотрению.

• В конце сценария содержится вызов pppd. Эта программа поддерживает большое количество опций. Опции, указанные в сценарии, за исключением некоторых, изменять не следует. Возможно, вам придется задать имя файла устройства, используемого для подключения модема (по умолчанию указано устройство /dev/ttyS0), а также скорость взаимодействия компьютера с модемом (по умолчанию используется значение 38400, но скорость 115200, как правило, дает лучшие результаты).

Скорректировав содержимое ррр-on, можно приступать к редактированию сценария ppp-on-dialer. Этот сценарий управляет взаимодействием программы pppd с модемом, в частности, использованием команд, предназначенных для установления взаимодействия, а также процессом аутентификации (в случае, если провайдер не использует средства PAP или CHAP). Сценарий вызывает утилиту chat, предназначенную для обмена текстовыми данными. Основную часть сценария составляют пары строк, представляющие собой ожидаемые сообщения и ответы на них, расположенные в два столбца. В первом столбце указаны сообщения, которые ожидает получить сценарий, а во втором столбце — последовательности символов, которые программа chat посылает в ответ. Некоторые из сообщений имеют специальное назначение. Например, ABORT сообщает chat о необходимости прекращения работы в случае ошибки. Большинство строк оканчивается обратной косой чертой (\), а это означает, что следующая строка является продолжением предыдущей. (На самом деле программе chat передается одна строка параметров; пары "сообщение-ответ" представлены в виде столбцов лишь для удобства восприятия.) В конце последней строки обратная косая черта отсутствует.

Изменения следует вносить только в последние три строки файла ppp-on-dialer. По умолчанию при составлении сценария предполагалось, что провайдер не использует PAP, поэтому в последних двух строках предусмотрена передача имени пользователя и пароля в ответ на запрос. (Имя пользователя и пароль хранятся в переменных ACCOUNT и PASSWORD; их значения задаются в сценарии ррр-on.) При необходимости вы можете удалить эти строки или поставить в начале их символы #, указывающие на то, что данные строки содержат комментарии. Если вы сделаете это, то вам также надо удалить обратную косую черту в третьей с конца строке. Удаление двух последних строк и изменение предшествующей им строки приведет к тому, что если pppd попытается использовать для аутентификации соединения протокол PAP или CHAP, chat завершит работу. Если протоколы PAP и CHAP не применяются, вам, возможно, потребуется отредактировать в последних строках сообщения, которые система ожидает получить от провайдера. Может быть, вы захотите выполнить дополнительные команды, например, запустить на компьютере провайдера программу поддержки PPP. В этом случае вам придется включить одну или несколько строк и указать в них в качестве ожидаемого сообщения приглашение для ввода команды.

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

Редактирование сценариев — наиболее трудоемкая часть работы по обеспечению PPP-взаимодействия. После того как данная задача выполнена, вам остается лишь ввести ррр-on, после чего соединение будет инициализировано. (Если сценарий ррр-on расположен в каталоге, который не учтен в переменной окружения PATH, вам придется указать полный путь к этому файлу.) Используя внешний модем, вы сможете следить за ходом установления соединения по светодиодным индикаторам на его панели; при соответствующей настройке модема вы также услышите характерный звук. Если соединение будет установлено нормально, то через несколько секунд вы получите доступ к Internet и сможете использовать клиент-программы для взаимодействия с Internet-серверами.

В случае возникновения проблем вам надо, прежде всего, ознакомиться с содержимым файла протокола (обычно сообщения об установлении соединения и возникающих при этом ошибках записываются в файл /var/log/messages). В конце файла должна содержаться информация о действиях программы pppd, включая операции, которые завершились неудачно. Там вы найдете сведения об истечении времени тайм-аута при ожидании PAP-аутентификации, об ошибках при выполнении chat и другие данные. Если вы не можете понять смысл сообщений, используйте термины, найденные в файле протокола, как ключевые слова при поиске на сервере http://groups.goggle.com. На этом сервере хранятся архивы сообщений, отправленных в группы новостей Usenet и посвященных сетевому взаимодействию системы Linux. Среди них вы найдете обсуждение проблем, связанных с установлением PPP-соединений. Не исключено, что какое-то из сообщений будет содержать ответ на ваш вопрос, либо, по крайней мере, вы поймете, в каком направлении следует искать решение проблемы. Полезными также будут сведения, содержащиеся в документе PPP HOWTO.

Большинство дистрибутивных пакетов сконфигурировано так, что инициализировать PPP-соединение может только пользователь root. Многие воспринимают это как недостаток. Подобные меры принимаются для того, чтобы повысить безопасность в том случае, когда на одном компьютере работают несколько пользователей. Однако иногда такие ограничения мешают в работе. Для того чтобы частично разрешить эту проблему, для программ, предназначенных для взаимодействия по коммутируемым линиям, устанавливается бит SUID, в результате чего эти программы запускаются с привилегиями root. Очевидно, что при этом снова приходится решать вопросы защиты. В частности, многие администраторы сужают круг пользователей, которые имеют право запускать подобные программы. Они создают группу PPP, включают в нее тех пользователей, которым действительно необходим доступ к удаленным узлам по коммутируемым линиям, устанавливают права доступа так, что запустить программу могут только члены группы PPP.

Многие провайдеры сообщают пользователям IP-адреса серверов DNS, которые должны использоваться при взаимодействии посредством PPP-соединения. Эти сведения можно включить в файл /etc/resolv.conf (структура данного файла обсуждалась выше).

 

Установление соединения по запросу

При работе на отдельной рабочей станции или компьютере необходимость использовать специальную программу установления взаимодействия или вручную запускать соответствующий сценарий практически не мешает работе. Если же PPP-соединением пользуется несколько компьютеров, подключенных к локальной сети, могут возникать проблемы. Часто пользователи пытаются установить соединение в то время, когда оно активно, разорвать соединение, когда другие пользователи обмениваются через него информацией с Internet, либо по окончании работы оставляют соединение активным на длительное время. Для решения этих проблем были созданы средства установления соединения по запросу (dial-on-demand). В системе Linux подобные функции выполняет инструмент под названием diald. Эта программа выявляет трафик, направленный из локальной сети к внешним узлам, и инициализирует PPP-соединение. Кроме того, если в течение определенного времени сетевая активность отсутствует, эта программа разрывает соединение. В результате клиентские программы, расположенные в локальной сети, могут работать почти так же, как и программы, находящиеся на компьютерах, постоянно подключенных к Internet; для того чтобы установить или разорвать PPP-соединение, пользователям не приходится предпринимать никаких действий. Различия проявляются лишь в том, что с момента, когда diald обнаруживает попытку обращения к внешнему узлу и до установления PPP-соединения, проходит определенное время. Это связано с тем, что система должна обратиться к модему, а модем, в свою очередь, установить соединение с модемом провайдера. Через некоторое время после прекращения сетевой активности соединение разрывается. Если вы зададите слишком малое значение этого интервала, задержка будет возникать слишком часто, так как с момента получения Web-страницы до запроса очередного документа сетевое взаимодействие отсутствует и система может разорвать соединение. Заметьте также, что если PPP-соединение не активно, при обращении к Web-странице броузер выведет сообщение о том, что документ не доступен. Причина в том, что время тайм-аута, используемое при работе броузера, значительно меньше времени, необходимого для установления PPP-соединения.

Чтобы программа diald могла работать, необходимо установить в ядре Linux средства поддержки SLIP (вопросы настройки и компиляции ядра рассматривались в главе 1). Протокол SLIP необходим для связывания компьютера с программой diald. Эта программа поддерживает постоянно активный сетевой интерфейс, поэтому она имеет возможность выявлять сетевой трафик и устанавливать при необходимости PPP-соединение.

К сожалению, diald не входит в состав большинства дистрибутивных пакетов Linux, поэтому этот инструмент необходимо устанавливать отдельно. Исходный код программы можно найти на сервере http://diald.sourceforge.net, а для того, чтобы получить двоичные коды diald для RPM и Debian, надо обратиться соответственно по адресам http://www.rpmfind.net и http://www.debian.org/distrib.packages.

Для настройки программы diald используются три конфигурационных файла, описанных ниже.

• /etc/diald.conf. В этом файле содержатся опции, подобные тем, которые используются сценарием ppp-on, например, имя устройства, посредством которого подключен модем (device), и скорость соединения (speed). Посредством опций local и remote задаются IP-адреса для внутреннего использования в программе diald. Эти адреса должны принадлежать одному сегменту, но следует следить за тем, чтобы они не совпадали с адресами узлов вашей локальной сети. Вы можете использовать для этой цели IP-адреса, специально выделенные для внутренних сетей, например адреса, принадлежащие диапазону

• /etc/ppp/diald-dialer. Этот файл практически идентичен рассмотренному ранее сценарию ppp-on-dialer. При настройке его содержимое необходимо изменить так же, как и ppp-on-dialer.

• /usr/lib/diald/standard.filter. В этом файле задается значение тайм-аута. Если в течение указанного интервала времени сетевая активность отсутствует, программа diald должна разорвать соединение. Если в процессе работы вы обнаружите, что соединение прекращается слишком быстро, имеет смысл вернуться к значению тайм-аута по умолчанию, первоначально заданному в файле /usr/lib/diald/standard.filter.

Если ваш провайдер использует PAP или CHAP, то кроме перечисленных выше конфигурационных файлов, вам надо также отредактировать файл /etc/ррр/pap-secrets или /etc/ppp/chap-secrets. В соответствующем файле указываются те же данные, что и при настройке PPP-соединения, устанавливаемого с помощью обычных сценариев. Вам также придется включить в файл /etc/resolv.conf адреса серверов DNS, которые сообщит провайдер. Для того чтобы запустить diald, надо задать команду /usr/sbin/diald. Сделать это может только пользователь root. После этого diald будет распознавать трафик, направленный извне, и устанавливать PPP-соединения. Первая попытка обращения к серверу Internet закончится неудачей, так как для установления соединения требуется время, превышающее время тайм-аута большинства служб Internet. Вторая попытка будет успешной.

Если вы хотите, чтобы программа diald автоматически запускалась при загрузке системы, вам надо создать сценарий запуска SysV или включить дополнительные записи в локальный сценарий (/etc/rc.d/rc.local или /etc/rc.d/boot.local). Программа diald будет нормально работать и в том случае, если ваш компьютер выполняет функции NAT-маршрутизатора.

 

Для того чтобы вести предметный разговор о стеках протоколов и обсуждать их достоинства и недостатки, необходимо иметь хотя бы общее представление о том, как организован стек, какие функции выполняют протоколы, входящие в его состав, и как они реализованы. Большинство стеков протоколов действует по единому принципу и отличается лишь в деталях. Однако именно эти детали и являются основным аргументом в пользу выбора тех или иных протоколов.

 

Модель сетевого взаимодействия OSI

В основу работы стека протоколов положена модель OSI (Open System Interconnection — взаимодействие открытых систем). Данная модель предусматривает семь уровней сетевого взаимодействия, на каждом из которых решаются конкретные задачи. Источником данных, предназначенных для передачи, является программа, находящаяся на верхнем уровне модели OSI, который называется прикладным уровнем. Программа передает данные нижележащему представительскому уровню, и далее информация перемещается вниз по стеку. На каждом уровне выполняется определенная обработка данных. Нижним уровнем OSI является физический уровень, на котором решаются вопросы передачи электрических сигналов, использования кабелей, концентраторов, коммутаторов и т.д. Именно на физическом уровне осуществляется реальная передача данных от передающего компьютера к принимающему. (Если оба компьютера принадлежат одному сегменту сети, данные передаются достаточно просто. В противном случае передача осуществляется поэтапно, и на каждом этапе выполняется дополнительная обработка информации.) На принимающем компьютере данные перемещаются вверх по стеку протоколов и в конечном итоге достигают программы на прикладном уровне. Получив информацию, программа может передать ответ. Данные, составляющие ответ, также движутся вниз по стеку, передаются через сетевые соединения, а затем на компьютере, которому они предназначены, перемещаются вверх по стеку протоколов. На рис. 3.1. проиллюстрирован описанный выше процесс.

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

На заметку

Несмотря на то что OSI является универсальной моделью, описывающей сетевое взаимодействие, в реальных стеках протоколов редко поддерживаются все семь уровней. Наиболее часто используемые стеки — TCP/IP, AppleTalk и NetBEUI — могут быть описаны в терминах OSI. При этом стек TCP/IP насчитывает лишь четыре уровня, однако общие принципы обработки передаваемых данных остаются неизменными.

Каждый уровень модели OSI взаимодействует только с двумя уровнями; один из них расположен непосредственно над ним, а другой — под ним. (Исключениями являются прикладной и физический уровни. Прикладная программа взаимодействует непосредственно с пользователем, а на физическом уровне решаются вопросы соединения двух компьютеров.) Для программных средств, реализующих различные уровни стека протоколов на конкретном компьютере, должен быть четко определен интерфейс межуровневого взаимодействия. Компоненты, соответствующие определенным уровням, должны допускать замену. Так, например, на прикладном уровне могут работать Web-броузеры и Web-серверы. Если вы замените один броузер или сервер другим, работа всего стека протоколов не нарушится. (В некоторых броузерах и серверах могут отсутствовать определенные возможности, например, броузер может не поддерживать средства SSL, однако на самом деле такие вопросы скорее относятся к интеграции сетевых средств.) Аналогично вы можете на физическом уровне заменять сетевые кабели, концентраторы и даже сетевые карты с драйверами. При этом средства поддержки более высоких уровней не нуждаются в модификации.

Для двух компьютеров, взаимодействующих по сети, действия на некотором уровне одного компьютера строго согласованы с действиями на этом же уровне другого компьютера. В некотором смысле можно утверждать, что результаты, получившиеся при обработке данных на определенном уровне стека протоколов передающего компьютера, отменяются на этом же уровне принимающего компьютера. Главная цель работы всего стека протоколов — обеспечение взаимодействия программ прикладного уровня, поэтому каждый уровень на принимающем узле сети должен получать от нижележащего уровня в точности те же данные, которые предоставил соответствующий уровень на передающем узле. Взаимодействие компьютеров, использующих стеки протоколов, можно представить себе так, как будто некоторый уровень обменивается данными не с нижележащим и вышестоящим уровнями, а непосредственно с соответствующим уровнем другого компьютера. Очевидно, что стеки протоколов на разных компьютерах должны отвечать одному стандарту, даже если эти компьютеры работают под управлением различных операционных систем. Например, на разных уровнях стека TCP/IP, реализованного для Linux, Windows, и BeOS, выполняются одинаковые действия, несмотря на то, что коды соответствующих программных средств различаются.

 

Инкапсуляция и извлечение данных

Стек протоколов хорошо иллюстрирует перемещение данных между программными компонентами, поддерживающими сетевое взаимодействие, однако он не дает ответа на вопрос, какие же изменения претерпевает информация на этом пути. На различных уровнях стека протоколов выполняются инкапсуляция и извлечение данных. При инкапсуляции данные разбиваются на фрагменты, и к каждому фрагменту добавляется управляющая информация (после добавления управляющей информации фрагменты данных, в зависимости от уровня протокола, становятся пакетами или кадрами). Кроме того, информация, предназначенная для передачи, может быть модифицирована, но подобная обработка выполняется крайне редко. При извлечении данных выполняются действия, противоположные инкапсуляции.

Рассмотрим в качестве примера передачу содержимого файла с помощью протокола FTP (File Transfer Protocol — протокол передачи файлов) в сети Ethernet. При этом используется стек протоколов TCP/IP. Размер файла может превышать максимальный размер пакета данных, допустимый в TCP/IP или Ethernet. В этом случае содержимое файла должно быть разбито на несколько фрагментов. На различных уровнях стека протоколов к каждому из этих фрагментов добавляется заголовок и, возможно, суффикс (служебная информация, следующая за передаваемыми данными). Заголовок и суффикс содержат информацию, необходимую для того, чтобы система могла передавать и обрабатывать остальную часть пакета. Результат действий по инкапсуляции данных показан на рис. 3.2. На самом деле ситуация может быть более сложной. На некотором уровне стека протоколов пакет может быть разбит на несколько фрагментов меньшего размера, так, например, драйверы Ethernet могут разбить IP-пакет на два Ethernet-кадра. Подобные действия могут выполнять и маршрутизаторы. При этом заголовки IP, TCP и FTP, показанные на рис. 3.2, остаются в одном из кадров и не дублируются в другом кадре. Однако если на некотором уровне стека протоколов пакет разбивается на кадры, то на том же уровне стека на принимающем узле эти кадры обязательно объединяются в исходный пакет. Точно так же дело обстоит в том случае, если разбиение пакета выполнит маршрутизатор.

В зависимости от используемого стека протоколов и даже от состава стека, структура пакета может отличаться от представленной на рис. 3.2. Например, если для обмена данными используется Web-броузер, то вместо заголовка FTP, показанного на рис. 3.2, в составе пакета будет присутствовать заголовок HTTP. Если же для подключения компьютера к сети будут использованы сетевые карты и драйверы, отличные от Ethernet, то заголовок и суффикс Ethernet будут заменены на заголовок и суффикс, соответствующие другой сетевой технологии. Заметьте, что при передаче пакета из одной локальной сети в другую маршрутизатор реально выполняет подобную замену, т.е. удаляет существующие заголовок и суффикс и включает вместо них заголовок и суффикс другой сети. Такая процедура выполняется несколько раз за время перемещения пакета по Internet, но содержащиеся в составе пакета, доставляются в неизменном виде.

Рис. 3.2. При перемещении вниз по стеку протоколов исходные данные разбиваются на фрагменты. К каждому фрагменту добавляется служебная информация, обеспечивающая передачу пакета по сети и восстановление на принимающем узле исходных данных

Заголовки и суффиксы содержат информацию, необходимую для доставки пакта по назначению, например, IP-адреса отправителя и получателя, номера портов, связанные с программами на прикладном уровне, расположение данных, содержащихся в пакете, в исходной битовой последовательности, и т.д. Маршрутизаторы используют эту информацию для определения маршрута пакета, а на принимающем узле эти сведения позволяют передать пакет той программе, для которой он предназначен. Адрес и порт отправителя используются при передаче ответа.

 

Роль стека протоколов TCP/IP в развитии сетей

В настоящее время TCP/IP является самым популярным стеком протоколов. В состав этого стека входят наиболее часто используемые протоколы, которые обсуждаются в данной книге. В большинстве приложений не реализована поддержка нескольких стеков протоколов, поэтому чаще всего приложение может работать с одним конкретным стеком. Одна из причин популярности стека протоколов TCP/IP — его гибкость. Протоколы TCP/IP являются маршрутизируемыми протоколами, т.е. пакеты TCP/IP могут передаваться из одной локальной сети в другую. Для передачи пакетов между различными сетями не нужна единая карта Internet; при маршрутизации используется распределенная информация о структуре сети, хранящаяся на различных маршрутизаторах. Число допустимых адресов в сетях TCP/IP достаточно велико (в IPv4 адрес представляется 32 битами, а в IPv6 используются 128-битовые адреса; подробно IP-адреса рассматривались в главе 2), кроме того, в этих сетях поддерживается иерархическая структура имен. Эти положительные качества стали причиной того, что протоколы TCP/IP были выбраны в качестве основы для создания глобальной сети Internet.

Впервые протоколы TCP/IP были использованы в UNIX; система Linux "унаследовала" их. Как в Linux, так и в UNIX средства TCP/IP используются для обеспечения работы различных компонентов системы. Сеть, в состав которой входят только компьютеры, работающие под управлением UNIX или Linux, может быть создана на основании TCP/IP, без использования других стеков протоколов.

В состав семейства TCP/IP входят HTTP, FTP, SMTP (Simple Network Mail Protocol — простой протокол передачи почтовых сообщений), NFS (Network File System — сетевая файловая система), Telnet, SSH (Secure Shell — защищенная оболочка), NNTP (Network News Transfer Protocol — протокол передачи сетевых новостей), X Window и многие другие протоколы. Широкое использование TCP/IP привело к тому, что в инструментах, изначально ориентированных на работу с другими стеками протоколов, была реализована поддержка TCP/IP. Например, несмотря на то, что в системе Windows используется стек протоколов NetBEUI (NetBIOS Extended User Interface — расширенный пользовательский интерфейс NetBIOS), средства поддержки протоколов SMB (Server Message Block — блок сообщений сервера) / CIFS (Common Internet Filesystem — общая межсетевая файловая система) могут взаимодействовать с TCP/IP через NetBIOS (Network Basic Input/Output System — базовая сетевая система ввода-вывода). Начиная с Windows 95 все версии Windows поддерживают TCP/IP. Аналогично, протоколы Apple, предназначенные для разделения файлов, могут работать не только с AppleTalk, но и с TCP/IP.

Несмотря на свои достоинства и популярность, стек TCP/IP не позволяет решить все задачи, возникающие при создании сетей. Так, например, в некоторых сетях могут присутствовать компьютеры, не поддерживающие TCP/IP. В частности, старые компьютеры Macintosh обеспечивают обмен файлами только средствами AppleTalk, а некоторые машины под управлением DOS или Windows могут быть сконфигурированы лишь для работы с IPX или NetBEUI. Поэтому поддержка альтернативных средств протоколов является положительным качеством системы Linux.

 

Стек протоколов создавался компанией AppleTalk параллельно с разработкой сетевого оборудования LocalTalk. Он нашел применение в компьютерах Macintosh, выпущенных в начале 1980-х. (Первоначально как аппаратные, так и программные средства назывались AppleTalk; в настоящее время это название используется лишь для обозначения программных компонентов.) С ростом популярности Ethernet Apple доработала AppleTalk для работы с аппаратным обеспечением Ethernet; этот вариант программ иногда называют EtherTalk. В системе Linux поддерживается стек протоколов AppleTalk и обеспечивается его работа как посредством аппаратуры LocalTalk, так и через Ethernet.

На заметку

Как ни странно, версии Linux, ориентированные на компьютеры Macintosh, не поддерживают аппаратные средства LocalTalk, а допускают лишь работу AppleTalk через Ethernet. Поэтому для включения компьютера Macintosh под управлением Linux в сеть AppleTalk необходимо, чтобы на нем присутствовал Ethernet-адаптер.

 

Особенности AppleTalk

Подобно TCP/IP, AppleTalk использует 32-разрядные адреса. Подобно IP-адресу, адрес AppleTalk состоит из двух компонентов: адреса сети и адреса компьютера. В отличие от IP, длина каждого из компонентов фиксирована: 16 из 32 битов выделены для представления адреса сети, а остальные 16 битов — для идентификации компьютера. В сетях AppleTalk поддерживается процедура переговоров, предпринимаемых для получения компьютером сетевого адреса. Благодаря наличию такой процедуры администратор избавлен от необходимости явно указывать адреса. (Если вы захотите, можете задать адрес явно или запросить его из определенного диапазона, но обычно в этом нет надобности.)

Кроме адресов для идентификации компьютеров в AppleTalk-сетях существует система имен, предназначенная для того, чтобы упростить работу пользователей. Каждому компьютеру присваивается имя, кроме того, для этого компьютера определяется принадлежность к локальной группе машин, которая называется зоной. Полное имя состоит из имени компьютера и имени зоны. В небольших сетях информация о зоне может не использоваться, в этом случае компьютеры идентифицируются только посредством имени. Netatalk (основной пакет, предназначенный для поддержки AppleTalk в Linux) по умолчанию генерирует AppleTalk-имена на базе доменных имен TCP/IP. Так, например, если компьютеру соответствует доменное имя larch.threeroomco.com, Netatalk назначит ему имя larch. Информация о домене при этом будет утеряна. (Если сеть разбита на зоны, имя зоны также генерируется автоматически, но оно не имеет никакого отношения к имени домена TCP/IP.) Двухкомпонентные имена существенно ограничивают размеры AppleTalk-сетей, в частности, создать сеть, насчитывающую больше нескольких тысяч компьютеров, затруднительно.

Основное назначение AppleTalk — обеспечение совместного использования файлов и принтеров. Многие сетевые принтеры могут непосредственно взаимодействовать посредством протокола AppleTalk, а средства разделения файлов поддерживаются в MacOS, Windows NT и 2000, Linux, BeOS и других операционных системах. Для решения других задач AppleTalk используется лишь в сетях, состоящих из компьютеров, которые работают под управлением MacOS. В сетях, компоненты которых используют иные операционные системы, целесообразнее применять другие стеки протоколов. Если в состав сети входят различные машины, на компьютерах устанавливают систему MacOS X, обеспечивающую работу с NFS. Пакет Netatalk (http://nettalk.sourceforge.net), используемый для поддержки AppleTalk в Linux, будет рассматриваться в следующем разделе.

Совет

При маршрутизации пакетов AppleTalk с помощью обычных маршрутизаторов возникают серьезные трудности. Чтобы исключить возможность взлома извне, можно запретить поддержку TCP/IP на сервере Netatalk (подобные действия имеют смысл только в том случае, если вы абсолютно уверены, что никто из пользователей локальной сети не предпримет попытку взлома, пользуясь недостатками в системе защиты Netatalk). Очевидно, что эта мера обеспечения безопасности не является единственно возможной. Средства защиты сетей TCP/IP будут подробно обсуждаться в части IV.

Программы для поддержки AppleTalk в системе Linux

Пакет Netatalk, поставляемый в составе большинства дистрибутивных пакетов Linux, предназначен для поддержки сетевого взаимодействия посредством AppleTalk. В состав этого пакета входят три основных компонента.

• Файловый сервер AppleTalk. Программа afpd обеспечивает функционирование компьютера под управлением Linux в качестве файлового сервера. В роли клиентов в данном случае могут выступать системы Macintosh. Файловый сервер поддерживает как AppleTalk, так и TCP/IP, таким образом, Linux может обслуживать даже старые компьютеры Macintosh, работающие с совместимыми аппаратными средствами. (Если соответствующие сетевые аппаратные средства не поддерживаются, можно использовать преобразователи LocalTalk — Ethernet.) Настройка сервера осуществляется с помощью файла afpd.conf, который обычно располагается в каталоге /etc/atalk. Для контроля разделяемых каталогов используется файл AppleVolumes.default, а файл AppleVolumes.system отображает расширения файлов в типы Macintosh, предназначенные для сохранения в файловой системе MacOS.

• Сервер печати AppleTalk. Программа papd реализует на компьютере Linux сервер печати для систем Macintosh. В сочетании с Ghostscript (компонентом стандартной очереди печати Linux) papd позволяет использовать недорогой струйный принтер как полнофункциональное PostScript-устройство и решать с его помощью достаточно сложные задачи, связанные с отображением документов. Средства, реализующие сервер печати, могут работать только с AppleTalk и не поддерживают TCP/IP.

• Клиент печати AppleTalk. Программа pap позволяет компьютерам под управлением Linux передавать задачи печати на принтеры, поддерживающие AppleTalk, или на серверы печати. Эта возможность становится полезной тогда, когда система Linux работает в сети, состоящей в основном из компьютеров Macintosh, в которой используются принтеры, не поддерживающие другие протоколы. Вы даже можете обращаться с помощью данного инструмента к другим компьютерам под управлением Linux и передавать им задания на печать. Однако подобные действия часто бывают не оправданы. Как вы узнаете, прочитав главу 9, собственные средства печати Linux достаточно просты в настройке. Программа pap не использует конфигурационный файл; принтер, на который следует передать задание на печать, указывается с помощью опции -p. Так, например, команда pap -p Laser2 sample.ps означает, что файл sample.ps должен быть выведен на принтер Laser2.

Работа первых двух из описанных выше инструментов базируется на использовании программы atalkd, которая представляет компьютер в сети AppleTalk (в частности, она поддерживает AppleTalk-имя и адрес узла). Настройка этой программы производится с помощью конфигурационного файла atalkd.conf, который обычно располагается в каталоге /etc/atalk.

На заметку

Netatalk не содержит клиентских программ, предназначенных для разделения файлов, поэтому из системы Linux нельзя обращаться к файлам AppleTalk. Такую возможность предоставляет версия 1.03b-alpha пакета afpfs , но этот инструмент выпущен очень давно и работает ненадежно. Если вам необходимо, чтобы система Linux работала с файлами, расположенными на компьютерах Macintosh, можете воспользоваться для этого средствами NFS или SMB/CIFS, например установить в системе MacOS NFS-сервер или DAVE ( http://www.thursby.com ).

Как правило, установленные средства поддержки AppleTalk работают корректно, но по умолчанию они настроены так, что разделяемым становится только рабочий каталог пользователя. Для того чтобы изменить конфигурацию, надо внести изменения в файл AppleVolumes.default. Например, приведенные ниже две строки из этого файла сообщают системе о том что экспортироваться должен как рабочий каталог пользователя (запись, состоящая из символа ~), так и каталог /mnt.

~

/mnt "Mount Points" options=noadouble

Первая строка не содержит опций. Во второй строке указано имя, которое должно предоставляться клиенту Macintosh вместо /mnt, а также ключевое слово options, посредством которого задаются специальные опции. В данном случае указана единственная опция noadouble, которая означает, что файлы AppleDouble не должны создаваться, за исключением тех случаев, когда они абсолютно необходимы. (AppleDouble — специальные файлы, которые находятся в каталоге .AppleDouble и содержат данные, специфические для MacOS.)

Если Netatalk поставляется в составе дистрибутивного пакета, его компоненты, скорее всего, будут автоматически запускаться при загрузке операционной системы. Если запуск Netatalk не предусмотрен, вы можете воспользоваться SysV или локальным сценарием запуска. (Подробно процедура запуска серверов описана в главе 4.) В первую очередь следует запустить atalkd, а затем afpd и papd. Одна из особенностей Netatalk состоит в том, что для запуска atalkd требуется достаточно длительное время; при использовании старых аппаратных средств оно может превышать одну минуту. Чтобы устранить задержку, надо включить в сценарий запуска после вызова программы символ &.

 

IPX (Internetwork Packet Exchange — межсетевой обмен пакетами) был разработан специалистами Novell как низкоуровневый транспортный протокол. При создании протокола разработчики основывались на ранних работах, выполненных компанией Xerox. Чаще всего IPX используется совместно с протоколом SPX (Sequences Packet Exchange — упорядоченный обмен пакетами). IPX и SPX составляют основы стека протоколов, возможности и популярность которого сопоставимы со стеками AppleTalk и NetBEUI. Традиционно протоколы IPX/SPX используются в продуктах NetWare, кроме того, в DOS, Windows и других операционных системах применяются программные пакеты, созданные на базе IPX/SPX. Одно из самых распространенных применений IPX/SPX — поддержка протокола NCP (NetWare Core Protocol — базовый протокол NetWare), используемого для разделения файлов и принтеров. Протоколы IPX/SPX поддерживаются в системе Linux; для этого используются как средства ядра (настройка ядра обсуждалась в главе 1), так и клиентские и серверные пакеты.

 

Возможности IPX/SPX

Подобно TCP/IP и AppleTalk, в IPX/SPX используются 32-разрядные адреса, которые обычно представляются в шестнадцатеричном виде, например 0x23a91002. Однако каждый адрес ставится в соответствие не одному компьютеру, а сегменту сети, который либо соединяется с другими сегментами с помощью маршрутизаторов, либо полностью изолирован от внешнего мира. В описании сети также указывается тип кадра, передаваемого на нижнем уровне; в сети IPX/SPX могут использоваться только кадры одного типа. Для идентификации отдельных компьютеров применяются аппаратные адреса узлов сети, на базе которой создается сеть IPX/SPX, например, если сеть IPX/SPX создана на основе Ethernet, то компьютеры, подключенные к ней, идентифицируются с помощью 48-разрядных адресов.

Как легко догадаться по названию и применяемой схеме адресации, протоколы разработаны для организации межсетевого обмена. Такой обмен обеспечивают IPX-маршрутизаторы, которые функционируют подобно маршрутизаторам TCP/IP. (При необходимости одна система может маршрутизировать пакеты IP и IPX. В изолированной сети маршрутизатор не нужен, но программы поддержки IPX/SPX включают соответствующие средства.

Серверы IPX/SPX используют протокол SAP (Service Advertisement Protocol — протокол объявления служб). Посредством этого протокола в сети периодически объявляются имя сервера и услуги, которые он предоставляет. Эти сообщения принимаются локальными компьютерами, а IPX-маршрутизаторы передают их в другие сегменты сети. Таким образом клиенты постоянно имеют информацию о доступных серверах, но в то же время при увеличении размеров сети этот подход приводит к возрастанию сетевого трафика, так как по сети постоянно передаются широковещательные SAP-сообщения.

 

Программы поддержки IPX/SPX в системе Linux

Как и большинство Linux-программ, средства поддержки IPX/SPX в основном распространяются в исходных кодах. (Caldera лицензировала NetWare, и специалисты компании реализовали в Linux поддержку взаимодействия с этой системой, однако сопровождение данного порта прекращено. Версия для трех пользователей доступна по адресу ftp://ftp.calderasystems.com/pub/old-products/netware/, но она может работать только с ядром 2.0.35.) Средства поддержки IPX/SPX для Linux перечислены ниже.

• Поддержка NCPFS ядром системы. В состав ядра Linux входят средства поддержки файловой системы NCP. Соответствующие опции находятся в подменю Network File Systems меню File Systems. Эти средства позволяют монтировать в системе Linux разделяемые каталоги NetWare. Для монтирования используется программа ncpmount, которая обычно входит в состав пакета ncpfs.

• LinWare. Этот пакет обеспечивает ограниченную поддержку сервера NCP. На момент написания данной книги последней была версия 0.95 beta, ориентированная на работу с ядром 1.3.x, другими словами, пакет не обновлялся с 1996 года. Однако в будущем ситуация может измениться. В настоящее время данный пакет хранится под именем lwared по адресу ftp://sunsite.unc.edu/pub/Linux/system/network/daemons/.

• Mars_nwe. Этот пакет, реализующий NetWare-сервер в системе Linux, в настоящее время доступен по адресу http://www.compu-art.de/mars_nwe/. Информация о пакете в основном представлена на немецком языке. Английская документация ограничивается документом Mars_mwe HOWTO, который можно получить, обратившись по адресу http://www.redhat.com/support/docs/tips/Netware/netware.html. Mars_nwe поддерживает как файловый сервер, так и сервер печати. Настройка пакета осуществляется посредством конфигурационного файла /etc/nwserv.conf или /etc/nwserv/nwserv.conf. Если Mars_nwe не запускается при загрузке системы, для его запуска можно использовать команду nwserv.

Все перечисленные выше пакеты требуют, чтобы средства поддержки IPX были скомпилированы в составе ядра (о включении компонентов ядра рассказывалось в главе 1). В ряде систем используется специальный пакет ipxutils, в состав которого входят утилиты, предназначенные для активизации стека протоколов IPX/SPX и управления им. (В некоторых версиях эти утилиты содержатся в пакете ncpfs.)

Если вы хотите, чтобы система Linux выступала в роли сервера для клиентов NetWare, надо выполнить несложную настройку Mars_nwe. Более того, конфигурация, установленная по умолчанию, обычно обеспечивает нормальную работу данного пакета. Конфигурационные файлы снабжены подробными комментариями; прочитав их, можно получить полное представление о процессе настройки пакета. Особое внимание надо уделить следующим деталям.

• В разделе 1 конфигурационного файла определяются разделяемые тома. В терминах Linux эти тома соответствуют каталогам. В зависимости от поставки, разделяемые тома могут быть либо определены, либо нет.

• В разделе 7 содержатся опции, управляющие шифрованием пароля. Если в вашей сети отсутствует bindery-сервер NetWare, поддерживающий аутентификацию пользователей, вам необходимо задать передачу пароля в незашифрованном виде.

• В разделе 13 определены пользователи, которым разрешен доступ к серверу. В этот раздел вам придется включить имена пользователей и пароли, дублируя соответствующие настройки Linux. Пароли хранятся в незашифрованном виде, что создает угрозу безопасности системы. Если в сети присутствует bindery-сервер, после первого запуска Mars_nwe вы можете удалить эти записи, так что риск становится минимальным. Вместо того чтобы задавать имена пользователей и пароли, соответствующие отдельным учетным записям, вы можете указать в разделе 15 автоматическое выполнение этих действий. Недостаток такого подхода состоит в том, что для всех учетных записей будет установлен один и тот же пароль.

Пакет Mars_nwe содержит средства, позволяющие автоматически включать IPX-поддержку для сетевого интерфейса. Однако эти средства не действуют при работе с клиентами NetWare. Перед использованием команды ncpmount вам надо разрешить автоконфигурацию, вызвав команду ipx_configure. Затем вы можете монтировать том NetWare. Команды, реализующие описанную процедуру, выглядят следующим образом:

# ipx_configure --auto_interface=on --auto_primary=on

# ncpmount -S NW_SERV -U anne -P p4rtu3a /mnt/nwmount

При выполнении этих команд разрешается автоматическое определение номера локальной сети, и том на NW_SERV, связанный с пользователем anne, монтируется в точке /mnt/nwmount, при этом используется пароль p4rtu3a.

 

NetBEUI во многом напоминает AppleTalk и IPX, однако средства NetBEUI в основном используются IBM и Microsoft для организации сетевого взаимодействия в системах DOS, Windows и OS/2. В системе Linux (по крайней мере в версиях ядра 2.4.x) стек NetBEUI не поддерживается. Тем не менее возможности NetBEUI могут быть реализованы средствами NetBIOS на базе TCP/IP, которые присутствуют в Linux (такую конфигурацию NetBIOS часто называют NBT). Кроме того, поддержка стека NetBEUI обеспечивается продуктами независимых производителей, но на сегодняшний день такие продукты находят лишь ограниченное применение.

 

Возможности NetBEUI

Подобно AppleTalk и IPX, стек NetBEUI был разработан для обеспечения взаимодействия в небольших сетях. Сеть под управлением NetBEUI может насчитывать не больше 256 компьютеров. В NetBEUI используются имена, подобные доменным именам TCP/IP, но, в отличие от TCP/IP, AppleTalk и IPX, числовая адресация не применяется. В NetBEUI компьютеры идентифицируются лишь с помощью имен. Имена NetBEUI состоят из двух компонентов: имени компьютера и имени группы. В зависимости от наличия централизованного сервера, предназначенного для управления регистрацией пользователя, группа компьютеров называется рабочей группой либо доменом. С момента включения компьютер, настроенный для взаимодействия посредством NetBEUI, передает широковещательные сообщения, свидетельствующие о его присутствии.

Средства NetBEUI могут работать практически в любой сетевой среде, но чаще всего сети, использующие этот стек, создаются на базе Ethernet. Подобно AppleTalk и IPX, NetBEUI может использоваться вместе с TCP/IP и другими стеками протоколов.

Средства NetBEUI очень часто применяются с протоколами SMB/CIFS, обеспечивающими разделение файлов и принтеров. По степени популярности их можно сравнить с NFS/lpd для Linux и UNIX или NCR SMB/CIFS могут работать на базе TCP/IP; такая конфигурация используется чрезвычайно часто, даже в сетях, состоящих исключительно из компьютеров под управлением Windows. Маршрутизация сообщений NetBEUI затруднена, и это обеспечивает дополнительную степень защиты сетей. В настоящее время неизвестны средства, с помощью которых злоумышленник, работающий на удаленном компьютере, мог бы незаконно получить доступ к серверу NetBEUI.

 

Средства поддержки NetBEUI для Linux

Компьютеры под управлением Linux редко участвуют в NetBEUI-взаимодействии, так как в стандартном ядре отсутствует поддержка этого стека. В 2000 г. силами Procom Technologies (http://www.procom.com) были реализованы средства поддержки NetBEUI для Linux, а также дополнения к Samba (подробно об этом рассказывается в главе 7), обеспечивающие работу Samba посредством NetBEUI. Эти дополнения не нашли широкого применения; они даже не были размещены на Web-узле Procom. Для того чтобы получить необходимые программные средства, надо обратиться в отдел технической поддержки компании. Совместно с ядрами, отличными от версий 2.0.x, средства поддержки NetBEUI могут работать некорректно (лично мне не удалось найти программы, совместимые с ядром 2.2.18). Стек NetBEUI ориентирован на работу с версиями Samba, предшествующими 2.0.7, однако были сообщения о том, что впоследствии будет реализована поддержка Samba 3.0. Для работы с NetBEUI необходимо перекомпилировать как ядро Linux, так и Samba. Таким образом, для того, чтобы устанавливать средства поддержки NetBEUI в Linux, надо иметь достаточно веские основания, например, делать это имеет смысл тогда, когда в сети запрещена поддержка стека протоколов TCP/IP. Для работы с NetBEUI вам придется использовать ядро Linux 2.0.x и Samba 2.0.6 либо более раннюю версию этого продукта.

Кроме дополнений к ядру Linux и Samba средства поддержки стека NetBEUI содержат большое количество специальных утилит, предназначенных для настройки стека и выполнения различных действий в сети NetBEUI. Настройка системы обычно не вызывает затруднений; в большинстве случаев для управления поведением NetBEUI можно использовать опции Samba. Среди утилит следует выделить netb; с ее помощью запускаются средства поддержки стека NetBIOS.

 

Использование программ поддержки NetBEUI

Пакет, предназначенный для поддержки стека NetBEUI, содержит файл README, в котором полностью описан процесс инсталляции. Установка пакета может быть выполнена двумя способами. Следуя одному из них, надо отредактировать файл Makefile, указав в нем ссылки на каталоги, содержащие коды ядра Linux и исходные тексты Samba, а также установив некоторые опции, специфические для конкретной системы. Затем необходимо скомпилировать ядро Linux и коды Samba, установить новое ядро и перезагрузить систему. Второй способ инсталляции также требует редактирования Makefile, но при этом надо предоставить системе детальные инструкции о выполнении каждого шага установки. Второй способ предпочтительнее первого, особенно если при установке возникают затруднения. В этом случае вы можете локализовать проблему и устранить ее.

Каким бы способом вы ни воспользовались, вам потребуются исходные коды как ядра Linux, так и пакета Samba. Найти их вы сможете, обратившись по адресам http://www.kernel.org и http://www.samba.org, а также на других узлах, содержащих архивы программ, например ftp://sunsite.unc.edu. Компиляция каждого пакета займет несколько минут. Если же при этом возникнут проблемы, то для установки средств поддержки NetBEUI вам потребуется значительно больше времени.

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

• netb. Передавая этой утилите параметр start, вы можете запустить средства поддержки NetBEUI. Чтобы запретить поддержку NetBEUI, надо выполнить команду netb stop. Использовать NetBEUI в Linux можно лишь после вызова утилиты netb.

• nbview. Эта утилита сообщает сведения о текущем состоянии локального стека NetBEUI. Она считает файл /proc/sys/netbeui, в котором содержатся соответствующие данные, отформатирует их и отобразит в виде, удобном для восприятия.

• nbstatus. Утилита nbstatus предоставляет информацию о конкретной машине в рабочей группе. Например, по команде nbstatus SERVER будут выведены данные о компьютере с именем SERVER.

• nbadmin. Данная утилита позволяет связывать NetBEUI с конкретным сетевым интерфейсом, разрывать связь NetBEUI с интерфейсом или прекращать указанный сеанс NetBEUI-взаимодействия. Для этого используются параметры bind, unbind и drop. Например, соответствующая команда может иметь вид nbadmin bind eth0 или nbadmin drop 102. (Получить номер сеанса можно с помощью утилиты nbview.)

В большинстве случаев необходимо задавать только команду netb start, а затем запускать Samba. Средства NetBEUI добавляют новые параметры к nmbd (поддержка имен NetBIOS), smbd (программа поддержки SMB) и smbclient (клиент Samba, работающий в текстовом режиме). Один из параметров имеет вид -Z и указывает, следует ли использовать TCP/IP или NetBEUI. Так, например, чтобы запустить smbd для поддержки NetBEUI, надо ввести команду smbd -Z NETBEUI. Кроме того, новый параметр -S ИМЯ программы smbd позволяет задать NetBEUI-имя системы.

Таким образом, вы можете превратить узел сети, работающий под управлением Linux, в сервер NetBEUI SMB/CIFS с именем NAME . Для этого надо скомпилировать ядро и коды Samba, включив в них средства NetBEUI, разработанные Procom, перезагрузить систему (возможно, для этого придется завершить работу Samba) и выполнить следующие команды:

# netb start

# nmbd -Z NETBEUI

# smbd -Z NETBEUI -S имя

Вы можете поместить приведенные выше команды в сценарий запуска системы или модифицировать соответствующим образом сценарий запуска Samba. Остальные средства Samba функционируют так, как описано в главе 7. Установив средства поддержки NetBEUI, вы добиваетесь следующих результатов. Во-первых, обеспечивается работа NetBEUI-клиентов, не поддерживающих TCP/IP, а во-вторых, снижается вероятность незаконного обращения к серверу, поскольку в нормальных условиях данные NetBEUI не маршрутизируются и не могут быть переданы по Internet. Описанные выше программы дублируют средства, обеспечивающие работу NetBIOS на базе TCP/IP. Эти средства присутствуют последних версиях ядра Linux и Samba и для их использования не требуется устанавливать дополнительные модули и перекомпилировать программы.

 

Многие технические решения, которые используются в системе System V UNIX, разработанной AT&T, стали стандартом для современных версий UNIX и Linux. Одним из них является способ запуска системных служб, в том числе серверов. Согласно схеме загрузки SysV, каждой службе должен соответствовать специальный сценарий запуска, поддерживающий параметры start и stop. В зависимости от полученного параметра, сценарий запускает программу поддержки данной службы или завершает ее работу. Многие сценарии запуска поддерживают дополнительные параметры, например, restart, используемый при изменении конфигурации программы. При получении параметра restart сценарий завершает работу сервера, а затем снова запускает его.

На заметку

Сценарии SysV используются не только для запуска сетевых серверов. В данной книге для обозначения программ, постоянно выполняющихся в операционной системе и предоставляющих некоторые услуги, но не обязательно доступных по сети, используется термин служба , или демон . Серверами называются программы, обслуживающие запросы по сети. Большинство служб, которые обсуждаются в этой книге, являются серверами. Многие специалисты не придерживаются данной терминологии, например, называют службами те программы, для обозначения которых здесь используется термин сервер.

Схема запуска SysV непосредственно связана с понятием уровня выполнения (runlevel). Каждому уровню выполнения соответствует набор сценариев запуска, который определяет службы, выполняющиеся в системе. (Посредством сценариев SysV запускаются не только серверы, но и другие службы, например, средства протоколирования, поддержки файловой системы и прочие программы.) Таким образом, настройка системы для запуска серверов с помощью сценариев SysV по сути сводится к выбору конфигурации уровней выполнения. Для решения данной задачи надо создать ссылки на требуемые сценарии и поместить их в каталог, соответствующий требуемому уровню выполнения.

 

Расположение сценариев запуска и соглашения по их именованию

Несмотря на то что основные принципы использования сценариев запуска SysV соблюдаются во всех системах, особенности такого использования могут различаться в зависимости от конкретного дистрибутивного пакета. В разных системах сценарии запуска размещаются в различных каталогах, имена сценариев могут различаться, но эти различия, как правило, не существенны. В табл. 4.1 описаны каталоги, используемые разными системами при работе со сценариями запуска SysV. Обратите внимание на то, что в табл. 4.1 указано размещение реальных сценариев, ссылок на эти сценарии, соответствующих определенным уровням выполнения, а также расположение локальных сценариев запуска (подробно локальные сценарии будут рассматриваться далее в данной главе). В именах ссылок на сценарии символом ? обозначается число, соответствующее уровню выполнения (от 0 до 6).

Таблица 4.1. Сценарии запуска для основных дистрибутивных пакетов Linux

На заметку

Уровень выполнения — это число от 0 до 6, которому соответствует конкретный набор действующих служб. Уровни выполнения будут более подробно описаны в одном из последующих разделов, сейчас же вам достаточно знать, что при загрузке компьютер переходит на некоторый уровень выполнения, на котором выполняется определенный набор сценариев запуска. При необходимости вы можете изменить уровень выполнения после загрузки компьютера.

На заметку

Далее в этой главе будут упоминаться каталоги сценариев SysV и каталоги ссылок. Если вам потребуется изменить некоторые файлы, вы должны знать, к каким каталогам необходимо обращаться.

В некоторых системах сценарии запуска используются абсолютно одинаково. К этим системам относятся Red Hat, Mandrake, TurboLinux; несколько отличается от них Caldera. В них сценарии запуска расположены в каталоге /etc/rc.d/init.d, а ссылки на сценарии — в каталоге /etc/rc.d/rc?.d. В других системах, а особенно в Slackware, сценарии расположены по-иному. Вместо того чтобы размещать ссылки на сценарии в каталогах, имена которых соответствуют уровням выполнения, Slackware использует для каждого уровня выполнения один сценарий. Так, например, сценарий /etc/rc.d/rc.4 управляет запуском служб на уровне выполнения 4.

В большинстве дистрибутивных пакетов Linux (за исключением Slackware) действуют строгие правила по именованию содержимого каталога ссылок SysV. Имя файла ссылки имеет вид C##имя , где С обозначает символ "S" или "K", ## — это число, состоящее из двух цифр, а имя обычно совпадает с именем соответствующего файла в каталоге сценариев. Например, сценариям network и nfs соответствуют файлы-ссылки S10network и K20nfs. Как нетрудно догадаться, принцип именования несет на себе определенную смысловую нагрузку. Часть имени ссылки, следующая за C## , дает представление о действиях, выполняемых сценарием. Первый символ ("S" или "K") указывает, должен ли сценарий запускать программу (“S” — start) или завершать ее работу ("K" — kill) при переходе на данный уровень выполнения. Например, имя S10network означает, что сценарий network должен быть вызван для запуска соответствующих служб (в данном случае основных программ, обеспечивающих сетевое взаимодействие), а имя говорит о том, что работа программ, запущенных с помощью сценария nfs (сервера NFS) должна быть завершена. Число, следующее за символом "S" или "K", определяет порядок запуска сценариев. Например, программы поддержки сетевого взаимодействия, которым соответствует ссылка S10network, будут запущены раньше, чем сервер SSH (ссылка S55sshd). Аналогично определяется последовательность активизации ссылок, имена которых начинаются с символа "K".

Имена ссылок, используемых для запуска и прекращения работы служб, могут различаться в зависимости от конкретного дистрибутивного пакета. Например, в системе Mandrake программы, поддерживающие основные сетевые средства, запускаются с помощью ссылки S10network, а в Debian для той же цели используется ссылка S35networking. Подобные различия имеют место для сценариев, запускающих конкретные серверы. В данном случае важен тот факт, что серверы, которые должны присутствовать в системе, запускаются в определенном порядке. Например, многие сетевые инструменты могут быть запущены лишь тогда, когда программы поддержки базовых сетевых средств уже начали работу. Менять порядок запуска и завершения работы служб можно лишь в случае крайней необходимости. Если вы решитесь сделать это, вы должны ясно представлять себе функции, выполняемые каждой из служб, и последствия, которые повлечет за собой изменение порядка вызова сценариев.

Говоря о различных дистрибутивных пакетах, следует отметить одну особенность системы SuSE. В этой системе для управления процессом запуска сценариев SysV используется файл /etc/rc.config. Разделы этого файла посвящены основным серверам, которые запускаются средствами SysV. Если сервер не указан в этом файле (о том, что сервер должен быть запущен, сообщает строка START_ ИМЯ_СЕРВЕРА ="yes" ), он не будет выполняться в системе, даже если соответствующая ссылка начинается с символа "S". В системе Caldera для некоторых серверов используется подобная схема запуска, а запуском остальных серверов управляют файлы в каталоге /etc/sysconfig/daemons. Имя такого файла соответствует имени сервера. Строка ONBOOT в управляющем файле определяет, должен ли сервер выполняться в системе, однако многие из сценариев запуска Caldera не поддерживают данную опцию.

 

Управление сценариями запуска вручную

Если вам необходимо разрешить или запретить запуск сервера с помощью сценариев SysV, вы можете сделать это, изменяя сценарии запуска или ссылки на них. Проще всего запретить запуск сервера, удалив соответствующий сценарий из каталога сценариев SysV. Этим вы добьетесь того, что сервер не будет присутствовать ни на одном из уровней выполнения системы, но такое решение нельзя назвать элегантным. Кроме того, если вам потребуется не запретить, а разрешить выполнение сервера, вам все равно придется искать способы сделать это.

Более приемлемое решение данной задачи — переименовать ссылку на сценарий запуска в каталоге, соответствующем требуемому уровню выполнения. Например, для того, чтобы запретить выполнение сервера, надо переименовать ссылку, заменив символ "S" в начале ее имени на символ "K". Чтобы разрешить работу сервера, надо сделать обратную замену. Сложности, возникающие при этом, связаны с тем, что последовательность запуска серверов может отличаться от последовательности их завершения. Для того чтобы решить эту проблему, надо найти ссылки на этот сценарий в каталогах, соответствующих различным уровням запуска. Если хотя бы на одном уровне выполняется нужное вам действие, вы узнаете требуемый номер. Например, в результате выполнения приведенной ниже команды отображаются все ссылки на сценарий запуска системы Mandrake, соответствующий почтовому серверу Postfix.

$ find /etc/rc.d -name "*postfix"

/etc/rc.d/rc0.d/K30postfix

/etc/rc.d/rc1.d/K30postfix

/etc/rc.d/rc2.d/S80postfix

/etc/rc.d/rc3.d/S80postfix

/etc/rc.d/rc4.d/S80postfix

/etc/rc.d/rc5.d/S80postfix

/etc/rc.d/rc6.d/K30postfix

/etc/rc.d/init.d/postfix

Полученные результаты позволяют выяснить, что Postfix запускается на уровнях выполнения 2-5 и порядок запуска этого сервера определяется номером 80. Аналогично, работа сервера завершается на уровнях 0, 1 и 6, и порядок завершения определяется номером 30. Если вы хотите запретить выполнение Postfix на уровне 3, вам надо переименовать ссылку S80postfix в каталоге, соответствующем этому уровню, и назначить ей имя K30postfix.

Если вам нужно временно запустить или остановить сервер, не перезагружая компьютер, либо если вы захотите перезапустить сервер после изменения его конфигурационного файла, вы можете вызвать сценарий запуска вручную и передать ему параметр start или stop. Например, для того, чтобы немедленно прекратить работу сервера Postfix в системе Mandrake, вам надо выполнить следующую команду:

# /etc/rc.d/init.d/postfix stop

Большинство версий Linux при попытке завершить работу сервера выводит специальное сообщение. Кроме того, после остановки сервера отображается дополнительное сообщение о том, насколько успешно выполнена данная операция. При запуске сценария SysV появляется сообщение об успешном запуске сервера. (Эти сообщения вы видите на экране при загрузке компьютера.)

Если вы работаете с системой Slackware, то вместо переименования, добавления и удаления сценариев запуска или ссылок на них вам надо отредактировать один файл сценария, соответствующий требуемому уровню выполнения. Так, например, чтобы изменить поведение системы на уровне 4, вам надо внести изменения в файл /etc/rc.d/rc.4. Заметьте, что для многих серверов сценарии запуска отсутствуют; эти серверы запускаются с помощью /etc/rc.d/rc.inet2 (программы поддержки базовых сетевых средств, используемых этими серверами, запускаются посредством /etc/rc.d/rc.inet1). Для того чтобы изменить набор серверов, выполняемых в системе, надо вручную отредактировать эти сценарии так, как будто вы имеете дело с локальными сценариями запуска. (Локальные сценарии запуска будут рассмотрены ниже в этой главе.)

 

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

Некоторые дистрибутивные пакеты включают специальные утилиты, которые упрощают управление сценариями запуска. Пользуясь этими утилитами, вы уменьшаете риск неправильно задать имя сценария. Так, например, изменяя набор серверов, выполняемых в системе, вручную, вы можете вместо S80postfix случайно задать имя s80postfix (т.е. вместо "S" в верхнем регистре задать "s" в нижнем регистре). При использовании специализированных утилит такая ситуация не возникнет. К сожалению, подобные утилиты присутствуют не во всех системах; чаще всего они входят в состав Red Hat и систем, созданных на ее основе, например Mandrake. Перенос утилиты из одной системы в другую не дает желаемого результата, так как в разных системах расположение и имена сценариев запуска и ссылок SysV, а также номера, определяющие порядок запуска, могут различаться.

На заметку

В данном разделе рассматриваются утилиты управления сценариями запуска, предоставляющие алфавитно-цифровой интерфейс. Для выполнения подобных задач могут использоваться также утилиты с графическим интерфейсом, которые будут обсуждаться далее в этой главе.

Использование chkconfig

Инструментальное средство chkconfig, предназначенное для управления сценариями запуска SysV, предоставляет пользователю низкоуровневый интерфейс. Вся информация, необходимая для выполнения задачи, задается в одной командной строке. Утилита chkconfig вызывается следующим образом:

chkconfig <--list|--add|--del> [ имя ]

chkconfig [--level уровни ] имя [on|off|reset]

Первый вариант вызова используется тогда, когда необходимо получить информацию о текущей конфигурации (опция --list), добавить или удалить ссылки из каталога ссылок SysV (соответственно опции --add и --del). Второй вариант вызова позволяет разрешить или запретить сценарий на некоторых (или на всех) уровнях выполнения (эта задача решается путем переименования ссылки SysV). Приведенные ниже примеры иллюстрируют использование данной команды.

Предположим, что вы хотите получить подробную информацию о конфигурации Postfix. Если вы знаете, что стартовый сценарий Postfix называется postfix, вы можете задать следующую команду:

# chkconfig --list postfix

postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off

В результате утилита выводит информацию о состоянии Postfix на каждом из уровней выполнения. Проверить правильность полученных данных можно, воспользовавшись командой find. Если chkconfig отображает значение on, это свидетельствует о том, что имя ссылки начинается с символа "S", соответственно off означает, что имя ссылки начинается с символа "K".

Если вы выполните команду chkconfig --list, не указав имени сценария, chkconfig выведет информацию о состоянии всех сценариев запуска. Если в вашей системе используется xinetd, вы, возможно, получите также сведения о серверах, которые запускаются с помощью этого суперсервера.

Опция --add добавляет ссылку (если она отсутствует), а опция --del позволяет удалить существующую ссылку. Используя эти опции, необходимо указать имя сценария запуска. Например, команда chkconfig --del postfix удаляет все ссылки SysV на сценарий, ответственный за запуск сервера Postfix. В результате ее выполнения Linux не будет запускать сервер посредством сценариев SysV, а также не будет предпринимать попыток изменить состояние сервера при переходе на другой уровень выполнения. Удалять ссылки имеет смысл в том случае, если вы собираетесь запускать сервер с помощью суперсервера либо локальных сценариев запуска. Для того чтобы выполнить обратные изменения, надо воспользоваться опцией --add.

Чаще всего при работе с chkconfig используются параметры on, off и reset. Они позволяют разрешить или запретить запуск сервера на указанном уровне выполнения, а также восстановить исходные установки для этого уровня. Если вы не укажете опцию --level, то изменения будут произведены на всех уровнях выполнения. Предположим, вам необходимо запретить запуск сервера Postfix на уровне 3. Сделать это можно с помощью следующей команды:

# chkconfig --level 3 postfix off

При выполнении этой команды не отображаются никакие данные. Проверить полученные результаты можно, вызвав утилиту chkconfig с опцией --list или просмотрев содержимое соответствующего каталога ссылок. Для того чтобы разрешить запуск сервера, надо вместо указать параметр on. Если вам необходимо, чтобы действие утилиты распространялось на несколько уровней выполнения, надо указать требуемые уровни выполнения в виде одной строки. Так, например, чтобы изменения были произведены на уровнях 3–5, надо указать значение 345 опции --level. Если вы поэкспериментировали с установками и хотите вернуть их в исходное состояние, вам следует задать параметр reset.

# chkconfig postfix reset

Эта команда вернет ссылки на сценарии запуска для сервера Postfix в первоначальное состояние. Для того чтобы восстановить установки лишь для отдельных уровней, следует задать опцию --level и указать в качестве ее значения один или несколько уровней.

Несмотря на то что chkconfig обычно рассматривается как средство управления сценариями SysV, во многих системах эта утилита также может использоваться для настройки xinetd. Предположим, что chkconfig сконфигурирована таким образом, что она воспринимает сервер FTP как программу, запускаемую посредством суперсервера. В этом случае вы можете применять эту утилиту для изменения конфигурации FTP так, как будто для запуска данного сервера используются сценарии SysV. При этом опция --level не работает, а при указании опции --list не отображается информация об уровнях выполнения. Любой сервер, запускаемый с помощью суперсервера, будет функционировать на тех уровнях выполнения, на которых запускается xinetd. Опции --add и --del действуют подобно параметрам on и off. Конфигурационные файлы /etc/xinetd.d не удаляются, но их использование запрещается. Подробно работа xinetd будет рассмотрена далее в этой главе.

При изменении конфигурации SysV посредством chkconfig состояние выполняющихся в системе серверов не изменяется. Например, если вы запретили запуск sshd, работа сервера не завершится. Чтобы это произошло, надо предпринять дополнительные действия, например, вызвать сценарий запуска SysV и передать ему опцию stop либо вручную остановить сервер.

Использование ntsysv

Программа ntsysv предоставляет пользователю интерфейс в виде текстового меню и позволяет управлять запуском серверов. Для того чтобы запустить программу, достаточно ввести ее имя, при необходимости можно задать опцию -level уровни ; в качестве значения опции -level указывается один или несколько уровней выполнения, которые вы хотите изменить. Если вы не зададите эту опцию, ntsysv изменит только конфигурацию текущего уровня. Внешний вид меню ntsysv показан на рис. 4.1.

Рис. 4.1. Программа ntsysv предоставляет пользователю простой интерфейс для настройки сценариев SysV

Программа ntsysv отображает сведения обо всех серверах, для которых созданы сценарии запуска SysV. Некоторые версии ntsysv также выводят данные о серверах, запускаемых с помощью xinetd. Для того чтобы разрешить или запретить запуск сервера, надо с помощью клавиш со стрелками выбрать сервер в меню и нажать клавишу пробела. Символ * слева от имени сервера указывает на то, что при переходе на данный уровень выполнения сервер будет запущен; отсутствие этого символа означает, что запуск сервера запрещен. После внесения изменений надо с помощью клавиши выбрать кнопку OK и нажать клавишу ; в результате изменения будут сохранены, и выполнение программы завершится.

С помощью ntsysv вы можете задавать уровни выполнения, на которых будут работать серверы, запускаемые с помощью суперсервера; данная программа не позволяет лишь изменять уровни выполнения для самого суперсервера. Запрет загрузки сервера не означает, что этот сервер немедленно прекратит работу. Чтобы это произошло, вам надо вручную завершить выполнение сервера либо, если этот сервер запускается посредством суперсервера, перезапустить суперсервер.

 

Управление уровнями выполнения

В предыдущих разделах постоянно упоминались уровни выполнения, но из сказанного вряд ли стало ясно, что же они собой представляют. Говорилось лишь о том, что уровни выполнения и сценарии запуска SysV тесно связаны между собой. При загрузке компьютер переходит на некоторый уровень выполнения. Этому уровню соответствует каталог ссылок SysV; содержащиеся в нем ссылки указывают на сценарии запуска. Если ссылка начинается с символа "S" Linux при вызове сценария передает ему параметр start, а если имя ссылки начинается с "K", сценарию передается параметр stop.

Но как Linux узнает, на какой уровень следует перейти после загрузки? Информация об этом хранится в файле /etc/inittab, который выполняет роль конфигурационного файла для init — первого процесса, выполняющегося в системе. Процесс init является родительским для всех остальных процессов в системе. В файле /etc/inittab содержатся записи наподобие приведенной ниже.

id:5:initdefault:

Ключевое слово id, расположенное в начале, идентифицирует данную строку, а число, следующее за ним (в данном случае 5), устанавливает постоянный уровень выполнения. Если вы измените это значение и перезагрузите компьютер, система будет работать на другом уровне. Уровни 0, 1 и 6 имеют специальное назначение. Уровень 0 соответствует завершению работы системы, уровень 1 — однопользовательскому режиму, а уровень 6 — перезагрузке системы. Уровни 2–5 задают нормальные режимы работы; назначение каждого из уровней может изменяться в зависимости от версии системы. В Caldera, Red Hat Mandrake SuSE7.3 и TurboLinux уровень 3 соответствует обычному текстовому режиму (система X Window не запускается), а уровень 5 поддерживает графический пользовательский интерфейс (система X Window запущена). В ранних версиях SuSE вместо уровней 3 и 5 для поддержки текстового режима и графического интерфейса используются уровни 2 и 3, а в Slackware для той же цели применяются уровни 3 и 4. По умолчанию в Debian на уровнях 2–5 набор серверов, запускаемых посредством сценариев SysV, существенно не отличается, но на уровнях выше третьего используется меньшее число инструментов с текстовым интерфейсом (детали настройки системы можно выяснить, просмотрев содержимое файла /etc/inittab). В большинстве систем файл /etc/inittab содержит подробные комментарии, которые описывают функциональные возможности каждого из уровней. Если вы используете версию системы, которая не обсуждается в данной книге, или если вам нужна дополнительная информация о работе системы на различных уровнях, вы можете получить требуемые сведения, просмотрев комментарии в этом файле.

Внимание

Не устанавливайте в качестве уровня по умолчанию уровень 0 или 6. Если вы поступите так, то сразу после загрузки работа системы будет завершена либо компьютер начнет перезагружаться. Для того чтобы изменить настройку, вам придется загрузить компьютер с другого диска.

Если вы хотите временно изменить уровень выполнения, сделайте это с помощью команды telinit (в некоторых системах для этого приходится вызывать init). Синтаксис telinit имеет следующий вид:

telinit [-t время_в_секундах ] [ уровень ]

При изменении уровня выполнения некоторые процессы могут быть завершены. Для завершения процесса Linux передает ему сигнал SIGTERM либо SIGKILL. Сигнал SIGTERM обеспечивает более "мягкий" режим окончания работы; при этом программа получает возможность закрыть файлы и освободить другие ресурсы. SIGKILL принудительно завершает выполнение программы, в результате файлы, используемые в процессе его работы, могут быть повреждены. При изменении уровня выполнения telinit сначала пытается использовать SIGTERM. Если процесс продолжает выполняться, то через пять секунд telinit передает ему сигнал SIGKILL. Опция -t позволяет изменить этот интервал. В большинстве случаев значение, равное пяти секундам, вполне приемлемо.

Второй параметр, передаваемый telinit, задает уровень выполнения. Для указания уровня используется один символ. Результаты, которые вы получите, задавая в качестве этого параметра число, очевидны. Кроме того, вы можете передать программе другие символы. Их назначение описано ниже.

• а, b или с. Некоторые записи в файле /etc/inittab идентифицируются с помощью символов a, b и с. Эти символы имеют специальное назначение. Если вы передадите один из них telinit, программа будет обрабатывать соответствующие ему записи /etc/inittab; при этом уровень выполнения системы не изменится.

• Q или q. Если задать одно из этих значений как уровень выполнения, telinit повторно считает содержимое файла /etc/inittab и продолжит работу с учетом внесенных изменений.

• S, или s. Эта опция переводит систему в однопользовательский режим.

• U, или u. Данная опция вызывает перезагрузку процесса init; при этом новое содержимое файла /etc/inittab не считывается.

Зачем может понадобиться переходить на другой уровень выполнения? Изменяя уровень выполнения по умолчанию, вы можете изменять набор серверов, работающих в системе. В большинстве дистрибутивных пакетов самым важным считается сервер X Window. Одна из последних записей в файле /etc/inittab управляет запуском этого сервера; в некоторых системах эта задача решается с помощью сценариев запуска SysV. Изменение уровня выполнения позволяет быстро перейти от одного набора сервера к другому, разрешить или запретить графический режим или временно отключить X Window.

 

В обычных условиях программа-сервер связывается с некоторым портом (ресурсом, для идентификации которого используется тип протокола и число в интервале от 1 до 65535). В зависимости от номера порта, указанного в запросе, этот запрос направляется тому или иному серверу. Например, почтовый сервер, поддерживающий SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты), традиционно использует TCP-порт 25, a HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовой информации), как правило, связывается с портом 80.

Программа inetd является одним из суперсерверов, используемых в операционной системе Linux. Суперсервер выполняет функции посредника. Вместо набора серверов в системе запускается один суперсервер, который связывается со всеми портами, соответствующими серверам из набора. При установлении соединения суперсервер загружает сервер, порт которого указан в запросе, после чего этот сервер выполняет требуемые действия по передаче данных. Использование суперсервера обеспечивает два основных преимущества по сравнению с постоянным выполнением обычных серверов. Во-первых, при таком подходе уменьшается объем используемой оперативной памяти; в особенности это заметно, если на компьютере должно присутствовать большое количество программ- серверов. Во-вторых, перед тем как запрос будет передан обычном серверу, его получает суперсервер, который может выполнять необходимую фильтрацию данных; это повышает безопасность системы. Недостаток использования суперсервера состоит в том, что продолжительность обработки запроса увеличивается (как правило, на одну-две секунды). Это связано с тем, что для загрузки сервера требуется определенное время. Поэтому суперсервер лучше применять для серверов, которые вызываются достаточно редко. Если запросы к серверу приходят часто, лучше, если такой сервер постоянно присутствует в памяти компьютера.

 

Формат файла /etc/inetd.conf

Для настройки inetd используется конфигурационный файл /etc/inetd.conf. Если не принимать во внимание комментарии (строки, начинающиеся с символа #), то можно сказать, что содержимое файла inetd.conf представляет собой набор строк, каждая из которых определяет отдельный сервер. Пример записи, содержащейся в файле /etc/inetd.conf приведен ниже.

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

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

• Имя сервера. Первое поле в строке идентифицирует протокол, используемый сервером. Имя протокола должно соответствовать имени, указанному в файле /etc/services. Например, обратившись к этому файлу, можно выяснить, что имени telnet соответствует значение 23/tcp, т.е. сервер, поддерживающий протокол telnet, должен использовать для взаимодействия порт 23. Для того чтобы программа inetd могла управлять сервером, для этого сервера должна существовать запись в файле /etc/services. Очевидно, что, планируя запуск редко встречающегося сервера посредством inetd, надо позаботиться о том, чтобы соответствующая запись была включена в этот файл. Подавляющее большинство серверов изначально учтено в /etc/services.

• Тип гнезда. Второе поле указывает тип гнезда, используемого при поддержке протокола. Допустимы типы stream, dgram, raw, rdm и seqpacket.

• Тип протокола. Третье поле указывает тип протокола. В данном случае речь идет о нижележащем протоколе транспортного уровня, например TCP или UDP. Допустимые протоколы указаны в /etc/protocols, однако в подавляющем большинстве случаев в этом поле указывается значение tcp или udp.

• wait /nowait . Четвертое поле записи содержит одно из двух значений: wait или nowait. Значение wait имеет смысл только для дейтаграмм (тип гнезда dgram). В остальных случаях предполагается значение nowait. Большинство серверов, поддерживающих обмен с помощью дейтаграмм, связываются с гнездом и освобождают inetd для обслуживания последующих обращений. Эти серверы называются многопотоковыми (multi-threaded); для них в рассматриваемом здесь поле должно содержаться значение nowait. Серверы, которые связываются с гнездом, обрабатывают все данные, а затем по истечении времени тайм-аута завершают работу, называются однопотоковыми (single-threaded); для них в данном поле должно содержаться значение wait. В этом поле можно также задать числовое значение, отделив его от ключевого слова wait точкой, например wait.60. Число указывает максимальное количество серверов данного типа, которые inetd может загрузить в течение одной минуты. По умолчанию принимается значение, равное 40.

• Имя пользователя. Программа inetd может запустить сервер с привилегиями указанного пользователя. Это позволяет существенно повысить уровень безопасности системы. Ограничив права сервера необходимым минимумом, вы сокращаете возможности злоумышленников по незаконному проникновению в систему. Так, например, серверу Apache не требуются никакие специальные привилегии, поэтому его можно запускать с правами пользователя nobody либо определить права Apache, создав для него отдельную учетную запись. В приведенном выше примере указано имя root, так как привилегии этого пользователя необходимы для выполнения процедуры регистрации, которая осуществляется в начале Telnet-сеанса. Если к имени пользователя вы добавите имя группы, разделив эти имена точкой, сервер получит привилегии группы. Например, значение nobody.nogroup указывает на то, что сервер должен быть запущен с правами пользователя nobody и группы nogroup.

• Программа-сервер. Шестое поле содержит имя программы-сервера, которую должен запустить inetd, приняв запрос. В приведенном примере указано имя программы /usr/sbin/tcpd. В действительности tcpd — это не сервер, а программа, реализующая TCP Wrappers (назначение TCP Wrappers будет рассмотрено ниже). В большинстве дистрибутивных пакетов, в которых используется inetd, также применяется TCP Wrappers, т.е. серверы, поддерживаемые inetd, запускаются через tcpd. Для некоторых серверов TCP Wrappers можно не использовать, но в большинстве случаев применение данного средства оправдано.

• Параметры, передаваемые серверу. Это поле может отсутствовать. Если же оно задано, то содержит параметры, которые должны быть переданы программе-серверу. Эти параметры могут изменять поведение сервера, указывать расположение конфигурационных файлов и предоставлять другие сведения. Если сервер запускается посредством TCP Wrappers, параметр задает имя этого сервера; в приведенном выше примере указан параметр in.telnetd. (При необходимости к имени сервера можно добавить параметры, предназначенные для него.)

Для редактирования /etc/inetd.conf можно использовать любой текстовый редактор. При подготовке содержимого файла следите за тем, чтобы поля записи помещались в одной строке. (Если в составе записи присутствуют длинные имена файлов или если серверу передается большое число параметров, редактор может автоматически перенести часть записи на другую строку. В этом случае при работе inetd возникнут проблемы.) Если вы хотите добавить новую запись для установленного вами сервера, изучите документацию на этот сервер и выясните, как должна выглядеть соответствующая запись inetd.conf. Часто бывает удобно создавать новые записи на основе существующих. При этом надо внимательно следить за тем, чтобы тип гнезда, тип протокола, параметры, передаваемые серверу, и другие сведения были заданы правильно, в противном случае сервер не будет работать.

Большинство дистрибутивных пакетов, в которых используется inetd, содержит файл /etc/inetd.conf, настроенный для поддержки наиболее распространенных серверов. Многие записи закомментированы. Для того чтобы сервер был активным, достаточно убрать символ комментариев из строки (очевидно, что это можно сделать только в том случае, если сервер установлен в системе). Для некоторых служб в составе inetd.conf присутствует несколько записей, например, в этот файл может быть включено несколько строк, описывающих различные FTP-серверы (ProFTPd и WU-FTPD). Вам, как администратору системы, необходимо проследить за тем, чтобы все такие записи, кроме одной, были закомментированы.

Совет

Инсталлировав систему Linux, вам надо внимательно просмотреть содержимое файла /etc/inetd.conf (или конфигурационного файла xinetd , который будет рассматриваться ниже) и закомментировать записи для тех серверов, которые не нужны в системе. Многие администраторы включают символы комментариев в начало тех записей, назначение которых им не понятно. Такие действия вполне допустимы, потому что ни один сервер, указанный в inetd.conf , не является необходимым компонентом системы; лишь некоторые из них могут потребоваться для регистрации пользователей по сети. Отключение лишних серверов повышает безопасность системы, так как сужает поле деятельности злоумышленников, пытающихся получить доступ в вашу систему из Internet. Использовать подобный подход для служб, загружаемых с помощью сценариев SysV, нельзя, поскольку многие из них жизненно важны для нормальной работы системы Linux.

 

Использование TCP Wrappers

Как было сказано ранее, инструмент TCP Wrappers играет роль посредника между inetd и целевым сервером. Средства TCP Wrappers применяются для повышения безопасности системы; они позволяют задавать правила установления соединений, защищая тем самым сервер от нежелательного взаимодействия. Предположим, что вы хотите, чтобы доступ к серверу Telnet имели только пользователи, работающие в вашей локальной сети. Программу, обеспечивающую работу сервера Telnet, можно настроить так, чтобы она отвергала попытки обращения с узлов, для обслуживания которых сервер не предназначен. Однако не все серверы предоставляют такие возможности. Передача TCP Wrappers полномочий по управлению соединением повышает гибкость системы, не требуя при этом внесения изменений в программы.

Для управления работой TCP Wrappers используются два файла: /etc/hosts.allow и /etc/hosts.deny. Эти файлы имеют одинаковый формат, но выполняют противоположные действия. В файле hosts.allow описываются узлы сети, которым разрешено обращаться к данному компьютеру; для всех остальных узлов доступ запрещен. Файл hosts.deny, напротив, содержит описания узлов, доступ с которых запрещен; все остальные узлы могут устанавливать соединение с данным компьютером. Если в системе присутствуют оба файла, приоритет имеет файл hosts.allow. Благодаря этому вы имеете возможность задать ограничения в файле hosts .deny, а затем разрешить доступ для отдельных компьютеров. Если сведения о сервере не включены ни в один из файлов (сервер может быть описан либо непосредственно, либо с помощью групповой операции), TCP Wrappers разрешает доступ к нему для всех узлов сети.

На заметку

TCP Wrappers можно сравнить с локальным брандмауэром, работа которого будет рассматриваться в главе 25. При этом TCP Wrappers реализует дополнительную защиту, которая может оказаться полезной, если брандмауэр настроен неправильно, кроме того, этот инструмент предоставляет новые возможности, например, фильтрацию на основе имени группы NIS.

Подобно другим конфигурационным файлам, символ # в начале строки означает, что в данной строке содержатся комментарии. Запись в файле hosts.allow или hosts.deny имеет следующий формат:

список_демонов : список_клиентов

В списке демонов указывается один или несколько серверов, к которым применяется данное правило. Если в списке указано несколько серверов, их имена разделяются запятыми или пробелами. Имена серверов должны совпадать с именами, содержащимися в файле /etc/services. Кроме имен серверов в этом поле можно также указывать ключевое слово ALL, определяющее групповую операцию. Оно означает, что правило применяется ко всем серверам, управляемым TCP Wrappers.

Внимание!

Не забывайте, что не все серверы запускаются с помощью TCP Wrappers. Поэтому групповая операция ALL может не включать все серверы, выполняющиеся в системе. Аналогично, указав сервер в списке демонов, вы не защитите его, если для управления им не применяются inetd и TCP Wrappers, либо если он не использует TCP Wrappers непосредственно.

Список клиентов определяет компьютеры, которым разрешен или запрещен доступ к серверу. Подобно списку доменов, в списке серверов может быть указан один узел либо несколько узлов. Идентификаторы узлов разделяются запятыми или пробелами. Описания узлов сети могут быть представлены в перечисленных ниже форматах.

• IP-адрес. В списке клиентов можно указать конкретный IP-адрес, например 10.102.201.23. Такое описание определяет только этот адрес.

• Диапазон IP-адресов. Задать диапазон IP-адресов можно несколькими способами. Проще всего сделать это, указав в составе адреса меньше четырех десятичных чисел; в этом случае адрес должен заканчиваться точкой. Например, значение 10.102.201. соответствует сети 10.102.201.0/24. Кроме того, можно использовать запись типа IP-адрес/маска. В файлах hosts.allow и hosts.deny также поддерживаются адреса IPv6. Они задаются в виде [ n : n : n : n : n : n : n : n ]/ длина , где n — значения компонентов адреса, а длина — это число битов, используемых для представления диапазона.

• Имя узла. Узел можно описывать с помощью его доменного имени, например badcracker.threeroomco.com. Этим способом определяется только один узел. В этом случае при получении запроса система выполняет преобразование имен, а, следовательно, если сервер DNS работает некорректно, при идентификации компьютера могут быть допущены ошибки.

• Домен. Домен можно задавать так же, как вы задается доменное имя одного компьютера. Отличие состоит лишь в том, что в данном случае имя должно начинаться с точки. Если в файле указано имя .threeroomco.com, оно определяет все компьютеры, принадлежащие домену threeroomco.com.

• Имя группы NIS. Если последовательность символов начинается со знака @, оно интерпретируется как имя группы NIS (Network Information Services — сетевая информационная служба). Этот метод предполагает, что в сети функционирует сервер NIS.

В списке клиентов могут присутствовать ключевые слова, определяющие групповые операции. Назначение этих ключевых слов описано ниже.

• ALL. Идентифицирует все компьютеры.

• LOCAL. Определяет все локальные компьютеры на основании анализа имени узла. Если в имени отсутствует точка, соответствующий узел считается локальным.

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

• KNOWN. Идентифицирует компьютеры, доменные имена и IP-адреса которых известны системе.

• PARANOID. Определяет компьютеры, имена которых не соответствуют IP-адресам.

При использовании последних трех ключевых слов надо соблюдать осторожность, поскольку, если они присутствуют в списке клиентов, компьютер обращается к серверу DNS. Неисправность сетевого оборудования может привести к ненадежной работе сервера DNS. Если сервер DNS недоступен, получить доменное имя компьютера не удастся. Пример файла /etc/hosts.allow, содержащего две строки, приведен ниже.

telnet,ftp : 192.168.34. dino.pangaea.edu

ssh : LOCAL .pangaea.edu

Первая строка задает правила установления соединений для серверов Telnet и FTP, разрешая доступ к ним только из сети 192.168.34.0/24 и с компьютера dino.pangaea.edu. Вторая строка сообщает о том, что доступ к серверу SSH разрешен только для машин локальной сети, а также для компьютеров, принадлежащих домену pangaea.edu. Поскольку другие серверы не указаны в списках демонов, TCP Wrappers не блокирует доступ к ним. Например, если вы запустите через inetd и TCP Wrappers Apache, обратиться к этому серверу сможет каждый желающий.

Используя в списке клиентов записи типа пользователь @ компьютер , вы можете управлять доступом отдельных пользователей, работающих на удаленных узлах. Для того чтобы это было возможно, на клиентском компьютере должен выполняться сервер ident (в некоторых системах он называется auth), который возвращает имя пользователя, работающего с конкретным сетевым портом. Компьютер, использующий TCP Wrappers, передает запрос клиентской машине и получает имя пользователя. В этом случае соединение устанавливается с некоторой задержкой, а информация о пользователе, полученная из Internet, не всегда заслуживает доверия. Поэтому данную возможность лучше использовать в локальной сети, где вы имеете возможность контролировать конфигурацию всех компьютеров.

В составе правила может присутствовать дополнительное ключевое слово EXCEPT. Оно определяет исключения из этого правила. Рассмотрим следующую запись, содержащуюся в файле /etc/hosts.deny:

www : badcracker.org EXCEPT [email protected]

В данном случае доступ к Web-серверу запрещается для всех компьютеров, принадлежащих домену badcracker.org. Исключением являются лишь запросы, полученные от пользователя [email protected]. Аналогичный результат можно получить, включив правило для [email protected] в файл /etc/hosts.allow.

Если перед вами стоит задача максимально повысить безопасность системы, вы можете начать настройку с создания файла /etc/hosts.deny, содержащего следующую информацию:

ALL : ALL

Эта запись блокирует доступ ко всем серверам, поддерживаемым TCP Wrappers, с любого компьютера, независимо от его адреса. Затем можно постепенно разрешать доступ к серверам, составляя соответствующие правила и записывая их в файл /etc/hosts.allow. Возможности доступа должны ограничиваться необходимым минимумом. В частности, к серверам, чувствительным к попыткам взлома извне, например к Telnet, следует разрешить доступ только для определенных компьютеров. (Дело в том, что в процессе Telnet-взаимодействия данные, в том числе пароль, передаются в незашифрованном виде. Строго говоря, если компьютер содержит важные данные, на нем не следует вовсе устанавливать Telnet-сервер. Подробно эти вопросы будут обсуждаться в главе 13.)

 

Традиционно inetd был основным суперсервером, использовавшимся в системе Linux. Однако в 2000 г. наметилась тенденция перехода к альтернативному суперсерверу xinetd. Условно xinetd можно представить себе как сочетание inetd и TCP Wrappers. Но между этими программами существуют некоторые отличия. Не все возможности xinetd можно реализовать с помощью inetd и TCP Wrappers, но ряд действий, которые можно выполнить, используя inetd и TCP Wrappers, нельзя сделать посредством xinetd. При необходимости xinetd можно использовать совместно с TCP Wrappers, поэтому считается, что данный инструмент обеспечивает большую степень гибкости по сравнению с inetd. В начале 2002 г. xinetd был использован в Red Hat и Mandrake в качестве суперсервера по умолчанию; ожидается также переход других операционных систем на xinetd.

 

Формат файла /etc/xinetd.conf

Поскольку возможности нового суперсервера расширены по сравнению с inetd, формат конфигурационного файла также отличается от inetd. Настройка xinetd производится с помощью файла /etc/xinetd.conf. Следует заметить, что файл xinetd.conf, поставляемый в составе дистрибутивных пакетов Red Hat и Mandrake, содержит лишь минимальный набор установок. В нем задана конфигурация серверов, а также содержится строка, которая указывает суперсерверу прочитать все файлы в каталоге /etc/xinetd.d и интерпретировать их как дополнительные конфигурационные файлы. Конфигурация xinetd напоминает конфигурацию SysV; каждому серверу соответствует собственный управляющий файл, названный по имени сервера. Например, для сервера Telnet используется файл /etc/xinetd.d/telnet. При необходимости xinetd можно настроить так, что этот суперсервер будет использовать лишь основной файл xinetd.conf, но в дистрибутивных пакетах Red Hat и Mandrake некоторые файлы запуска уже содержатся в каталоге /etc/xinetd.d.

Независимо от того, содержится ли описание сервера в /etc/xinetd.conf или в файле, находящемся в каталоге /etc/xinetd.d, оно может занимать несколько строк. Базовое определение включает те же данные, что и запись в файле inetd.conf. Например, приведенное ниже описание почти эквивалентно рассмотренной ранее записи для Telnet-сервера, находящейся в файле inetd.conf.

service telnet

{

 socket_type = stream

 protocol = tcp

 wait = no

 user = root

 server = /usr/sbin/in.telnetd

}

В конфигурационном файле xinetd каждое поле именуется. Несмотря на то что в данном примере поля расположены в том же порядке, что и в рассмотренной ранее записи inetd, порядок их следования может быть произвольным. Как нетрудно заметить, в данном примере не вызывается TCP Wrappers, однако при необходимости этот инструмент можно использовать (для того, чтобы Telnet-сервер запускался через TCP Wrappers, надо задать значение /usr/bin/tcpd поля server и добавить поле server_args, присвоив ему значение /usr/sbin/in.telnetd).

В дополнение к стандартным средствам inetd xinetd предоставляет новые опции, расширяющие возможности суперсервера. Большинство из этих опций включаются в описание сервера и помещаются в фигурные скобки. Наиболее важные опции описаны ниже.

• Средства защиты. Как упоминалось ранее, xinetd поддерживает большое количество опций, предназначенных для повышения безопасности системы. Средства, соответствующие многим из этих опций, эквивалентны средствам, предоставляемым TCP Wrappers. Опции защиты подробно будут рассматриваться в следующем разделе.

• Запрет вызова сервера. Для того чтобы запретить вызов сервера, управляемого суперсервером inetd, надо закомментировать соответствующую строку в конфигурационном файле. В программе xinetd для этой цели используется опция disable = yes, которая помещается в описание требуемого сервера. Тот же результат можно получить, включив в раздел defaults основного файла /etc/xinetd.conf опцию disables = список_серверов, где список серверов состоит из имен серверов, разделенных пробелами. Различные инструментальные средства настройки используют оба способа. Если в описании сервера присутствует опция disable = no, это значит, что сервер активен.

• Перенаправление. Если вам необходимо передать запрос на другой компьютер, вы можете сделать это с помощью опции redirect = целевой_компьютер , где целевой компьютер (т.е, компьютер, которому должен быть передан запрос) задается с помощью доменного имени или IP-адреса. Например, если вы включите в описание сервера, содержащееся в файле /etc/xinetd.d/telnet на узле dummy.threeroomco.com, опцию redirect = 192.168.3.78, то при попытке обращения к Telnet-серверу на компьютере dummy.threeroomco.com запрос будет перенаправлен на 192.168.3.78. Эту возможность использует NAT-маршрутизатор для того, чтобы организовать обслуживание внешних запросов компьютером, принадлежащим внутренней сети. Тот же результат достигается с помощью iptables, но применяя для этой цели xinetd, вы можете использовать средства управления доступом суперсервера.

• Протоколирование. Используя опции log_on_success и log_on_failure суперсервера xinetd, вы можете определять, какая информация должна записываться в файл протокола в случае успешного или неудачного обращения к серверу. Значениями этих опций могут быть PID (идентификатор процесса сервера), HOST (адрес клиента), USERID (идентификатор пользователя клиентской системы, которая передала запрос), EXIT (время получения запроса и статус завершения его обработки) и DURATION (длительность сеанса). При необходимости вы можете добавлять к набору, принятому по умолчанию, или исключать из него отдельные значения, используя вместо символа = пары символов += и -=.

• Ограничения на установление соединений. Ограничить число соединений, поддерживаемых xinetd, можно несколькими способами. Опция per_source определяет, сколько запросов от одного источника xinetd может обработать в единицу времени. (Значение UNLIMITED этой опции позволяет обрабатывать неограниченное число запросов.) Опция instances задает максимальное количество процессов, которые xinetd может породить (это значение должно быть больше, чем значение опции per_source). При использовании опции cps ей передаются два значения, разделенные пробелом: число соединений, которые xinetd может установить в течение одной секунды, и длительность паузы (в секундах), которая должна быть выдержана, если число соединений превысит максимально допустимое. Приоритет серверов, управляемых xinetd, задается с помощью опции nice; эта опция действует подобно программе nice. И наконец, опция max_load, значением которой является число с плавающей точкой, указывает максимальную загрузку системы, при достижении которой xinetd должен отвергать последующие запросы. При использовании этих опций снижается вероятность того, что сервер пострадает от атаки, предпринятой с целью вывода его из строя, или в результате обилия запросов, вызванных высокой популярностью сервера.

Большинство из приведенных выше опций можно использовать либо в описании сервера, либо в разделе defaults файла /etc/xinetd.conf. Помещенная в раздел defaults опция воздействует на все серверы, управляемые xinetd. Если опция присутствует и в разделе defaults, и в описании, принимается значение опции, заданное в описании сервера.

Если вы внесли изменения в файл /etc/xinetd.conf или в один из файлов, содержащихся в каталоге /etc/xinetd.d, необходимо перезапустить программу xinetd. Поскольку суперсервер xinetd чаще всего запускается посредством сценария SysV, проще всего перезапустить его с помощью команды типа /etc/rc.d/init.d/xinetd restart (в некоторых системах сценарий запуска может находиться в другом каталоге). Можно поступить и по-другому — передать xinetd сигнал SIGUSR1 или SIGUSR2, используя для этого команду kill. При получении сигнала SIGUSR1 xinetd читает содержимое нового конфигурационного файла и продолжает работу. В ответ на сигнал SIGUSR2 суперсервер делает то же самое, но при этом завершает работу тех серверов, которые согласно новому конфигурационному файлу должны быть неактивны.

 

Средства управления доступом

Одно из преимуществ xinetd состоит в том, что эта программа объединяет в себе функции суперсервера и средства управления доступом, характерные для TCP Wrappers. Кроме того, настройка xinetd выполняется достаточно просто. Средства управления доступом xinetd не дублируют соответствующие функции TCP Wrappers; некоторые задачи лучше решаются с помощью xinetd, для решения других приходится применять TCP Wrappers. Настраивая xinetd, можно определять доступ либо одновременно для всех серверов, либо для каждого сервера в отдельности. Основные опции, предназначенные для управления доступом, описаны ниже.

• Ограничения для различных узлов. Для xinetd предусмотрены опции only_from и no-access, которые выполняют те же функции, что и содержимое файлов /etc/hosts.allow и /etc/hosts.deny TCP Wrappers. Эти опции могут присутствовать либо в главном конфигурационном файле, либо в файле, предназначенном для конкретного сервера. В качестве значения опции only_from задается список компьютеров, которым разрешено обращаться к серверу (для всех остальных компьютеров доступ запрещен). Аналогично, значение опции no-access представляет собой "черный список"; компьютеры, указанные в списке, не имеют права устанавливать соединение с сервером, а для остальных компьютеров доступ разрешен. Если адрес присутствует в обоих списках, приоритет имеет адрес, заданный более конкретно. Для идентификации компьютеров используются разные способы. В опциях only_from и no-access может быть указан IP-адрес узла (например, 172.23.45.67), адрес сети, оканчивающийся нулем (например, 172.23.0.0 для сети 172.23.0.0/16) или заданный с помощью маски (172.23.0.0/16), имя сети, указанное в файле /etc/networks, или доменное имя узла (например, badguy.threeroomco.com). Если в качестве значения опции указано имя узла, xinetd выполняет преобразование имени в адрес один раз при загрузке суперсервера. Поскольку в течение работы xinetd доменное имя может измениться, данный способ установления ограничений неэффективен.

• Ограничения по времени. Для указания временного интервала, в течение которого сервер доступен для клиентов, используется опция access_times. Значение этой опции задается в формате часы : минуты - часы : минуты , например, 08:00-18:00 означает, что к серверу можно обращаться с 8 до часов. Значение опции access_times влияет только на установление соединения. Например, если для Telnet-сервера задан интервал 08:00-18:00, то соединение, установленное в 17:58, может использоваться как угодно долго.

• Ограничения на использование интерфейсов. При необходимости вы можете связать сервер с одним сетевым интерфейсом. Для этого используется опция bind (либо опция interfасе, которая является синонимом bind). В качестве значения опции задается IP-адрес, связанный с интерфейсом. Например, если интерфейсу eth1 присвоен адрес 172.19.28.37 и для сервера задана опция bind = 172.19.28.37, это означает, что обращаться к этому серверу можно только через интерфейс eth1. Попытки установить соединение через eth0 окончатся неудачей; результат будет такой же, как в случае, когда сервер не установлен в системе. Эту опцию удобно использовать на маршрутизаторах или на компьютерах, подключенных одновременно к нескольким сетям. Предположим, что на компьютере, обеспечивающем связь локальной сети с Internet и использующем для соединения с сервером провайдера PPP-соединение, установлены серверы Telnet и FTP. С помощью опции bind вы можете настроить xinetd так, чтобы доступ к серверам Telnet и FTP имели только компьютеры, подключенные к локальной сети.

В этом и предыдущем разделе были описаны лишь наиболее часто используемые опции xinetd. Для получения информации об остальных опциях обратитесь к справочным данным.

 

В составе многих дистрибутивных пакетов Linux поставляются инструментальные средства с графическим пользовательским интерфейсом, которые позволяют настраивать основные сетевые средства, организовывать запуск серверов и выполнять другие задачи, связанные с администрированием системы. В разных версиях Linux используются различные инструменты, но все они обладают некоторыми общими чертами. Эти программы обычно доступны с рабочего стола KDE (K Desktop Environment — среда рабочего стола K) или GNOME (GNU Network Object Model Environment — среда сетевой объектной модели GNU). Для их запуска можно также ввести команду в окне xterm. (Запускать инструменты администрирования может только пользователь root; в последние годы это правило строго соблюдается.) В данном разделе обсуждаются инструменты Linuxconf (используемый в Red Hat и системах, созданных на ее основе, например, Mandrake), YaST и YaST2 (применяемые в SuSE) и ksysv (вариант программы ntsysv, которая рассматривалась ранее в этой главе, снабженный графическим интерфейсом).

На заметку

Существуют инструменты Webmin и SWAT, позволяющие выполнять задачи администрирования, взаимодействуя с системой средствами Web. Строго говоря, к таким инструментам можно отнести и Linuxconf, так как эта программа может размещаться не только локально, но и на удаленном компьютере; в этом случае для взаимодействия используется Web-интерфейс. Данные инструменты обсуждаются в главе 16.

 

Использование Linuxconf

Утилита Linuxconf представляет собой модульный инструмент конфигурирования системы. Она состоит из базовой структуры, в которую включаются модули, обеспечивающие поддержку конкретных серверов и позволяющие выполнять различные задачи по настройке системы. Linuxconf может работать в текстовом режиме (меню строятся из символов), в графическом режиме (в этом случае программа выполняется в отдельном окне), а также позволяет использовать в качестве интерфейса Web-броузер (этот режим будет рассматриваться в главе 16). Для поддержки графического интерфейса нужна не только основная программа linuxconf, но также дополнительный пакет (gnome-linux-conf или linuxconf-gui). Если программа Linuxconf может поддерживать графический интерфейс, она отображает его, в противном случае Linuxconf начинает работу в текстовом режиме. В данном разделе рассматривается работа утилиты в графическом режиме на локальном компьютере, но работа в текстовом режиме и через Web отличается лишь в деталях. Структура интерфейса в разных системах может быть различной. Например, в Red Hat программа отображает одно окно и выводит в нем сведения обо всех модулях, в то время как в Mandrake для каждого модуля открывается отдельное окно.

На заметку

Подробная информация о Linuxconf представлена на официальном Web-узле Linuxconf по адресу http://www.solucorp.qc.ca/linuxconf/ . В настоящее время данная программа поставляется с Red Hat 7.2 и Mandrake 8.1, но не рекомендована к применению в обеих системах. Поэтому можно ожидать, что в ближайшее время вместо нее в состав дистрибутивных пакетов будет включен другой инструмент. На момент написания книги еще неизвестно, какие средства придут на замену Linuxconf: будет ли это один универсальный инструмент или набор средств, ориентированных на конкретные серверы. Несмотря на то что пакет Linuxconf предназначен для выполнения в системах Red Hat и Mandrake, существуют также версии для других систем. Информацию о них можно найти на Web-узле Linuxconf.

После запуска Linuxconf отображает информацию об областях конфигурации; данные распределены в трех вкладках: Config, Control и Status. Каждая область может включать подобласти; переходя от одной подобласти к другой, можно получить доступ к конкретному конфигурационному модулю. (В реализации Linuxconf для Mandrake после щелчка на области отображается отдельное окно, содержащее опции, доступные для этой области. Открывая таким образом новые окна, вы получаете доступ к конфигурационному модулю.) На рис. 4.2 показана реализация Linuxconf для Red Hat; информация в окне соответствует выбору модуля Control→Control Panel→Control Service Activity. Этот модуль позволят управлять сценариями SysV и запуском сервера с помощью xinetd. Для того чтобы разрешить или запретить запуск сервера, выполните следующие действия.

Рис. 4.2. Программу linuxconf можно использовать для управления работой системы Linux

1. Запустите Linuxconf и обратитесь к модулю Control→Control Panel→Control Service Activity (см. рис. 4.2).

2. Выберите требуемый сервер в списке, отображаемом в правой части окна. Например, для управления сервером sendmail найдите пункт sendmail и щелкните на нем мышью. В результате в правой части окна Linuxconf отобразится новая вкладка, на которой будет отображаться текущее состояние сервера.

3. Выберите вкладку Run Levels. При этом окно программы должно выглядеть так, как показано на рис. 4.3. Вы можете разрешить или запретить запуск сервера на любом из уровней выполнения, для этого установите флажок опции рядом с требуемым уровнем.

Рис. 4.3. С помощью linuxconf можно разрешать или запрещать запуск сервера на любом уровне выполнения

4. Щелкните на кнопке Accept, а затем на кнопке Dismiss вкладки Service Control.

5. Выберите пункт меню File→Act/Changes, и программа выведет список возможных действий. Щелкните на пункте Do It, подтвердив тем самым внесенные изменения.

В результате этих действий система настраивается для загрузки серверов на указанном уровне выполнения. Чтобы проверить результаты, надо воспользоваться утилитой chkconfig или просмотреть имена файлов в каталоге ссылок SysV.

Помимо разрешения или запрета загрузки серверов, Linuxconf предоставляет возможность настройки некоторых из них. Поскольку данная программа не рекомендована к применению в Red Hat и Mandrake, многие модули настройки серверов не включаются в состав дистрибутивных пакетов. Эти модули можно найти на Web-узле Linuxconf, но они не всегда корректно работают. Причина в том, что расположение конфигурационных файлов серверов и даже их содержимое меняются в зависимости от версии системы, поэтому создать универсальный конфигурационный модуль невозможно.

 

Использование YaST и YaST2

В системе SuSE используются инструменты YaST (Yet Another Setup Tool) и YaST2. YaST работает в текстовом режиме, a YaST2 предоставляет графический интерфейс. Несмотря на различия в интерфейсе, обе программы обеспечивают одинаковые возможности. В этом разделе рассматривается YaST2, но если вам по каким-то причинам придется перейти на YaST, вы не будете испытывать затруднений при работе с этой программой. (Для простоты я употребляю термин YaST для обозначения обеих программ, за исключением тех случаев, когда обсуждаются различия между ними.) Для того чтобы вызвать YaST в текстовом режиме, надо ввести команду yast; аналогично, программа YaST2, предоставляющая графический интерфейс, вызывается по команде yast2. Внешний вид основного окна YaST2 показан на рис. 4.4. Категория, или область конфигурации, выбирается в левой части окна, а конкретные инструменты, предназначенные для настройки системы, отображаются справа.

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

В системе SuSE для настройки процедуры запуска наряду с содержимым каталога ссылок SysV используется файл /etc/rc.config. Для управления запуском серверов посредством YaST необходимо изменить содержимое конфигурационного файла. Для этого предусмотрен инструмент RC-Config Editor, содержащийся в области Misc. После выбора данного инструмента отображается окно, показанное на рис. 4.5. Большинство переменных, управляющих запуском сетевых серверов, расположено в области Start-Variables→Start-Network. Щелкните мышью на одном из пунктов списка, показанного на рис. 4.5, и YaST предоставит вам средства для установки значения переменной. Обычно программа предлагает на выбор значения Yes и No, соответствующие разрешению и запрету запуска сервера.

Рис. 4.5. Для разрешения или запрета запуска сервера переменной присваивается значение Yes или No

С помощью YaST можно задавать и другие характеристики системы. Многие важные переменные, определяющие параметры серверов, хранятся в файле /etc/rc.config; их значения можно задавать с помощью тех же инструментов, которые вы используете для настройки сценариев запуска SysV. Например, вы можете указать имя узла (Network→Network-Basics) или сообщить системе, допустима ли регистрация пользователя root с удаленного компьютера (Security→Security-Basics). Просмотрев содержимое различных областей, вы получите представление о возможностях YaST.

Специальные средства настройки серверов в основном находятся в области Network. Например, в этой области вы найдете инструменты NFS и Sendmail Configuration, которые используются соответственно для настройки NFS и sendmail. Вопросы настройки NFS и sendmail рассматриваются в главах 8 и 19, однако в них не уделяется внимание использованию YaST.

 

Использование ksysv

В одном из предыдущих разделов данной главы обсуждались инструментальные средства chkconfig и ntsysv, предназначенные для управления сценариями запуска SysV (а в некоторых случаях и серверами, загружаемыми с помощью суперсервера). Эти инструменты существенно упрощают процесс администрирования системы, но если администратор предпочитает программы с графическим интерфейсом, ему неудобно работать с ними. Существуют альтернативные программы администрирования, предоставляющие графический пользовательский интерфейс; в качестве примеров таких программ можно привести ksysv и tksysv. Программа ksysv создана в рамках проекта KDE, но может работать и в других средах. Инструмент tksysv не связан ни с какой конкретной графической средой. Обе эти программы нормально работают в Red Hat и в системах, созданных на ее основе. Окно программы ksysv показано на рис. 4.6.

Рис. 4.6. Для того чтобы задать особенности работы сервера, надо щелкнуть мышью на его имени

Как ksysv, так и tksysv выводит слева в окне список сценариев запуска SysV; в остальной части окна отображаются списки серверов, запуск которых разрешен или запрещен на разных уровнях выполнения. После щелчка на пункте списка Available Services отображается диалоговое окно, содержащее описание сервера и управляющие элементы, посредством которого можно запустить, остановить или перезагрузить сервер, а также изменить имя файла и права доступа. Если вы щелкнете на пункте списка, соответствующего любому из уровней выполнения, будет выведено диалоговое содержащее вкладки Service и Entry (рис. 4.7). На вкладке Service представлено описание сервера, а на вкладке Entry находятся инструменты, позволяющие изменить имя ссылки, указывающей на сценарий запуска и номер, определяющий порядок запуска.

Рис. 4.7. После щелчка на имени службы ksysv отображает диалоговое окно, позволяющее редактировать сценарии запуска и ссылки SysV

Для того чтобы разрешить автоматический запуск сервера, надо перетащить мышью имя сервера из списка Stop, соответствующего определенному уровню выполнения, в список Start того же уровня. Чтобы запретить запуск сервера, надо выполнить обратное действие. Вы также можете перетащить имя сервера из списка Available Services в список, соответствующий уровню выполнения. В любом случае ksysv присвоит серверу последовательный номер, определяемый позицией, в которую вы перетащили соответствующий пункт списка. Например, если вы перетащили имя сервера и вставили его между пунктами списка с последовательными номерами 20 и 30, ksysv присвоит ему номер 25. Для того чтобы изменить этот номер, надо щелкнуть на имени сервера в списке, соответствующем уровню выполнения, и ввести новое значение в поле Sorting Number (см. рис. 4.7). Очевидно, что ksysv не имеет сведений о том, какой номер наиболее подходит для сервера в вашей системе, поэтому при настройке системы приходится уделять внимание выбору последовательных номеров. Используя ksysv, можно получить конфигурацию, при которой на каком-то из уровней имя сервера будет присутствовать как в списке Start, так и в списке Stop, поэтому необходимо следить за тем, чтобы подобная ситуация не возникала.

Утилиты ksysv и tksysv не обеспечивают той степени гибкости, которой позволяют добиться такие инструменты, как Linuxconf и YaST. Инструменты, предназначенные для управления сценариями SysV, в отличие от более универсальных средств, ориентированы на выполнение одной задачи. Несмотря на то что специализированные утилиты упрощают работу со сценариями SysV, использование их не освобождает вас от необходимости знать основные принципы работы системы. Вы должны представлять себе, что такое уровни выполнения, как определяется последовательность вызова сценариев, и другие особенности работы со средствами запуска SysV.