авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Государственное образовательное учреждение высшего профессионального образования «Пензенский ...»

-- [ Страница 4 ] --

Подобно хосту 192.168.10.4/24, хост 192.168.20.4/24 имеет один реаль ный сетевой интерфейс, но для корректного функционирования ему необ ходим дополнительный маршрут, поскольку хост имеет прямое соединение сразу с двумя маршрутизаторами. Трафик сети 192.168.20.0 должен прохо дить через маршрутизатор Rl, а весь остальной трафик – направляться в Internet через хост R2;

поэтому таблица маршрутов хоста 192.168.20.4/ имеет вид (рис. 4.7):

Рис. 4. Можно сконфигурировать хост 192.168.20.4/24 так, чтобы изначально он «знал» только об одном шлюзе, полагаясь на помощь директив переад ресации протокола ICMP для устранения избыточных переходов. Ниже показан пример начальной конфигурации (рис. 4.8):

Рис. 4. Теперь, если хост 192.168.20.4/24 посылает пакет хосту 192.168.20.4/24, прямой маршрут найден не будет, и пакет отправится на хост R2. Поскольку хост R2 является маршрутизатором, он имеет полную информацию о состоянии сети и, следовательно, «знает» о роли хоста Rl, куда и будет послан пакет. Кроме того, маршрутизатор R2 обнаружит, что хосты Rl и 192.168.20.4/24 находятся в одной сети;

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

Некоторые администраторы выбирают для своих систем директивы пе реадресации протокола ICMP в качестве основного «протокола» маршру тизации, думая, что подобный подход обеспечит большую динамичность.

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

Для настройки выхода в Internet подключите и настройте устройство NAT. Для этого сеть Vmnet4 переведите в режим NAT (см. рис. 3.8, 3.9).

Связь устройства NAT с другими машинами проверяется утиллитой ping.

Таким образом, для нормальной работы сети (см. рис. 4.2) внесите со ответствующие изменения в таблицы маршрутов всех рабочих станций и маршрутизаторов и проверьте связь между компьютерами утиллитой ping.

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

4.4. Моделирование службы DNS DNS (Domain Name Service – Служба имен доменов) – пожалуй, наибо лее распространенная служба как в Internet, так и в частных сетях. DNS выполняет преобразование имен систем в их IP-адреса и обратно. Возмож ность такого преобразования обеспечивается иерархической организацией имен, обслуживаемой децентрализованными системами с соответствую щим рограммным обеспечением. Это простая и мощная служба, приме няемая почти повсеместно. К этой службе (косвенно) обращается каждый пользователь Internet. Имена DNS указаны как элементы Web-адресов.

Например, адрес Web-узла http://www.alpha.com/ содержит имя DNS www.alpha.com. Именно это имя преобразуется определенным сервером (или серверами) DNS в IP-адрес. Когда же становится известен IP-адрес, соответствующая Web-страница находится по стеку протоколов TCP/IP.

Имена DNS имеют иерархическую структуру. Компоненты имени раз деляются точками;

те из них, которые располагаются правее, имеют более высокую иерархию. Следовательно, в приведенном выше имени com пред ставляет компонент с наиболее высокой иерархией, alpha.com – на один уровень ниже. Эти две части составляют имя домена. Домен DNS – это набор всех узлов, объединенных общим именем. В данном случае, com – это домен верхнего уровня (TLD), alpha.com – субдомен домена com. Бо лее того, com – пример зарезервированного TLD. Зарезервированные TLD распределяются организациями, ответственными за присвоение имен и номеров в Internet. Обозначить свое присутствие в Internet, зарегистриро вав субдомены наподобие alpha.com, могут компании и частные лица. Для этого необходимо обратиться в соответствующую организацию. Все заре гистрированные субдомены в Internet являются субдоменами определен ных TLD.

Все TLD подразделяются на две категории: TLD общего назначения и коды стран (ccTLD). Примеры TLD общего назначения: com, net и org.

Коды ccTLD назначаются определенным странам и имеют вид: ru, de, uk.

Список ccTLD с указателем соответствующих стран можно загрузить с Web-страницы http://www.iana.org/cctld/cctld-whois.htm Что касается сведений о TLD общего назначения, то их можно найти в Web-узлах IANA и ICANN: http://www.iana.org/ http://www.icann.org/ Следует заметить, что использование TLD регулируется в Internet, но не во внутренних сетях, никак с Internet не связанных. В таких сетях до пускается использование любых имен доменов или субдоменов, если толь ко не требуется преобразование этих имен в адреса Internet. Создание внутренних доменов и субдоменов DNS мы рассмотрим в следующем подразделе.

4.4.1. Иерархия имен доменов Систему имен DNS проще всего представить графически. На рис. 4. показана часть иерархии имен доменов в том виде, как она реализована в Internet. Это именуется деревом DNS.

Темными кружками на рис. 4.9 обозначены домены Internet, кружками c точками внутри – внутренние домены. Т.е. все внутренние домены оказы ваются принадлежащими alpha.com (имя домена выбрано для примера), и здесь существенно лишь то, что они попадают в зависимость от тех, кто управляет субдоменом alpha.com. Домены Internet (темные кружки) име нуются иначе узлами дерева DNS. Каждый узел представляет опреде ленный уровень DNS;

допустимое число этих уровней равно 127. Обратите внимание на узлы дерева, обозначенные как серверы имен. Сервер имен DNS – это система с программным обеспечением, способным отвечать на запросы DNS. Один из таких пакетов программного обеспечения известен как BIND (Служба доменных имен в сети Internet) – наиболее распростра ненный пакет в системах UNIX.

Рис. 4.9. Иерархия имен доменов DNS и серверов доменных имен По запросу DNS происходит преобразование имени в адрес или наобо рот. Мы подробно рассмотрим серверы имен и запросов ниже, а пока за метим, что в каждом домене DNS должен быть как минимум один первич ный, или главный, сервер. Главный сервер DNS ответственен за поддержа ние записей соответствия имен и адресов для некоторого множества узлов, включая модификацию этих записей и добавление новых. Главный сервер DNS может обслуживать несколько доменов. Множество имен, на которые распространяется влияние главного сервера, именуется его зоной ответ ственности. В самом верху рис. 4.9 обозначен безымянный корневой до мен. Этот домен верхнего уровня должен присутствовать в любой реали зации DNS и обычно обозначается точкой (.). Как и все домены, он должен иметь как минимум один главный сервер имен. На практике каждому Internet-домену, включая корневой, так же, как и TLD, для непрерывного и безошибочного функционирования требуется более одного главного сер вера – как, впрочем, и других серверов имен.

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

Теперь рассмотрим хост regis.sales.alpha.com. Записанное таким обра зом имя домена квалифицируется как FQDN (Fully Qualified Domain Name – Полное составное доменное имя). Строго говоря, в FQDN входит также и последняя (справа) точка, хотя обычно она опускается. FQDN с точкой – это абсолютное имя. Вспомним, что иерархическая значимость имен DNS убывает справа налево. Таким образом, com – это TLD, alpha.com – суб домен com, a sales.alpha.com – субдомен alpha.com. Наконец, regis – это хост субдомена sales.alpha.com. Для обращения к этому хосту внутри его собственного домена достаточно указать только его имя (regis);

для обра щения из alpha.com необходимо имя субдомена sales (regis.sales);

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

Хосту regis.sales.alpha.com присвоен IP-адрес 192.29.83.61. DNS со держит записи соответствия имен и IP-адресов хостов, по которым он вы полняет преобразования из одного в другое. Преобразование из FQDN в IP-адрес именуется прямым.. Однако DNS должен выполнять также преобразования из IP-адреса в FQDN, именуемые обратными, для чего используется специальный TLD – in.-addr.arpa, к которому отнесены все адреса IP версии 4. В частности, обратное FQDN для regis.sales.alpha.com имеет вид:

61.83.29.192.in-addr.arpa Необходимо помнить, что иерархическая значимость этих имен убы вает справа налево;

именно для сохранения этого свойства и понадобилось обратное представление FQDN. Вне конфигурационных файлов главных серверов DNS это представление применяется редко.

4.4.2. Имена DNS Формально имя DNS – это последовательность меток, перемежаемых разделителями. Метки представляют собой последовательности текстовых символов, разделителями служат точки. Например, имя домена sales.alphа.соm состоит из последовательности меток sales, alpha и com.

Согласно стандарту RFC 1035, длина метки может составлять до 63 байт, число уровней (длина цепочки меток) – до 127. Каждая метка представляет отдельный уровень. Следовательно, длина имени DNS может достигать (63 х 127) + 126=8126 байт. Число 126 в этой формуле соответствует макси мальному количеству точек, разделяющих метки. Абсолютное имя включает также точку в конце;

поэтому его длина составит 8128 байтов. Впрочем, на практике достижение максимальной длины – будь то метки или всего FQDN – маловероятно.

Все имена хостов проверяются на совместимость со стандартом RFC 952. Этот стандарт ограничивает имена хостов только состоящими из цифро-алфавитных текстовых знаков – то есть a-z, A–Z и 0–9. Разрешен знак минус или черточка («-»). Символ подчеркивания (_) не разрешен.

Эти ограничения были распространены также на FQDN – несмотря на то, что стандарт RFC 952 был разработан до всеобщего принятия DNS.

Проверку соответствия RFC 952 со стороны клиента можно отменить установкой параметра no-check-names в файле /etc/resolv.conf. На сервере это же делается установкой параметра check-names.

Рассмотрим, как разрешаются запросы DNS. Этот процесс схемати чески изображен на рис. 4.10. Схема отображает преобразование FQDN в IP-адрес. Процесс начинается с ввода пользователем системы regis.sales.alpha.com команды regis$ ftp ftp.rs.internic.net (в данном случае – запрос к FTP-серверу).

Для того чтобы команда ftp инициировала инкапсуляцию, необходимо определить адрес хоста ftp.rs.internic.net. Процесс получения IP-адреса для FQDN инициируется самой командой ftp, которая вызывает для этого про цедуру gethostname(3). Эта процедура применяет для разрешения имени разнообразные методы, в зависимости от настроек системы. Если одним из методов оказывается DNS, инициируется распознаватель DNS для гене рирования запроса к серверу имен. Распознаватель DNS – это, фактиче ски, набор программ обработки DNS-запросов и ответов.

Рис. 4.10. Типичный DNS-запрос На рис. 4.10 этот запрос обозначен стрелкой с меткой 1. Когда хосту regis.sales.sgi.com потребовалось разрешить FQDN ftp.rs.internic.net, он отправил соответствующий DNS-запрос серверу имен ns.sales. sgi.com до мена sales. sgi.com. Такие запросы именуются рекурсивными. В ответ на рекурсивный запрос сервер имен должен ответить возвратом IP-адреса или сообщения об ошибке.

Сервер имен ns.sales.alpha.com, получив запрос, выполняет поиск в ба зе данных и кэше. Любой сервер DNS может иметь базу данных хостов и, кроме того, поддерживать некоторое количество свежих записей пар имен хостов и IP-адресов в DNS-кэше. Если ns.sales.alpha.com не находит у себя нужной записи, он посылает запрос другому серверу. Эта операция – запрос сервера имен ns.sales. sgi.com к серверу имен ns. sgi.com, обслу живающему сервер sgi.com, – помечена на рис. 4.10 цифрой 2.

Сервер имен ns. sgi.com повторяет эту процедуру, также проверяя базу данных и кэш, а затем, в случае неудачного поиска, передает запрос сле дующему серверу. Однако в этом случае ns. sgi.com посылает итератив ный запрос некоторому серверу в домене com (операция 3 на рис. 4.10).

Итеративный запрос предполагает, что сервер имен, получивший его, должен ответить (если сумеет) или передать этот запрос другому серверу.

Итеративные запросы преобладают в Internet ввиду их эффективности.

Например, в операции 3 на рис.4.10 ns. sgi.com посылает запрос серверу имен в домене com и получает ответ с предложением обратиться к серверу имен в домене net (операция 4). Сервер имен домена net, в свою очередь, предлагает серверу ns. sgi.com обратиться к ns.internic.net, что тот и делает (операция 5). Далее ns.internic.net определяет IP-адрес хоста ftp.ns.internic.net, и ftp. sgi.com передает этот адрес серверу имен ns.sales.

sgi.com (операция 6). Наконец, ns.sales. sgi.com отвечает на исходный запрос и передает полученный IP-адрес хосту regis.sales. sgi.com. Следует заметить, что каждый из серверов, участвовавших в этой цепочке, запи сывает полученную информацию на некоторое время в свой кэш (выде ленную область памяти), так что последующее обращение к этому же хосту не потребует повторения всей процедуры. Как уже было сказано, при разрешении имени или адреса сервер просматривает как базу данных, так и кэш. Следует иметь в виду, что если ns.internic.net является авторитет ным сервером для ftp.rs.internic.net, то и полученный от него ответ име нуется авторитетным. Если же ответ исходит от другого сервера (напри мер, он записан в кэше), этот ответ неавторитетный. Подавляющее боль шинство DNS-ответов в Internet – неавторитетные, поскольку получение авторитетного ответа связано с дополнительными затратами времени и по лосы пропускания.

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

4.5. Типы и конфигурационные файлы DNS-серверов Существует ряд типов DNS-серверов. Выше мы уже рассмотрели один из них – главный DNS-сервер. В табл. 4.1 дано уточненное определение этого сервера, а также двух других типов – подчиненного и кэширующего;

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

Таблица 4. Основные типы систем DNS Тип DNS Описание Главный Главный DNS-сервер – это система, содержащая базу дан сервер ных официально утвержденных пар имен и адресов хостов и иной информации об обслуживаемых системах. Эта система способна давать авторитетные ответы на запросы о систе мах, внесенных в ее базу данных и, следовательно, отне сенных к ее зоне ответственности. Каждый DNS-домен об служивается как минимум одним главным сервером. Глав ный сервер безымянного корневого домена именуется кор невым главным сервером Подчиненный Подчиненный сервер идентичен главному во всем, за исклю сервер чением зоны ответственности, которая не определяется его собственной базой данных, а задается главным сервером. Под чиненные серверы служат для подстраховки главного в случае его останова, а также используются как вспомогательные для повышения производительности. Наличие подчиненных сер веров не обязательно, но чаще всего желательно. Иногда под чиненные серверы именуют вторичными Кэширующий Кэширующим называется сервер, не обладающий базой дан сервер ных – будь то собственной или полученной от другого сервера. Кэширующий сервер выполняет запросы для клиентов и помещает ответы в собственный кэш, со вре менем накапливая значительный объем данных. Главное назначение кэширующего сервера – повышение произво дительности Клиент Клиентом DNS называется любая система, принимающая участие в процедуре DNS. Клиент делает запросы, но не возвращает ответов. Как правило, на клиентах не за пускаются никакие службы, однако здесь следует принять во внимание, что любой сервер может действовать также и в качестве клиента. Кроме того, вполне возможна установка кэширующего сервера, который будет отвечать только на за просы, генерированные им самим, – иногда это приходится делать в разветвленных многопользовательских системах.

На каждом DNS-сервере, независимо от типа, должен запускаться демон BIND с именем named. Этот демон, если его инициировать, считывает конфигурационный файл (по умолчанию, /etc/named.conf) и переходит в фоновый режим прослушивания DNS-запросов, поступающих на порт 53 (по умолчанию). Существует ряд команд и сценариев, связан ных со службой named и относящихся к программному обеспечению BIND. Мы рассмотрим их позже.

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

Таблица 4. Файлы DNS Файл Описание 1 /etc/nsswitch.conf Определяет службы, используемые для разрешения раз личных системных ресурсов – имен хостов, учетных записей пользователей, сетевых служб. DNS должен быть указан здесь как один из способов разрешения имен хостов, иначе BIND не будет инициирован для боль шинства приложений /etc/named.conf Главный конфигурационный файл серверов BIND Файл подсказок Содержит список DNS-серверов. Сервер, на котором этот файл расположен, может, не найдя решения у себя, инициировать итеративный запрос Зонный файл Содержит базу данных для преобразования имен хостов в IP-адреса Обратный Содержит базу данных для преобразования IP-адресов в зонный файл имена хостов Обратный файл Содержит записи, необходимые для преобразования loopback IP-адреса 127.0.0.1 в интерфейс loopback localhost. По су ществу, это обратный зонный файл /etc/resolv.conf Содержит информацию, необходимую для создания и передачи DNS-запросов, в том числе IP-адреса серверов имен Чтобы избежать путаницы относительно того, какой файл необходим какому серверу, в табл. 4.3 приведено сопоставление этих файлов и серве ров различных типов. Описание синтаксиса записей каждого файла можно найти, используя ссылки, приведенные в подразд. 4.5.1.

Таблица 4. Сопоставление файлов и систем DNS Главный Подчиненный Кэширующий Клиент сервер сервер сервер /etc/nsswitch.conf Обязателен Обязателен Обязателен Обязателен /etc/named. conf Обязателен Обязателен Обязателен Отсутствует Файл подсказок Обязателен Обязателен Обязателен Отсутствует Зонный файл Обязателен Копируется Отсутствует Отсутствует с главного Обратный Обязателен Копируется Отсутствует Отсутствует зонный файл с главного Обратный файл Обязателен Обязателен Обязателен Отсутствует loopback /etc/resolv.conf Рекомендован Рекомендован Рекомендован Обязателен 4.5.1. Программное обеспечение BIND Программное обеспечение BIND – это реализация DNS в соответствии со стандартами, описанными в различных документах RFC.

4.5.2. Компоненты пакета BIND В пакет BIND входят три компонента:

демон сервера имен named, отвечающий на запросы;

библиотечные функции, контактирующие с серверами распределен ной базы данных DNS;

утилиты nslookup, dig, host, позволяющие выполнять DNS-запросы из командной строки.

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

4.5.3. Демон named: сервер имен пакета BIND Демон named отвечает на запросы об именах и IP-адресах компью теров. Если демону неизвестен ответ на какой-нибудь запрос, он опраши вает другие серверы и помещает результаты их ответов в кэш. Кроме того, демон осуществляет так называемые зонные пересылки, копируя данные между серверами домена. (Зона – это домен без поддоменов. Серверы имен работают именно с зонами, но часто говорится «домен», хотя на самом деле подразумевается «зона».).

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

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

Таблица 4. Классификация серверов имен Тип сервера Описание 1 Авторитетный Официальный представитель зоны (authoritative) Главный (master) Основное хранилище данных зоны, берет инфор мацию из дискового файла Подчиненный (slave) Копирует данные с главного сервера Усеченный (stub) Напоминает подчиненный сервер, но копирует дан ные только о серверах имен (записи NS) Внутренний Сервер, доступный только в пределах домена* (так (distribution) же называется невидимым сервером) Неавторитетный** Отвечает на запросы, пользуясь данными из кэша;

не (nonauthontative) «знает», являются ли эти данные корректными Кэширующий Кэширует данные, полученные от предыдущих за (caching) просов, обычно не имеет локальных зон Переадресующий Выполняет запросы от имени многих клиентов, фор (forwarder) мирует большой кэш Рекурсивный Осуществляет запросы от имени клиента до тех пор, (recursive) пока не будет найден ответ Нерекурсивный Отсылает клиента к другому серверу, если не может (nonrecursive) получить ответ на запрос * Внутренний сервер доступен любому, кто знает его IP-адрес.

** Строго говоря, атрибут «неавторитетный» относится к ответу на DNS-запрос, а не к самому серверу.

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

4.5.4. Функции распознавания имен Клиенты ищут соответствия между именами компьютеров и их IP-адресами, вызывая библиотечную функцию gethostbyname. Для того чтобы такую информацию выдавала система DNS, функция должна делать запросы к модулю распознавания (распознавателю), который знает, как на ходить серверы имен и взаимодействовать с ними. Распознаватель обычно интегрируется в стандартные библиотеки, которые будут использоваться при компиляции приложений.

В большинстве систем функция gethostbyname может черпать инфор мацию из нескольких источников: обычных файлов (например, /etc/hosts), DNS и даже локальной административной СУБД наподобие NIS. Файл «переключения служб» позволяет осуществлять четкий административный контроль над тем, какие источники опрашиваются и в каком порядке.

Сетевые приложения обычно работают с усеченной библиотекой рас познавателя, посылающей DNS-запросы локальному кэшированному DNS-серверу.

4.5.5. Выполнение запросов из командной строки В пакет BIND входят утилиты dig, host и nslookup, позволяющие выполнять DNS-запросы в режиме командной строки. Они используются при отладке и для извлечения информации из базы данных DNS. Все эти утилиты обладают сходными функциональными возможностями, но реали зованы по-разному.

4.6. Установка DNS-сервера 4.6.1. Настройка сетевых параметров Поскольку DNS-сервер очень сильно связан со всей сетевой инфра структурой, его работоспособность зависит от правильной конфигурации сети. В современных дистрибутивах, если вы выбрали соответствующий тип установки, конфигурирование сетевых параметров производится ав томатически – с помощью DHCP-сервера. При выключенном DHCP-сервере все сетевые настройки следует проводить вручную. Разработчик дистри бутива рассчитывает на абстрактную среднестатистическую систему, кото рой, как показывает практика, не существует. Поэтому следует убедиться, что с сетевыми настройками у вас все в порядке, вследствие чего рас смотрим основные файлы, отвечающие за конфигурацию сети. Просмотр и редактирование файлов можно осуществить с помощью файлового ме неджера Midnight Commander, который запускается командой mc. По умолчанию Midnight Commander при инсталляции системы не устанавли вается;

поэтому его следует инсталлировать с помощью утилиты yast2, которая запускается командой # yast.

4.6.2. Файл /etc/hosts Вам необходим способ отображения имен хостов на IР-адреса. Обычно это делается с помощью сервера DNS, но он еще не настроен. А между тем, вы можете обеспечить отображение тех хостов, которые вам известны, используя для этого файл /etc/hosts. В этом файле должны находиться пары «IР-адрес – имя»:

127 0.0.1 localhost localhost.localdomain 192.168.0.1 user 192.168.0.2 user Причем обязательно должна присутствовать следующая строка:

127.0.0.1 localhost localhost.localdomain Этот файл позволяет делать преобразование «имя – IР-адрес» без обращений к DNS-серверу, что обычно используется в небольших локаль ных сетях. Этот файл просматривается перед любыми запросами к DNS, поэтому он работает одновременно как запасной DNS (когда настоящий недоступен) и как его переопределение (если DNS предоставляет недосто верную информацию).

Отредактируйте файл так, чтобы в нем находились пары «IР-адрес – имя рабочих станций», имеющихся в ваших сетях!

После этого следует проверить правильность редактирования файлов /etc/host.conf и /etc/hosts командой ping, заменяя IР-адреса рабочих стан ций, имеющихся в вашей сети, на их имена.

4.6.3. Файл etc/host.conf Этот файл предназначен для того, чтобы система могла определить, каким образом она будет получать информацию об именах и IP-адресах.

Следующая запись в файле host.conf означает, что при поиске хостов сна чала произойдет обращение к /etc/hosts рабочей станции, а только потом к DNS-серверу:

order hosts, bind Запись должна быть именно такая, поскольку возможен случай, что по какой-либо причине нет доступа к DNS-серверу (например, он еще не запущен), а уже есть необходимость воспользоваться сетью. Обычно этот файл в редактировании не нуждается. В данном случае на первом месте находится файл /etc/hosts, и только после этого будет запущена команда bind для выполнения запроса к DNS-серверу. Что это дает? А то, что можно увеличить скорость доступа к основным серверам. Допустим, что вы каждый день посещаете сайт http://www.redhat.com/, при этом каждый раз происходит запрос к DNS-серверу, что может служить задержкой перед началом загрузки страницы. Чтобы ускорить этот процесс, можно вручную прописать в файл /etc/hosts следующую запись:

209.132.177.50 www.redhat.com Адрес 209.132.177.50 действительно соответствует сайту www.redhat.com.

Если сайт по каким-либо причинам перестал загружаться, то необхо димо удалить соответствующую запись из файла hosts и с помощью коман ды ping redhat.com проверить связь с сервером сайта, а заодно узнать его адрес. В ответ на эту директиву на экране обязательно отображается реаль ный IP-адрес, с которым происходит обмен эхо-сообщениями. IP-адреса у большинства сайтов изменяются редко;

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

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

Конфигурирование распознавателя. На каждом Linux-компьютере, подключенном к сети, должен находиться файл /etc/resolv.conf со списком DNS-серверов, которым можно посылать запросы. Если хост получает свой IP-адрес и сетевые параметры от DHCP-сервера, этот файл заполня ется автоматически, иначе его нужно редактировать вручную. Формат за писей файла таков:

search имя_домена...

nameserver IP-адрес Может быть указано от одного до трех серверов имен. Приведем пример:

search cs.colorado.edu colorado.edu ee.colorado.edu nameserver 128.138.243.151 ;

ns nameserver 128.138.204.4 ;

piper nameserver 128.138.240.1 ;

anchor Для файла resolv.conf никогда не вводилось понятие комментариев.

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

В строке search приведен список доменов, которые следует опраши вать, если имя компьютера не полностью определено.

Например, когда пользователь вводит команду ssh foo, распознаватель дополняет имя первым доменом в списке (в случае приведенного выше файла resolv.conf – cs.colorado.edu), после чего ищет хост foo.cs.colorado.edu.

Если это имя не найдено, делается попытка найти хост foo.colorado.edu, затем foo.ee.colorado.edu. Количество доменов, которые можно указать в директиве search, как правило, не превышает 6–8.

Серверы имен, указанные в файле resolv.conf, должны быть рекурсив ными, поскольку распознаватель не понимает отсылок. Серверы имен опрашиваются в том порядке, в котором заданы директивы nameserver.

Если первый сервер отвечает на запрос, другие серверы игнорируются. В случае превышения тайм-аута запрос переадресуется следующему серверу.

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

Большинство распознавателей допускает наличие максимум трех сер веров имен. Все остальные просто игнорируются. Если хост сам является сервером имен, он должен быть указан первым в собственном файле resolv.conf. Если не будет указано ни одного сервера имен, значит, речь идет о локальном хосте (на хостах обычно устанавливают кэширующие DNS-серверы, существенно ускоряющие преобразование «имя – IР-ад рес»). Однако в этих ситуациях локальный хост лучше указать явно пер вым в списке:

nameserver 127.0.0. Тестирование распознавателя. После конфигурирования файла /etc/resolv.conf (предполагается, что соединение с локальной сетью уста новлено и функционирует корректно) пользователь может ссылаться на другие компьютеры по именам, а не IP-адресам. Если при обращении к ло кальному компьютеру команда «зависнет», попробуйте найти компьютер по IP-адресу. Успешное завершение такого поиска означает, что в конфи гурации DNS есть ошибка. Убедитесь в том, что IP-адреса серверов имен в файле /etc/resolv.conf правильны, а серверам разрешено обрабатывать запросы из вашей сети. На эти вопросы можно ответить с помощью команд ping, nslookup, dig.

4.6.5. Конфигурирование сервера BIND Как уже отмечалось, каждый компьютер-клиент для связи с другим компьютером по его имени должен с помощью службы DNS получить IР-адрес этого компьютера. Следовательно, эта служба должна быть установлена и соответствующим образом сконфигурирована.

Для функционирования DNS-сервера любого типа на Linux-компью тере необходимо наличие настроенных пакетов: bind и bind-utils. Если их нет в системе, то их можно установить с дистрибутива командой rpm -i имя пакета или с помощью специальной утилиты. В дистрибутивах openSUSE 10.2 -11.2 для этого можно использовать утилиту yast.

Пакет BIND – настоящий пожиратель ресурсов. Его база данных хранится в памяти;

поэтому одновременно с увеличением кэша растет число страниц памяти, занимаемых демоном named. Обратите внимание!

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

Конфигурационные файлы сервера BIND. По стандартам для под держки домена требуется наличие двух DNS-серверов: первичного и вто ричного. Это необходимо для надежности функционирования DNS-служб – если один сервер по каким-то причинам недоступен, то второй берет на себя обслуживание запросов по домену.

А вот стратегии организации DNS для вашего домена firma.ru могут быть различными. Самый простой для администратора, но не самый де шевый, – прописать свой домен на DNS-серверах провайдера. При этом следует учитывать, что некоторые провайдеры прописывают домены клиентов в оба своих сервера, а некоторые – только в первичный либо только во вторичный. Другой вариант – один DNS-сервер настроить у себя, а второй – у кого-то еще. Рассмотрим конфигурирование первичного DNS-сервера на примере.

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

ос тальные файлы представляют собой коллекции отдельных DNS-записей, отформатированных в соответствии со спецификацией DNS.

В конфигурационном файле демона named – named.conf – задается роль (главный, подчиненный или усеченный) сервера и определяется способ, которым сервер должен получать копию данных для каждой зоны, обслуживаемой сервером. Здесь же приводятся всевозможные параметры – как глобальные, связанные с работой самого демона, так и локальные, применяемые только к трафику DNS.

Конфигурационный файл состоит из набора инструкций, каждая из которых оканчивается точкой с запятой. Лексемы разделяются пробель ными символами, к которым относится и символ новой строки. Иногда для группировки лексем применяются фигурные скобки. Формат файла до вольно «хрупкий»: достаточно маленькой ошибки, чтобы все перестало работать. К счастью, в BIND 9 имеются удобные средства проверки син таксиса конфигурационного файла (named-checkconf) и зонных файлов (named-checkzone). Эти утилиты ищут не только синтаксические ошибки, но и очевидные пропуски.

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

/* Это комментарий, который может занимать несколько строк. */ // Весь текст до конца строки является комментарием.

# Весь текст до конца строки является комментарием.

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

в этом случае будут приняты установки по умолчанию. Список поддерживаемых инструкций приведен ниже.

include Подключает внешний файл (например, файл с ключами шифрования, доступный только демону named) options Задает глобальные параметры конфигурации сервера имен, а также установки по умолчанию ас1 Формирует списки управления доступом кеy Определяет параметры аутентификации trusted- keys Задает заранее установленные ключи шифрования server Задает параметры сервера masters Определяет список главных серверов для включения в усеченные и подчиненные зоны logging Устанавливает категории журнальных сообщений и каналы их распространения zone Определяет зону, для которой демон является автори тетным controls Определяет, как утилита ndc будет управлять сервером имен view Определяет представление пространства имен lwres Конфигурирует сервер имен в качестве упрощенного распознавателя 4.6.6. Конфигурирование первичного DNS сервера Рассмотрим конфигурацию первичного DNS-сервера для вымышлен ного домена firma.ru. Главный конфигурационный файл DNS – это файл /etc/named.conf, содержащий ссылки на зонные файлы, представляющие собой базу данных (БД) DNS-сервера.

Файл /etc/named.conf. Для нашего сервера данный файл должен содер жать следующие строки:

options { directory "/var/lib/named ";

};

};

zone ". " IN { type hint;

file "named, ca";

};

zone "localhost" IN { type master;

file "localhost.zone";

};

zone "0.0.127.in-addr.arpa" IN { type master;

file "named.local";

};

zone "firm.ru" IN { type master;

file "firm.ru";

};

// Office LAN zone "firma" IN { type master;

file "firma";

};

zone "0.168.192.in-addr.arpa" IN { type master;

file "firma.rev";

};

Строка directory указывает bind, в каком каталоге искать файлы. Все файлы, используемые впоследствии, будут иметь путь относительно ка талога "/var/lib/named.

Секция zone "." самая важная. Что это за зона в виде точки? В базе данных DNS так обозначается корень, т.е. раздел описывает корневую зо ну. Тип зоны hint, т.е. сервер будет всего лишь хранить ссылки на DNS серверы. Так как это корневая зона, то и ссылки будут на корневые сер веры.

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

dig @rs.internic.net. ns named.ca.

Для работы в сетях без выхода в Internet коррекция этого файла не требуется.

Секция zone "localhost" описывает зону для подсети localhost, является в ней мастером, а файл описания зоны – localhost.zone Секция zone "0.0.127.in-addr.arpa" показывает, что bind также отвеча ет за обратную зону для подсети 127.*.*.*, является в ней мастером, а файл описания зоны – 127.0.0.zone.

Секция zone "firm.ru" определяет, что наш DNS-сервер предназначен для зоны firma.ru и является в ней мастером (другие серверы лишь синхронизируют по нему свои записи по зоне firma.ru), при изменении записей в зоне не извещает другие серверы и использует для описания зоны файл firma.ru.

Секция zone "firma" определяет, что DNS-сервер предназначен для зоны firma, и является в ней мастером, при изменении записей в зоне не извещает другие серверы и использует для описания зоны файл firma (наша локальная сеть), а также не разрешает получать другим DNS-серве рам информацию об этой зоне.

Секция zone "0.168.192.in-addr.arpa" определяет, что DNS-сервер поддерживает реверсную зону 0.168.192.in-addr.arpa, является в ней мастером, при изменении записей в зоне не извещает другие серверы и использует для описания зоны файл firma.rev.

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

Первые не являются частью БД, а предназначены для упрощения ввода записей.

Записи о ресурсах. С каждой зоной в иерархии DNS связан набор записей о ресурсах. Перечень ресурсных записей и их характеристика приведены ниже.

SOA Начало зоны. Содержит административную информацию NS Идентифицирует серверы имен для данного домена А Отображение имени в адрес, составляют основную часть БД PTR Обратный указатель, обеспечивает перевод IP-адресов в имена MX Используется системой электронной почты для более эффективной маршрутизации CNAME Каноническое имя, позволяет назначать узлу дополнитель ные имена SRV Определяют местонахождение служб в пределах домена ТХТ Позволяют добавлять произвольный текст в файл Кроме того, в файлах зон также могут использоваться спе циальные символы @ Обозначает имя текущего домена () Объединяет несколько строк в одну строку * Метасимвол. Может применяться только в имени. Обозна чает все возможные комбинации ;

Строки комментария Рассмотрим более подробно формат основных записей Запись SOA. SOA (Start of authority – начало полномочий) обозначает начало зоны. Зона продолжается до тех пор, пока не встретится другая запись SOA. Наличие SOA указывает на то, что данный сервер DNS является первичным источником информации для данного домена.

Разберем подробнее возможную форму записи для ресурса. Имена узлов приведены для примера и являются вымышленными.

stuff.org. IN SOA first.stuff.org. admni.first.stuff.org. ( 2004123101 ;

Порядковый номер 10800 ;

Период обновления в секундах 3600 ;

Интервал между попытками ;

обновления в секундах 60448 ;

Период устаревания в секундах 7200) ;

Время жизни в секундах Данный файл описывает зону stuff.org. Класс зоны – Internet (IN).

Первичным сервером зоны является сервер first.stuff.org. Адрес электрон ной почты администратора домена admin.first.stuff.org, читать этот адрес надо как admin@first.stuff.org. Следует также обратить внимание на точку в конце строки.

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

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

1) w – неделя;

2) d – дни;

3) h – часы;

4) m – минуты.

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

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

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

Запись NS. Задает сервер имен домена. Обратите внимание на точку в конце записи.

П р и м е р : stuff.org. IN NS first.stuff.org. stuff.org. IN NS second.stuff.org.

Здесь для домена stuff.org. задано два сервера имен: first.stufF.org. и second.stuff.org.

Запись А. Эта запись является основной для БД DNS и отображает имя в IP-адрес. Для каждого сетевого интерфейса существует одна запись А.

Для компьютера может существовать несколько записей, по каждой на один сетевой интерфейс, например:

first.stuff.org. IN A 128.100.241. first.stuff.org. IN A 128.100.241. second.stuff.org.IN A 128.100.241. Здесь первые две записи относятся к одному компьютеру с именем first.stuff.org. и двумя сетевыми картами, имеющими IP-адреса 128.100.241.212 и 128.100.241.213. Третья запись относится ко второму компьютеру second.stuff.org., сетевая карта которого имеет адрес 128.100.241.214.

Запись PTR. Эта запись обеспечивает обратный перевод, то есть пере вод IP-адресов в символьные имена. Точно так же, как и в предыдущем случае, для каждого сетевого интерфейса существует только одна запись PTR. В простейшем случае это записанный наоборот IP-адрес (см. пример записи А) с суффиксом in-addr.arpa.

Пример:

212.241.100.128. in-addr.arpa. IN PTR first.stuff.org.

213.241.100.128. in-addr.arpa. IN PTR first.stuff.org.

214.241.100.128. in-addr.arpa. IN PTR second.stuff.org.

Запись MX. Эта запись используется в электронной почте для более эффективной маршрутизации. Запись MX подменяет адресатов сообщений.

П р и м е р : stuff.org. IN MX 10 first.stuff.org.stuff.org. IN MX second.stuff.org.

Эта запись означает, что вместо сервера почты stuff.org. будут задей ствованы серверы first.stuff.org. и second.stuff.org., 10 и 20 означают приоритет: чем меньше число, тем больше приоритет. Допустимым явля ется диапазон приоритета 0–65535. На практике приоритет используется с шагом 10, чтобы можно было поставить число между 10, 20 и 30, без переписи файла.

Запись CNAME. Каноническое имя позволяет назначать узлу допол нительные имена. Эта запись используется для закрепления за компьюте ром определенных функций.

П р и м е р : www. stuff.org. IN CNAME second.stuff.org.

Здесь узлу second.stuff.org. присвоено каноническое имя www.stuff.org.

Соответственно, при вводе в адресной строке www. stuff.org. вы попадете на узел second.stuff.org.

Запись SRV. Эта запись определяет местонахождение служб в преде лах домена. С помощью этой записи легко менять адреса служб.

Формат записи:

Служба.протокол.имя IN SRV приоритет вес порт сервер Реализован в примере:

http.tcp.www IN SRV 10 0 80 second.stuff.org..

Запись ТХТ. Эта запись задает произвольный текст. Например, IN TXT "Это произвольный текст".

4.6.8. Пример конфигурации собственного домена Файл /etc/named/firma.ru В файле зоны firma.ru содержатся следующие данные:

$TTL @ IN SOA ns.firma.ru. hostmaster.firma.ru. ( 2005020501 28800 7200 604800 86400 ) IN NS ns.firma.ua.

IN NS ns..te.net..ua.

IN NS ns.te.net.Odessa ua.

IN MX 10 firma.firma.ru IN MX 20 relay3.te.net.ua IN A. 195.66.200. ns IN A 195.66.200. www IN CNAME ns firma IN CNAME ns localhost A 127.0.0. ns A 192.168.0. Этот файл зоны содержит 4 записи ресурсов (Resource Records, RR):

SOA – запись SOA (начало полномочий) находится в преамбуле каждого из файлов зон, она должна быть первой записью в файле. Описы вает зону, откуда ее берут (ns.firma.ru), кто отвечает за содержимое зоны (hostmaster@firma.ru);

NS – это RR для сервера имен (Name Server, NS);

MX – запись MX (Mail eXchanger, почтовый сервер) сообщает почто вой системе, куда посылать почту, адресованную любому адресату в домене firma.ru, в нашем случае – серверам firma.firma.ru. или relay3.te.net.ua.

Число перед каждым именем системы – это приоритет записи MX.

Запись ресурса с наименьшим номером (10) – это хост, куда почта должна посылаться в первую очередь. Если происходит ошибка, то почта может быть послана на машину с большим номером и т. д. Таким образом, можно указать несколько почтовых серверов, что поможет вам в случае форс-мажорных обстоятельств не потерять ваши почтовые сообщения;

A – A (Address, адрес) – IP-адрес:

localhost A 127.0.0. ns A 192.168.0. mail A 192.168.0. Эти строки описывают соответствие имен mail и ns в зоне firma.ru их IP-адресам.

Файл /var/named/firma Файл зоны для локальной сети будет иметь следующий вид:

$TTL @ IN SOA ns.firma. hostmaster.firma. ( 2005021402 28800 7200 604800 86400 ) IN NS ns.firma.

IN TXT "firma local domain" IN A 192.168.0. ns IN A 192.168.0. server IN CNAME ns Файл /var/naed/firma.rev Для нормального функционирования DNS-сервера требуется обратная (реверсная) зона, которая дает возможность DNS преобразовывать IP адреса в имена хостов. Эти имена используются серверами различного рода (FTP, IRC и т.п.). Поэтому обратная зона требуется для полного доступа к различным службам в Интернете.

Файл реверсной зоны для локальной сети имеет следующий вид:

$TTL @ IN SOA ns.firma. hostmaster.firma. ( 2003122401 36000 3600 720000 86400 ) IN NS ns.firma.

1 IN PTR ns.firma.

Вот, собственно, и все. Перезапускаем DNS-сервер и проверяем правильность функционирования нашей системы.

4.6.9. Настройка вторичного DNS сервера Cервер может быть одновременно первичным и вторичным DNS-сервером для разных зон. Предположим, что требуется вторичный DNS-сервер для домена, к примеру, cdfree.ru. Рассмотрим, что необходимо для этого сделать.

Файл /etc/named.conf В этом файле для домена cdfree.ru появится такая запись:

// Secondary * zone "cdfree.ru" IN { type slave;

masters { 195.108.80.22;

};

file "cdfree.ru";

Тип DNS-сервера определяется строкой type slave;

– (подчиненный, вторичный). Строка masters { 195.108.80.22;

}, указывает, какой DNS-сер вер является первичным и откуда наш сервер будет брать информацию. И последняя строка file "cdfree.ru";

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

Файл /etc/named/cdfree.ru $ORIGIN.

$TTL 86400 ;

1 day cdfree.ru IN SOA ns.cdfree.ru. hostmaster.cdfree.ru. ( 2004220403 ;

serial 28800 ;

refresh (8 hours) 14400 ;

retry (4 hours) 3600000 ;

expire (5 weeks 6 days 16 hours) 86400,- minimum (1 day) ) NS cgo.te.ru.


A 195.108.80. MX 10 cgo.te.ru.

$ORIGIN cdfree.ru.

ns A 195.108.80. www A 195.108.80. Этот файл синхронизируется с содержимым соответствующего файла первичного DNS-сервера.

4.7. Кэширующие DNS-серверы Файлы etc/host.conf и /etc/hosts можно применять взамен сервера DNS, если он не установлен или не настроен. Эти файлы позволяют делать пре образование «имя – IР-адрес» без обращений к DNS-серверу, что обычно используется в небольших локальных сетях. Они просматриваются перед любыми запросами к DNS;

поэтому этот файл работает одновременно как запасной DNS (когда настоящий недоступен) и как его переопределение (если DNS предоставляет недостоверную информацию).

В сети достаточно много кэширующих серверов, выполняющих свои функции автоматически. Достаточно только установить такой сервер, настроить и запустить его. Кэширующий DNS-сервер предназначен для нахождения пары «имя – IР-адрес» в своем кэше или на других серверах и сохранения этой пары в своем кэше. При этом он сконфигурирован таким образом, что только принимает данные извне сети, но не отдает инфор мацию наружу. Такого типа серверы используются для уменьшения време ни ожидания ответа и рекомендуются при медленном соединении или в том случае, когда внешний DNS-сервер перегружен;

поэтому кэширующие DNS-серверы часто устанавливают на рабочих станциях, обладающих достаточными ресурсами.

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

4.7.1. Настройка кэширующего DNS сервера Настройка может проводиться как редактированием конфигурацион ных файлов, так и с помощью специальных утилит. Рассмотрим первый вариант.

Файл /etc/named.conf Это основной конфигурационный файл DNS-сервера. Для кэширую щего DNS-сервера он должен содержать следующие строки:

options { directory "/var/lib/named";

};

zone "." { type hint;

file "root.hint";

};

zone "0.0.127.in-addr.arpa" { type master;

file "127.0.0.zone";

};

Назначение этих зон должно быть ясно из описания аналогичных файлов первичных DNS-серверов.

Файл /var/lib/named/127.0.0.zone 127.0.0.zone – это файл, который отвечает за преобразование IP адресов в символические имена. Файл 127.0.0.zone должен выглядеть следующим образом:

@ IN SOA ns.lazy.ru. hostmaster.lazy.ru. ( 1 ;

Serial 8Н ;

Refresh 2Н ;

Retry 1W ;

Expire 1D) ;

Minimum TTL IN NS ns.lazy.ru.

1 PTR localhost.

Эта запись обозначает следующее:

@ указывает, что описываем localhost;

описываемая зона поддерживается сервером с именем ns.lazy.ru;

отвечает за нее администратор, доступный по адресу hostmaster@lazy.ru (первая точка заменяет @);

у зоны серийный номер равен 1 (обычно для него используют дату последней правки зоны – на него опираются другие серверы, которые получают информацию с нашего сервера);

другие серверы будут обновлять информацию о нашем сервере с пе риодичностью в 8 часов;

при неудачном обновлении следующая попытка будет произведена через 2 часа;

зона будет считаться содержащей недостоверную информацию, если не обновится через 1 неделю;

но не менее чем через 1 день;

строка IN NS ns.lazy.ru. показывает, что авторитетным сервером для этой зоны является ns.lazy.ru., и именно ему надо рассылать обновления зоны ns.lazy.ru;

строка 1 PTR localhost. показывает, что хост с адресом 1 в зоне 127.0.0.zone имеет имя localhost.

4.8. Описание модели службы DNS На рис. 4.11 приведена конфигурация виртуальной сети, в каждой подсети которой – по две ВМ;

причем, например, ВМ с IP-адресами 192.168.10.3, 192.168.20.3, 192.168.30.3 являются рабочими станциями с ОС Linux, на которых установлены кэширующие DNS-серверы. ВМ с IP-адресами 192.168.10.10, 192.168.20.10, 192.168.30.10 являются рабо чими станциями c OC Windows, а DNS-серверы для них – кэширующие DNS-серверы рабочих станцийс ОС Linux подсетей, а главный DNS-сервер установлен на маршрутизаторе.

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

4.8.1. Конфигурирование и настройка главного DNS сервера 1. Определение основных и реверсных зон главного DNS-сервера.

2. Создание и редактирование зонных файлов БД DNS-службы.

3. Создание и редактирование конфигурационного файла DNS /etc/named.conf, содержащего ссылки на зонные файлы.

4. Создание и редактирование файла распознавателя /etc/resolv.conf со списком DNS-серверов, которым можно посылать запросы.

5. Тестирование главного DNS-сервера с помощью программ nslookup и ping (подразд. 4.8.3).

4.8.2. Конфигурирование и настройка кэширующего DNS сервера 1. Определение основных и реверсных зон DNS кэш-сервера.

2. Создание и редактирование зонных файлов DNS кэш-сервера.

3. Создание и редактирование конфигурационного файла /etc/named.conf кэш-сервера.

4. Создание и редактирование файла распознавателя /etc/resolv.conf со списком DNS-серверов, которым можно посылать запросы.

5. Тестирование DNS кэш-сервера с помощью программ nslookup и ping (подразд. 4.8.3).

4.8.3. Запуск и тестирование named После правки конфигурационных файлов можно запускать сервер.

Наберите /etc/init.d/named start без опций и нажмите клавишу Enter.

Затем запускаем программу nslookup:

# nslookup Default Server: localhost Address: 127.0.0. _ Если вы увидели нечто похожее на мониторе – система работает. Каж дый раз, когда вы изменяете файл named.conf, необходимо перезапустить named, используя команду /etc/init.d/named restart.

Далее вводим реальные имена компьютеров, доступных вашему DNS-серверу. Предполагается, что компьютер с DNS-сервером имеет вы ход в Интернет. Проверим функционирование DNS-сервера, для этого введем:

userl.ya.ru Server: 213.166.195. Address: 213.166.195. Name: userl.ya.ru Address: 213.166.195. При этом программа nslookup попросила наш DNS-сервер посмотреть информацию о данном хосте. У себя сервер этой информации не нашел, а нашел у DNS-сервера провайдера, который имеет IP-адрес 213.166.195.22.

Если вы повторно попросите узнать адрес компьютера userl.ya.ru, то получите такой ответ:

# userl.ya.ru Server: localhost Address: 127.0.0. Non-authoritative answer:

Name: userl.ya.ru Address: 213.166.195. В этот раз вы получили сообщение Non-authoritative answer. Это зна чит, что во второй раз запрос к внешним DNS-серверам не делался, а был произведен поиск в кэше. Поскольку вы увидели это сообщение, наш DNS-сервер нормально функционирует. Получив положительный резуль тат, можно завершить работу программы nslookup, дав команду exit.

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

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

Следует помнить, что для выхода сетевых компьютеров в Интернет через шлюз в нем обычно используется устройство NAT (Network Address Translation device), присоединяющее виртуальный адаптер к реальному (су ществующему на главном компьютере). При этом никаких новых интер фейсов в реальной сети не появляется. ПО NAT перехватывает все про ходящие пакеты и изменяет их так, чтобы системы, находящиеся в реаль ной сети, считали, что общаются с реальным адаптером основной системы.

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

Рис. 4. Сетевые карты дополнительного маршрутизатора настроены так:

первая из них смотрит в VMNet3 и имеет адрес 192.168.30.12, а вторая будет получать параметры своих настроек от сервера DHCP, работающего в виртуальной подсети VMnet8 (адрес 192.168.32.0), настроенной на ис пользование NAT (см. рис. 4.12). Следует отметить, что шлюзом по умол чанию для второй карты будет адрес 192.168.32.2 устройства NAT.

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


Поскольку для связи с внешним миром эта ОС будет использовать NAT, нужно подправить настройки сети VMnet8. Как обычно, для этих целей используем редактор сетей VMWare Workstation. Выбираем вкладку NAT, убеждаемся, что выбрана именно VMnet8, и жмем клавишу Edit, в ответ открывается диалог настроек NAT (рис. 4.13).

Жмем Port forwarding. Появляется еще одно окно, разделенное на два окна поменьше, верхняя часть отвечает за проброс внутрь сети входящих TCP-пакетов, а нижняя – для UDP. Нам нужно настроить TCP;

поэтому используем кнопку Add верхнего окна и устанавливаем № порта 80 – это стандартный порт веб-сервера. Можно ввести и другие номера портов – например № 23 для электронной почты.

Рис. 4. Входим в окно настроек службы DNS и прописываем IP-адреса DNS-серверов Интернета, необходимые для обслуживания модели сети (рис. 4.14).

Рис. 4. 4.9.1. Настройка DNS с помощью утилиты yast Использование утилиты yast существенно упрощает настройку DNS-службы, но требует хорошего знания методики создания конфигура ционных файлов. Кроме того, эта утилита, несмотря на большие удобства, имеет ограниченные возможности применения – она поставляется только с дистрибутивами SUSE 10.0 – 11.2. В других дистрибутивах используются другие утилиты.

Итак, рассмотрим алгоритм настройки DNS-сервера.

Включаем утилиту в режим «Сетевые службы – DNS-сервер».

Выбираем режим Загрузка, в котором определяем режим запуска службы – при загрузке ОС или вручную. Здесь же указываем режим за пуска брандмауэра (рис. 4.15).

Рис. 4. Выбираем режим Ретрансляторы, в котором определяем рекурсивные серверы DNS (рис. 4.16).

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

Выбираем режим DNS-зоны, в котором создаем зоны, обслуживаемые сервером (рис. 4.17).

Выбираем режим редактирования DNS-зоны, в котором создаем все записи конкретных зон (рис. 4.18).

Рис. 4. Рис. 4. Проверяем правильность настроек сервера с помощью утилиты nslookup (рис. 4.19).

Проверяем правильность настроек сервера с помощью утилиты ping (рис. 4.20).

Рис. 4. Рис. 4. 4.10. Основы Web-хостинга Хостинг Web-сайта мало чем отличается от других сетевых услуг. В ос нове WWW лежит HTTP (HyperText Transfer Protocol – протокол передачи гипертекста) – простой протокол семейства TCP/IP, используемый для пе редачи документов, который содержит различные типы информации, включая текст, изображения, звук, анимацию и видео. HTTP аналогичен другим клиент-серверным протоколам сети Internet, таким, как SMTP (электронная почта) и FTP (передача файлов).

Web-сервер – это система, сконфигурированная для ответа на HTTP-за просы. Чтобы преобразовать обычную Linux-систему в платформу Web-хос тинга, запускается демон, прослушивающий TCP-порт с номером 80 (в соот ветствии со стандартом HTTP), и принимаются запросы на выдачу докумен тов, а затем посылаются эти документы пользователю.

Web-браузеры, такие, как Firefox, Opera и Internet Explorer, подклю чаются к удаленным Web-серверам и делают запросы от имени пользо вателей. Полученные при этом документы могут содержать особые указа тели (гиперссылки) на другие документы, находящиеся (или не находя щиеся) на том же сервере, к которому изначально подключился пользо ватель. Поскольку протокол HTTP полностью стандартизирован, клиенты, работающие в любой ОС на любой платформе, могут подключаться к любому серверу HTTP. Подобная независимость от платформы наряду с возможностью автоматического перенаправления пользователя от одного сервера к другому способствует повышению популярности протокола HTTP.

В настоящее время Web-хостинг «перешагнул» рамки протокола HTTP.

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

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

4.10.1. Унифицированные указатели ресурсов Унифицированный указатель ресурса (Uniform Resource Locator – URL) – это адрес объекта или службы в сети Internet. Он описывает порядок доступа к объекту с помощью пяти основных компонентов:

протокола или приложения;

имени хоста;

порта TCP/IP (необязательно);

каталога (необязательно);

имени файла (необязательно).

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

Таблица. 4. Протокол Назначение Пример file Получение доступа к file://etc/syslog.conf локальным файлам ftp Получение доступа к файлам ftp://ftp.admin.com/adduser.tar.gz по протоколу FTP http Получение доступа к файлам http: //admin. com/index. html по протоколу HTTP https Получение доступа К файлам https : //admin. com/order. shtml по протоколам HTTP/SSL ldap Получение доступа к службе ldap://ldap.bigfoot.com:389/cn=Her каталогов LDAP b mailto Отправка электронного сооб- mailto: linuxSbook. admin. com щения по указанному адресу 4.10.2. Принцип работы HTTP протокола Как уже говорилось, в основе WWW лежит HTTP – удивительно простой клиент-серверный протокол, не хранящий информацию о состоя нии сеанса. В модели HTTP инициатором подключения всегда является клиент (обычно браузер). Клиент запрашивает у сервера «содержимое» за данного URL-адреса. Сервер отвечает, передавая поток данных или возвра щая сообщение об ошибке. После этого клиент может переходить к за просу еще одного объекта.

Поскольку протокол HTTP довольно прост, можно легко подключиться к Web-браузеру с помощью утилиты telnet. Для этого достаточно подклю читься к порту 80 выбранного Web-сервера. После установления соеди нения сервер готов принимать HTTP-команды. Чаще всего используется команда GET, которая запрашивает содержимое документа. Обычно она задается в формате GET /. В этом случае возвращается корневой документ (как правило, начальная страница) сервера. Протокол HTTP является чув ствительным к регистру символов;

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

$ telnet localhost Trying 127.0.0.1...

Connected to localhost.atrust.com.

Escape character is ‘^]'.

GET / далее идет содержимое стандартного файла Connection closed by foreign host Более «полный» HTTP-запрос включал бы номер версии HTTP-про токола, имя хоста, для которого предназначен запрос (необходимое для извлечения файла с виртуального хоста, основанного на именах) и другую информацию. А ответ тогда включал бы не только данные самого ответа, но и информационные заголовки. Например:

$ telnet localhost Trying 127.0.0.1...

Connected to localhost.atrust.com.

Escape character is ‘^]'.

GET / HTTP/1. Host: www. atrust.com НТТР/1.1 200 ОК Date: Sun, 06 Aug 2006 18:25:03 GMT Server: Apache/1.3.33 (Unix) PHP/4.4. Last-Modified: Sun, 06 Aug 2006 18:24:49 GMT Content-Length: Content-Type: text/html далее идет содержимое стандартного файла Connection closed by foreign host.

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

4.11. Установка и настройка web-сервера Apache В качестве web-сервера в UNIX-сообществе в основном используется Apache, который распространяется по лицензии GNU. По статистическим данным, более половины всех web-серверов в Интернет созданы на базе Apache. У него много достоинств – он кроссплатформенный, мощный и легкий в настройке. Конфигурация сервера задается в файлах httpd.conf, srm.conf, access.conf и.htaccess. Файл httpd.conf предназначен для общей настройки, srm.conf содержит описание доступных ресурсов, a access.conf – права доступа к ресурсам. Однако в современных версиях сервера любая директива конфигурации может лежать в любом из этих файлов.

Установим в виртуальной сети (см. рис. 3.51) на одном из компьютеров с ОС SUSE Linux веб-сервер Apache и все необходимые для его работы модули с помощью утилиты yast по системе ее меню Программное обеспечение - Управление программным обеспечением - Поиск на ходим и устанавливаем пакет apache2.

Установку можно также осуществить через меню Фильтр Образцы Веб-сервер раздела Управление программным обеспечением.

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

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

Рассмотрим последний способ как наиболее легкий для начинающих.

Обратите внимание, что сразу после установки веб-сервера вы его не найдете в разделе Сетевые службы утилиты. Чтобы он там появился, перезагрузите виртуальную машину, войдите в yast, через меню Сетевые службы HTTP сервер войдите в процесс настроек этого сервера.

Прежде всего откроется окно Выбор сетевого устройства (рис. 4.21).

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

Рис. 4. После нажатия кнопки Далее в следующем окне выберите скриптовый язык для поддержки сервера (рис. 4.22).

Рис. 4. Далее определяем конфигурацию хоста по умолчанию (рис. 4.23).

Рис. 4. Параметр DocumentRoot srv/www/htdocs" – указывает корневую ди ректорию для документов web-сайта.

ServerRoot "/etc/httpd" – указывает на конфигурационный каталог, который использует Apache.

Timeout 120 – время ожидания реакции от клиента, после которого соединение закрывается.

Listen 80 – список портов, которые слушает сервер, можно задать несколько.

User apache – определяет пользователя, от имени которого работает сервер.

Group apache – определяет группу.

serverAdmin admin@mail.ru – адрес электронной почты администра тора.

serverName site.ru: 80 – задает имя и порт для web-сайта.

AccessFiieName.htaccess – определяет файл, при наличии которого считываются ограничения на доступ к web-сайту.

scriptAiias /cgi-bin/ " /srv/www/cgi-bin/ – путь к каталогу сценариев.

Здесь видим, в какую директорию необходимо поместить Web-сайт – это /srv/www/htdocs – в ней по умолчанию создается ряд файлов, в том числе файл с именем index.html, в котором имеется текст It works!, служащий для исходного тестирования работы сервера. Здесь приведены и остальные параметры сервера.

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

В окне Итог указаны все параметры настройки сервера (рис. 4.24).

Рис. 4. Если в настройках стоит Запустить сервер вручную, из командной строки запускаем его командой # service apache2 start, после чего прове ряем его работу из графической среды машины из меню браузера, вводя запрос к серверу в виде http//127.0.0.1/index.html. Если все настроено пра вильно, в браузере увидим надпись It works! (рис. 4.25).

Рис. 4. Далее аналогично проверяем работу web-сервера с других машин сети.

Если сеть настроена правильно, проблем не возникает.

На созданном сервере можно разместить любой сайт.

4.11.1. Конфигурационные файлы сервера Конфигурационный файл httpd.conf является основным и содержит настройки, связанные с работой web-сервера, виртуальных серверов, а так же всех его программных модулей. Кроме того, именно в нем настраи вается перекодирование русских букв при передаче от сервера к клиенту и обратно. Далее рассмотрим урезанный конфигурационный файл с краткими пояснениями. Файл условно разбит на 3 секции.

Секция номер 1.

### Section I: Global Environment ServerRoot "/etc/httpd" – эта директива показывает, где находятся конфигурационные файлы сервера.

Timeout 120 – время тайм-аута в секундах. Обычно этого значения вполне достаточно для нормального функционирования сервера.

Listen 80 – доказывает, что сервер слушает 80-й порт. При желании можно задать еще IP-адрес, например 192.168.21.5:80. А можно задать несколько портов или адресов, которые слушает сервер.

LoadModule authdigest_module modules/mod_auth_digest.so LoadModule ldap_module modules/mod_ldap.so LoadModule auth_ldap_module modules/mod_auth_ldap.so LoadModule include_module modules/mod_include.so LoadModule log_config_module modules/mod_log_config.so Здесь описываются загружаемые модули. Их много, и, возможно, не все они нужны вам.

Секция номер 2. Основные конфигурационные параметры сервера.

### Section 2: 'Main' server configuration User apache Group apache Директивы user и Group задают пользователя, от имени которого за пускается web-сервер. Без особой нужды менять их нет необходимости.

ServerAdmin root localhost – эта директива определяет адрес админи стратора web-сервера, на который пользователи могут отсылать электрон ные письма. Этот адрес в большинстве случаев будет отображаться на страницах с сообщениями об ошибках.

DocumentRoot "/srv/www/htdocs" – параметр, определяющий каталог, где находятся HTML-документы, отображаемые web-сервером.

AccessFileName.htaccess – параметр, определяющий имя файла, в кото ром можно дополнительно описать каталоги, к которым имеют/не имеют доступ пользователи web-сервера.

ErrorLog logs/error_log – задает файл, где будут сохраняться все сооб щения об ошибках сервера.

### Section 3: Virtual Hosts Секция З. Предназначена для конфигурации виртуальных хостов.

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

ServerName www.site.ru VirtualHost 192.168.21. DocumentRoot /www/site.ru ServerName www.site.ru ErrorLog /var/log/error_log.site.ru CustomLog /var/log/access_log.site.ru combined /VirtualHost На созданном сервере можно разместить любой сайт. В примере создан форум на основе дистрибутива phpBB (рис. 4.26) с использованием языка программирования php5 и СУБД mysql4.

Рис. 4.26. Установленное веб-приложение 4.12. Модель сети с FTP-сервером FTP-сервер предназначен для передачи файлов в сети Интернет. Он несколько устарел, частично функции передачи файлов взял на себя HTTP, но, несмотря на это, будет использоваться еще долгое время.

FTP, в отличие от большинства других протоколов, для пересылки файла использует два TCP-соединения;

одно – для передачи файла, а второе – для управления процессом передачи. Порт 20 предназначен для пересылки данных, а порт 21 – для управляющего соединения. FTP может использовать как TCP-, так и UDP-соединение.

Программа ftp – это пользовательский интерфейс к стандартному про токолу передачи файлов по Интернету – File Transfer Protocol. Программа позволяет передавать файлы на удаленный компьютер и получать файлы с удаленного компьютера. Однако, введя команду ftp, вы запускаете только клиентскую программу. Для того чтобы получить доступ к файлам уда ленного компьютера, на нем должен быть запущен FTP-сервер. Кроме то го, либо необходимо знать имя и пароль пользователя, либо FTP-сервер должен разрешать анонимный доступ.

Для работы с FTP-сервером можно использовать любой Telnet-клиент и, подключившись к 21-му порту сервера, вручную передавать команды.

Большинство команд, используемых в FTP-протоколе, схожи с теми директивами, которые вы применяете в Linux для управления файлами. Дело в том, что во время разработки протокола основной сетевой ОС была Unix.

Это в наше время везде стоит Windows, a 20 лет назад все было иначе. Но в последнее время клоны ОС Unix приобретают все большую популярность.

Примеры использования команд FТР-протокола Рассмотрим Пример1, в котором клиентская программа обменивается командами с FTP-сервером. Если в начале строки стоит знак "", то текст из нее был отправлен серверу клиентом, в противном случае – это ответ FTP-сервера клиенту.

Пример1.

220 ftpserv.ru FTP server (Version wu-2.6.2-5) ready.

USER Anonymous 331 Anonymous access allowed, send identity (e-mail name) as password.

PASS your@mail.com 230 Anonymous user logged in.

PWD 257 "/" is current directory.

TYPE A 200 Type set to A.

PASV 227 Entering Passive Mode (127,0,0,1,13,20).

LIST 125 Data connection already open;

Transfer starting.

226 Transfer complete.

Самой первой строкой идет приглашение FTP-сервера. Его мы полу чаем в ответ на соединение с 21-м портом. В этой строке чаще всего на ходятся текстовое описание сервера, с которым произошло соединение, и его версия. Из нее видно, что это – FTP-сервер wu-ftpd, один из наиболее популярных.

После чтения строки сообщения можно посылать команды FTP-сер веру. Но ничего особого выполнить не удастся, пока вы не представитесь серверу. Для этого нужно выполнить FТР-команды: user с параметром имя пользователя, а затем pass, указав пароль.

Серверы FTP позволяют работать с тремя типами авторизации: дей ствительной, гостевой и анонимной. В первом случае вы должны передать серверу реальное зарегистрированное имя и пароль пользователя, кото рому разрешен доступ к серверу. Тогда после выполнения команды user вы в строке 331 ……. увидите сообщение о необходимости ввести правильный пароль для указанного пользователя.

В случае с анонимным доступом в качестве имени нужно указать Anonymous (команда user Anonymous). В ответ сервер вернет нам сооб щение: 331 Anonymous access allowed, send identity (e-mail name) as password.

Здесь говорится, что анонимный доступ разрешен, и вы должны пере дать в качестве пароля E-mail-адрес. Честно говоря, можно ввести и чужой E-mail, например соседа или кого-нибудь другого. Это сервер проконтро лировать не сможет. Некоторые серверы вообще не проверяют корректность адреса даже по простым шаблонам, и можно передавать что угодно.

На практике анонимный доступ обладает минимальными возмож ностями чтения файлов и директорий и используется только в открытых файловых архивах. Имя Anonymous чаще всего используют для публика ции открытых документов для всеобщего доступа через РТР. Например, разработчики программ создают анонимные FTP-серверы для того, чтобы пользователи могли скачать с сервера последние версии программ или обновления уже существующих.

Реальный пользователь может путешествовать по всей файловой систе ме, и его возможности ограничены правами доступа используемой учетной записи.

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

Обратите внимание, что пароль в команде pass передается абсолютно в открытом виде. Это серьезная проблема. Ну что поделаешь, если на заре рождения Интернета никто не думал о хакерах. Теперь приходится изобре тать разные методы, чтобы спрятать пароль.



Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.