DNS В КОРПОРАТИВНОЙ СЕТИ




Цель работы

Цель данной работы – научиться конфигурировать и тестировать службу имен для корпоративной сети на основе сервера DNS bind.

Теоретические сведения

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

В сети Интернет корнем дерева является домен “.”. Полное - абсолютное или полностью определенное, fully qualified domain name - доменное имя заканчивается точкой, обозначающей корень доменного дерева, но часто эта завершающая точка опускается. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (для каждой страны мира выделен свой домен с двух символьным именем в соответствии со стандартом ISO, например, ua – Украина, ru – Россия, uk – Англия и т.п.) или характер организации (образовательная, коммерческая, правительственная и т.п.). Таим образом, домены верхнего уровня (Top Level Domains, TLD) - это хорошо известные всем домены, такие как org (бесприбыльная организация), com (коммерческая организация), gov (государственное учреждение), mil (военное предприятие или организация), edu (учебное заведение), int (международная организация), net (большая сеть) и т.д.

Ниже по дереву имен расположены домены второго и последующих уровней. В некоторых странах существуют домены, подобные исторически первым TLD, например, org.ua, gov.ua, edu.ua и т.п. В Украине для каждой области выделены двухбуквенные домены, такие как cn.ua – Чернигов, dp.ua – Днепропетровск, и т.д., хотя исторически сложившиеся домены, такие как kiev.ua, kharkov.ua, chernigov.ua, тоже поддерживаются. Маленький фрагмент интернетовской иерархии имен показан на рисунке 1. Число уровней реально больше, но обычно не превышает 5.

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

За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным, primary, или, в новой терминологии — master. остальные - вторичными, secondary, или slave. Первичный сервер содержит оригинальные файлы с базой данных DNS для своей зоны. Вторичные серверы получают эти данные по сети от первичного сервера и периодически запрашивают первичный сервер на предмет обновления данных. Признаком обновления данных служит увеличение серийного номера в записи SOA – см ниже. В случае, если данные на первичном сервере обновлены, вторичный сервер запрашивает "передачу зоны" ("zone transfer")- т.е. базы данных требуемой зоны.

Ход работы

Конфигурируем первычный master. Файлы конфигурации приведены ниже через sudo su:

Файл “named.conf.local”(nano /etc/bind/named.conf.local)

 

Файл “db.lab5.org”

 

Файл “db.rev_lab5.org”:

После настройки, перезагружаем сервер bind9(/etc/init.d/bind9 restart), и проверяем наши параметры:

 

 

 

 

Конфигурируем вторичный master. Файлы конфигурации приведены ниже:

 

 

Файл “named.conf.local”(nano /etc/bind/ named.conf.local)

Тестируем:

 

Выводы

В ходе выполнения лабораторной работы были получены знания и навыки конфигурирования и тестирования службы имен для корпоративной сети на основе сервера DNS bind.

ЛАБОРАТОРНАЯ РАБОТА № 6
СЕРВИСЫДЛЯ СЕТЕЙ WINDOWS. НАСТРОЙКА СЕРВИСА SAMBA

Цель работы

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

Теоретические сведения

В любой корпоративной сети, независимо от ее размера, необходимо выделять общие ресурсы, такие как принтеры, диски, службы времени, службы авторизации и аутентификации, репозитории ПО и т.д. В операционных системах семейства Windows для этих целей используются протоколы Server Message Block (SMB) и, позже - Common Internet File System (CIFS). Эти протоколы являются развитием спецификаций NetBIOS и NetBEUI, разработанных в середине 80-х компаниями IBM и Microsoft для работы в локальных сетях. В POSIX-совместимых OC данное семейство протоколов реализовано в пакете свободного ПО Samba (https://www.samba.org).

В виду закрытости протоколов SMB и CIFS в начале разработка Samba велась методом реверс-инжиниринга, однако в 2004-м году Еврокоммиссия вынудила Microsoft смягчить политику лицензирования интеллектуальной собственности и проект Samba в 2007-м году получил доступ к документации по указанным протоколам, что дало возможность более точно и надежно реализовать сервисы указанных протоколов. На момент написания этой книги свободная реализация SMB/CIFS Samba является функционально полной и предоставляет весь набор сервисов, необходимых для интероперабельности UNIX-подобных ОС и ОС семейства Windows.

Протокол CIFS появился в середине 90-х, когда компания Microsoft подала черновики его спецификаций в организацию Internet Enginiring Task Force (IETF). Основная часть спецификации посвящена описанию разделения в сети файловых ресурсов, основанном на уже применяемом, но плохо документированном и уязвимом протоколе SMB.

Протокол SMB был изначально разработан для работы поверх NetBIOS (Network Basic Input Output System) в локальных сетях. Цитируя книгу Кристофера Хертеля «Реализация CIFS», можно сказать, что «NetBIOS - это грязный маленьки скелет в шкафу CIFS». До появления Win2K поддержка NetBIOS была необходима для работы SMB. Фактически, «компьютеры» и «службы», которые видны в «Сетевом окружении» - это имена NetBIOS. Для работы не только поверх кадров 802.3, но и поверх высокоуровневого протокола IP, необходимо отображать 16-байтное символьное имя NetBIOS на IP адрес, и механизм такого отображения, а также инкапсуляции протокола NetBIOS в транспортные протоколы TCP и UDP были предложены интернет-сообществом в RFC 1001, RFC1002. С развитием ОС Windows (Windows 3.11) компании Microsoft пришлось реализовать предложенные стандарты, поскольку семейство протоколов TCP/IP стало доминирующим в локальных сетях в виду широкого распространения Интернет. В этой же версии ОС был предложен механизм поиска сервисов, основанный на широковещательных сообщениях о доступных ресурсах. Естественно, такой механизм создавал в сети ситуацию с трафиком, аналогичную шуму на базаре, когда каждый торговец громко рекламирует свой товар. Здесь же была предложена концепция рабочих групп для упрощения управления ресурсами, которая послужила основой для доменов Windows NT.

Выполнение работы

В процессе настройки сервиса был получен следующий файл настроек:

Samba config file created using SWAT

# from UNKNOWN (127.0.0.1)

# Date: 2016/12/29 21:53:12


[global]
workgroup = WORKGROUP

server string = %h server (Samba, Ubuntu)

dns proxy = yes

security = user

bind interfaces only = yes

log file = /var/log/samba/log.%m

max log size = 1000

map to guest = bad user

usershare allow guests = yes

 

[Dekoder]
comment = Dekoder directory

path = /home/Dekoder

browseable = yes

read only = no

guest ok = yes

writable = yes


[laba6]
comment = Primer Laba6

path = /home/Dekoder/laba6

browseable = yes

read only = yes

guest ok = yes

writable =no

Для тестирования samba-сервера необходимо создать пользователя. Сначала создаем группу:

Sudo groupadd smbuser

Затем создаем пользователя:

Sudo useradd –g smbuser Dekoder

Добавляем пароль для нашего тестового пользователя в список пользователей samba:

Sudo smbpasswd -a Dekoder

После этого можно протестировать доступность серверов samba с локальной машины:

Рисунок 6.1 – Результаты доступа к samba с локальной машины

Результаты подключения дисков и синхронизации времени на ОС Windows:

Рисунок 6.2 – Подключение дисков

Рисунок 6.3 – Синхронизация времени

Выводы

В ходе выполнения лабораторной работы удалось приобрели навыки в настройке сервиса на основе свободно распространяемого пакета Samba, обеспечивающего основные сервисы для рабочих станций под управлением ОС Windows.

ЛАБОРАТОРНАЯ РАБОТА № 7
КОНФИГУРИРОВАНИЕ СЛУЖБЫDHCP В КОРПОРАТИВНОЙ СЕТИ

Цель работы

Ознакомиться с сервисом DHCP, а также получить навыки в его настройке.

Теоретические сведения

Dynamic Host Configuration Protocol (DHCP) - протокол динамической конфигурации хостов) предназначен для автоматической настройки параметров стека TCP/IP рабочей станции в момент ее загрузки. Он используется для настройки изменяемых сетевых параметров хостов (клиентов) с помощью сервера. Настраиваются следующие основные параметры: IP адрес и маска сетевого интерфейса, маршрут по умолчанию, адреса серверов DNS и WINS в сети.

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

Процесс взаимодействия сервера и клиента происходит в следующем порядке. Сервер получает запрос и откликается с предложением об аренде (lease), содержащим конфигурационные данные для хоста. Ресурс, содержащийся в предложении сервера, временно блокируется для предложения другим хостам до получения ответа от хоста или истечения тайм-аута. Хост может получить предложения от нескольких DHCP-серверов, работающих в данном широковещательном сегменте сети. Хост, на основании настроек своего DHCP-клиента, решает принять предложение определенного сервера (или принять первое поступившее предложение, если никаких настроек нет). Хост отвечает выбранному серверу сообщением "выбор". Сервер подтверждает выдачу аренды; после получения подтверждения хост конфигурирует себя в соответствии с полученными данными.

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

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

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

В любом случае использование DHCP позволяет избежать конфигурирования стека TCP/IP на каждом хосте сети отдельно и проводить гибкую, централизованную административную политику.

Выполнение работы

Выполнение лабораторной работы состоит из следующих шагов:

1. Проверка наличия установленных пакетов dhcp (команда rpm –qa | grep dhcp). Если пакеты установлены – приступаем к работе (шаг два), если нет – устанавливаем необходимые пакеты (dhcpd-XXX.rmp).

2. Создание конфигурационного файла сервера /etc/dhcpd.conf по приведенному выше примеру (подробности man dhcpd.conf).

3. Настройка одной из машин в аудитории на получение IP адреса автоматически. Зафиксируем результаты в отчете (ifconfig /all на клиенте и /var/lib/dhcp/dhcpd.leases на сервере).

4. Создание статической записи для каждого клиента сети на основе файла /var/lib/dhcp/dhcpd.leases. Зафиксируем результат в отчет.

В результате выполнения лабораторной работы был создан файл dhcpd.conf:

 

ddns-update-style none;

default-lease-time 600;

max-lease-time 7200;

 

# If this DHCP server is the official DHCP server for the local

# network, the authoritative directive should be uncommented.

authoritative;

 

# Use this to send dhcp log messages to a different log file (you also

# have to hack syslog.conf to complete the redirection).

log-facility local7;

 

# No service will be given on this subnet, but declaring it helps the

# DHCP server to understand the network topology.

 

subnet 192.168.0.0 netmask 255.255.255.0 {

range 192.168.0.100 192.168.0.254;

}

# Fixed IP addresses can also be specified for hosts. These addresses

# should not also be listed as being available for dynamic assignment.

# Hosts for which fixed IP addresses have been specified can boot using

# BOOTP or DHCP. Hosts for which no fixed address is specified can only

# be booted with DHCP, unless there is an address range on the subnet

# to which a BOOTP client is connected which has the dynamic-bootp flag

# set.

host lab7 {

hardware ethernet 1c:6f:65:4b:48:f0;

fixed-address 192.168.0.133;

}

Получение IP-адресса динамически:

root@Debian:/var# ifconfig

eth0 Link encap:Ethernet HWaddr c8:0a:a9:dc:6f:22

inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::ca0a:a9ff:fedc:6f22/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:1478 errors:0 dropped:0 overruns:0 frame:0

TX packets:1113 errors:0 dropped:0 overruns:0 carrier:7

collisions:0 txqueuelen:1000

RX bytes:396314 (387.0 KiB) TX bytes:279191 (272.6 KiB)

Interrupt:45

 

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr:::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:437 errors:0 dropped:0 overruns:0 frame:0

TX packets:437 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:116843 (114.1 KiB) TX bytes:116843 (114.1 KiB)

dhcpd.leases:

server-duid "\000\001\000\001\032#\343\224\310\012\251\334o\"";

 

lease 192.168.0.100 {

starts 6 2017/01/02 22:21:11;

ends 6 2017/01/02 22:31:11;

cltt 6 2017/01/02 22:21:11;

binding state active;

next binding state free;

rewind binding state free;

hardware ethernet c8:0a:a9:dc:6f:22;

client-hostname "Dekoder-Debian";

}

Получение статического IP-адресса:

E:\>ipconfig

Настройка протокола IP для Windows

Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения.....:

Локальный IPv6-адрес канала...: fe80::70cb:c846:9a0c:1301%11

IPv4-адрес............: 192.168.0.133

Маска подсети..........: 255.255.255.0

Основной шлюз.........:

Выводы

В ходе выполнения лабораторной работы ознакомились с сервисом DHCP, а также приобрести навыки по его настройке.

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2018-01-08 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: