4.2.3. Содержание отчёта

Отчёт о проделанной работе должен содержать следующее:

1. Тема, цель работы, номер варианта и содержание индивидуального задания.

2. Схему собранной сети с указанием ОС и всех IP адресов.

3. Схему прохождения генерируемых в работе пакетов по цепочкам.

4. Алгоритм (последовательность действий) настройки МСЭ с описанием выполненных действий и команд.

5. Выводы о работе.

4.3. Примерный перечень вопросов для самостоятельного контроля

1. Для чего используется поле TTL в IP-пакетах? В чём измеряется величина, заносимая в TTL?

2. В чём отличие блокирования прохождения пакетов с помощью действия DROP от блокирования с помощью действия REJECT?

3. Каким образом помечаются пакеты с использованием действия MARK?

4. Влияет ли фильтрация пакетов на безопасность ЛВС? Почему?

5. Каково назначение режима forwarding?

6. Каково дальнейшее продвижение пакета по цепочкам, если он попадает под действие ACCEPT?

7. Каково дальнейшее продвижение пакета по цепочкам, если он попадает под действие DROP?

8. Каково дальнейшее продвижение пакета по цепочкам, если он попадает под действие REJECT?

9. В каких случаях необходимо применять цепочку FORWARD для таблицы filter, а в каких цепочку INPUT?

10. В какие цепочки не попадают пакеты, к которым применено действие REDIRECT?

Литература

1. Бруй В.В., Карлов С.В. LINUX-сервер: пошаговые инструкции инсталляции и настройки. – Москва, 2003. – 572 с.

2. Единая система документации ОС МСВС.

3. Интернет-Университет Информационных Технологий. http://www.INTUIT.ru

4. Колисниченко Д.Н. Linux-сервер своими руками. СПб., 2002. – 576с.

5. Мохаммед Д.К. RedHat Linux 6 Server. – Москва, 2001. – 560с.

6. Немет Э., Снайдер Г., Хейн Т.Р. Руководство администратора Linux, 2-е издание. – Москва, 2007. – 1072с.

7. Стахнов А.А. Сетевое администрирование Linux. – СПб., 2004. – 480с.

5. Настройка dns

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

1. Теоретическая часть

1. Принципы работы dns

Как известно, протокол TCP/IP, которым пользуются в Интернете, может адресовать хосты лишь по IP-адресу. Запоминание четырёх трёхзначных чисел довольно сложно для человека, поэтому был изобретен механизм, называемый службой доменных имён (DNS), позволяющий называть хосты по имени — например, «ask.microsoft.com.». Точка после com — вовсе не опечатка. Она должна там быть. Тем не менее, браузеры позволяют её опускать. Задача DNS — взять доменный адрес хоста и преобразовать его в IP-адрес хоста¹⁰. Именно это и делают браузеры перед тем, как подключаются к запрашиваемому сайту (обычно этот процесс занимает около секунды — от появления слов «Connecting» до «Connected, waiting for reply» в строке состояния браузера).

Завершающая точка (в представленном примере после com) в терминологии DNS называется корневым доменом, или доменом нулевого уровня. Фактически, он представляет собой базу данных, распределенную по нескольким интернациональным серверам по всему миру, в которой содержится список всех доменов первого уровня, таких как com., net., ru. и т. д. Совершенно такая же схема применяется и далее: каждый домен первого уровня содержит в себе список доменов второго уровня (например, dklab.ru.), и соответствующий ему список IP-адресов. При этом в нём, конечно, не содержится никакой информации о доменах третьего уровня — этим занимается второй уровень.

Согласно руководящим материалам (RFC 1034, RFC 1035) система доменных имен состоит из трех основных частей:

• всего множества доменных имен (domain name space)

• серверов доменных имен (domain name servers)

• клиенты DNS (Resolver’ы)

Сервис системы доменных имен строится по схеме «клиент-сервер». В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени IP-адресу (или наоборот IP-адреса имени). Это программное обеспечение и называют resolver. В качестве сервера выступает прикладная программа-сервер.

Чаще всего, Resolver не является какой-либо программой или системной компонентой. Это набор процедур из библиотеки прикладного программного обеспечения (например, из библиотеки libc), которые позволяют программе, отредактированной с ними, выполнять запросы к системе доменных имен и получать ответы на них. Эти процедуры обращаются к серверу доменных имен и сервер обслуживает запросы прикладных программ пользователя.

Ряд производителей операционных систем, например, Sun или SGI, предлагали решения, в которых resolver являлся отдельным процессом, и прикладные программы через него реализовывали взаимодействие с DNS.

Другой пример реализации resolver’а – это браузеры Nescape некоторых версий, где для ускорения процесса получения ответов на запросы к DNS запускался отдельный процесс resolver’a.

Самостоятельный resolver может быть собран и в BIND версии 9. Это, так называемый, lightweight resolver. Он состоит из rosolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО. Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.

В качестве серверов доменных имен чаще всего используются различные версии BIND¹¹ (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.

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

Рис. 5.1. Рекурсивный запрос resolver и не рекурсивная (итеративная) процедура на разрешение доменного имени сервером доменных имен

Данную схему разрешения имени (установки соответствия между именем и IP-адресом) называют не рекурсивной (итеративной). Отличие процедур будет рассмотрено далее.

Поясним приведенную схему не рекурсивной процедуры разрешения запроса:

1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес).

2. Местный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:

   1. если адрес находится в зоне его ответственности (местного сервера), сразу сообщает его resolver’у;

   2. если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server);

   3. обращается к TLD-серверу за адресом;

   4. получает от него адрес удаленного сервера;

   5. обращается к удаленному серверу за адресом;

   6. получает от удаленного сервера адрес.

В данном случае была рассмотрена вложенность доменного имени второго порядка, т.е. хост имел имя похожее на «quest.example.com» или даже «example.com».

Последнее важно понять, т.к. корпоративные почтовые адреса типа «user@example.com» как раз и требуют от прикладного программного обеспечения обращения за IP-адресом хоста «example.com». TLD-сервер домена «com» не обладает информацией о том, какому IP-адресу данное имя соответствует, но при этом он знает какой сервер отвечает за домен «example.com».

Если вложенность доменного имени будет большей, скажем третьего уровня («host.department.corp.ru»), и этот уровень будет поддерживаться другим сервером доменных имен, отличным от того, который поддерживает второй уровень вложенности, то тогда локальному серверу удаленный сервер доменных имен передаст не адрес хоста, а адрес нового сервера доменных имен, в зоне ответственности которого находится запрашиваемое имя.

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

При входе в режиме удаленного терминала на компьютер «polyn.net.kiae.su» по команде:

MCBC > telnet polyn.net.kiae.su

Получаем в ответ:

trying 144.206.130.137 ...

login:

.....

Строчка, в которой указан IP-адрес компьютера «polyn.net.kiae.su», показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен. После этого прикладная программа, в данном случае telnet, получила на свой запрос IP-адрес. Таким образом, после ввода команды с консоли, и до появления IP-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.

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

Другой пример – это программа traceroute¹². Здесь задержка на запросы к серверу доменных имен проявляется в том, что время ответов со шлюзов, на которых «умирают» ICMP пакеты, указанное в отчете, маленькое, а задержки с отображением каждой строчки отчета довольно большие.

Если в примере с telnet и ftp были рассмотрены, только «прямые» (forward) запросы к серверу доменных имен, то в примере с traceroute впервые были упомянуты «обратные» (reverse) запросы. В «прямом» запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При «обратном» запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

Следует заметить, что скорость разрешения «прямых» и «обратных» запросов в общем случае будет разная. Все зависит от того, где описаны «прямые» (forward) и «обратные» (reverse) зоны в базах данных серверов доменных имен, обслуживающих соответствующие домены (прямой и обратный).

Не рекурсивным рассмотренный выше запрос является только с точки зрения сервера. С точки зрения resolver’а процедура разрешения запроса является рекурсивной, так как resolver перепоручил локальному серверу доменных имен заниматься поиском необходимой информации. Согласно RFC 1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы.

В этом случае resolver обращается к локальному серверу доменных имен, если не получает от него адреса, то опрашивает сервер корневого домена, получает от него адрес удаленного сервера TLD, опрашивает этот сервер, получает адрес удаленного сервера, опрашивает удаленный сервер и получает IP-адрес, если он посылал, так называемый «прямой» запрос.

Рис.5.2. Нерекурсивный запрос resolver’а

Как видно из этой схемы (рисунок 5.2), resolver сам нашел нужный IP-адрес. Однако общая практика такова, что resolver не порождает не рекурсивных запросов, а переадресовывает их локальному серверу доменных имен.

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

Самые умные resolver’ы, такие, например, как resolver Windows 2000 Server и BIND 9 умеют поддерживать кэш, в котором сохраняют не только удачно установленные соответствия имени и адреса (positive response), но и так называемые «негативные» отклики (negative response results) на запросы. Кроме того, эти resolver’ы упорядочивают отклики об адресах серверов в соответствии с принятыми в них (resolver’ах) алгоритмами выставления предпочтений, которые базируются на времени отклика сервера (рисунок 5.3).

Рис.5.3. Схема разрешения запросов с кэшированием ответов

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

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

1. Поиск ответа в локальном кэше.

2. Поиск ответа на локальном сервере.

3. Поиск информации в сети.

При этом кэш может быть как у resolver’а, так и у сервера.