1-31

advertisement
1. Обобщённая иерархическая структура корпоративной сети
2. Агрегация сетевого трафика и суммирование маршрутов
Агрегация достигается за счет объединения трафика, поступающего по
большому числу низкоскоростных каналов передачи информации, которые
связывают уровень распределения с устройствами уровня доступа, в
несколько широкополосных каналов, которые, в свою очередь, связывают
уровень распределения с ядром сети. Подобная стратегия порождает в сети
эффективные точки суммирования и уменьшает количество маршрутов.
Эта информация используется маршрутизаторами ядра при принятии
решения о коммутации пакетов.
3. Сегментирование сети с использованием маршрутизаторов
Несегментированная
Сегментированная
4. Разбиение на подсети с использованием VLAN.
Гибкое разделение устройств на группы
Как правило, одному VLAN соответствует одна подсеть. Устройства, находящиеся
в разных VLAN, будут находиться в разных подсетях. Но в то же время VLAN не
привязан к местоположению устройств и поэтому устройства, находящиеся на
расстоянии друг от друга, все равно могут быть в одном VLAN независимо от
местоположения
Уменьшение количества широковещательного трафика в сети
Каждый VLAN — это отдельный широковещательный домен. Например,
коммутатор — это устройство 2 уровня модели OSI. Все порты на коммутаторе, где
нет VLANов, находятся в одном широковещательном домене. Создание VLAN на
коммутаторе означает разбиение коммутатора на несколько широковещательных
доменов. Если один и тот же VLAN есть на разных коммутаторах, то порты разных
коммутаторов будут образовывать один широковещательный домен.
Увеличение безопасности и управляемости сети
Когда сеть разбита на VLAN, упрощается задача применения политик и правил
безопасности. С VLAN политики можно применять к целым подсетям, а не к
отдельному устройству. Кроме того, переход из одного VLAN в другой
предполагает прохождение через устройство 3 уровня, на котором, как правило,
применяются политики разрешающие или запрещающие доступ из VLAN в VLAN.
5. Установка и настройка базовых параметров Scope-области DHCP-сервера
DHCP (Dynamic Host Configuration Protocol/протокол динамической конфигурации узла)
— это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и
другие параметры, необходимые для работы в сети TCP/IP.
Добавление областей DHCP
На странице Добавление или изменение DHCP-областей (Add Or Edit DHCP Scopes),
можно определить или отредактировать области DHCP-сервера.
Область представляет собой административное группирование IP-адресов компьютеров в
подсети, использующей службу DHCP. Каждая подсеть может располагать лишь одной
DHCP-областью с единым непрерывным диапазоном IP-адресов.
Чтобы добавить новую область, щелкните кнопку Добавить (Add). Откроется диалоговое
окно Добавление области (Add Scope), Чтобы добавить новую область, щелкните кнопку
Добавить (Add). Откроется диалоговое окно Добавление области (Add Scope).
Создание области — самый важный аспект настройки DHCP-сервера. В следующем
списке указаны функции, которые можно конфигурировать для области в этом
диалоговом окне.
■ Имя области (Scope Name)
Это имя не играет роли для DHCP-клиентов, а лишь используется для области в
консоли DHCP
■ Начальный и конечный IP-адреса (Starting/Ending IP Address)
Во время определения диапазона IP-адресов для области следует
использовать последовательные адреса, составляющие подсеть, в которой будет
включена служба DHCP. Из этого определенного диапазона также следует исключить все
статические адреса для существующих или запланированных серверов в сети.
■ Маска подсети (Subnet Mask)
В это поле вводится значение маски подсети, которая будет назначена DHCP-клиентам,
арендующим адреса в этой области. Здесь следует указать ту же маску подсети, которая
отконфигурирована для самого DHCP-сервера.
■ Основной, шлюз (необязательно) (Default Gateway (optional))
В этом поле можно отконфигурировать опцию 003 Маршрутизатор (Router); она назначает
адрес основного шлюза DHCP-клиентам, арендующим адреса в этой области
■ Тип подсети (Subnet Type) В этом поле можно указать один из двух сроковаренды для
области. По умолчанию назначается тип подсети Проводной (Wired) со сроком аренды 6
дней. Для второго типа — Беспроводной (Wireless) — назначается срок аренды 8 ч.
■ Активировать эту область (Activate This Scope)
Аренду адресов может выполнять только активированная область. Этот флажок
активации новой области установлен по умолчанию.
6. Настройка передаваемых параметров Scope-области DHCP-сервера
Некоторыми из наиболее часто используемых опций являются:




IP-адрес маршрутизатора по умолчанию;
маска подсети;
адреса серверов DNS;
имя домена DNS.
Некоторые поставщики программного обеспечения могут определять собственные,
дополнительные опции DHCP.
7. Конфигурирование DHCP-клиента
?
8. Конфигурирование агента ретрансляции DHCP Relay Agent.
Если в сетевом сегменте между клиентскими системами и сервером DHCP установлены
маршрутизаторы, не отвечающие по своим характеристикам ряду стандартов, описанных
в соответствующих документах RFC, могут возникнуть разнообразные проблемы. Эту
проблему можно решить, разместив в локальной сети агент ретрансляции DHCP, который
не является сервером DHCP, а передает запросы реальному серверу DHCP. Агент
ретрансляции DHCP должен выполняться на компьютере под управлением серверной
системы Windows.
1. Зарегистрируйтесь с правами администратора в системе под управлением Windows
Server.
2. Откройте меню Сеть (Network) в окне Панель управления (Control Panel) (Пуск >
Настройка > Панель управления > Сеть (Start > Settings > Control Panel > Network)) или
кликните правой кнопкой мыши на значке Сетевое окружение (Network Neigborhood) и
выберите в контекстном меню команду Свойства (Properties).
3. Перескочите на вкладку Службы (Services) и кликните на кнопке Добавить (Add).
4. Выберите раздел Агент ретрансляции DHCP (DHCP Relay Agent) и кликните на
кнопке OK.
5. Введите путь к файлам (например, d:\i386) и кликните на кнопке OK.
6. Будет выдан запрос на добавление IP-адреса в список серверов DHCP. Кликните на
кнопке Да (Yes).
7. Перескочите на вкладку DHCP Relay и кликните на кнопке Добавить (Add).
8. В поле DHCP Server введите IP-адрес сервера DHCP и кликните на кнопке Добавить
(Add).
9. Кликните на кнопке OK.
10. Перезагрузите компьютер.
9. Конфигурирование Scope-областей двух DHCP-серверов в одном
широковещательном домене.
?
10. Планирование DHCP Relay Agent’ов в корпоративной сети.
Широковещательные запросы DHCP могут быть исключениями, в зависимости от типа
маршрутизатора. Если маршутизатор следует стандарту RFC 1542 и на нем включена
возможность передачи запросов BOOTP, то маршрутизатор будет передавать между
сетями пакеты DHCP Discover. Если маршрутизаторы не соответствуют стандарту RFC
1542 и у сервера DCHP в одной подсети есть клиенты в нескольких подсетях, есть два
пути решения проблемы:


Приобрести новый маршрутизатор, совместимый со стандартом RFC 1542
Настроить сервер Windows, поддерживающий службу Маршрутизация и
удаленный доступ (Routing and Remote Access), выступать в качестве агента
ретрансляции запросов DHCP
11. Рекурсивные запросы DNS
Если сервер DNS не знает адрес запрашиваемого сайта, то он использует один из двух
методов для определения IP адреса сайта.
Предпочтительный метод преобразования имени в адрес называется рекурсией (recursion).
Если говорить в общем, то рекурсия это процесс, при котором сам сервер DNS отправляет
запросы на другие сервера DNS, для того чтобы затем по обратной цепочке передать ответ
клиенту, который совершил запрос. В общем, DNS сервер становится DNS клиентом.
Некоторые администраторы предпочитают отключить рекурсию в целях увеличения
производительности. Если рекурсия отключена, то сервер DNS использует процесс,
называемый итерация (iteration), для обработки запроса.
12. Итеративные запросы DNS
При итеративном запросе сервер имен должен сразу предоставить ответ, не обращаясь к
другим DNS-серверам. Если этот сервер не может предоставить запрошенную
информацию, он возвращает ссылку на другой сервер имен, который, вероятно, может
дать ответ. Задача поиска ответа на запрос перекладывается на первый запрашивающий
сервер.
13. Основные типы и форматы ресурсных записей DNS
A
Address
1
Адресная запись, соответствие
между именем и IP-адресом
A+1+1+1 (A
использовался для
AAAA
28 Адрес в формате IPv6
IPv4, AAAA для
IPv6)
одна из самых часто
используемых записей
эквивалента А для IPV4
CNAME Canonical name
широко используется
(но имеет ограничения
по применению)
MX
критически важна для
SMTP-протокола,
основа маршрутизации
почты в Интернете
NS
Каноническое имя для
5 псевдонима (одноуровневая
переадресация)
Адрес почтового шлюза для
домена. Состоит из двух
Mail Exchanger
15 частей — приоритета (чем число
больше, тем ниже приоритет), и
адреса узла
Адрес узла, отвечающего за
Authoritative name
доменную зону. Критически
2
server
важна для функционирования
самой системы доменных имён
Реализует механизм
переадресации
DNS
широко используется
для IPv4-адресов в
домене in-addr.arpa, для
IPv6 — в ip6.arpa
PTR
Domain name
pointer
12
SOA
Start of authority
Указание на авторитетность
6 информации, используется для
указания на новую зону
Text string
Sender Policy Framework
Запись произвольных двоичных
16
(устарело), DNSданных, до 255 байт в размере
туннели
TXT
DNS
14. Первичная зона DNS. Формат ресурсной записи SOA.
Запись SOA (Start of Authority) означает, что сервер имен DNS является лучшим
источником информации для этого домена. Записи SOA также содержат адрес
электронной почты ответственного лица для зоны, признак модификации зонного файла
базы данных, а также используются для установки таймеров, определяющих
периодичность обновления копий зонной информации другими серверами.
15. Вторичная зона DNS
За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным,
primary, остальные - вторичными, secondary. Первичный сервер содержит оригинальные
файлы с базой данных DNS для своей зоны. Вторичные серверы получают эти данные по
сети от первичного сервера и периодически запрашивают первичный сервер на предмет
обновления данных (признаком обновления данных служит увеличение серийного номера
в записи SOA - см. ниже). В случае, если данные на первичном сервере обновлены,
вторичный сервер запрашивает "передачу зоны" ("zone transfer")- т.е. базы данных
требуемой зоны. Передача зоны происходит с помощью протокола TCP, порт 53 (в
отличие от запросов, которые направляются на UDP/53).
Изменения в базу данных DNS могут быть внесены только на первичном сервере. С точки
зрения обслуживания клиентских запросов первичный и вторичные серверы идентичны,
все они выдают авторитативные ответы. Рекомендуется, чтобы первичный и вторичные
серверы находились в разных сетях - для увеличения надежности обработки запросов на
случай, если сеть одного из серверов становится недоступной. Серверы DNS не обязаны
находиться в том домене, за который они отвечают.
Примечание. Вторичный сервер необязательно получает данные непосредственно с
первичного сервера; источником данных может служить и другой вторичный сервер. В
любом случае сервер-источник данных для данного вторичного сервера называется
"главным" ("master"). Далее в этом разделе считается, что вторичный сервер получает
данные зоны непосредственно с первичного сервера.
16-17. Алгоритм разрешения DNS-имени на клиенте/сервере
Алгоритм разрешения имен достаточно прост. Когда программе-клиенту требуется по
доменному имени выяснить IP-адрес, она связывается с сервером имен, адрес которого
указан в настройках TCP/IP.
Чтобы программное обеспечение пользовательского компьютера
могло осуществлять преобразование доменных имен в IP-адреса, в
настройках TCP/IP обязательно должен быть указан адрес хотя бы
одного сервера имен.
Сервер имен, получив запрос, рассматривает его, чтобы выяснить, в каком домене
находится указанное имя. Если указанный домен входит в его зону ответственности, то
сервер преобразует имя в IP-адрес на основе собственной базы данных и возвращает
результат клиенту. В случае же, когда сервер имен не способен самостоятельно
осуществить преобразование из-за того, что запрашиваемое доменное имя не входит в его
зону, он опрашивает известные ему другие сервера имен с целью получения результата.
Для функционирования серверу имен не обязательно знать адреса всех остальных DNSсерверов Интернет. Достаточно располагать адресами серверов имен корневого домена.
Как правило, эта информация изначально и постоянно присутствует в программахсерверах. Очевидно также, что сервер имен должен знать адреса DNS-серверов
делегированных зон.
Порядок взаимодействия DNS-клиента с сервером для обеспечения разрешения имен
определяется специальным протоколам DNS. Этот протокол предусматривает свой
формат сообщения (пакета) и использует для доставки данных транспортные протоколы
UDP и TCP как нижележащие.
Задачи, решаемые сервисом DNS, являются относительно простыми, поэтому DNSсообщение устроено несложно: оно включает в себя:




поле заголовка, определяющее тип сообщения (например, "запрос клиента", "ответ
сервера" и т.д.);
поле запроса, в котором клиент указывает разрешаемое имя и параметры запроса;
поле ответа, в которое сервер помещает результат обработки запроса;
два служебных поля передачи для управляющей и дополнительной информации.
18. Сервисные записи SRV службы DNS
Служебная запись (SRV-запись) — стандарт в DNS, определяющий местоположение, то
есть имя хоста и номер порта серверов для определенных служб. Определяется в RFC
2782. Некоторые Интернет-протоколы, такие как SIP и XMPP, часто требуют поддержки
SRV-записей.
SRV-запись имеет такой формат:
_service._proto.name TTL class SRV priority weight port target
service: символьное имя сервиса.
proto: транспортный протокол используемый сервисом, как правило TCP или UDP.
name: доменное имя, для которого эта запись действует.
TTL: стандарт DNS, время жизни.
class: стандарт DNS, поле класса (это всегда IN).
priority: приоритет целевого хоста, более низкое значение означает более
предпочтительный.
weight: относительный вес для записей с одинаковым приоритетом.
port: Порт TCP или UDP, на котором работает сервис.
target: канонические имя машины, предоставляющей сервис.
Как и в MX-записях, хост в SRV-записи должен указывать на адрес (A- или AAAAзапись). Hostname-псевдоним (CNAME-запись, en:CNAME record) не может быть
использован как допустимый параметр.
19. DNS серверы кэширования. Примеры использования.
Все серверы DNS кэшируют запросы, которые удалось разрешить. Однако среди этих
серверов имеются специальные серверы кэширования, которые только выполняют
запросы, кэшируют ответы и возвращают результаты. Они не являются удостоверяющими
серверами для какого-либо домена, а информация, которую они содержат, ограничивается
той, что была кэширована при разрешении запросов.
При определении необходимости использования сервера такого типа следует учитывать,
что в момент запуска этот сервер вообще не содержит кэшированной информации.
Информация накапливается со временем по мере обслуживания запросов клиентов.
Однако если работа ведется в глобальной сети с медленными связями между узлами, такая
возможность может оказаться полезной, поскольку по мере заполнения кэша трафик
снижается. Кроме того, сервер кэширования не выполняет передачу зон, которая также
увеличивает нагрузку в глобальной сети.
20. Конфигурирование DNS сервера пересылки
Сервер пересылки - это DNS-сервер в сети, который пересылает DNS-запросы внешних
DNS-имен на DNS-серверы за пределами этой сети. Сервер также можно настроить на
пересылку запросов в соответствии с определенными именами домена, используя
условную пересылку.
DNS-сервер используется как сервер пересылки, когда другие DNS-серверы в сети
настроены на переадресацию запросов, которые не могут быть разрешены локально, на
этот DNS-сервер. С помощью сервера пересылки можно управлять разрешением имен для
имен, находящихся за пределами организации, например в сети Интернет, что может
способствовать увеличению эффективности разрешения имен для компьютеров в сети.
Дополнительные сведения об использовании серверов пересылки и условной пересылки
см. в разделе Общее представление о серверах пересылки.
21. Зоны-заглушки stub zones DNS
Зоны заглушки — это такие зоны (stub zone), которые не содержат никакой информации о
членах домена соответствий имя-ip, а только служит для переадресации запросов к списку
назначенных серверов для различных доменов. То есть по сути, эта зона просто
перенаправляет конкретные зоны на конкретный список серверов.
22. Динамическая регистрация записей DNS
В традиционном DNS записи о ресурсах зоны вносятся и корректируются вручную, что
не всегда удобно, особенно в связи с использованием DHCP сервисов, динамически
распределяющих IP-адреса при подключении компьютеров к сети. Для облегчения
администрирования записей DNS был разработан стандарт динамического DNS (DDNS Dynamic DNS). Он позволяет авторизованным серверам, например серверам,
выполняющим авторизацию клиентов в сети, автоматически обновлять записи ресурсов
зоны на сервере DNS.
Динамические обновления могут выполняться при любом из следующих условий или
событий.
IP-адрес добавлен, удален или изменен в конфигурации свойств TCP/IP для любого из
установленных сетевых подключений.
Изменена или обновлена аренда IP-адреса на DHCP-сервере для любого из
установленных сетевых подключений. Например, когда запускается компьютер
или используется команда ipconfig /renew.
С помощью команды ipconfig /registerdns вручную принудительно обновляется
регистрация имени клиента в DNS.
Компьютер запускается при его включении.
Когда одно из перечисленных событий запускает динамическое обновление, обновления
отправляются службой DHCP-клиент (а не службой DNS-клиент). Такая возможность
разработана для того, чтобы при изменении IP-адреса службой DHCP, в DNS выполнялись
соответствующие обновления для синхронизации сопоставления имени и адреса
компьютера. Служба DHCP-клиент выполняет эту функцию для всех сетевых
подключений, используемых компьютером, в том числе для подключений, не
настроенных на использование DHCP.
23. Взаимодействие DHCP и DNS при динамическом обновлении записей DNS
DNS-серверы обеспечивают разрешение имен для сетевых ресурсов и тесно связаны со
службой DHCP. DHCP-серверы и DHCP-клиенты могут осуществлять динамическую
регистрацию выдаваемых IP-адресов и ассоциированных с ними доменных имен в базе
данных DNS-сервера. При этом в базе данных DNS-сервера создаются ресурсные записи
типа PTR (указатель) и А (адрес).
24. Конфигурирование DHCP-сервера при динамической регистрации записей DNS
Если нужно, чтобы регистрация доменных имен выполнялась непосредственно на уровне
DHCP-сервера, необходимо в окне свойств объекта, ассоциированного с сервером,
перейти на вкладку DNS и установить флажок Enable DNS dynamic updates according to the
settings below (Разрешить динамические обновления в DNS в соответствии со
следующими настройками) Дополнительно нужно выбрать условия регистрации
доменных имен в базе данных DNS. Сервер DHCP будет посылать сообщение службе
DNS каждый раз, когда клиенту выдается IP-адрес.
25. Конфигурирование DNS клиента
Задача клиента - взаимодействие с DNS-сервером, который будет, по запросу клиента,
выполнять описанные выше преобразования. При ручном конфигурировании DNSклиента указываются:



имя хоста,
домен, в котором находится данный хост,
IP-адрес сервера DNS, обслуживающего этот домен.
Получение всех этих данных возможно автоматически - в случае конфигурирования стека
TCP/IP с помощью DHCP-сервера, либо их выдает администратор сети
26. Конфигурирование DNS сервера.
?
27. Логическая структура AD. Схема AD. Классы объектов, атрибуты. Домен, дерево,
лес.
Логическая структура Active Directory по сути представляет собой контейнеры, которые
используются для хранения объектов службы каталога (разделов каталога, доменов и
лесов) на предприятии. Что бы это понять проще так и представляйте себе некий
контейнер в котором хранится все остальное, в том числе и другие контейнеры, ну что то
наподобие матрешки.Логическая структура иди группировка позволяет отыскивать
сетевые ресурсы по именам, не запоминая их физическое местоположение. Исходя из того
что все ресурсы сети группируются по логическому принципу физическая структура сети
не видна пользователям. Отношения между доменами, подразделениями и лесами
отражено на рисунке 6.
Ресурсы хранятся в AD как объекты. Объекты хранятся в виде контейнеров и
подконтейнеров. По сути, объект в AD – набор атрибутов. Атрибуты, образующие объект,
определяются классом объекта.
28. Типы отношений доверия между доменами AD. Функциональные уровни домена,
леса.
?
29. Физическая структура AD. Сайты, подсети, контроллеры домена.
Контроллер домена - это компьютер на котором установлен Windows Server 2003, и
который поддерживает копию базы данных службы Active Directory. То есть это как
правило сервер на котором установлена операционная сетевая система Windows Server
2000 или Windows Server 2003 и как говорят администраторы "поднята" (установлена)
служба каталогов Active Directory.
Наличие в домене нескольких контроллеров домена повышает отказоустойчивость. В
случае если один контроллер домена по тем или иным причинам отказал, все функции по
обеспечению работоспособности нашего домена берет на себя оставшиеся контроллеры
домена.
Контроллеры домена регулируют все аспекты взаимодействия пользователей с с доменом.
В частности помогают найти объекты Active Directory, осуществляют контроль попыток
регистрации пользователей и другое.
айт (site) или узел представляет собой часть от общей сети предприятия.
Сайты сведены между собой.
Или, суммируя все сказанное Сайт - представляет собой совокупность подсетей, соединенных между собой
высокоскоростными линиями связи.
Предполагается (или так лучше всего делать) что сайты соединяются друг с другом
высокоскоростными линиями связи (но в жизни бывает и не так).
Получается что сайт — это группа компьютеров в одной или нескольких IP-подсетях,
используемая для планирования физической структуры сети. Планирование сайта
происходит независимо от логической структуры домена. Active Directory позволяет
создать множество сайтов в одном домене или один сайт, охватывающий множество
доменов. Также нет связи между диапазоном IP-адресов сайта и пространством имен
домена.
30-31. Роли хозяина/мастера операций на уровне леса/домена AD.
Некоторые операции уровня домена или предприятия, для которых не может
выполняться обновление с несколькими хозяевами, выполняются только на одном
контроллере домена в рамках домена или леса Active Directory. Контроллеры домена,
выполняющие подобные операции, называются хозяевами операций или обладателями
ролей FSMO (Flexible Single Master Operations).
Ниже перечислены 5 ролей FSMO, существующие в лесу Active Directory, и
операции, выполняемые обладателями этих ролей:
• Хозяин схемы. Роль хозяина схемы — это роль уровня леса. В каждом лесу
существует один хозяин схемы. Хозяин схемы выполняет расширение схемы леса Active
Directory. Кроме того, хозяин схемы необходим для выполнения команды adprep
/forestprep.
• Хозяин именования домена. Роль хозяина именования домена — это роль уровня
леса. В каждом лесу существует один хозяин именования домена. Хозяин именования
домена выполняет удаление и добавление доменов и разделов приложений в лесу.
• Хозяин RID. Роль хозяина RID — это роль уровня домена. В каждом домене
существует один хозяин RID. Хозяин RID выполняет выделение идентификаторов RID,
которые необходимы контроллерам домена для создания групп безопасности, а также
учетных записей пользователей и компьютеров.
• Эмулятор PDC. Роль эмулятора PDC — это роль уровня домена. В каждом домене
существует один эмулятор PDC. Эмулятор PDC — это контроллер домена, отправляющий
обновления базы данных резервным контроллерам домена Windows NT. Эмулятор PDC
также используется некоторыми средствами администрирования и получает обновления
паролей учетных записей пользователей и компьютеров.
• Хозяин инфраструктуры. Роль хозяина инфраструктуры — это роль уровня домена.
В каждом домене существует один хозяин инфраструктуры. Хозяин инфраструктуры
необходим для успешного выполнения команды adprep /forestprep, а также для обновления
идентификаторов SID и различающихся имен объектов при использовании междоменных
ссылок.
32. Планирование размещения хозяев операций на уровне домена AD.
?
Download