Инфраструктура территориально распределенной корпоративной сети

• ВВЕДЕНИЕ
• 1. АНАЛИЗ ТРЕБОВАНИЙ ТЗ
• 2. РАЗРАБОТКА ФИЗИЧЕСКОЙ СТРУКТУРЫ СЕТИ
• 2.1 Распределение IP-адресов
• 2.2 Разработка структуры сети зданий
• 3. РАЗМЕЩЕНИЕ БАЗОВЫХ СЕТЕВЫХ СЕРВЕРОВ DNS, DHCP, WINS, КОМПОНЕНТОВ ACTIVE DIRECTORY
• 3.1 Размещение серверов DNS
• 3.2 Размещение серверов WINS
• 3.3 Размещение серверов DHCP
• 3.4 Разработка структуры Active Directory
• 4. WLAN
• 5. ДЕМИЛИТАРИЗОВАННАЯ (DMZ) ЗОНА
• 6. ПОДКЛЮЧЕНИЕ ФИЛИАЛОВ КОРПОРАЦИИ И УДАЛЕННЫХ ПОЛЬЗОВАТЕЛЕЙ
• 6.1 Подключение здания В по каналу Е1
• 6.2 Подключение здания С с использованием ADSL
• 6.3 Подключение сотрудников корпорации в Европе по каналам ISDN
• 6.4 Подключение сотрудников по коммутируемым каналам связи Dial-up
• ЗАКЛЮЧЕНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, УСЛОВНЫХ ОБОЗНАЧЕНИЙ, ТЕРМИНОВ КМ — коммутатор МШ — маршрутизатор ОП — организационное подразделение

AD — Active Directory

DHCP — Dynamic Host Configuration Protocol

DNS — Domain Name System

ISA — Internet Security and Acceleration

VLSM — Variable Length Subnet Mask

Основанием для проведения курсовой работы является учебный план кафедры ИУ6.

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

Информационные службы, в свою очередь, не могут работать без сети. Сеть включает в себя программные и аппаратные компоненты, необходимые для обеспечения связи между различными устройствами как внутри организации, так и с устройствами за её пределами. Аппаратные компоненты (компьютеры, сетевые адаптеры, кабели, телефонные линии, маршрутизаторы и коммутаторы) обеспечивают физические соединения между устройствами. Программные компоненты — протоколы связи и сетевые службы — необходимы для обмена данными между физически соединенными устройствами.

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

1. АНАЛИЗ ТРЕБОВАНИЙ ТЗ

Согласно заданию на курсовую работу корпорация CorpUTY имеет главный офис (здание А) и два филиала:

— производство продукции Manufacture (M) — здание B;

— отдел исследований и новейших разработок Research ® — здание C.

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

1 этаж. Подразделения корпорации:

— отдел кадров и подготовки специалистов Human Resource (HR);

— отдел маркетинга Sales (S);

— служба информационных технологий и технической поддержки Information Technologies (IT).

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

2 этаж. Подразделения:

— руководство корпорацией Executive (E) — 6 рабочих групп по 14 компьютеров;

— бухгалтерия Accounting (Acc) — 5 рабочих групп по 16 компьютеров;

— отдел экономики и планирования Business (Bus) — 3 рабочие группы по 8 компьютеров.

На 3, 4, и 5 этажах расположено проектное отделение, при этом:

3 этаж. Проектный отдел Project 1 (P1) — 16 рабочих групп по 10 компьютеров;

4 этаж. Проектный отдел Project 2 (P2) — 16 рабочих групп по 12 компьютеров;

5 этаж. Проектный отдел Project 3 (P3) — 12 рабочих групп по 17 компьютеров.

В одноэтажном здании филиала B имеются отделы:

— M1 — 26 рабочих групп по 10 рабочих станций;

— M2 — 20 рабочих групп по 22 рабочие станции;

— Production (P) — 9 рабочих групп по 44 рабочие станции.

В двухэтажном здании С:

— 1 этаж — отдел Research 1 (R1) — 6 рабочих групп по 16 рабочих станций;

— 2 этаж — отдел Research 2 (R2) — 10 рабочих групп по 10 рабочих станций.

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

В настоящее время в каждом офисе имеются небольшие ЛВС, которые будут объединены в единую корпоративную сеть. В качестве рабочих станций используются компьютеры с установленными ОС W98, XP Prof, W2000 Prof. В ближайшие 12−18 месяцев планируется переход части клиентов отдела маркетинга и руководства корпорацией на новые ОС семейства Vista.

Руководство компании приняло решение принять в качестве базовой ОС сети MS Windows Server 2003 и согласно использовать избыточное оборудование там, где это будет обоснованно указано.

Филиал Manufacture (M) (здание В) расположен в другом городе, удаленном на значительное расстояние, и соединен с главным офисом каналом Е1. Филиал Research (здание С) связывается с главным офисом через Internet маршрутизаторами с функцией «дозвон по требованию», используя подключение ADSL (см. рис. 1).

сеть сервер коммутируемый связь Рис. 1. Схема корпоративной сети корпорации CorpISO

Имеется небольшой штат сотрудников корпорации в Европе, которые соединяются с главным офисом по каналам ISDN. Несколько привилегированных сотрудников работают в своих домашних офисах SOHO, подключающихся к главному офису по коммутируемым каналам связи Dial-up 56 Кб/с. Максимальное число компьютеров в SOHO — не более 5.

Две независимые группы сотрудников отдела маркетинга в основном работают на ноутбуках и подали заявку на создание защищенной беспроводной сети с выходом в интернет.

2. РАЗРАБОТКА ФИЗИЧЕСКОЙ СТРУКТУРЫ СЕТИ

2.1 Распределение IP-адресов

Согласно заданию на курсовую работу, корпорации CorpUTY был выделен следующий диапазон внутренних адресов: 10.69.0.0/16. Необходимо каждой рабочей станции корпорации назначить адрес из этого диапазона.

Будем использовать технологию с масками переменной длины (Variable Length Subnet Mask, VLSM), которая позволяет соблюдать структуризацию при разбиении общего адресного пространства на части, а также — распределять адреса «экономно», то есть избежать больших потерь адресов при разбиении сети более высокого уровня на подсети.

Общее число компьютеров в сети составляет 2252. Причем, в здании A их число 960, в здании B — 1096, в здании С — 196. Разобьем исходное адресное пространство 10.69.0.0/16 на подсети, выделив каждому зданию свою подсеть. Маску этих подсетей изменим на 20. В этом случае у нас получится в каждой такой подсети адресовать по 4094 компьютеров, чего вполне достаточно для текущих нужд корпорации.

Для каждого отдела предполагается выделить свою подсеть. Результаты разбиения приведены в табл. 1:

Таблица 1. Распределение внутренних IP-адресов

Структурная схема разбиения адресного пространства — на рис.2:

Рис. 2. Структурная схема разбиения адресного пространства

Помимо рабочих станций во всех зданиях также будут размещены различные служебные серверы (такие как WINS, DNS, DHCP). В главном здании будут использоваться серверы FTP, DNS, RAS/VPN, Mail. Необходимо также предусмотреть дополнительные IP-адреса для резервных серверов.

В демилитаризованной зоне здания A планируется разместить DNS, RAS, Mail, FTP-серверы. Это не точный состав используемых серверов. Их количество на данном этапе проектирования неизвестно, поэтому необходимо предусмотреть некоторый запас.

Будем использовать подсеть 10.69.7.0/24 для выделения адресов для DMZ-зоны. Увеличим маску этой подсети до 28. Получим 16 подсетей, в каждой из которых можно использовать по 14 адресов. Одну такую подсеть и будем использовать для адресации компьютеров в DMZ-зоне. Например, сеть 10.69.7.0/28. Вторую сеть 10.69.7.16/28 можно использовать для серверов здания A, а подсеть 10.69.7.32/28 — для резервных серверов.

Минимальный адрес хоста в сети DMZ — 10.69.0.1, максимальный — 10.69.0.14.

Перейдем к зданию B. В этом здании есть резервная подсеть 10.69.40.0/21. Можно сдвинуть маску в этой подсети, сделав её равной, например, 28, и одну из получившихся подсетей с 14-ю IP-адресами использовать в качестве подсети серверов. Но в этом случае у нас получится 128 подсетей с 14-ю адресами в каждой. В дальнейшем может оказаться, что такие подсети использовать неудобно. Поэтому предлагается постепенно увеличивать маску от 21 до 28 (на единицу при каждой итерации). Причем в дальнейшем разбиении на подсети участвует только одна из получившихся подсетей. В результате получим подсеть 10.69.40.0/28, которую и будем использовать для серверов.

В здании С будем использовать свободную подсеть 10.69.17.0/25, сдвинув маску в которой до 28, получим 8 подсетей с 14-ю IP-адресами в каждой. Для серверов будем использовать первую подсеть 10.69.17.0/28, где минимальный адрес хоста 10.69.17.1, а максимальный — 10.69.17.14.

2.2 Разработка структуры сети зданий

Согласно заданию на курсовую работу, в головном здании, А — 5 этажей, в здании B — один этаж, в здании C — 2 этажа. На каждом этаже находится различное число отделов (от одного до трех). Число рабочих групп в отделе и число машин в рабочей группе также варьируется в широких пределах. В задании на курсовую работу также сказано, что каждое подразделение корпорации (отдел) имеет свой конфиденциальный сервер приложений. Причем доступ к этому серверу могут иметь только сотрудники соответствующего подразделения.

Таким образом, стоит задача выбора структуры сети, которая с одной стороны имела бы достаточно простое управление и высокую пропускную способность, а с другой — затраты на её реализацию были бы не очень высоки.

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

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

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

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

Отдадим предпочтение сетевому оборудованию фирмы СISCO.

Спектр выпускаемого фирмой СISCO оборудования довольно широк. Необходимо выбрать коммутаторы, которые должны удовлетворять следующим требованиям:

1. Поддержка Fast Ethernet.

2. Возможность организации стека.

3. Наличие высокоскоростного порта для подключения к магистрали здания (Gigabit Ethernet).

4. Желательно, чтобы можно было выбирать модели с разным числом портов (16−48) из одной линейки продуктов.

5. Отсутствие функций, которые не планируется использовать и которые существенно повышают стоимость устройств.

Всем этим требованиям удовлетворяют коммутаторы серии Сisco Catalyst 2960. Коммутаторы семейства Cisco Catalyst 2960 — это коммутаторы фиксированной конфигурации, которые предназначены для инфраструктуры сетей Fast Ethernet и Gigabit Ethernet и обеспечивают производительность на скорости среды передачи. Бесплатно распространяемое программное приложение Cisco Network Assistant для централизованного управления коммутаторами семейства Catalyst 2960 упрощает администрирование коммутаторов, маршрутизаторов и беспроводных точек доступа Cisco, предлагая дружественный к пользователю графический интерфейс для удобства конфигурирования, поиска и устранения неисправностей, а также включения и мониторинга элементов сети. Семейство коммутаторов Cisco Catalyst 2960, рассчитанное на обеспечение высокой производительности, включает 24-портовые и 48-портовые модели. Два гигабитных порта, которыми располагает каждый коммутатор семейства, могут быть использованы для объединения в стек или для высокоскоростного соединения с сетевой магистралью или с локально подключенными серверами. Один гигабитный порт может быть настроен на работу или с медной, или с оптоволоконной средой передачи — 1000Base-T (разъем RJ45), а другой порт — на работу с 1000Base-X (с помощью SFP-трансиверов). Эти коммутаторы монтируются в стандартную 19-дюймовую стойку или шкаф для электрооборудования (крепёжные детали включены в комплект поставки).

Необходимо также учесть, что две группы сотрудников (24 человека) отдела маркетинга должны работать с ноутбуками с помощью беспроводной сети. Для этого необходимо установить точку доступа. Точки доступа Cisco Aironet 1240AG поддерживают стандарты 802.11a/b/g и являются универсальным решением для сетей корпоративного класса. Точка доступа Cisco Aironet серии 1240AG поставляется либо в «облегченном» (lightweight), либо в автономном варианте. Во втором случае ее впоследствии можно будет модернизировать до «облегченного» варианта на месте.

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

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

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

Таблица 2. Состав стеков коммутаторов

Выбранные коммутаторы имеют 2 порта двойного назначения. Один порт может использоваться как дополнительный порт RJ-45 с автоматическим определением 10/100/1000. Таким образом, один порт одного коммутатора в каждом стеке можно использовать для подключения к магистрали здания.

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

1000BASE-SX: 220−500 метров (в зависимости от характеристик оптоволоконного кабеля, полнодуплексный режим);

1000BASE-LX: 550 метров — для многомодового кабеля, 5000 м — для одномодового;

1000BASE-TX: 100 метров;

1000BASE-CX: 25 метров.

Выберем технологию 1000BASE-LX с использованием многомодового кабеля. В этом случае допустимая длина сегмента сети составит 550 метров.

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

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

Начнем со здания А. В этом здании наиболее разветвленная структура из всех. В здании — 5 этажей. Соответственно, от объединяющего этажи устройства потребуется наибольшее число портов. Из устройств такого рода, предлагаемых фирмой Cisco, для здания, А нам наиболее подходит серия Cisco Catalyst 4500. Cisco Catalyst 4500 — серия коммутаторов, предназначенных для использования в узлах корпоративных сетей, филиалах крупных корпораций и магистральных узлах, где необходимо использование коммутации третьего уровня. Серия Cisco Catalyst 4500 представляет из себя серию модульных коммутаторов, которые поддерживают любой из трех типов управляющих модулей (Supervisor Engine) и исчерпывающую линейку интерфейсных модулей с портами высокой плотности, включающими модули с портами 10/100, 10/100/1000 (с поддержкой технологии Power over Ethernet и без), 100-FX и 1000BASE-X. Серия коммутаторов Cisco Catalyst 4500 является дальнейшим развитием серии коммутаторов Catalyst 4000. Устройства серии Catalyst 4500 обеспечивают неблокируемую коммутацию на уровнях L2/¾ с огромным выбором функций для построения мультисервисных сетей, а также функций по обеспечению резервирования. Серия Catalyst 4500 состоит из следующих типов шасси: Catalyst 4510R (10 слотов), Catalyst 4507R (7 слотов), Catalyst 4506 (6 слотов), Catalyst 4503 (3 слота). Все типы шасси обладают возможностью резервирования источников питания, интеграции inline-power для IP-телефонии, программных и аппаратных функций реализации отказоустойчивости. Ко всему прочему, шасси: Catalyst 4510R и Catalyst 4507R обладают возможностью резервирования модуля супервизора.

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

Структура сети здания A показана на рис. 3:

Рис. 3. Структура сети в здании А

Рис. 4 Пример организации подключения компьютеров на 1этаже к стеку коммутаторов

Помимо стеков коммутаторов этажей к коммутатору здания, А будут подключаться и корпоративные серверы (такие как WINS, DNS, DHCP). С этой целью в Cisco Catalyst 4500 есть некоторый запас портов. Описание использования этих портов — в соответствующих разделах.

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

Но в связи с большим числом рабочих станций в здании B (1096) было принято решение выделить отдельный стек коммутаторов под каждый отдел. Состав стеков в каждом отделе приведен в табл. 3.

Таблица 3. Состав стеков коммутаторов в здании B

Отдельный коммутатор Сisco Catalyst 2960 предполагается выделить для подключения различных серверов в здании B (DHCP, WINS, Active Directory).

Филиал, располагающийся в здании B, подключается к головному офису по линии E1. Необходимо выбрать пограничное устройство (маршрутизатор), располагающийся в здании B и обеспечивающий связь с главным офисом A. Выбор устройства осуществим среди продуктов компании Сisco. Наиболее подходящими маршрутизаторами для подключения удаленных офисов являются устройства серии Сisco MC3810.

Помимо этого, маршрутизаторы этой серии поддерживают функции межсетевого экрана с учётом состояний, а также механизм защиты от атак Cyber Attack Defense Engine, приостанавливающий типичные атаки на сети, обеспечивая высокий уровень доступности критически важных Интернет-приложений. Кроме того, межсетевой экран поддерживает механизм адресации NAT и возможность переадресации портов.

Мультисервисная платформа Cisco MC3810 с интегрированным доступом дает возможность организациям объединять голосовой, факс и видео трафик с трафиком данных в одну общую сеть. Cisco MC3810 может внедряться поверх частных или общих сети, существенно сокращая количество оборудования и стоимость связи, упрощая управление сетью и улучшая производительность приложений. Cisco MC3810 объединяет коммутируемый голос и сетевой трафик для передачи поверх сетей Frame Relay, ATM или выделенным линиями со скоростями вплоть до T1/E1. Cisco MC3810 создан на базе программного обеспечения Cisco IOS и оптимизирован для работы со всеми маршрутизаторами, основанными на IOS, Cisco IGX 8400 и LightStream1010.

Но маршрутизатор имеет только 2 порта 10/100. Поэтому необходимо еще одно устройство, которое объединит 3 стека коммутаторов отделов (Catalyst 2960) и один коммутатор серверов (для объединения серверов поставим 20-портовый Catalyst 2960). Также это устройство должно поддерживать VLAN. Выберем для этих целей коммутатор Catalyst 2960 20-Port, который имеет 20 порта с автоопределением скорости 10BASE-T/100BASE-TX/1000BASE-T, 2 из них являются комбо-портами (порт RJ-45 или SFP Gigabit слот). Схема сети в здании B — на рис. 5.

Рис. 5. Структура сети здания B

В здании С — 2 этажа, на каждом из которых располагается отдел. Число рабочих станций в одном отделе невелико (90 и 88). Структура сети здания С будет в целом такая же, как в здании B. Стеков коммутаторов будет не 3, а 2. Поскольку здание C подключается к главному офису не по линии E1, а по ADSL, то необходимо использовать маршрутизатор Cisco SB100.

3. РАЗМЕЩЕНИЕ БАЗОВЫХ СЕТЕВЫХ СЕРВЕРОВ DNS, DHCP, WINS, КОМПОНЕНТОВ ACTIVE DIRECTORY

3.1 Размещение серверов DNS

Прежде чем приступать к проектированию структуры Active Directory, рассмотрим сначала реализацию DNS. Предполагается применить нестандартный подход, а именно — использовать т. н. разделение DNS (split-brain DNS). Разделенный DNS делает ресурсы доступными, прозрачными и независимыми по расположению для внешних и для внутренних пользователей. Под прозрачностью понимается, что пользователю не нужно использовать различные имена или перенастраивать клиентские приложения на использование разных имен в зависимости от его местоположения в настоящий момент.

Разделение DNS работает за счет того, что используется 2 или больше доступных серверов DNS, предназначенных для этого имени домена. Один или больше серверов отвечают за разрешение имен для хостов внутренней сети, другие же (один или больше) серверы отвечают за разрешение имен для хостов в Internet.

Сервер DNS, ответственный за разрешение имен во внутрикорпоративной сети, содержит записи DNS, которые отображают имена серверов в их внутренние IP-адреса, которые и используются во внутренней сети. DNS-сервер; ответственный за разрешение имен для внешних пользователей, отображает имена во внешние IP-адреса, обеспечивая доступ к корпоративным ресурсам снаружи. Схема разделения DNS приведена на рис. 6:

Рис. 6. Разделение DNS

Как показано на рис. 6, внутренние серверы DNS размещаются в Intranet за сетевым экраном (firewall), а внешние серверы DNS устанавливаются в демилитаризованной зоне (DMZ) или в Internet. При этом только внутренние клиенты имеют доступ к внутреннему серверу DNS, хранящему адресную информацию о компьютерах внутренней сети. Запросы внешних клиентов о доменных Internet-именах и адресах организации выполняются внешним DNS-сервером. Любые запросы, идущие из Internet в Intranet, запрещены. Если на внутренний DNS-сервер приходит запрос о разрешении имени Internet, которого нет в локальном кэше, то запрос отправляется на внешний DNS-сервер. На внешнем сервере DNS, следует разрешить только запросы, исходящие из внутренней сети.

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

Для корпорации CorpUTY необходимо зарегистрировать домен второго уровня. Например, corputy.ru. Для обеспечения автономности сетей отдельных филиалов и рационального обмена служебной информацией через WAN, выделим в домене corputy.ru. два дочерних поддомена: manuf. corputy.ru. и res. corputy.ru соответственно для зданий B и C.

Согласно рекомендации технического задания, DNS-сервер будут базироваться на платформе Windows 2003 Advanced Server. Для обеспечения надежности с ним в паре будет работать еще один сервер (Secondary), который сможет обеспечивать работоспособность сети в случае выхода из строя первого сервера. В нашем случае оценивая вариант выхода из строя только первичного сервера, ввиду конкретно его технических или программных неисправностей, целесообразным будет размещение вторичного сервера в том же здании. Желательно только обеспечить его питание от другого источника, что бы в случае перебоя с электроэнергией сеть оставалась бы работоспособной. Обязательное наличие источников бесперебойного питания также подразумевается.

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

Для функционирования такой структуры необходимо на внутреннем DNS-сервере в качестве forwarder’а установить внешний DNS-сервер, а на внешнем DNS-сервере установить либо режим рекурсивного запроса к DNS провайдера, либо итеративный опрос DNS-серверов, начиная с корневых (root-hints). Форвардинг запросов будет осуществляться на кэширующий сервер, что позволит благодаря использованию кэша снизить нагрузку при обработке «внешних» запросов, так как в основной массе запросы будут касаться разрешения имен машин корпоративной сети.

В реализации структуры DNS главного здания участвуют 3 DNS-сервера: внутренний, внешний и сервер провайдера. Внутренний сервер отвечает за зоны main. corputy.ru (куда входят все отделы здания А), proj. corputy.ru (планируется создать специальный домен для проектов в Active Directory). Внешний сервер устанавливается в качестве forwarding-сервера для внутреннего для того, чтобы перенаправлять запросы, не разрешенные с помощью кэша. Внешний DNS-сервер, в свою очередь, отправляет рекурсивные запросы к DNS-серверу провайдера.

DNS-серверы в зданиях B пересылают неразрешённые запросы на DNS-сервер здания A.

Для того чтобы из здания C можно было разрешать имена компьютеров, располагающихся в здании B без нагрузки на DNS-серверы здания А, необходимо на DNS-сервере здания C создать так называемые зоны-заглушки или упрощённые зоны (stub-zone). Упрощенная зона представляет собой копию зоны, содержащую только те ресурсные записи, которые необходимы для локализации DNS-серверов, являющихся носителями полной версии зоны. Основное назначение упрощенной зоны — идентификация DNS-серверов, которые способны выполнить разрешение доменных имен, принадлежащих к этой зоне.

Таким образом, на DNS-сервере здания C будет создана stub-zone для каждой из зон здания A и для зоны здания B. А в качестве forwarder-DNS выступит DNS-сервер провайдера.

На всех внутренних DNS-серверах следует включить режим Dynamic DNS Updates, для того, чтобы узлы могли регистрировать свои записи в соответствующих зонах. Поскольку мы используем ADIZ, рекомендуется также включить режим безопасных обновлений (secure updates). В этом режиме администратор AD может определять, кому и какие действия разрешается выполнять над ресурсными записями DNS.

3.2 Размещение серверов WINS

Согласно заданию на курсовую работу, среди рабочих станций в сети корпорации есть машины под управлением ОС Windows 98, которые используют имена NetBIOS. Поэтому наряду с DNS в проектируемой сети должна быть реализована служба разрешения имен NetBIOS. Для этой цели необходимо установить серверы WINS.

Сервер WINS рассчитан на высокую нагрузочную способность и может один обслуживать компанию с 10−15 тысячами компьютеров. Имена NetBIOS являются 16-байтными адресами, которые однозначно идентифицируют узлы в сети. Этот адрес имеет длину в 15 знаков и 16-тый используется для однозначной идентификации службы, запущенной на системе, такой, например, как службы Сервера или Рабочей Станции. Основная цель использования WINS — это разрешение имен NetBIOS в IP-адреса. Как и в случае NT 4, системы, настроенные на использование службы WINS, при загрузке будут регистрировать свои имена NetBIOS и соответствующие им IP-адреса. В целях повышения надежности установим в главном здании 2 WINS-сервера, а в зданиях филиалов — по одному WINS-серверу.

Сервер WINS можно задействовать совместно с сервером DNS для разрешения имен NetBIOS. Для этого на сервере DNS используются записи типа WINS. Если сервер DNS снабжен адресом сервера WINS (при помощи записи WINS), то сервер DNS будет пытаться опрашивать сервера WINS для разрешения имен, не найденных в собственной базе данных.

Обычно серверы WINS можно разместить на контроллерах домена. Например, если Active Directory спланирована так, что имеется корневой домен, не содержащий пользователей и применяемый лишь как держатель имени домена и административных групп, то его контроллеры домена не очень загружены и могут выполнять дополнительные функции.

3.3 Размещение серверов DHCP

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

В спецификации протокола DHCP определяются два участника: DHCP-сервер и DHCP-клиенты. Служба клиента DHCP запрашивает у DHCP-сервера параметры для настройки стека протоколов TCP/IP. Служба сервера DHCP обрабатывает клиентские запросы, осуществляя выдачу в аренду IP-адреса из некоторого диапазона. Каждый адрес выделяется на определенный срок. По окончании этого срока хост должен либо продлить срок аренды, либо освободить адрес. Все удовлетворенные запросы пользователя фиксируются службой сервера DHCP в собственной базе данных. Подобное решение позволяет предотвратить выделение одного IP-адреса двум хостам. Одновременно с выдачей IP-адреса DHCP-сервер может также предоставить клиенту дополнительную информацию о настройках стека протоколов TCP/IP, такую как маска подсети, адрес шлюза и адреса серверов DNS и WINS.

В составе Windows Server 2003 реализован как DHCP-клиент (который устанавливается по умолчанию), так и DHCP-сервер (который может быть установлен и сконфигурирован администратором при необходимости).

Запрос к серверу DHCP посылается клиентом широковещательно, следовательно, не может выйти за пределы локальной подсети. Чтобы клиент из подсети, не соединенной непосредственно с DHCP сервером, мог получать от него IP адреса, необходимо убедиться, что маршрутизатор (в нашем случае, коммутатор 3 уровня), объединяющий подсети, поддерживал направление широковещательных сообщений DHCP, то есть поддерживал стандарт RFC 1542. В противном случае необходимо будет установить в каждой из подобных подсетей агент ретрансляции DHCP (DHCP Relay Agent) или сервер DHCP. Агент ретрансляции DHCP — это хост, который прослушивает подсети на наличие широковещательных сообщений DHCP/BOOTP и переадресовывает их на некоторый заданный DHCP-сервер. Использование агентов ретрансляции избавляет от необходимости устанавливать сервер DHCP в каждом физическом сегменте сети. Агент не только обслуживает прямые локальные запросы клиента DHCP и перенаправляет их на удаленные DHCP-серверы, но также возвращает ответы удаленных DHCP-серверов клиентам.

Поскольку для объединения подсетей в главном здании используется коммутатор Сisco Catalyst 4500, то нет необходимости ставить агент ретрансляции DHCP, так как выбранный коммутатор отвечает стандарту RFC 1542. В зданиях B и C используются маршрутизаторы, также поддерживающие этот стандарт. Поэтому необходимость использования агентов ретрансляции в проектируемой корпоративной сети отпадает.

Для повышения надежности во всех зданиях корпорации будем использовать по 2 DHCP-сервера в связи с довольно большим числом рабочих станций в них и для повышения надежности

Для того чтобы DHCP-сервер начал корректно работать, необходимо на нем настроить области (т. н. scopes). Область DHCP — административная группа, идентифицирующая полные последовательные диапазоны возможных IP-адресов для всех клиентов DHCP в физической подсети. Области определяют логическую подсеть, для которой должны предоставляться услуги DHCP, и позволяют серверу задавать параметры конфигурации, выдаваемые всем клиентам DHCP в подсети. Область должна быть определена прежде, чем клиенты DHCP смогут использовать сервер DHCP для динамической конфигурации TCP/IP.

В главном здании выделим 9 областей в соответствии с числом отделов. Пусть области отделов HR, Sales, IT, Exec, Bus, Acc, Project 1, Project 2 обслуживаются одним DHCP-сервером, а области отдела Project 3 — другим. В этом случае между серверами будет соблюдена пропорция 80/20 по количеству обслуживаемых рабочих станций, как и рекомендует Microsoft.

Настройка DHCP областей на каждом сервере включает следующее:

— Начальный адрес (start IP address);

— Конечный адрес (End IP address);

— Маска подсети (Subnet mask length);

— Исключения (Exclusions)

— Резервирование (Reservation).

Рассмотрим настройку DHCP-области на примере отдела HR: начальным адресом будет являться 10.69.4.1, конечным — 10.69.4.126. Маска подсети — 25 (то есть, 255.255.255.128), а диапазон статических адресов определим следующий: 10.69.4.1 — 10.69.4.10. Статические адреса могут использоваться, например, для конфиденциального сервера отдела, сервера печати или еще для каких-либо целей.

В здании B отдадим под управление одному DHCP-серверу отделы M1 и M2, а второму серверу — отдел P. Опять будет соблюдена пропорция количества обслуживаемых серверами рабочих станций 80/20, обеспечена некоторая отказоустойчивость.

В здании C выделим области (scopes) в соответствии с отделами R1 и R2. Наличие двух серверов DHCP в сети может при определённых условиях привести к её частичной или полной неработоспособности. Подобное было возможно в более старых ОС из-за того, что практически любой мог активизировать свой сервер DHCP. Для того чтобы этого не случилось, необходимо авторизовать установленные DHCP-серверы в Active Directory. В этом случае при попытке запустить службу DHCP происходит обращение к Active Directory, где просматривается список адресов IP для всех авторизованных в домене серверов DHCP. Если адреса рассматриваемого сервера нет, то служба DHCP будет автоматически на нем терминирована.

3.4 Разработка структуры Active Directory

Active Directory — это служба каталогов в Windows 2003 Server. Active Directory содержит каталог, в котором хранится информация о сетевых ресурсах и службы, предоставляющие доступ к этой информации. Ресурсы, хранящиеся в каталоге, такие, как данные, сведения о принтерах, серверах, базах данных, группах, службах, компьютерах, политике безопасности, — называются объектами (object). Active Directory встроена в Windows 2003 Server и обеспечивает:

— упрощенное администрирование;

— масштабируемость;

— поддержку открытых стандартов;

— поддержку стандартных форматов имен.

Active Directory иерархически упорядочивает ресурсы в домене — логическом объединении серверов и других сетевых ресурсов в единое имя домена. Домен является основной единицей репликации и безопасности в сети Windows 2003.

Логическая часть Active Directory включает в себя лес, деревья, домены и OU (организационные подразделения, ОП). Физическая часть — сайты и контроллеры домена. Пространство имен Active Directory будет базироваться на ранее описанной структуре доменных имен службы DNS.

Один домен способен поддерживать до 10 миллионов объектов каталога. Согласно этому утверждению, можно было бы для всей корпорации создать один домен. Однако при создании доменов следует руководствоваться другими критериями — не только количеством объектов, которые могут быть созданы в Active Directory.

Первый критерий — административная политика. Необходимо так спроектировать систему, чтобы ей было проще управлять.

Второй критерий — безопасность. Внутри домена действуют правила безопасности, не распространяющиеся за его пределы.

Третий критерий — размер. Управлять доменом с огромным числом пользователей может оказаться значительно сложнее, чем несколькими доменами с меньшим числом объектов.

Несмотря на то, что у однодоменной структуры есть свои преимущества (простота управления; меньшая стоимость; меньшее число администраторов; предельная емкость, равная емкости леса доменов), предпочтение при проектировании Active Directory в корпорации CorpUTYотдадим многодоменной структуре. А именно — лесу.

Одной из причин, по которым выбирается структура с несколькими доменами, является как раз безопасность. Если в организации существуют ОП, требования к безопасности которых существенно отличаются от остальных, то такие подразделения лучше выделить в отдельные домены. Проблема безопасности также тесно связана с полномочиями администраторов. Если взять администраторов единственного домена (а значит, и корневого домена в лесу), то по умолчанию они включены в такие группы как Domain Admins, Schema Admins, Enterprise Admins. Последние два наделены огромными полномочиями в рамках леса, которые нужны далеко не всем администраторам. Чтобы у администратора не было возможности самостоятельно включить себя в группу с обширным списком прав, целесообразно создавать корневой домен пустым — в котором нет пользователей, но есть учетная запись администратора предприятия. В остальных хранятся учетные записи пользователей и администраторов домена.

Создание пустого корневого домена для хранения в нем учетных записей администратора предприятия обязательно при наличии более чем одного дочернего домена или нескольких деревьев в лесу. В нашем случае дочерних доменов планируется создать как минимум 2 (для зданий B и C), поэтому создадим пустой корневой домен.

Пустой корневой домен играет и ещё одну важную роль. Это своего рода «хранитель имени» организации. Так как корневой домен дает имя всему лесу, то никакие изменения в нижележащей доменной структуре не отражаются в имени леса. Можно легко добавлять новые домены в лес или удалять их из леса.

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

Естественно, у структуры леса с пустым корневым доменом есть и недостаток — необходимость использовать 2 дополнительных сервера в качестве контроллеров домена. Но аппаратные требования к таким контроллерам невысоки, поэтому не будем принимать во внимание указанный недостаток.

Развертывание сетевой структуры начнем с пустого корневого домена corpUTY.ru. Дочерние домены будут выделены соответственно для главного здания (main.corputy.ru), здания B (manuf.corputy.ru) и здания C (res.corputy.ru). Также предполагается создать еще один дочерний домен с особой политикой безопасности (например, для проектов). Конфигурация этого домена будет меняться в зависимости от текущих проектов. Назовем его, например, proj.corputy.ru.

Заканчивая проектирование логической структуры Active Directory, надо сказать об организационных подразделениях (ОП), которые используются:

— для делегирования административных полномочий;

— для разграничения групповой политики;

— для рассортировки объектов;

— для ограничения числа объектов в контейнерах;

— для помощи в миграции.

Предполагается для каждого отдела создать ОП. Таким образом, в здании A будет 9 ОП, в здании B — 3 ОП, и в здании C — 2 ОП. В домене проектов (proj.corpiso.ru) организационные подразделения будут создаваться в соответствии с текущими проектами компании.

Перейдем к физической структуре Active Directory. Начнем её рассмотрение с сайтов. Сайт — это часть физической структуры Active Directory, совокупность одной или нескольких IP-подсетей, соединенных высокоскоростными каналами связи. Основная задача сайта — обеспечивать хорошее сетевое соединение.

Проектируемую корпоративную сеть можно представить как 3 области с качественными линиями связи LAN (они соответствуют сетям головного офиса и двух филиалов), которые соединены между собой линиями связи WAN, имеющими другое качество и пропускную способность. Следовательно, целесообразно представить физическую структуру сети в виде трех сайтов. Каждый сайт соответствует одному зданию корпорации. Отдельный сайт в Active Directory может включать несколько доменов. Сайт в здании A будет включать в себя 3 домена: пустой корневой, домен здания A и домен проектов. В зданиях B и C сайты будут содержать по одному домену.

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

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

Проектируя AD для крупного предприятия, стоит подумать об оптимальном расположении мастеров операций.

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

Мастер доменных имен (Domain Naming Master) также один на весь лес. Он отвечает за добавление в лес новых доменов, кроме существующих, и за добавление/удаление объектов кросс-ссылок на внешние каталоги. Эти операции может выполнять только администратор с правами Enterprise Admins, следовательно, как и мастера схемы, мастер доменных имен разместим в пустом корневом домене. Мастер доменных имен отвечает за то, чтобы имена доменов в лесу были уникальны. Когда добавляется новый домен, этот мастер обращается к серверу ГК в поисках такого имени. Именно поэтому он должен располагаться на одном сервере с сервером ГК. Компьютер, на котором располагается мастер доменных имен, не несет практически никакой нагрузки, так как домены в лес добавляются нечасто. Это позволяет поместить его на одном компьютере с мастером схемы. Он должен быть доступен из любой точки сети.

Имитатор PDC (PDC Emulator) прежде всего нужен для клиентов старого типа (ранее Windows 2000), так как, с их точки зрения, он играет роль главного контроллера домена. Помимо этого, он выполняет роль master browser для приложений, использующих NetBIOS. Он отвечает за срочное тиражирование изменений в AD, таких как смена паролей или блокировка учетных записей. Кроме того, он отвечает за аутентификацию пользователей, сменивших пароль.

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

Мастер относительных идентификаторов (Relative Identifier Master) хранит общий пул идентификаторов домена и выдает их контроллерам по мере необходимости, при этом обеспечивается уникальность RID в домене, переносит объекты из одного домена в другой: при переносе между доменами у учетной записи меняется DN и SID, а уникальный ID остается неизменным. Компьютер, выполняющий данную роль, относительно не загружен, поэтому может располагаться на тех же контроллерах, где и другие мастера доменных операций.

Мастер инфраструктуры (Infrastructure Master) периодически проверяет ссылки на отсутствующий на данном контроллере домена объект в доступной ему реплике базы AD. Для этого он обращается к ГК и проверяет, не изменились ли у объекта с данным GUID его DN и SID. Если они изменились, то соответствующие изменения вносятся в локальную реплику и тиражируются на остальные контроллеры в домене.

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

Учитывая все сказанное выше, предлагаем следующую схему размещения мастеров: в каждом домене устанавливается как минимум два сервера-контроллера домена, причем на первом сервере размещается ГК и мастер относительных идентификаторов. Этот же сервер выступает в роли форпоста при междоменной репликации. На втором сервере устанавливается имитатор PDC и мастер инфраструктуры.

Для поддержки целостности информации в сети, необходимо организовать репликацию AD. В Windows 2003 действует модель multi-master (нескольких главных), означающая, что на любом контроллере домена можно производить обновления в Active Directory. Однако, вместе с усложнением репликации в Windows 2003 Active Directory, здесь так же присутствует возможность более простого контроля процесса репликации, через использование сайтов, site links (связей сайтов) и работы по расписанию. В среде Active Directory контроллерам домена нет необходимости связываться с одним главным контроллером домена для получения изменений. Вместо этого, они создают связи друг с другом для отслеживания, какой контроллер домена будет выступать в качестве источника репликации изменений. Эти взаимоотношения называются connection objects (объекты-подключения). Процесс, который создает объекты подключения между контроллерами домена, запускается на всех контроллерах домена автоматически и называется Knowledge Consistence Checker (KCC — дословно: служба проверки непротиворечивости знаний). КСС стартует каждые 15 минут и вносит изменения в топологию объектов-подключения, если это необходимо (например, если какой-либо из контроллеров домена временно недостижим).

Внутрисайтовая репликация:

1) RPC over IP — Remote Presage Call over IP — асинхронный трафик, несжимаемый, не требует сертификатов.

2) SMTPасинхронный, сжатый, требует сертификата

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

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

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