1. Обобщенная структура территориально распределенной корпоративной сети Типовые методы объединения отдельных сетей офисов в единую кспд
 Скачать 3.9 Mb.
|
|
широковещательном домене. 1 вариант: Особенности DHCP: a. Если слетел – быстро восстановить b. Минимум два сервера (они обслужат всю сеть) Есть два DHCP-сервера в одном широковещательном домене. Если количество адресов ad, то 0.4ad - развитие Объявляем весь scope1 и у первого сервера исключаем адреса второго (но область широковещательного диапазона одна и название одно), а у второго сервера исключаем адреса первого. Настройка передаваемых параметров: 003 – IP-адрес роутера 006 – DNS сервер 015 – DNS domain name 044 – WINS server 046 – NETBIOS server 2 вариант: Используем два DHCP сервера – расположены в разных серверных контейнерах (?). Создаем одну scope-область для обоих серверов, которую будем между ними разделять. Величина диапазона: рассчитываем необходимое нам количество адресов, увеличиваем на какой-либо процент (40%;60 %) – для «запаса». Получившееся количество адресов увеличиваем вдвое – для 2х серверов. ad*(1+0,4)*2 Для каждого сервера: - объявляем полный диапазон - исключаем служебные адреса - исключаем одну из половин выделенной области (в зависимости от сервера) - прописываем все стандартные настройки (DG, DNS, domain name, WINS, NetBIOS 33 27. DHCP snooping DHCP snooping — функция коммутатора, предназначенная для защиты от атак с использованием протокола DHCP. Например, атаки с подменой DHCP-сервера в сети или атаки DHCP starvation, которая заставляет DHCP-сервер выдать все существующие на сервере адреса злоумышленнику. DHCP snooping регулирует только сообщения DHCP и не может повлиять напрямую на трафик пользователей или другие протоколы. Некоторые функции коммутаторов, не имеющие непосредственного отношения к DHCP, могут выполнять проверки на основании таблицы привязок DHCP snooping (DHCP snooping binding database). В их числе: Dynamic ARP Protection (Inspection) — проверка ARP-пакетов, направленная на борьбу с ARP- spoofing, IP Source Guard — выполняет проверку IP-адреса отправителя в IP-пакетах, предназначенная для борьбы с IP-spoofing-ом. DHCP snooping позволяет: защитить клиентов в сети от получения адреса от неавторизованного DHCP-сервера, регулировать какие сообщения протокола DHCP отбрасывать, какие перенаправлять и на какие порты. Для правильной работы DHCP snooping, необходимо указать какие порты коммутатора будут доверенными (trusted), а какие — нет (untrusted, в дальнейшем — ненадѐжными): Ненадѐжные (Untrusted) — порты, к которым подключены клиенты. DHCP-ответы, приходящие с этих портов отбрасываются коммутатором. Для ненадѐжных портов выполняется ряд проверок сообщений DHCP и создаѐтся база данных привязки DHCP (DHCP snooping binding database). Доверенные (Trusted) — порты коммутатора, к которым подключен другой коммутатор или DHCP- сервер. DHCP-пакеты полученные с доверенных портов не отбрасываются. Принцип работы: По умолчанию коммутатор отбрасывает DHCP-пакет, который пришел на ненадѐжный порт, если: Приходит одно из сообщений, которые отправляет DHCP-сервер (DHCPOFFER, DHCPACK, DHCPNAK или DHCPLEASEQUERY); Приходит сообщение DHCPRELEASE или DHCPDECLINE, в котором содержится MAC-адрес из базы данных привязки DHCP, но информация об интерфейсе в таблице не совпадает с интерфейсом, на котором был получен пакет; В пришедшем DHCP-пакете не совпадают MAC-адрес указанный в DHCP-запросе и MAC-адрес отправителя; Приходит DHCP-пакет, в котором есть опция 82. Порядок настройки 1. Настройка и проверка работы DHCP-сервера и DHCP-ретранслятора без включенного DHCP snooping. 2. Включение DHCP snooping. После включения DHCP snooping на коммутаторе и в соответствующих VLAN, все порты коммутатора по умолчанию считаются ненадѐжными. 3. Указание доверенных портов. Те порты, к которым подключены коммутаторы и которые ведут к DHCP-серверу (или порты, к которым сервер подключен), должны быть настроены как доверенные. 4. Настройка политики обработки опции 82. 5. (Опционально) Включение или выключение дополнительных проверок DHCP-сообщений. После того, как DHCP snooping включен на коммутаторе, по мере выдачи адресов клиентам, начинает заполняться база данных привязки DHCP. В базе данных привязки DHCP хранятся (информация хранится только о ненадѐжных портах): MAC-адрес клиента Арендованный IP-адрес клиента Время аренды в секундах Идентификатор VLAN Идентификатор порта, к которому присоединен клиент 34 Включить DHCP snooping: sw2(config)# ip dhcp snooping Включить DHCP snooping в VLAN, которые должны быть защищены с его помощью: sw2(config)# ip dhcp snooping vlan 10 По умолчанию на коммутаторе все порты ненадѐжные, поэтому доверенные порты надо явным образом указывать. Указать доверенные порты: sw2(config)# interface fa 0/1 sw2(config-if)# ip dhcp snooping trust (Опционально) Указать адрес авторизованного DHCP-сервера, доступного через доверенный порт: sw2(config)#ip dhcp-server 10.84.168.253 Настройка remote ID (по умолчанию используется MAC-адрес коммутатора): sw2(config)# ip dhcp snooping information option format remote-id [string ASCII-string | hostname] Настройка политики обработки пакетов с опцией 82. Коммутатор не будет отбрасывать пакеты, в которых есть опция 82: sw2(config)# ip dhcp snooping information option allow-untrusted Отключить вставку опции 82: switch(config)# no ip dhcp snooping information option 35 28. Первичная и вторичная зона, зона – заглушка (stub zone) DNS. Зона в DNS — это часть пространства имѐн DNS, управляемая конкретным сервером или группой серверов DNS. Зоны прямого просмотра - это такой тип зоны, в котором на запрос имени — получают ответ в виде IP-адреса, например: ping localhost ответ 127.0.0.1 Зона обратного просмотра - это зона, выполняющая противоположную роль зоне прямого просмотра, из IP узнаем имя машины в сети, например: ping-a 127.0.0.1 ответ localhost [127.0.0.1] Первичная зона — это зона (primary zone), которая находится на корневом сервере данной зоны, то есть сервер с такой зоной — это тот сервер, который держит данную зону и все изменения производятся непосредственно в этой зоне (При условии, если это не интегрированная зона в Active Directory). Вторичная зона — это зона (secondary zone), которая создается для разгрузки и резервирования первичной зоны. Это копия первичной зоны, только для чтения, но не изменения. Все изменения делаются в первичной зоне, а затем они передаются с сервера с первичной зоны на сервер, держащий вторичную зону. Зоны заглушки — зона, в которой не содержится никакой информации о членах домена и которая служит просто для перенаправления запросов к списку назначенных серверов имен для различных доменов. Следовательно, в такой зоне могут содержаться только записи NS, SOA и связанные записи. Связанные записи (glue records) представляют собой, по сути, записи А, которые используются в сочетании с конкретной записью NS для преобразования IP-адреса того или иного сервера имен. Сервер, который обслуживает зону-заглушку какого-либо пространства имен, полномочным для нее не является. Зоны-заглушки можно использовать в следующих целях: Поддержка самых текущих сведений о зоне. С помощью регулярного обновления зоны-заглушки для одной из дочерних зон DNS-сервер, содержащий как родительскую зону, так и зону-заглушку, будет поддерживать текущий список полномочных DNS-серверов для дочерней зоны. Улучшение разрешения имен. С помощью зон-заглушек DNS-сервер может выполнять рекурсию, используя список серверов имен из зоны-заглушки, без необходимости отправки запроса о пространстве имен DNS в Интернет или на внутренний корневой сервер. Упрощение администрирования DNS. С помощью использования зон-заглушек в инфраструктуре DNS можно распределить список полномочных DNS-серверов для зоны без необходимости использования дополнительных зон. Однако назначение зон-заглушек отличается от назначения дополнительных зон, и зоны-заглушки не являются альтернативой увеличению избыточности и распределению нагрузки. 36 29. Основные типы и форматы ресурсных записей DNS. Ресурсные записи DNS — записи о соответствии имени и служебной информации в системе доменных имен, которые Вы можете редактировать в описанных ниже полях: Поле «Имя», предполагает несколько вариантов заполнения и, в зависимости от введенных данных, будет указывать на зону редактирования (на страницу, на которой Вы находитесь или на другие, на домен или поддомен) и влияет на перенаправление по требуемому адресу. Поле «Тип» записи отвечает за разные типы запросов (например, запрос был отправлен из браузера с целью отображения сайта, или из почтовой программы с целью отправки почты на соответствующий почтовый домен). Значение или адрес, на который будет перенаправлен соответствующий запрос. Основные типы записей: A (address) - Адресная запись, соответствие между именем и IP-адресом. AAAA или A6 (Address version 6) - Адрес в формате IPv6. CNAME (Canonical name) - Каноническое имя для псевдонима (одноуровневая переадресация). Позволяет присваивать хосту мнемонические имена. Мнемонические имена, или псевдонимы, широко применяются для связывания с хостом какой-либо функции, либо просто для сокращения имени. MX (Mail Exchanger) - Адрес почтового шлюза для домена. Состоит из двух частей — приоритета (чем число больше, тем ниже приоритет), и адреса узла. NS (Authoritative name server) - Адрес узла, отвечающего за доменную зону. Количество записей типа NS в файле зоны должно точно соответствовать количеству DNS-серверов, обслуживающих домен и включать все DNS-серверы, указанные в домене. SRV используются для поиска серверов, обеспечивающих работу тех или иных служб в данном домене. Критически важные для функционирования самой системы доменных имѐн: PTR (Domain name pointer) - связывает IP хоста с его каноническим именем, TXT (Text string) - Запись произвольных двоичных данных, до 255 байт в размере, SOA (Start of authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, параметры времени кеширования зонной информации и взаимодействие DNS-серверов. Поле имя может содержать символ @, обозначающий имя текущей зоны. Формат ресурсной записи <Владелец> TTL <Класс> <Тип> <Данные о ресурсе> Владелец– имя узла или домена DNS, которому принадлежит данная запись ресурса. Время жизни (TTL) – 32-битное число, определяющее время в секундах, в течение которого DNS-сервер или клиент хранит в КЭШе данную запись. По истечению этого срока запись удаляется из КЭШа. Это поле необязательно, и, если оно не определено, используется минимальное TTL, определенное в начальной записи зоны SOA Класс – определяет используемое семейство протоколов. Для DNS-серверов записям ресурсов всегда назначается IN – Интернет. Тип – тип записи ресурса (А,SOA,PTR) Данные о ресурсе – поле переменной длины, содержащее информацию, определенную типом записи ресурса 37 30. Формат ресурсной записи SOA первичной зоны DNS. Имя домена, ресурсы которого описаны в этой записи …. Тип Класс Время жизни (TTL) Длина записи о ресурсах Информация о ресурсах Рис.1. Формат ресурсных записей в DNS (RR) имя *TTL+ SOA Данные Всего существует 20 различных типов RR-записей. Имя домена в такой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип = 1 - это 4 байта IP-адреса. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании. Ресурсная запись SOA говорит о том, что сервер имен является источником данных для данного домена. Записи SOA содержат электронный адрес администратора данной зоны. Адрес администратора задается в формате admin.dns.net (здесь вместо @ после слова admin следует точка). Комментарии начинаются с точки с запятой. Запись SOA (Start of Authority) означает, что сервер имен DNS является лучшим источником информации для этого домена. Записи SOA также содержат адрес электронной почты ответственного лица для зоны, признак модификации зонного файла базы данных, а также используются для установки таймеров, определяющих периодичность обновления копий зонной информации другими серверами. В любой зоне должна быть только одна SOA-запись для имени, совпадающего с именем зоны. В записи хранится имя системы DNS и имя лица, ответственного за ее работу. Пример записи SOА: ; Start of Authority (SOA) record dns.com. IN SOA dnsl.dns.com. owner.dns.com. ( 000000001 ; serial # (counter) 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400) ; TTL (1 day) Адрес владельца задается в формате owner.dns.com, что следует читать как owner@dns.com. Строка завершается открывающей круглой скобкой, парная закрывающая скобка находится в последней строке после значения TTL. Запись может быть представлена в следующем формате, который также вполне допустим: Dns.com. IN SOA dnsl.dns.com. owner.dns.com. (000001 10800 3600 604800 86400) Данные: Primary Name Server. Первичный (Primary) DNS-сервер для некоторой зоны — DNS- сервер, на котором хранится полная исходная информация об этой зоне. Пример записи: ns3-l2.nic.ru. (неизменяемая запись). Hostmaster - адрес электронной почты человека, ответственного за содержимое файла зоны. Serial number (серийный номер) — это номер версии файла зоны. Этот номер должен быть положительным целым числом и увеличиваться каждый раз, когда в файл зоны вносятся изменения (см. RFC1982). Увеличение серийного номера показывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Refresh. Временной параметр Refresh показывает, как часто вторичные серверы должны запрашивать первичный сервер, чтобы узнать, не увеличился ли Serial number (серийный номер) зоны и, следовательно, не нужно ли обновить ее у себя. Рекомендуемое значение: от 1h до 6h. Retry. Параметр Retry показывает, как долго вторичный сервер имен должен ждать, перед тем как повторить попытку запроса первичного сервера (на предмет изменений серийного номера данной зоны), если предыдущая попытка оказалась неудачной. Рекомендуемое значение: от 20m до 60m; Expire. Параметр Expire указывает верхнее ограничение по времени, в течение которого вторичный сервер может использовать ранее полученные данные о зоне до того, как они потеряют силу из-за отсутствия обновления (например, вследствие отключения первичного сервера имен на длительное время). 38 31. Сервисные записи SRV службы DNS. SRV – одна из разновидностей записей в DNS. Указывает месторасположение серверов для различных сервисов. SRV запись состоит из следующих частей: service proto priority weight port hostname, где service – имя сервиса. Например _xmpp-server или _sip proto – имя протокола. Обычно _tcp или _udp priority – приоритет записи weight – вес записи. Используется для записей с одинаковым приоритетом port – порт на сервере. hostname – имя сервера. Service Address (SRV) - тип записи, который ассоциирует доменное имя, имя сервиса и протокол с некоторым хостом. Другими словами, эта запись используется для указания расположения некоторого сервиса на некотором хосте. При добавлении или редактировании этого типа записи, поля Protocol (Протокол) и Service Name (Имя сервиса), предназначены для ввода протокола, который использует сервис (TCP, UDP, TLS) и имени (названия) сервиса соответственно. Названия сервисов могут быть такими - pop3, telnet и другие. Когда клиент ищет некоторую SRV запись, то вид запроса записи следующий: _telnet._tcp.example.ru (например). Webmin автоматически преобразует вами созданную запись к такому (правильному) виду. Это означает, что нет необходимости создавать или редактировать такого типа записи вручную. Поле Priority (Приоритет) предназначено для ввода приоритета для этого сервера, означающий (приоритет) то же самое, что и приоритет для MX записей. Поле Weight (Вес) предназначено для ввода числа, означающего «вес» этого хоста. Обращения пользователей будут преимущественно к серверу, имеющему бОльший «вес». Поле Port предназначено для ввода номера порта, на котором предоставляется данный сервис. 39 32. Алгоритм разрешения DNS-имени на DNS-сервере. Когда программе-клиенту требуется по доменному имени выяснить IP-адрес, она связывается с сервером имен, адрес которого указан в настройках TCP/IP. Чтобы программное обеспечение пользовательского компьютера могло осуществлять преобразование доменных имен в IP-адреса, в настройках TCP/IP обязательно должен быть указан адрес хотя бы одного сервера имен. Сервер имен, получив запрос, рассматривает его, чтобы выяснить, в каком домене находится указанное имя. Если указанный домен входит в его зону ответственности, то сервер преобразует имя в IP- адрес на основе собственной базы данных и возвращает результат клиенту. В случае же, когда сервер имен не способен самостоятельно осуществить преобразование из-за того, что запрашиваемое доменное имя не входит в его зону, он опрашивает известные ему другие сервера имен с целью получения результата. Для функционирования серверу имен не обязательно знать адреса всех остальных DNS-серверов Интернет. Достаточно располагать адресами серверов имен корневого домена. Как правило, эта информация изначально и постоянно присутствует в программах-серверах. Очевидно также, что сервер имен должен знать адреса DNS-серверов делегированных зон. Порядок взаимодействия DNS-клиента с сервером для обеспечения разрешения имен определяется специальным протоколам DNS. Этот протокол предусматривает свой формат сообщения (пакета) и использует для доставки данных транспортные протоколы UDP и TCP как нижележащие. Задачи, решаемые сервисом DNS, являются относительно простыми, поэтому DNS-сообщение устроено несложно. Оно включает в себя: поле заголовка, определяющее тип сообщения (например, "запрос клиента", "ответ сервера" и т.д.); поле запроса, в котором клиент указывает разрешаемое имя и параметры запроса; поле ответа, в которое сервер помещает результат обработки запроса; два служебных поля передачи для управляющей и дополнительной информации. Служба доменных имен работает как распределенная база, данные которой распределены по DNS- серверам. Сервис DNS строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера - DNS-сервер. Например, когда мы хотим обратиться к серверу ipm.kstu.ru, браузер, используя resolver, поступает следующим образом: 1. Ищет запись ipm.kstu.ru в файле hosts, если не находит, то, 2. Посылает запрос на известный DNS-кэширующий сервер (как правило, локальный), если на этом сервере запись не найдена, то, 3. Сервер DNS-кэширующий обращается к DNS-ROOT серверу с запросом адреса DNS-сервера, отвечающего за домен первого уровня ru, если получает адрес, то, 4. Сервер DNS-кэширующий обращается к DNS-серверу, отвечающего за домен первого уровня ru, с запросом адреса DNS-сервера, отвечающего за домен второго уровня kstu.ru, если получает адрес, то, 5. Сервер DNS-кэширующий посылает запрос на DNS сервер, отвечающий за домен второго уровня kstu.ru, если получает адрес, то, 6. Сервер DNS-кэширующий адрес кэширует и передает клиенту 7. Клиент обращается по IP адресу - 195.208.44.20 Алгоритм разрешения имен: 40 |