Новости :

Apache как прокси-сервер

Apache как прокси-сервер

Валентин Синицын (val AT linuxcenter DOT ru), "Apache как прокси-сервер" - 04/05/2006 || Библиотека ЛинуксЦентра

Рассмотрим типичную для небольшой организации конструкцию: шлюз в Интернет, работающий под управлением Unix или Microsoft Windows, прокси-сервер, web-сервер сети Интранет, почтовый сервер и т.д. Оказывается, число ее элементов можно несколько сократить, и в соответствии с золотым правилом инженера, увеличить тем самым общую надежность системы. Сегодня мы поговорим о делегировании Apache основных функций кэширующего прокси-сервера (например, Squid) и даже кое-чего сверх них. В качестве базовой ОС будем использовать Linux, хотя многое из сказанного ниже может быть без ограничения общности применено и для других платформ.

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

Покончив с теоретическими вопросами, перейдем к техническим деталям. Для реализации задуманного нам понадобится Apache версии 2.0.53 и выше (более ранние версии имеют ошибки в mod_cache, препятствующие нормальной работе с кэшированными документами) с включенными mod_proxy, mod_cache и mod_deflate. В отличие от специализированных решений вроде упомянутого выше Squid, прокси-сервер на базе Apache имеет существенно модульную архитектуру, все мыслимые и немыслимые функции которой построены по принципу: общая база + провайдеры. Мы не раз убедимся в этом по ходу изложения. Итак, приступим к первой фазе:

Запуск прокси-сервера

Для того, чтобы Apache мог принимать и обрабатывать прокси-запросы, необходимо загрузить модуль mod_proxy, входящий в стандартный комплект поставки и прекрасно документированный. Здесь и далее в этой статье мы не будем дублировать страницы руководства, останавливаясь лишь на нетривиальных моментах. mod_proxy, как и большая часть других упомянутых в статье модулей, обычно не собирается в стандартной конфигурации Apache, поэтому вам, вероятно, придется заново скомпилировать сервер, указав соответствующие параметры сценарию configure. За поддержку mod_proxy отвечает опция «--enable-proxy», прочие же параметры я буду приводить в тексте в скобках после имени соответствующего модуля.

В соответствии с представленной выше формулой, mod_proxy образует фундамент, на котором работает система поддержки прокси-запросов. Их реализации, специфичные для различных протоколов, вынесены в отдельные модули: mod_proxy_http (--enable-proxy-http), mod_proxy_ftp (--enable-proxy-ftp) и mod_proxy_connect (--enable-proxy-connect). Последний из них необходим для работы с запросами HTTP CONNECT, в частности, защищенными SSL-соединениями.

Прежде чем говорить о настройке mod_proxy, сделаем пару замечаний. Первое: Apache поддерживает два типа прокси-серверов: прямые (forwarding proxy) и обратные (reverse proxy). Нас будут интересовать исключительно прямые прокси-сервера. Обратные прокси применяются для балансировки нагрузки и не имеют ничего общего с темой данной статьи. Второе: прокси-запрос не является для Apache чем-то чужеродным. Заглянув в исходные тексты сервера, вы обнаружите, что все клиентские запросы, независимо от того, кому они адресованы, описываются одной и той же структурой. Apache помечает запросы, предназначенные другим серверам, специальным флагом, но не более того. Из этого, к примеру, следует, что в параметрах модуля mod_proxy отсутствует директива для указания порта, который следует использовать для приема входящих соединений (сноска: напомним, что согласно общепринятым соглашениям для этих целей используется порт 3128). Apache способен принимать и обрабатывать прокси-запросы на любом порту, который разрешен к “прослушиванию” директивой Listen. Впрочем, на практике зачастую оказывается удобнее провести границу между локальными и переадресуемыми запросами. Для достижения этой цели можно создать специальный виртуальный хост, например, на порту 3128, пользуясь директивой VirtualHost. Подробности ищите в документации к Apache. Дальнейшее изложение неявно предполагает, что вы уже настроили виртуальный хост и размещаете предлагаемые директивы внутри принадлежащей ему секции httpd.conf (Подсказка для самых нетерпеливых: в конце статьи приведен завершенный фрагмент конфигурационного файла, практически пригодный для вставки по методу Ctrl-C – Ctrl-V)

Чтобы Apache мог принимать прокси-запросы, необходимо явным образом разрешить их, используя директиву “ProxyRequests On”. Однако, не спешите этого делать, не позаботившись о безопасности сетевых соединений! Оплачивать мегабайты, загруженные предприимчивыми подростками с ProxyHunter'ом в руках – не самое приятное времяпровождение. Параметры доступа к серверу задаются в секции <Proxy> и, в частности, могут иметь следующий вид:

<Proxy *> # Для всех прокси-запросов

Order deny,allow # Сперва запретить, потом разрешить

Deny from All # Запретить всем

Allow from 192.168.0.1/24 # Разрешить доступ из внутренней сети организации

</Proxy>

Здесь реализована простейшая схема контроля доступа, базирующаяся на IP-адресах клиентов. Во многих случаях ее будет достаточно. Но что делать, если вы хотите разрешить использование сервера с компьютеров, не имеющих фиксированного IP-адреса (например, домашних машин особо приближенных сотрудников, которые не прочь получить “городской прокси”)? Для этих целей можно применить авторизацию по имени пользователя и паролю. Поскольку директивы контроля доступа, заключенные между тегами <Proxy> и </Proxy> на самом деле обрабатываются теми же самыми модулями, что следят за «неприкосновенностью» локальных каталогов сервера (ну, не говорил ли я вам, что Apache практически не отличает прокси-запрос от обычного?), вы можете использовать привычную конструкцию:

<Proxy *> # Для всех прокси-запросов

AuthName “Tresspassers” # «Посторонним в.»

AuthFile /some/secret/file # Имя файла, содержащего реквизиты пользователей

AuthType Basic # Метод авторизации - базовый

Require valid-user # Пропускать всех, кто перечислен в /some/secret/file

</Proxy>

Естественно, предварительно следует создать файл /some/secret/file при помощи утилиты htpasswd(1) и загрузить соответствующие модули (mod_access и/или mod_auth). При необходимости оба метода можно комбинировать. При этом бывает полезно пользоваться директивой “Satisfy All|Any”, указывающей, требовать ли от потенциального клиента соответствия всем условиям (применительно к нашей задаче это означает «иметь разрешенный IP-адрес и ввести правильное имя пользователя/пароль») или лишь одному из них. Последний вариант наиболее интересен с практической точки зрения, поскольку позволяет избежать раздражающей процедуры ввода пароля для пользователей внутренней сети организации.

Внеся необходимые изменения в httpd.conf, не забудьте перезапустить Apache. После этого откройте свой любимый браузер и удостоверьтесь, что настройки безопасности действуют именно так, как вы задумали.

Кэширование

Мы успешно справились с первым этапом, а именно: научили Apache обрабатывать запросы, адресованные внешним серверам. Нашей следующей задачей будет организация локального кэширования запрашиваемых данных. По некоторым сведениям, это позволяет сэкономить 10-20 процентов внешнего трафика, что, согласитесь, не так уж мало.

Кэшированием данных в Apache заведует модуль mod_cache (--enable-cache). Именно он принимает решение о том, допустимо ли локальное сохранение того или иного объекта. Непосредственной записью данных на носители занимаются модули-”провайдеры”, из которых нас в первую очередь будет интересовать mod_disk_cache (--enable-disk-cache), реализующий хранение кэша на жестком диске.

Отметим, что в Apache 2.0 оба этих модуля (mod_cache и mod_disk_cache) имеют статус экспериментальных. Ситуация обещает измениться в Apache 2.1, который пока что пребывает в состоянии альфа-версии.

Чтобы включить кэширование, используйте директиву “CacheEnable disk /”, где “disk” - идентификатор модуля-провайдера. Местоположение дискового кэша и его желаемый объем (в килобайтах) задается соответственно директивами “CacheRoot <имя каталога>” и «CacheSize <NNN>», относящимися уже не к mod_cache, а mod_disk_cache. Apache предпринимает меры к тому, чтобы конфиденциальные данные никогда не попадали в кэш сервера, однако, лишняя безопасность все же не повредит. Я рекомендую сделать каталог, в котором хранится кэш, недоступным ни для кого, кроме Apache.

# chown apache:apache /path/to/cache

# chmod 0700 /path/to/cache

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

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

К сожалению, Apache 2.0 не имеет никаких штатных средств для управления содержимым кэша. Вы не можете постепенно удалять старые данные или делать это при превышении кэшем некоторой дисковой квоты. Часть из этих проблем решена в Apache 2.1 при помощи специальной утилиты htcacheclean, которая очищает кэш по мере необходимости. Мне не известно, перенесена ли она в ветвь 2.0, однако, в качестве некоторой замены, вы можете написать сценарий, периодически очищающий каталог (и, для верности, перезапускающий Apache), самостоятельно.

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

На данном этапе мы завершили все работы, необходимые для получения “идентичного натуральному ароматизатора” Squid, а точнее, того подмножества его функций, которое используется в типичной малой сети. Теперь мы пойдем несколько дальше и реализуем нечто новое – прозрачное сжатие web-страниц.

Сжатие

Модуль для сжатия HTTP-документов известен каждому уважающему себя web-мастеру. Называется он mod_deflate (--enable-deflate), и, к вящей радости замученного бесконечными сборками из исходных текстов читателя, обычно включен даже в стандартной конфигурации. Его основное предназначение – сжимать локальные HMTL-страницы перед отправкой их пользователю, но, коль скоро Apache “близорук” и не делает особых различий между обычным и переадресованным запросом, он вполне годится и для последних.

После своей загрузки mod_deflate создает фильтр “DEFLATE”, который может быть установлен стандартным образом, например, при помощи директивы “SetOutputFilter DEFLATE”. Руководство к модулю рекомендует поостеречься и отключить сжатие данных для браузеров, которые, несмотря на заявленную функциональность (сноска: Отметим, что отсечение клиентов, не поддерживающих сжатие данных, mod_deflate производит сам, безо всякого участия администратора) не могут обеспечить должный уровень поддержки (например, Netscape Navigator 4.x может корректно обрабатывать только сжатые данные типа text/html, а его версии 4.06-4.08 не способны даже на это), однако, применительно к прокси-серверу это имеет смысл лишь в том случае, когда такие “динозавры” до сих пор имеют хождение в вашей организации. Из других директив, поддерживаемых mod_deflate, следует упомянуть DeflateCompressionLevel,

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

mod_filter

Казалось бы, все хорошо. Наш Apache теперь умеет обрабатывать прокси-запросы, хранить их в кэше и даже сжимать перед отправкой. Однако, спустя некоторое (обычно – весьма непродолжительное) время обнаруживаются странные артефакты. Архивы почему-то оказываются упакованными дважды, что пугает неподготовленных пользователей. И тут же возникают два вековечных русских вопроса: “Кто виноват?” и “Что делать?”

Благо, за ответом на первый из них далеко ходить не надо. Как наверняка уже догадался проницательный читатель, проблема кроется в излишней «жадности» нашего mod_deflate, который сжимает все и вся, тогда как браузер готов распаковать лишь вполне определенные типы файлов: текст, HTML-страницы, графические изображения... Лежащее на поверхности решение – ограничить список файлов, подлежащих динамическому сжатию, по расширению (кстати, оно очень хорошо описано в документации к mod_deflate), можно отбросить сразу же. Расширение файла далеко не всегда соответствует его содержимому (те же архивы иногда называются как-нибудь вроде http://www.some-tricky-company.ru/download/download.pl?id=1234&uid=5678), кроме того, вариантов, подлежащих фильтрации, оказывается чересчур много (на самом деле, нам проще сказать, что должно сжиматься и выкинуть остальное). Вторая идея – использовать директиву “AddOutputFilterByType DEFLATE <список MIME-типов>” также терпит фиаско, поскольку она принципиально не способна работать с прокси-запросами (это редкое исключение, подтверждающее правило). Да и нужные нам шаблоны, типа “text/*”, не говоря уж о более сложных, ей явно не по зубам. Что же делать?

Решение существует! (Читатели, имеющие за плечами мат-мех или физфак наверняка испытали непроизвольный прилив радостных эмоций). Это специализированный модуль mod_filter, написанный Ником Кью (Nick Kew) и включенный в стандартный комплект поставки Apache 2.1, усеченная версия которого была портирована автором этих строк обратно в 2.0. В данном разделе речь будет вестись именно о ней.

Исходный код модуля доступен по адресу: http://ktf.physics.usu.ru/~val/mod_filter.zip. Чтобы установить его, распакуйте архив во временный каталог на вашем сервере и дайте команду: apxs -c -i -a mod_filter.c.

Основная идея mod_filter состоит в том, чтобы заменить обычный фильтр так называемым “умным” (smart filter). «Умный» фильтр – это некоторая абстрактная конструкция, содержащая условия срабатывания и набор так называемых провайдеров (опять это слово!), которые, в свою очередь, являются обычными фильтрами. В перспективе подобный подход может сократить количество дублирующегося кода, встречающегося практически в каждом модуле и дающего ответ на вопрос: “Должны ли мы обработать эту порцию данных?” Впрочем, сейчас нас будут интересовать сугубо практические аспекты.

Условия срабатывания “умного” фильтра могут использовать самую различную информацию: поля заголовков прямого запроса (req) и ответа на него (resp), значения внутренних переменных Apache, устанавливаемых с помощью mod_setenvif (env), имена обработчиков (handler), а таже тип передаваемых данных (Content-type).

Для создания “умного” фильтра используется директива “FilterDeclare <имя фильтра>”. Подключением отдельных провайдеров управляет директива “FilterProvider <имя фильтра> <имя провайдера> <условие>”. Здесь под именем провайдера подразумевается название “обычного” фильтра, например, DEFLATE. Завершив настройку “умного” фильтра, следует добавить его в «цепочку» командой FilterChain. При обработке поступившего запроса звенья цепочки последовательно просматриваются до тех пор, пока не будет найден фильтр, условие срабатывания которого для данного конкретного запроса окажется истинным. По умолчанию добавление нового “умного фильтра” происходит в конец цепочки, однако, это поведение можно подавить, используя специальные префиксы в директиве FilterChain. Подробности ищите в документации.

Теперь путь решения проблемы становится ясным. Нам необходимо добавить “умный” фильтр “Compressor” (конечно, вы можете использовать другое имя), который будет обрабатывать данные с типом “text/*”. На самом деле, диапазон MIME-типов, подлежащих сжатию, может быть более широким. Я, например, использую следующую конструкцию:

FilterProvider Compressor DEFLATE resp=Content-type $text/

FilterProvider Compressor DEFLATE resp=Content-type $application/xhtml

FilterProvider Compressor DEFLATE resp=Content-type $application/xml

Знак долара «$» в начале каждого условия обозначает операцию поиска по подстроке. Кроме него, доступен поиск по регулярному выражению (обрамляется символами «/»), а также весь спектр арифметических операций сравнения и специальное условие «*», которое всегда истинно. Обратите внимание, что мы используем «resp=Content-type» вместо «Content-type». Между этими двумя вариантами существует тонкое различие. В первом случае MIME-тип определяется по заголовкам, сформированным удаленным сервером, тогда как в последнем сведения поступают из локальной базы MIME-типов. Некоторые сайты, например, репозитарий SourceForge.net, используют для своих файлов двусмысленные имена, что приводит к недопониманию: http://prdownloads.sourceforge.net/project/release-x.y.tar.gz?download на проверку оказывается HTML-страницей, содержащей список доступных зеркал для файла release-x.y.tar.gz, поэтому лучше доверить право определения типа содержимого удаленному серверу. Уж он-то точно знает, что нам отправил.

Заключение

Вот и подошла к концу данная статья. Если вы внимательно и творчески следовали всем перечисленным рекомендациям, то сейчас в вашем распоряжении имеется многофункциональный сервер Apache, который может самостоятельно обрабатывать запросы, переадресовывать их удаленным web-узлам, кэшировать и динамически сжимать передаваемые данные, причем делает все это в рамках одной кодовой базы. Некоторые из описанных в статье функций в настоящий момент имеют статус экспериментальных или являются сторонними разработками. Ситуация изменится с выходом финальной версии Apache 2.1, который будет содержать “штатные“ реализации mod_cache и mod_filter. До тех пор вы, при желании, можете рассматривать предлагаемое решение как перспективное, хотя мой личный опыт показывает, что надежности вышеупомянутых модулей вполне достаточно для решения “бытовых” задач. Попробуйте сами!

Врезка 1. Пример вызова configure, обеспечивающий поддержку всех необходимых модулей

сonfigure \

--enable-proxy –-enable-proxy-http -–enable-proxy-ftp -–enable-proxy-connect\

--enable-cache –enable-disk-cache\

--enable-deflate\

--enable-mods-shared=all

Врезка 2. Фрагмент файла httpd.conf, реализующий описанную в статье систему

...

# Слушать порт 3128

Listen 3128

...

# Загрузить необходимые модули

LoadModule cache_module modules/mod_cache.so

LoadModule disk_cache_module modules/mod_disk_cache.so

...

LoadModule deflate_module modules/mod_deflate.so

...

LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_connect_module modules/mod_proxy_connect.so

LoadModule proxy_ftp_module modules/mod_proxy_ftp.so

LoadModule proxy_http_module modules/mod_proxy_http.so

...

LoadModule filter_module modules/mod_filter.so

...

# Создать виртуальный хост на порту 3128

NameVirtualHost *:3128

<VirtualHost *:3128>

# Включить поддержку прокси-запросов

ProxyRequests On

<Proxy *>

# Ограничение доступа по IP

Order deny,allow

Deny from all

Allow from 192.168.0.1/24

# или авторизация по имени пользователя и паролю

AuthName "No trespassers"

AuthType Basic

AuthUserFile <файл с реквизитами пользователей>

Require valid-user

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

# All, чтобы затребовать разрешенный IP-адрес И правильный пароль

# Any, чтобы затребовать разрешенный IP-адрес ИЛИ правильный пароль

Satisfy Any

</Proxy>

# Настройки кэша

CacheEnable disk /

CacheRoot <путь к каталогу кэша>

CacheSize 51200

CacheDirLevels 2

CacheDirLength 3

# «Умный» фильтр для динамического сжатия

FilterDeclare Compressor

FilterProvider Compressor DEFLATE resp=Content-type $text/

FilterProvider Compressor DEFLATE resp=Content-type $application/xhtml

FilterProvider Compressor DEFLATE resp=Content-type $application/xml

FilterChain Compressor

</VirtualHost>


Статья была впервые опубликована в журнале "Системный администратор", апрель 2005

Валентин Синицын (val AT linuxcenter DOT ru), "Apache как прокси-сервер" - 04/05/2006 || Библиотека ЛинуксЦентра
Комментарии: (0) | Интернет и Сети | 2006-06-05

Microsoft тестирует сервис для детей и родителей

Microsoft тестирует сервис для детей и родителей

Корпорация Microsoft сообщила о начале бета-тестирования нового сервиса Windows Live Family Safety Settings. Он содержит несколько инструментов, которые дают возможность обеспечить безопасность при работе с разными приложениями и в Интернете. Среди них фильтрация содержимого веб-страниц, отчеты о деятельности в интернете и другие. Пользователи могут устанавливать разрешение или запрет на доступ к определенным сайтам или на группы сайтов. Конечная версия сервиса выйдет уже летом этого года. Использовать ее смогут все пользователи Windows XP Service Pack 2 и Windows Vista.

Поскольку Microsoft не считает себя большим специалистом по особенностям детской психики, при разработке параметров по умолчанию для нового сервиса корпорация консультировалась с Американской академией педиатрии.

Автор: Сергей Бондаренко

Источники: techtree.com, 3dnews.ru

Комментарии: (0) | Интернет и Сети | 2006-03-20

Имена Интернет (настройка DNS)

Имена Интернет

Подстрешный Артем,
программист
Radio-MSU Network,
art@radio-msu.net

Введение

Для человека, поработавшего даже небольшое время в сети, становится совершенно естественным, что у каждого компьютера, подключенного к интернет, есть свое название, имя, которое легко запомнить. Система, которая позволяет нам использовать эти привычные для человека имена, избегая других неудобных способов "маркировки" компьютеров, называется DNS (Domain Name System, доменная система имен).

В интернете существует, вообще говоря, два основных способа адресации компьютеров. Первый - численный (или IP-адрес; например, 193.124.134.101), второй - символьный (noc.radio-msu.net). DNS создана для того, чтобы поставить в соответствие один способ другому.

Чтобы облегчить упорядочивание наименований, вся структура компьютерных имен устроена таким образом:есть отдельные уровни (домены), которые могут включать в себя как другие поддомены, так и имена компьютеров. Все названия должны состоять только из латинских букв, цифр и, может быть, знака "минус". Отдельные уровни доменов разделяются точкой.

Типичное полное доменное имя компьютера может выглядеть так: computer3.otdel-5.firma.msk.ru В этом примере такой адрес мы присвоили компьютеру номер три, который стоит в отделе (номер сообразите сами) фирмы с изысканным английским названием "firma", которая находится в Москве ("msk"), в России ("ru"). Локальным именем компьютера (hostname) здесь является "computer3", а ".ru" обычно называется доменом верхнего уровня. Домен msk.ru, соответственно, является доменом второго уровня; firma.msk.ru - третьего...

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

Тот, кто имеет право администрировать домен, может делать изменения только в пределах этого домена. Например, системный администратор отдела N5 может, скажем, изменить имя "computer3" на "computer4" или на что-то более человеческое, например, назвать этот компьютер "julia" (Тогда полный его адрес станет julia.otdel-5.firma.msk.ru). Но для того, чтобы изменить имя домена 4-го уровня "otdel-5", администратору придется просить об этом у сисадмина фирмы (если, конечно, это не одно и тоже лицо). Процедура получения имени, например, в зоне .ru или .com называется регистрацией домена. Конечно, каждая компания, подключающаяся к интернет, стремится зарегистрировать как можно более естественное и легкое для запоминания имя. Так, для "Microsoft inc." логично зарезервировать домен microsoft.com

Доменов верхнего уровня очень немного - всего около 250.. Большая часть из них - так называемые, географические домены. Например, .de (Deutschland, Германия), .ru (Russia, Россия), .iq (Iraq, Ирак). Оставшиеся негеографические домены верхнего уровня - .com (для коммерческих компаний), .net (для сетевых ресурсов), .edu (образовательные учреждения), .mil (военные организации), .org (некоммерческие организации), .gov (правительственные ведомства), .int (интернациональные корпорации).

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

К началу 1998 года во всем интернете зарегистрировано около 30 миллионов хостов. Распределение по доменам верхнего уровня приведено в таблице:

домен  число хостов  описание
 com    8201511      Commercial
 net    5283568      Networks
 edu    3944967      Educational
 jp     1168956      Japan
 mil    1099186      US Military
 us     1076583      United States
 de      994926      Germany
 uk      987733      United Kingdom
 ca      839141      Canada
 au      665403      Australia
 org     519862      Organizations
 gov     497646      Government

Россия в этом списке находится на 28-м месте. Под доменом .ru зарегистрировано около 100 тысяч компьютеров. А в Антарктике (.aq), как оказывается, нет ни одного компьютера, подключенного к интернет..

DNS вашей компании

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

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

- Получение численных (IP) адресов. Для того, чтобы ваши компьютеры, подключенные к интернет, стали доступны, необходимо выделить для них уникальные численные адреса. Обычно в договоре на подключение к интернет указывается, сколько и каких адресов отдается в пользование вашей компании. Формат IP-адресов такой: четыре числа от 1 до 255, отделенных точками. Например, 193.124.134.101 - IP-адрес какого-то компьютера в сети.

- Настройка DNS. Допустим, вы получили блок IP-адресов. Теперь следует правильно сконфигурировать систему имен и корректно настроить работу серверов с этими именами.

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

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

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

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

Name-сервера бывают primary и secondary. Иногда их называют первичными и вторичными, а также master и slave. Primary name-сервер может быть только один. На нем хранится вся информация о доменах, и если происходят изменения, то конфигурация правится только на нем. Secondary name-серверов может быть несколько, но обычная практика - один secondary nameserver. Дополнительные вторичные name-сервера служат для повышения скорости расшифровывания вашего адреса и для повышения устойчивости такого преобразования. Для небольших сетей три и больше вторичных name-сервера - это уже излишество. Secondary name-сервера с заданной периодичностью в автоматическом режиме считывают текущую конфигурацию с primary-сервера. Заметим, что один и тот же компьютер может одновременно являться primary-сервером для одних доменов и secondary nameserver'ом для нескольких других. Конкретную реализацию таких DNS-серверов мы рассмотрим в следующих разделах.

Выбор и регистрация домена

Если вы имеете некоторый опыт работы в интернет, то вам, скорее всего, известны примеры доменных имен различных организаций и фирм. В качестве примера приведем случайно взятые адреса серверов:
www.playboy.com - web-сервер журнала "Playboy"
www.internic.net - основной web-сервер компании Network Solutions
rs.internic.net - регистрационный сервер Network Solutions
www.ripn.net - сервер организации RIPN


Как настроить DNS

Сама программа named в большинстве случаев входит в стандартный набор средств операционных систем UNIX. Если в вашем случае ее не оказалось, попробуйте сделать поиск программы named для вашей системы в поисковых серверах интернета (AltaVista, Lycos и т.д.). Обычно главный файл с настройками named называется named.boot и лежит в директории /etc. Запускать демон named обязательно с привилегиями пользователя root.

В данном случае рассматривается FreeBSD версии 2.2.2 со стандартной named. Сама программа лежит в /usr/sbin/named, а заготовки для конфигурации в директории /etc/namedb.

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

Скопируем named.boot в нужную директорию:

% cp /etc/namedb/named.boot /etc

Комментарии в named.boot начинаются с ";" на первом месте в строке.

Рассмотрим различные директивы в named.boot:


directory       /etc/namedb

Это та директория, в которой будут храниться конфигурационные файлы для каждого из доменов, которые этот name-сервер будет держать.


cache    .   named.root

Эта специальная опция задает имя файла named.root в директории /etc/namedb, в котором содержатся IP-адреса компьютеров, которые "знают все" о доменных именах, то есть, содержат домен "точка". В этих серверах хранится информация обо всех доменах верхнего уровня, и если на DNS-запрос ответ не был дан на более раннем этапе, то, добежав до одного из таких top-level серверов, запрос пойдет по необходимой ветке вниз. Вот кусок этого файла:


; formerly NS.INTERNIC.NET
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4

; formerly NS1.ISI.EDU
. 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107

Файл named.root впоследствие нужно периодически забирать с FTP.RS.INTERNIC.NET, так как IP-адреса top-level серверов через несколько месяцев могут и поменяться.

Следующая директива в конфигурационном файле говорит о том, что наш name-сервер является primary name-сервером для какой-то зоны, то есть, содержит всю информацию о ней. Синтаксис ее таков:

primary [имя.домена] [имя_файла]

Пример:


primary radio-msu.net db.radio-msu.net
primary math.msu.su db.math.msu.su

Это означает, что мы установили primary nameserver для доменов radio-msu.net (домен второго уровня) и math.msu.su (третьего уровня), но мы проделали только небольшую часть работы. После этого нужно будет описать эти домены в текстовых файлах, называющихся db.radio-msu.net и db.msu.su в директории /etc/namedb. Мы специально выбрали имена файлов похожими на имена соответствующих им доменов из соображений удобства. Имена конфигурационных файлов больше нигде роли не играют, и вы вправе их называть как угодно. Создавать и редактировать их можно при помощи обычного текстового редактора, находясь в директории /etc/namedb. Подробное описание db.* файлов будет дано чуть ниже.

Для того, чтобы стать вторичным nameserver'ом для других доменов, в named.boot нужно написать строчку такого плана:


secondary npi.msu.su    158.250.2.232 db.npi.msu.su
secondary rector.msu.su 193.232.112.1 db.rector.msu.su

Общий вид директивы таков:

secondary [имя.домена] [IP-адрес primary nameserver'а] [имя_файла]

Первый параметр здесь - имя домена, для которого мы устанавливаем secondary. Для него обязательно должен существовать первичный name-сервер, с которого демон будет периодически считывать данные об этом домене. Вместо одного IP-адреса primary nameserver'а может идти и список адресов, откуда еще можно узнать информацию о домене. Это используется в том случае, если мы создаем многоуровневую систему nameserver'ов с различными приоритетами, и т.д. В большинстве случаев в это поле заносится только адрес primary. Последний параметр - имя временного файла, выбранное нами произвольным образом, в котором демон named будет хранить информацию о домене, полученную от primary name-сервера. Как и в первом случае, имена файлов лучше назначать созвучными с именем домена. Кстати, для того, чтобы установить вторичный nameserver для домена, нужно только добавить одну такую строчку named.boot, и все.

Чтобы правильно настроить primary name-сервер, нам осталось рассмотреть конфигурационные файлы db.* (эти файлы также называются файлами зоны). Общий вид записи в этом файле:

[domain] [opt_ttl] [opt_class] [type] [resource_record_data]

где domain есть "." для описания домена верхнего уровня, "@" для текущего домена или обычное доменное имя (в частности, просто имя машины (hostname)).

opt_ttl - необязательное поле, целое число, которое означает время жизни (time-to-live) этой записи в секундах. По истечении этого срока содержимое записи должно автоматически обновиться.

opt_class - тип адреса объекта. Такой тип существует только один, который, собственно, и указывается ("IN").

type - тип записи (рассмариваются ниже)

resource_record_data - данные этого типа

Рассмотрим пример primary nameserver'а и соответствующего ему файлу зоны для домена radio-msu.net. В случае, если вы будете использовать эти примеры как руководство, не забудьте, пожайлуста, поменять все записи соответственно структуре вашей сети.

В named.boot мы должны прописать такую строчку:


primary  radio-msu.net  db.radio-msu.net

И в директории /etc/namedb создаем файл с названием db.radio-msu.net примерно такого содержания:


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;     BIND configuration for the primary nameserver
;             Radio-MSU.NET host table
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@               IN      SOA  ns.radio-msu.net.  art.radio-msu.net. (
                        1998022300      ; Serial
                        28800           ; Refresh
                        7200            ; Retry
                        604800          ; Expire
                        86400 ) ; Minimum ttl
;----------------------------------------------------------------
                IN      NS              ns.radio-msu.net.
                        NS              mskws.desy.de.
localhost       IN      A               127.0.0.1
;----------------------------------------------------------------
@               IN      MX      20      mpr
                        MX      40      mskws.desy.de.
;----------------------------------------------------------------
ns              IN      A               193.124.134.1
                IN      MX      10      ns
                IN      MX      50      relay
;----------------------------------------------------------------
telion                  IN      A       193.124.134.2
                        MX      10      telion
                        MX      20      relay.radio-msu.net.
                        MX      50      mskws.desy.de.
www                     IN      CNAME   telion
;----------------------------------------------------------------
noc                     IN      A       193.124.134.101
                        IN      MX      10 noc
                        IN      MX      20 relay
;----------------------------------------------------------------
mpr                     IN      A       193.124.134.3
                        MX      10      mpr
                        MX      50      mskws.desy.de.
pop                     IN      A       193.124.134.3
uucp                    IN      A       193.124.134.3
relay                   IN      A       193.124.134.3
mail                    IN      A       193.124.134.3
vika                    IN      A       193.124.134.5
                        MX      10      vika
                        MX      50      relay
;----------------------------------------------------------------
brusun                  IN      A       193.124.134.20
diana                   IN      A       193.124.134.7
sftgames                IN      CNAME   telion
chat                    IN      CNAME   brusun
;------------------------  THE  END  ----------------------------

Заметим, что все строки, начинающиеся с ";", являются комментариями и используются для улучшения читабельности текста.

Теперь рассмотрим типы записей, встречающиеся в нашей конфигурации:

Самая первая запись в любом таком файле выглядит следующим образом:


@               IN      SOA  ns.radio-msu.net.  art.radio-msu.net. (

Символ "@" означает, что дальнейшие директивы относятся к текущему домену (то есть, к домену radio-msu.net). Поле "IN" можнно считать несущественым, а после него идет описание типа записи:

SOA - (Start of authorizing) - зона ответственности. Дальнейшие параметры определяют, кто отвечает за этот домен, как часто обновлять информацию об этой зоне на secondary-серверах, а также другую служебную информацию. Первое поле параметров этой записи - имя primary name-сервера, содержащего зону. После него следует адрес технического контактного лица, отвечающего за домен. Обратите особое внимание на точки в конце этих адресов! Точка в конце означает, что этот адрес является обычным доменным именем, и его не нужно дополнять справа доменом, которому соответствует наш конфигурационный файл. То есть, если вместо ns.radio-msu.net. написать ns.serv, то будет иметься ввиду компьютер ns.serv.radio-msu.net

Точку в конце символьных имен нужно не забывать ставить и в других полях зоны. Это одна из самых распространенных ошибок. Написать "ns.radio-msu.net" - значит, иметь ввиду сервер "ns.radio-msu.net.radio-msu.net", которого просто не существует.

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

Первое число ("1998022300" у нас) - сериальный номер (serial number) записи. По изменению сериального номера secondary name-сервера определяют, было ли изменено содержимое домена или нет, и соответственно, нужно ли считывать весь домен с primary-сервера. Сериальный номер должен состоять из десяти цифр и обязательно должен быть заменен вручную на какой-либо больший при любом измеении любой записи в файле домена. Для этих целей идеально подходит такой вариант: первые четыре цифры serial'а - год, затем две на месяц и число. Последние две - порядковый номер (начиная с 00) редакции в течение дня. Если мы меняем конфигурацию домена, то заодно мы должны увеличить и сериальный номер. А при таком задании serial'а увеличение происходит автоматом.

После сериального номера идет поле Refresh, которое указывает время в секундах, по истечении которого secondary name-сервер проверяет не изменилась ли данная зона на primary-сервере, и если изменения были, то происходит передача файла с зоной.

Если при этом у него не получилось по каким-либо причинам соединиться с сервером, то следующую попытку secondary сделает по истечении Retry секунд (третий параметр).

В том случае, если и последующие попытки подключиться к primary и узнать информацию о зоне оканчиваются неудачей, вторичный name-сервер по прошествии Expire секунд забудет всю информацию по этой зоне.

Последнее поле ('Minimum TTL') указывает на минимальное время жизни (Time To Live) записей в файле зоны, если только в какой-то записи не будет указано другое значение в необязательном поле opt_ttl.

Рекомендуемые значения для этих величин таковы:


 28800  ; Refresh     8 hours
 7200   ; Retry       2 hours
 604800 ; Expire      7 days
 86400  ; Minimum TTL 1 day

Однако вам никто не вправе помешать поставить свои значения. Только не ставьте слишком маленькие величины (меньше часа) - иначе вы просто забьете сеть бесполезной информацией, непрерывно пересылаемой от primary к secondary.

Теперь рассмотри записи следующего типа:

NS - (Name Server) - перечисляет name-сервера (и primary, и secondary), которые держат эту зону. Не забывайте про точку в конце имени!


                IN      NS              ns.radio-msu.net.
                        NS              mskws.desy.de.

Здесь мы для зоны .radio-msu.net указали два name-сервера (первый из них - primary, второй - secondary), на которых содержится вся информация о домене.

Далее идет одна из наиболее часто встречающихся записей DNS:

A - (Address) - адрес хоста. На первом месте в такой строке будет стоять символьное имя компьютера в текущем домене, после этого "IN A", а затем - числовой IP-адрес, соответствующий этой машине. Рекомендуется внести, например, такую строку в файл зоны:

 
localhost       IN      A               127.0.0.1

Это позволит обращаться с любого компьютера в сети к самому себе, используя зарезервированное имя localhost. Для того, чтобы как-нибудь назвать новый компьютер в сети, вам нужно просто добавить такую строчку в файл зоны (не забудьте только после этого подправить сериальный номер в записи SOA и после всех изменений перезапустить демон named (сделать ему kill -1)).

В рассмотренном примере мы видим такие строки:


ns              IN      A               193.124.134.1
telion          IN      A               193.124.134.2
diana           IN      A               193.124.134.7

Значит, мы назвали компьютеры с соответствующими IP-адресами именами ns,telion и diana. Очень часто используется имя www, которое позволяет обращаться к web-серверу домена. Если бы мы изменили здесь слово 'telion' на 'www', то по адресу http://www.radio-msu.net/ откликнулась машина с IP-адресом 193.124.134.2. В нашем случае, можно поступить более хитрым образом, используя запись типа CNAME.

CNAME - (Canonical name) - в транслитерации с латинского, на компьютерном жаргоне такая запись называется алиас (alias). Вы как бы добавляете компьютеру еще одно имя, которое при разрешении превратится в тот же IP-адрес, что и основное имя.


www             IN      CNAME   telion

Теперь имя www.radio-msu.net будет аналогично telion.radio-msu.net. Алиасов для одного IP-адреса может быть сколько угодно, но на них накладывается единственное условие: то имя (каноническое), которое стоит после CNAME, должно также где-либо быть описанным. Допускается использовать в качестве канонического имени и alias, лишь бы такая цепочка алиасов не замыкалась. В качестве cname может выступать любой именной адрес в сети, не обязательно из текущего домена, например:


other           IN      CNAME   www.sun.com.

И пойдя теперь по адресу other.radio-msu.net, мы попадем на сервер Sun Microsystems.

Заметим еще один момент. Второе имя компьютеру можно дать и так:


mail                    IN      A       193.124.134.3
relay                   IN      A       193.124.134.3

При этом у нас будет несколько записей типа 'A', соответствующих одному IP-адресу. Это ничему не противоречит, но так делать - плохой стиль.

Следующий важный тип записей - записи типа MX.

MX - (Mail eXchange) - пересылка почтовых сообщений. Они обычно следуют за записями типа 'A' или 'SOA'. Используются они обычно так:

[domain] IN MX [pref_value] [mail_server]

где domain - необязательное поле. Если оно есть, то запись онтосится к этому домену, если нет - то к предыдущему с типом 'A'. В том случае, если на месте [domain] стоит символ '@' или это поле отсутствует, но сама запись находится в самом начале файла зоны (сразу же после SOA), то такое поле MX будет относиться к домену, которому соответствует текущий db-файл.

'IN' также можно указывать, а можно опускать. mail_server - доменное имя почтового сервера, которому достанется вся почта, приходящая на этот домен. На этом сервере должны стоять программы, поддерживающие почтовый протокол SMTP. Для повышения надежности пересылки почты, вы можете указать подряд несколько почтовых серверов. В том случае, если один из них перестанет работать, вся почта на домен будет отправляться на эти "запасные" mail-сервера, которые при первой же возможности отправят все накопившиеся у них электронные письма на основной почтовый сервер. Чтобы регулировать такую систему, и вводится параметр pref_value (приоритет соответствующего почтового сервера), который может меняться от 0 (самый большой приоритет) до 32767 (почта на mail-сервер с таким значением pref_value будет приходить в совсем крайнем случае). Если у вас запись MX единственная для какого-то домена, то значение этого поля не играет роли. Но при использовании только одного mail-сервера в те моменты, когда он по каким-либо причинам недоступен, почта будет теряться. Поэтому обыкновенно ставят две-три MX-записи, а приоритеты у них устанавливают круглыми числами от 10 до 100. Пример:


mpr                     IN      A       193.124.134.3
                        MX      10      mpr
                        MX      50      mskws.desy.de.

Итак, почта, идущая на mpr (например, на john@mpr.radio-msu.net), прежде всего попытается лечь на сам mpr, а в том случае, если у нее это не получится, то будет использован второй вариант (50 больше, чем 10) - mskws.desy.de, где почта пролежит до того момента, пока mpr опять не заработает. Зачастую нужно использовать более короткие почтовые адреса, вроде alla@radio-msu.net. Делается это таким образом:


@               IN      MX      20      mpr
                        MX      40      mskws.desy.de.

Ситуация в точности та же. Почта на somebody@radio-msu.net перенаправляется на mpr (или на mskws), а на этих компьютерах уже должны быть корректно настроены почтовые программы, понимающие, на какой домен приходит почта и что с ней надо делать дальше. Для этого вам, к несчастью, придется ознакомиться с соответствующей документацией к почтовому серверу.

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

NULL - пустая запись. Скорее всего, должна использоваться для резервирования доменного имени, но на практике применяется только в том случае, если необходимо убрать на некоторое время из DNS'а запись о какой-то машине. Хотя проще такие строчки просто закомментарить.

RP - (Responsible Person) - ответственное за этот домен лицо:


xerox		IN	RP	Ivanov Ivan

HINFO - (Host Information) - информация о компьютере (тип процессора, операционная система и т.д.). Используется крайне редко.

Нам осталось рассмотреть последний особый тип записи 'PTR' (domain name pointer), эта запись используется в db.* файлах так называемой "обратной зоны" (reverse-dns).
;

Настройка "обратной зоны"

В рассматриваемых до этого примерах мы видели, как установить взаимосвязь между символьными именами и числовыми IP-адресами, но только в одну сторону: от символьных имен к числовым. Доменная система имен должна также обеспечивать обратное преобразование: из числового адреса в строковый. Для этих целей, собственно и служат файлы обратной зоны (Reverse-DNS), структура которых во многом напоминает файлы зон, которые мы рассматривали выше. Для обратных зон также необходимы primary и secondary сервера. В конфигурационном файле named.boot для установки primary name-сервера может быть написана примерно такая строка:


primary  134.124.193.in-addr.arpa  db.193.124.134

Домен 'in-addr.arpa' - служебный. Он используется для обозначения числовых IP-адресов.

Будьте внимательны: при таком способе записи от вашего полного IP адреса из 4-х чисел остаются только первые три, общие для компьютеров внутри вашей локальной сети (или какого-то ее участка). Причем, эти числа меняются местами: так домен 80.67.194.in-addr.arpa будет соответствовать адресам сетки 194.67.80.*.

Secondary name-сервера обратных зон устанавливаются аналогично прямым зонам - в named.boot пишется строка


secondary  100.250.158.in-addr.arpa  158.250.100.1 db.158.250.100

Этой строкой мы установили secondary name-сервер для reverse-зоны IP-адресов сети 158.250.100, а primary name-сервером будет компьютер этой сети с адресом 158.250.100.1.

Обязательной строчкой в named.boot является обратная зона сетки 127.0.0, так как в ней находится IP-адрес 127.0.0.1 (localhost,loopback) - это специальный адрес, при обращении на который с любого компьютера, мы попадаем на него же. Итак, в named.boot должна быть строчка:


primary  0.0.127.IN-ADDR.ARPA  db.local

Большие и маленькие буквы здесь не различаются. А в директории /etc/namedb создадим файл db.local примерно такого содержания (имена доменов вам, естественно, придется поменять на свои):


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;  db.local  -   Local domain configuration
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@        IN      SOA     ns.radio-msu.net.  art.radio-msu.net. (
                 1995101500      ; Serial
                 14400           ; Refresh
                 3600            ; Retry
                 3600000         ; Expire
                 259200 )        ; Minimum ttl
 
         IN      NS      ns.radio-msu.net.
1        IN      PTR     localhost.
;-----------------------------------------------

Итак, вы установили Reverse-DNS для 127.0.0.1. Рассмотрим теперь пример установки обратной зоны для того же домена ('radio-msu.net'). В named.boot primary name-сервера записывается строка:


primary  134.124.193.in-addr.arpa  db.193.124.134

В директории /etc/namedb создаем файл с именем db.193.124.134 для обратной зоны. Здесь, как и в предыдущих ситуациях, само по себе имя большой роли не играет, поэтому можно выбирать его легким для запоминания. Теперь посмотрим на то, что может содержаться в этом файле:


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;     BIND configuration for the primary nameserver  
;             Radio-MSU.NET reverse DNS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@               IN      SOA  ns.radio-msu.net. art.radio-msu.net. (
                        1998022300      ; Serial
                        14400           ; Refresh
                        3600            ; Retry
                        1209600         ; Expire
                        345600 )        ; Minimum ttl
 
                IN      NS      ns.radio-msu.net.
                        NS      mskws.desy.de.
 
0               IN      PTR     Radio-MSU-Ether.Radio-MSU.net.
                        A       255.255.255.0

1               IN      PTR     ns.radio-msu.net.
2               IN      PTR     telion.radio-msu.net.
3               IN      PTR     mpr.radio-msu.net.
5               IN      PTR     vika.radio-msu.net.
7               IN      PTR     diana.radio-msu.net.
20              IN      PTR     brusun.radio-msu.net.
101             IN      PTR     noc.radio-msu.net.
;----------------------------------------------------------------

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

[ip_address #4] IN PTR [имя.домена]

где ip_address #4 - последнее из 4-х чисел IP-адреса (его значения могут быть от 0 до 255). Первые три компоненты задаются для данного файла обратной зоны из named.boot. Запись PTR задает соответствие между IP-адресом и именем домена. Важно отметить, что для правильной работы необходимо соответствие числовых и символьных адресов в прямых и обратных зонах, иначе результат будет непредсказуем.

В файле обратной зоны первой записью стоит запись типа SOA, полностью аналогичная SOA прямой зоны. После этого идет перечисление name-серверов (записи типа NS). И особняком стоит строка для адреса 193.124.134.0, который обозначает весь Ethernet-участок сети. Прописывать нулевой адрес необязательно, но это считается правилом хорошего тона.

Наконец, после всех этих манипуляций ваш сервер готов к работе. Демон named должен запускаться при старте машины. Все изменения в конфигурации должен производить только пользователь root. После каждого изменения не забывайте менять серийные номера в db.* файлах, согласовывать прямые и обратные зоны, перезапускать (kill -1) named.

Комментарии: (0) | Интернет и Сети | 2006-06-03

Основы совместного доступа в интернет для нескольких ПК

Основы совместного доступа в интернет для нескольких ПК

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

Построение локальной сети

Первое что мы сделаем с вашими компьютерами с Windows, это убедимся, все ли они имеют сетевые Ethernet карты и установлен ли на них протокол TCP/IP. Многие игры используют протокол SPX/IPX, лучше деинсталлируйте все протоколы с вашей машины кроме TCP/IP. Установка и удаление протоколов производится через щелчок правой клавишей мыши по значку "Сетевое окружение" (Network Neighborhood) или "Моя сеть" (My Network Places). Далее перейдите в свойства (properties), а потом нажмите правой клавишей на ваше соединение и там тоже выберите свойства. Сейчас вы сможете управлять соединением.

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

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

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

Следующее, что нужно определить: использовать концентратор (hub) или нет. Некоторые говорят: "Почему это я должен использовать какой-то концентратор, если я соединяю две системы друг с другом одним кабелем, и все прекрасно работает?" Хорошо. Во-первых, ваша связь не такая быстрая, какой могла бы быть. Вам придется использовать перекрещенный кабель, который не так хорош с точки зрения скорости и надежности, как обычный CAT 5 кабель плюс концентратор. Во-вторых, при использовании концентратора вы без труда добавите еще некоторое количество компьютеров к вашей сети. А при прямом кабельном соединении вы столкнетесь с проблемами. Поэтому мне больше нравится использовать концентратор даже при соединении всего двух компьютеров. Цены на концентраторы сейчас настолько низки, что на них уже можно не обращать внимание. Также следует отдельно отметить, что лучше покупать даже не концентратор, а коммутатор (switch). Коммутатор намного лучше концентратора, так как он может обрабатывать несколько потоков данных одновременно и может перенаправлять сетевой трафик в зависимости от MAC адреса получателя. Предположим, у нас есть три компьютера. Если первый компьютер общается с третьим, то второй компьютер не сможет передать много трафика. Пакеты на второй компьютер будут передаваться в промежутках между общением 1-го и 3-го. Поэтому, если у вас есть выбор между концентратором и коммутатором, выбирайте второе. Он стоит немного больше, но, поверьте, он того стоит.

Хорошо, предположим, что у вас установлено два компьютера с Windows и протокол TCP/IP. Сейчас необходимо сделать несколько шагов, которые позволят компьютерам увидеть друг друга в сети. Пропуск хотя бы одного шага приведет к неработоспособности сети. Во-первых, убедитесь, что IP адреса компьютеров принадлежат одной подсети. Я обычно использую подсеть 192.168.0.x. Вы можете использовать IP-адрес 192.168.0.10 для первого компьютера, и 192.168.0.20 для второго, маска подсети для них будет 255.255.255.0. Объяснение масок подсетей и адресации TCP/IP выходит за рамки нашей статьи, но вы можете найти интересующую вас информацию сами (посмотрите список литературы в конце статьи). Во-вторых, необходимо убедиться, что обе машины принадлежат одной и той же рабочей группе. Для этого нажмите правой клавишей мыши на "Сетевое окружение", выберите свойства и перейдите на закладку "Идентификация". Назовите свою рабочую группу как-нибудь покруче, но без всяких "левых" символов и не слишком длинно. Далее, назовите ваши компьютеры как-нибудь осмысленно. Эти имена вы будете использовать для связи по сети. После того, как вы все это сделаете, попытайтесь выполнить ping на компьютеры с помощью IP адресов, чтобы удостовериться в работоспособности сети. Следующий шаг не является обязательным, но он весьма полезен. Нажмите клавишу "Пуск" и попробуйте поискать на жестком диске файл hosts. Вы найдете его в каталоге /drivers/etc, и, скорее всего, он будет называться hosts.sam. Откройте его с помощью Блокнота (Notepad) и добавьте в него имена ваших компьютеров и их IP адреса, как показано в примере в этом же файле. (Данная операция имеет смысл только при присвоении статических адресов вашим компьютерам. Но это все равно не помешает запуску DHCP, если вы будете его использовать, так что не беспокойтесь). Сохраните измененный файл без расширения (то есть уберите .sam). Сейчас у вас есть файл узлов, который будет использоваться для разрешения имен совместно с DNS сервером. Вы можете произвести ping на свои любимые сайты, получить их IP адрес и добавить его под каким-нибудь коротким именем в файл hosts. После этого вы сможете обращаться к сайту по этому имени. Но самое важное: вы сейчас можете производить ping компьютеров в локальной сети по имени, а не по IP адресу. Сейчас произведите ping машин по тем именам, которые вы ввели в файл.

Отлично, вы установили сеть. Пришло время настроить соединение с интернетом.

Среди вас будут и те, кто не приобрел маршрутизатор по каким-либо причинам. Я сам был таким же некоторое время и решал свои проблемы с помощью Windows Internet Connection Sharing, ICS ("Общий доступ к подключению интернета" в русской версии, прим. переводчика). Самое главное, что здесь следует запомнить: одна из машин выделяется под соединение, и если ее выключить, все остальные компьютеры останутся без интернета. На самом деле, ICS является разновидностью NAT (Network Address Translation, перевод сетевых адресов), в том смысле, что она использует компьютер для раздачи динамических адресов другим машинам подобно DHCP серверу. Узловой компьютер, который осуществляет связь с интернетом, имеет настоящий IP адрес, а все остальные машины получают "левый" IP адрес. По умолчанию MS использует для ICS подсеть 192.168.0.x, где 192.168.0.1 является узловым компьютерам, а все остальные адреса подсети раздаются другим машинам. В общем, после установки ICS на ваш компьютер, подключенный к интернету, его сетевой карте будет присвоен адрес 192.168.0.1, а всем остальным компьютерам в сети нужно будет указать на получение своих адресов с DHCP ("получать адрес автоматически" в свойствах TCP/IP, прим. переводчика).

Windows ICS входит в состав Windows 98, Windows ME и Windows 2000. Она также будет поставляться и с будущей версией Windows XP.

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

Используем маршрутизатор

Хотя ICS и может разделять соединение с интернетом на другие компьютеры, по указанным выше причинам это не лучший метод. По возможности, следует купить и настроить домашний маршрутизатор для разделения соединения с интернетом. Как было сказано выше, мы рекомендуем использовать Netgear RT314. У него есть свой форум поддержки на dslreports.com, и довольно обширное общество энтузиастов, которые могут вам настроить устройство для максимальной безопасности и производительности.

RT314 (мы будем использовать эту модель для примера, хотя и Lynksys тоже очень на него похож) имеет два интерфейса управления, Telnet и Web, но также может использовать и соединение по COM порту, если у вас есть кабель и вам это нужно. Мы предпочитаем использовать Telnet для управления, а Web использовать только для первоначальной настройки. После приобретения маршрутизатора, вы легко выполните физическую установку и подключите его к вашему широкополосному (broadband) подключению (в России это, как правило, или выделенная линия, или ISDN. Прим. переводчика). Большинство маршрутизаторов не поддерживают доступ по коммутируемой линии (dial-up). Далее следует получить информацию о соединении от вашего провайдера и ввести ее через Web-интерфейс маршрутизатора по адресу http://routersdefaultaddress, скорее всего это 192.168.0.1 или 192.168.1.1. После этого выполните соединение через Telnet с вашим маршрутизатором и произведите необходимую настройку. Большинство настроек относятся к усилению безопасности и производятся через модификацию фильтров брандмауэра/firewall.

Очень полезно будет сделать DNS запись для вашего маршрутизатора в файле hosts. Выберите крутое имя и добавьте в файл hosts строку следующего вида:


192.168.0.1 Fw

Таким образом, когда вы набираете fw в строке адреса вашего браузера, вы попадаете на Web-интерфейс маршрутизатора. Также вы сможете в командной строке набрать "telnet fw" и, установив telnet соединение, вы получите запрос на ввод пароля. Ну, или вы сможете проверить доступность маршрутизатора, выполнив "ping fw". Сейчас давайте обсудим некоторые вопросы, связанные с безопасностью. Вы набираете 192.168.x.x изнутри вашей сетки, и попадаете на Web-интерфейс маршрутизатора. Но если вы попытаетесь сделать то же самое снаружи, вы никуда не попадете. Этот IP адрес является "левым" и он присваивается внутреннему интерфейсу маршрутизатора. Когда вы попытаетесь получить доступ к маршрутизатору, вы его не получите. Уже введенные по умолчанию фильтры блокируют web, telnet и ftp порты по умолчанию. Это очень хорошо: вы же не хотите, чтобы весь интернет ломился к интерфейсу управления вашего маршрутизатора, даже если у вас там длинный пароль? Да, и обязательно поменяйте свой пароль. В следующей статье, мы, возможно, более детально рассмотрим этот вопрос. Но общеизвестно, что очень многие хакеры проникает в системы через пустые, или принятые по умолчанию пароли. Убедитесь, что вы поменяли пароль прежде чем выходить в интернет.

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

Итак, вы уже все установили, осталось произвести только окончательные настройки. Вы можете посмотреть сетевую статистику на маршрутизаторе через Telnet или Web-интерфейс. Да, там вы сможете оценить, насколько быстр RT314. На самом деле он является не только маршрутизатором, но еще и коммутатором. Вы можете играться, скачивать файлы и читать почту в одно и то же время, и вы никогда не увидите перегрузки (коллизии). Я никогда еще не наблюдал ее на своей сети. Под окончательными настройками я подразумеваю скачивание улучшенных фильтров и прошивок маршрутизатора. Все это можно получить на www.dslreports.com, и там же вы сможете завести персональную учетную запись. Все это бесплатно, и этот сайт великолепен с точки зрения поддержки маршрутизатора, поэтому я его вам и рекомендую. Там вы сможете просмотреть форумы и найти форум, посвященный Netgear. Посмотрите ответ на ваш вопрос в предыдущих сообщениях, прежде чем его задавать. Скорее всего, кто-то уже решал возникшую у вас проблему. Прошивки маршрутизатора также можно скачать на этом сайте.

От переводчика: В качестве главного сервера я рекомендую использовать Windows 2000 Server. Там вы легко сможете настроить DHCP и DNS (и не придется прописывать файл hosts). Все это не так сложно как кажется. Если возникают вопросы: купите книжку из списка литературы. Если вы не будете использовать внешнего маршрутизатора, установка Windows 2000 все равно предпочтительнее, так как там можно использовать различные фильтры пакетов. А Windows 98/Me лучше в интернет вообще не выставлять, это система не для работы, а для игрушек. IMHO.

Источник: www.3dnews.ru

Комментарии: (0) | Интернет и Сети | 2006-06-05

Регистрация в DMOZ aka The Open Directory Project (ODP)

Регистрация в DMOZ aka The Open Directory Project (ODP)

Автор: Фил Крэвин
www.webworkshop.net

Перевод: Webmasterpro

Добавление сайта в Open Directory может оказаться затруднительным. Известно, что присутствие сайта в DMOZ повышает рейтинг в поиске Google, но процесс регистрации может длиться очень долго. В этой статье я объясню, почему регистрация часто занимает много времени и что нужно делать, когда заявка на добавление является причиной задержки. Но сперва я объясню, что такое DMOZ и почему стоит обратить на него внимание.

DMOZ (от Directory Mozilla, еще известен как The Open Directory Project (ODP)) — большой, разбитый по категориям каталог сайтов, который поддерживается добровольцами. Каждый сайт или страница просматривается вручную перед добавлением в каталог. Регистрация бесплатна. На самом деле немного людей используют DMOZ для поиска в той же мере как Yahoo!, поэтому каталог сам по себе является слабым трафикогенератором. Однако его базой можно воспользоваться в целях создания собственного каталога сайтов. Одним из крупных сайтов, использующих DMOZ, является Google. Фактически, каталог Google не что иное как загруженный DMOZ'овский каталог.

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

Внесение в DMOZ создает две важных ссылки на сайт — одну из DMOZ (Google сканирует DMOZ точно так же как любой другой сайт) и одну из каталога Google. Обе обычно имеют приличный PageRank. Теперь, добавив сюда ссылки на тысячах маленьких сайтов, которые загрузили и используют каталог DMOZ, вы поймете, почему весьма выгодно для сайта быть внесенным в DMOZ. Простое внесение в DMOZ может поднять значение Toolbar PageRank от 3 до 4, и даже от 4 до 5.

Почему регистрация в DMOZ занимает много времени?

Во время написания статьи, главная страница DMOZ заявляла о наличии 57,251 модератора (добровольцев, которые просматривают и добавляют сайты в каталог), но это не совсем правильная цифра. На самом деле у них нет столько модераторов, даже близко к этому. Это число — общее количество модераторов с момента старта проекта. Большинство из них больше не работают. Существенная часть тех, которые еще являются модераторами, неактивны или редко проявляют активность. Так что число модераторов, активно рассматривающих и добавляющих сайты, относительно мало.

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

Представьте как кто-то подает заявку на внесение сайта в категорию, которая является близкой по его содержанию, но сайт на самом деле принадлежит к другой категории. Что случится? Заявка ожидает в очереди категории, на которую представлена заявка. Рано или поздно наступает ее очередь, и модератор находит, что сайт принадлежит к другой категории. Этот модератор не может редактировать другую категорию, так что заявка будет передана к другой категории и добавлена в очередь. Заявка не пойдет вне очереди из-за того только, что уже ждала в другой. В конечном счете наступит снова ее черед и она будет рассмотрена заново. Это — простая последовательность событий, когда сайт представлен к неправильной категории. На практике, тем не менее, часто случается по-иному.

Когда первый модератор рассматривает сайт, часто в прошествии долгого времени после подачи заявки, и находит, что он не принадлежит в категории, что он (она) может подумать? «Если Вы не побеспокоились найти правильную категорию для сайта, не буду этого делать и я». Так что сайт часто отсылается к категории, которая является более близкой, но совсем не обязательно к нужной. Новый модератор в конечном счете добирается до него и посылает его к более соответствующей категории — возможно на этот раз к нужной, а может и нет. Задержки прибавляются только из-за того, что вебмастер, подавший заявку на внесение сайта, не уделил достаточно времени на выбор нужной категории.

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

Почему некоторые сайты получают отказ?

Политика DMOZ — рассмотррение сайтов, которые имеют уникальное содержание. Это означает, что много сайтов не соответствуют требованиям: среди сайтов, которые могут быть отклонены — те, у которых слишком много места занимает контент от сайтов-партнеров. Некоторое содержание такой информации приемлемо, но когда она занимает много места на сайте, то он вероятно будет отклонен.

Другая причина отказа — из-за заявки. Если Title (заголовок) и Description (описание), заполняемые при регистрации не соответствуют рекомендациям DMOZ, то некоторые модераторы склонны считать так: «если Вы не уделяете небольшое время на это, почему же я должен беспокоиться и переписывать это за Вас?», и отклоняют заявку. Лично, я нахожу трудным поверить, что модераторы сделали бы это, но я слышал о таких случаях. Так что читайте и следуйте рекомендациям при заявке сайта. Описание предназначено для того, чтобы дать людям понять, что может быть найдено на сайте, а не для раскрутки.

Людей не уведомляют об отклонении их сайтов, и многие думают, что их заявки все еще ожидают своей очереди, хотя на самом деле они уже отклонены. Есть только один способ узнать состояние заявки — заставить кого-то на той стороне сообщить это Вам. К счастью, есть место, где Вы можете сделать это. Это — Open Directory Public Forum, который поддерживается некоторыми модераторами. Они помогают в выяснении состояния дел в процессе внесения сайта. Если сайт был отклонен, они сообщат вам и скорее всего укажут причину. Иногда модераторы могут даже рассмотреть сильно просроченную заявку, но только если определенная категория не имеет модератора, или он не подает никаких признаков выполнения своих обязанностей на протяжении значительного времени.

О модераторах DMOZ

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

06.11.2003

Комментарии: (0) | Интернет и Сети | 2006-06-04


Страница 1 из 212 »