Наконец-то Internet приобретает человеческие черты. Сегодня любой желающий по- лучает от сети не только услуги электронной почты , но и полный доступ практически ко всем ресурсам Сети. К сожалению, в большинстве случаев используется так называемое "типовое PPP-подключение", реализуемое без приложения мысленных усилий с использо- ванием Windows95 и броузера WWW Explorer или Netscape.
Почему к сожалению? Дело в том, что использование "простейших" средств, как правило, приводит к получению простейших же результатов. Я уже писал о том, что исполь- зование более перспективной операционной системы Linux [1] позволяет повысить реальную пропускную способность арендуемого коммутируемого канала (телефонной линии) почти вдвое! Но и это не предел. В упомянутой мною публикации выигрыш достигался исключи- тельно за счет эффективной работы ядра операционной системы Linux, которая изначально ориентировалась на работу в сетях TCP/IP. Но этим возможности организации эффективной работы в сети никоим образом не исчерпываются! Возьмем хотя бы службу DNS...
Основное назначение службы доменных имен (DNS – Domain Name System) состоит в упрощении навигации в Internet для человека, которому символьную последовательность запомнить гораздо легче, чем десяток цифр. Компьютеру же наоборот – оперировать с чис- лами гораздо легче, да и быстрее. Для разрешения этого противоречия было создано целое семейство различных серверов DNS – программ, единственной функцией которых является преобразование имен типа www.geocities.com в 123.22.22.11 и наоборот.
Задача, казалось бы, тривиальная: таблица из двух полей и большого количества строк – нашел значение в одном поле, взял из второго, и все в порядке... Но на практике и разработчики, и пользователи столкнулись с несколькими препятствиями. Во-первых, не- прерывно растущая сеть постоянно увеличивает количество использованных IP-адресов, что приводит к разбуханию нашей таблицы соответствий до, прямо-таки скажем, просто непри- личных размеров. Во-вторых, информация в этой таблице подвержена непредсказуемым изменениям: узлы появляются и исчезают, меняют свои адреса и имена и так далее. И, нако- нец, самый неприятный момент – Internet не является однородной системой, управляемой чьей-либо "железной рукой" и раздача адресов IP (и присвоение им доменных имен) проис- ходит если и не совсем хаотично, то, во всяком случае, децентрализовано.
Выход из создавшейся ситуации "прогрессивно мыслящее человечество" усмотрело в создании глобальной информационной системы, обеспечивающей пользователей DNS- информацией "по запросу". При этом в сети одновременно функционирует достаточно большое количество серверов DNS, каждый из которых отвечает за свой участок сети и яв- ляется для этого участка "авторитетом". Наряду с авторитетными серверами в сети разме- щено огромное количество кэширующих серверов, каждый из которых копирует наиболее часто использующуюся информацию от авторитетов. Поскольку любая информация имеет тенденцию к устареванию, для каждой из кэшированных записей устанавливается опреде- ленный срок ее достоверности, по истечении которого сервер повторно запрашивает авто- ритетный сервер соответствующего домена.
Конечные пользователи, как правило, подключаются к DNS-серверам своих провай- деров, которые работают в режиме авторитетного сервера для своих пользователей и осуще- ствляют кэширование всех остальных запросов. С точки зрения пользователя Windows эта проблема по-другому и не решается, но как только вы переходите в UNIX и начинаете гово- рить с Internet на общем языке, у вас появляются весьма интересные возможности.
Одной из них является создание собственного локального кэширующего DNS-сервера.
В самом деле, при каждом обращении к удаленному узлу вам приходится запрашивать у провайдера IP-адрес. Клиентов, подобных вам, у провайдера несколько десятков , и на обслуживание вашего запроса уходит драгоценное время, которое, как вы можете заметить, если будете внимательно разглядывать строку состояния в Netscape Navigator или Explorer может составлять 30-40 секунд на каждом обращении к DNS . А при установке собственного сервера вы сможете: ? обеспечить максимальный уровень привилегий в обслуживании запросов DNS – вы ведь единственный и любимый пользователь; ? создать базу данных DNS узлов, к которым постоянно обращаетесь, и узнать из полученной информации немало интересного (подробнее об этом написано в [2]); ? ускорить процедуру установления соединения с серверами Internet.
Поскольку авторитетом для вашего IP-адреса (безразлично, статического или дина- мического) является ваш провайдер, вам достаточно установить простой кэширующий сер- вер. К счастью, программа сервера DNS – bind, едина для всех типов серверов (включая но- мер версии – 4.9.3), а конкретный режим работы определяется только параметрами настрой- ки. Сам же сервер входит в обязательном порядке во все дистрибутивы Linux, и нередко встречается в исходных текстах. Есть только одна неувязочка, о которой стоит предупредить заранее. Пакет c DNS-сервером и в RedHat и в Slackware называется bind (какой-нибудь вер- сии), но исполняемая программа сервера имеет совершенно другое название – named! По- этому, проверяя, не установлен ли сервер DNS в вашей системе, вам придется воспользо- ваться следующими командами: ps -ax " grepnamed Скорее всего, named в системе не установлен, но лучше все же проверить. Связано это с режимом последующего запуска сервера: первоначальный запуск осуществляется с помощью команды named, а перезапуск, при работающем сервере – командой named.restart. В любом случае, если в вашей изолированной системе уже запущен сервер DNS, его необхо- димо отключить, или, говоря на языке UNIX – "убить" соответствующий процесс .
Теперь необходимо проверить настройку сетевого интерфейса TCP/IP. Для того чтобы локальные серверы вашей системы могли обслуживать запросы локальных же клиентских программ, в TCP/IP предусмотрен специальный адрес IP, называемый localhost, который имеет значение 127.0.0.1.
Расхожее мнение гласит, что этот адрес в любом компьютере является синонимом адреса текущего компьютера и может использоваться наряду с обычным адресом при обра- щении к локальным ресурсам. Действительность же оказывается более суровой. Адрес localhost не может использоваться внешними пользователями для обращения к вашим ре- сурсам, поскольку при таком обращении любой компьютер начинает опрашивать только свои собственные ресурсы. В остальном адрес localhost подчиняется всем правилам, уста- новленным для адресов IP. А это означает, что вы должны не забыть прописать его в файле /etc/hosts, а также подключить маршрут доступа к этому файлу. Как ни странно, но довольно часто именно отсутствие этих двух простых настроек делает невозможным работу с серве- рами и клиентами TCP/IP. Но давайте по порядку.
Во-первых, база данных хостов сети /etc/hosts. Не отвлекаясь на исторические под- робности, отметим, что localhost прописан в ней обычно первой же строкой. За подробно- стями по содержанию этого файла отсылаю вас к статье [1] и к руководствам пользователя.
Справедливости ради должен отметить, что эта проблема в любом дистрибутиве Linux, как правило, решена. Вторая проблема напрямую связана с маршрутизацией в сети. Прежде все- го, вам необходимо определиться, какие маршруты для вашей машины уже определены. Для этого воспользуйтесь командой route: #routeKernelroutingtableDestinationGatewayGenmaskFlagsMSSWindowUseIface loopback * 255.0.0.0 U 3584 0 1 lo Вот что должна сообщать ваша система при правильной конфигурации сетевого ин- терфейса (при этом мы полагаем, что Ethernet-интерфейса в вашей системе нет – в противном случае процесс конфигурирования станет даже проще, ведь у вас появится собственный "аппаратный" IP-адрес, к которому вы сможете обращаться без оглядки на особенности lo- calhost). Обратите внимание, что мы не видим указания на наш любимый адрес localhost. Дело в том, что в данном случае команде route предшествовало включение в таблицу маршру- тизации целой подсети 127.0.0.0 , что, конечно же, решает наши проблемы, но по большому счету, является излишним.
В случае если таблица маршрутизации, формируемая программой route, оказывается пуста, вам необходимо добавить в инициализационный файл настройку маршрута доступа к локальному узлу. Сделать это можно двумя способами: добавив целую подсеть: 127.0.0.0 или один только localhost. Я предпочитаю использовать более предсказуемый по своим по- следствиям второй путь: route add 127.0.0.1 Вообще говоря, для многозадачных и многопользовательских систем, к которым Linux можно отнести с куда большим основанием, чем нашумевшую Windows95 применимо одно важное правило: нужно вводить только те установки среды и конфигурации, которые необходимы для решения конкретных, текущих задач. Ну да ладно, после того, как мы включили в маршрут доступа (и в инициализационный файл) наш localhost, можно присту- пать к настройке собственно сервера DNS. Перегружать компьютер не нужно! Во-первых, мы еще не закончили, а во-вторых, все изменения вступают в силу немедленно после вы- полнения соответствующих утилит , и вы должны лишь позаботиться о том, чтобы необхо- димые настройки устанавливались при последующих запусках системы.
Итак, приступим к конфигурированию named. При загрузке сервер DNS осуществляет считывание собственного инициализационного файла, который обычно имеет имя /etc/named.boot. Вы, безусловно, можете изменить и каталог, и имя инициализационного файла, но для этого вам придется самостоятельно перекомпилировать named из исходных текстов, самостоятельно заменив указанное имя файла на альтернативное. Сложного в этом процессе ничего нет, но мы отвлекаться на это не будем.
Поскольку мы предполагаем реализовать только простейший, кэширующий сервер DNS, то и особых проблем с настройкой сервера пока не предвидится. Вот типовое содер- жание файла named.boot: ; ; Загрузочный файл кэширующего сервера DNS ; directory /var/namedcache .
root.cache В этом файле вы указываете компьютеру на два обстоятельства: ? Все остальные конфигурационные файлы сервера DNS размещаются в каталоге /var/named. Это традиционный каталог для их размещения, но если вам больше нравится, вы можете создать для этих целей подкаталог, например, в /etc.