Сети ЭВМ и телекоммуникации

Сети ЭВМ и телекоммуникации
DHCP
DHCP (Dynamic Host Configuration Protocol —
протокол динамической конфигурации узла)
— это сетевой протокол, позволяющий компьютерам автоматически
получать IP-адрес и другие параметры, необходимые для работы в
сети TCP/IP.
• Данный протокол работает по модели «клиент-сервер».
Для автоматической конфигурации компьютер-клиент на
этапе конфигурации сетевого устройства обращается к
серверу DHCP, и получает от него нужные параметры.
• Сетевой администратор может задать диапазон адресов,
распределяемых сервером среди компьютеров.
• Протокол позволяет избежать ручной настройки
компьютеров сети и уменьшает количество ошибок.
• DHCP используется в большинстве крупных (и не очень)
сетей TCP/IP.
История DHCP
Стандарт протокола DHCP был принят в
1993 года.
октябре
Действующая версия протокола (март 1997 года)
описана в RFC 2131.
Новая версия DHCP, предназначенная для
использования в среде IPv6, носит название DHCPv6 и
определена в RFC 3315 (июль 2003 года).
DHCP является расширением протокола BOOTP,
использовавшегося ранее для обеспечения
бездисковых рабочих станций IP-адресами при их
загрузке.
Распределение IP-адресов
• Протокол DHCP предоставляет три способа распределения
IP-адресов:
– Ручное распределение – администратор сопоставляет
аппаратному адресу (для Ethernet сетей это MAC-адрес)
каждого клиентского компьютера определённый IP-адрес.
– Автоматическое распределение – каждому компьютеру на
постоянное использование выделяется произвольный
свободный IP-адрес из определённого администратором
диапазона.
– Динамическое распределение – способ аналогичен
автоматическому распределению, за исключением того, что
адрес выдаётся компьютеру не на постоянное пользование, а
на определённый срок. Это называется арендой адреса. По
истечении срока аренды IP-адрес вновь считается свободным.
• Некоторые реализации службы DHCP способны
автоматически обновлять записи DNS, соответствующие
клиентским компьютерам, при выделении им новых
адресов.
Опции DHCP
• Помимо IP-адреса, DHCP также может сообщать клиенту
дополнительные параметры, необходимые для
нормальной работы в сети.
• Список стандартных опций можно найти в RFC 2132.
• Наиболее часто используемые опции:
–
–
–
–
–
IP-адрес хоста клиента;
IP-адрес маршрутизатора по умолчанию;
маска подсети;
адреса серверов DNS;
имя домена DNS.
• Некоторые поставщики программного обеспечения
могут определять собственные, дополнительные опции
DHCP.
Описание протокола
• Протокол DHCP является клиентсерверным, то есть в его работе участвуют
клиент DHCP и сервер DHCP.
• Передача данных производится при
помощи протокола UDP, при этом сервер
принимает сообщения от клиентов на
порт 67 и отправляет сообщения клиентам
на порт 68.
Структура сообщений DHCP
• Сообщение протокола DHCP разбивается на поля,
каждое из которых содержит определённую
информацию.
• Все поля, кроме последнего (поля опций DHCP),
имеют фиксированную длину.
Поля опций DHCP
Поле
op
htype
hlen
hops
xid
secs
flags
ciaddr
yiaddr
siaddr
giaddr
chaddr
sname
file
options
Описание
Длина (в
байтах)
Тип сообщения. Может принимать два значения: BOOTREQUEST (1 - запрос от клиента к серверу)
1
и BOOTREPLY (2 - ответ от сервера к клиенту).
Тип аппаратного адреса. Допустимые значения этого поля определены в RFC «Assigned
1
Numbers». Например, для MAC-адреса Ethernet 10 Мбит/с это поле принимает значение 1.
Длина аппаратного адреса в байтах. Для MAC-адреса Ethernet — 6.
1
Количество промежуточных маршрутизаторов (так называемых агентов ретрансляции DHCP),
1
через которые прошло сообщение. Клиент устанавливает это поле в 0.
Уникальный идентификатор транзакции, генерируемый клиентом в начале процесса получения
4
адреса.
Время в секундах с момента начала процесса получения адреса. Может не использоваться (в
2
этом случае оно устанавливается в 0).
Поле для флагов — специальных параметров протокола DHCP.
2
IP-адрес клиента. Заполняется только в том случае, если клиент уже имеет собственный IP-адрес
и способен отвечать на запросы ARP (это возможно, если клиент выполняет процедуру
4
обновления адреса по истечении срока аренды).
Новый IP-адрес клиента, предложенный сервером.
4
IP-адрес сервера. Возвращается в предложении DHCP.
4
IP-адрес агента ретрансляции, если таковой участвовал в процессе доставки сообщения DHCP до
4
сервера.
Аппаратный адрес (обычно MAC-адрес) клиента.
16
Необязательное имя сервера в виде нуль-терминированной строки.
64
Необязательное имя файла на сервере, используемое бездисковыми рабочими станциями при
128
удалённой загрузке. Как и sname, представлено в виде нуль-терминированной строки.
Поле опций DHCP. Здесь указываются различные дополнительные параметры конфигурации. В
начале этого поля указываются четыре особых байта со значениями 99, 130, 83, 99 («волшебные
числа»), позволяющие серверу определить наличие этого поля. Поле имеет переменную длину, переменная
однако DHCP-клиент должен быть готов принять DHCP-сообщение длиной в 576 байт (в этом
сообщении поле options имеет длину 340 байт).
Пример процесса получения адреса
• Предположим, клиент ещё не имеет
собственного IP-адреса, но ему известен его
предыдущий адрес — 192.168.1.100.
• Процесс состоит из четырёх этапов:
– Обнаружение DHCP;
– Предложение DHCP;
– Запрос DHCP;
– Подтверждение DHCP.
Обнаружение DHCP
• Вначале клиент выполняет широковещательный запрос по всей
физической сети с целью обнаружить доступные DHCP-серверы. Он
отправляет сообщение типа DHCPDISCOVER, при этом в качестве IPадреса источника указывается 0.0.0.0 (так как компьютер ещё не имеет
собственного IP-адреса), а в качестве адреса назначения —
широковещательный адрес 255.255.255.255.
• Клиент заполняет несколько полей сообщения начальными значениями:
– В поле xid помещается уникальный идентификатор транзакции, который
позволяет отличать данный процесс получения IP-адреса от других,
протекающих в то же время.
– В поле chaddr помещается аппаратный адрес (MAC-адрес) клиента.
– В поле опций указывается последний известный клиенту IP-адрес. В данном
примере это 192.168.1.100. Это необязательно и может быть
проигнорировано сервером.
• Сообщение DHCPDISCOVER может быть распространено за пределы
локальной физической сети при помощи специально настроенных
агентов ретрансляции DHCP, перенаправляющих поступающие от
клиентов сообщения DHCP серверам в других подсетях.
Предложение DHCP
• Получив сообщение от клиента, сервер определяет требуемую
конфигурацию клиента в соответствии с указанными сетевым
администратором настройками.
• В данном случае DHCP-сервер согласен с запрошенным
клиентом адресом 192.168.1.100. Сервер отправляет ему ответ
(DHCPOFFER), в котором предлагает конфигурацию.
• Предлагаемый клиенту IP-адрес указывается в поле yiaddr.
• Прочие параметры (такие, как адреса маршрутизаторов и DNSсерверов) указываются в виде опций в соответствующем поле.
• Это сообщение DHCP-сервер отправляет хосту, пославшему
DHCPDISCOVER, на его MAC.
• Клиент может получить несколько различных предложений
DHCP от разных серверов; из них он должен выбрать то,
которое его «устраивает».
Запрос DHCP
• Выбрав одну из конфигураций,
предложенных DHCP-серверами, клиент
отправляет запрос DHCP (DHCPREQUEST).
• Запрос рассылается широковещательно, при
этом к опциям, указанным клиентом в
сообщении DHCPDISCOVER, добавляется
специальная опция:
• идентификатор сервера — указывающая адрес DHCPсервера, выбранного клиентом (в данном случае —
192.168.1.1).
Подтверждение DHCP
• Сервер подтверждает запрос и направляет
это подтверждение (DHCPACK) клиенту.
• После этого клиент должен настроить свой
сетевой интерфейс, используя
предоставленные опции.
Динамическое выделение адресов
1. Клиент посылается широковещательный (BROADCAST255.255.255.255) запрос DHCPDISCOVER всем серверам
DHCP.
2. Все активные серверы посылают широковещательный
ответ DHCPOFFER. Клиент принимает все ответы,
инициализацию делает по адресу канального уровня
(MAC-адрес для Ethrnet).
3. Клиент выбирает один из предложенных адресов и
посылает широковещательно DHCPREQUEST, которое
должно содержать параметр Server Identifier (поле
OPTIONS), чтобы указать, какой сервер им выбран.
4. Сервер посылает широковещательно DHCPACK.
5. Клиент может работать.
Прочие сообщения DHCP
•
•
•
•
Отказ DHCP
Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что
указанный сервером адрес уже используется в сети, он рассылает широковещательное
сообщение отказа DHCP (DHCPDECLINE), после чего процедура получения IP-адреса
повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив
запрос ARP.
Отмена DHCP
Если по каким-то причинам сервер не может предоставить клиенту запрошенный IP-адрес,
или если аренда адреса удаляется администратором, сервер рассылает
широковещательное сообщение отмены DHCP (DHCPNAK). При получении такого
сообщения соответствующий клиент должен повторить процедуру получения адреса.
Освобождение DHCP
Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет
сообщение освобождения DHCP (DHCPRELEASE) тому серверу, который предоставил ему
адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается
широковещательно.
Информация DHCP
Сообщение информации DHCP (DHCPINFORM) предназначено для определения
дополнительных параметров TCP/IP (например, адреса маршрутизатора по умолчанию,
DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то
есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением
подтверждения (DHCPACK) без выделения IP-адреса.
ARP
• ARP (Address Resolution Protocol —
протокол определения адреса)
— протокол предназначен для
определения адреса канального уровня
по известному адресу сетевого уровня.
• Протокол низкого уровня.
• Наибольшее распространение этот протокол
получил благодаря повсеместности сетей IP,
построенных поверх Ethernet, поскольку
практически в 100 % случаев при таком
сочетании используется ARP.
Описание ARP
• Описание протокола было опубликовано в ноябре 1982 года в RFC 826.
• ARP был спроектирован для случая передачи IP-пакетов через сегмент
Ethernet. Общий принцип, предложенный для ARP, был использован
для сетей других типов.
• Существуют следующие типы сообщений ARP:
– запрос ARP (ARP request)
– ответ ARP (ARP reply).
• Перед тем как передать пакет сетевого уровня через сегмент Ethernet,
сетевой стек проверяет кэш ARP, чтобы выяснить, не зарегистрирована
ли в нём уже нужная информация об узле-получателе. Если такой
записи в кэше ARP нет, то выполняется широковещательный запрос ARP.
• Записи в кэше ARP могут быть статическими и динамическими.
• Пример добавления статической записи:
•
arp -s <IP-адрес> <MAC-адрес>
Записи в таблице ARP, созданные динамически, остаются в кэше в течение 2-х
минут. Если в течение этих двух минут произошла повторная передача данных
по этому адресу, то время хранения записи в кэше продлевается ещё на 2
минуты. Эта процедура может повторяться до тех пор, пока запись в кэше
просуществует до 10 минут. После этого запись будет удалена из кэша, и будет
отправлен повторный запрос ARP.
Принцип работы
• Узел, которому нужно выполнить отображение IPадреса на локальный адрес, формирует ARP запрос,
вкладывает его в кадр протокола канального уровня,
указывая в нем известный IP-адрес, и рассылает
запрос широковещательно.
• Все узлы локальной сети получают ARP запрос и
сравнивают указанный там IP-адрес с собственным.
• В случае их совпадения узел формирует ARP-ответ, в
котором указывает свой IP-адрес и свой локальный
адрес и отправляет его уже направленно, так как в
ARP запросе отправитель указывает свой локальный
адрес.
Структура пакета
• Hardware type (HTYPE)
Каждый транспортный протокол передачи данных имеет свой номер,
который хранится в этом поле. Например, Ethernet имеет номер 0x0001.
•
Protocol type (PTYPE)
Код протокола. Например, для IPv4 будет записано 0x0800.
• Hardware length (HLEN)
Длина физического адреса в байтах. Ethernet адреса имеют длину 6 байт.
• Protocol length (PLEN)
Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта.
• Operation
Код операции отправителя: 1 в случае запроса и 2 в случае ответа.
• Sender hardware address (SHA)
Физический адрес отправителя.
• Sender protocol address (SPA)
Логический адрес отправителя.
• Target hardware address (THA)
Физический адрес получателя. Поле пусто при запросе.
• Target protocol address (TPA)
Логический адрес получателя.
Пример
+
0
32
Bits 0 — 7
8 — 15
16 — 31
Hardware type = 0x0001
Hardware length = 6
64
Protocol type = 0x0800
Protocol length = 4
Operation = 1
SHA (first 32 bits) = 0x000958D8
96
SHA (last 16 bits) = 0x1122
SPA (first 16 bits) = 0x0A0A
128
SPA (last 16 bits) = 0x0A7B
THA (first 16 bits) = 0x0000
160
THA (last 32 bits) = 0x00000000
192
TPA = 0x0A0A0A8C
+
0
32
64
Bits 0 — 7
8 — 15
16 — 31
Hardware type = 0x0001
Hardware length = 6
Protocol type = 0x0800
Protocol length = 4
Operation = 2
SHA (first 32 bits) = 0x000958D8
96
SHA (last 16 bits) = 0x33AA
SPA (first 16 bits) = 0x0A0A
128
SPA (last 16 bits) = 0x0A8C
THA (first 16 bits) = 0x0009
160
THA (last 32 bits) = 0x58D81122
192
TPA = 0x0A0A0A7B
RARP
• RARP (Reverse Address Resolution Protocol — Обратный протокол
преобразования адресов) — протокол сетевого уровня, выполняет
обратное отображение адресов, то есть преобразует аппаратный адрес
в IP-адрес.
• Протокол применяется во время загрузки узла .
• Например:
– компьютер при инициализации интерфейса посылает групповое
сообщение-запрос со своим физическим адресом.
– Сервер принимает это сообщение и просматривает свои таблицы в поисках
соответствующего физическому, IP-адреса.
– После обнаружения найденный адрес отсылается обратно на запросивший
его узел.
– Другие станции также могут «слышать» этот диалог и локально сохранить
эту информацию в своих ARP-таблицах.
• RARP позволяет разделять IP-адреса между не часто используемыми
хост-узлами. После использования каким либо узлом IP-адреса он
может быть освобождён и выдан другому узлу.
• RARP является дополнением к ARP, и описан в RFC 903.
ICMP
• ICMP (Internet Control Message Protocol — протокол
межсетевых управляющих сообщений) — сетевой
протокол, входящий в стек протоколов TCP/IP.
• ICMP используется для передачи сообщений
об ошибках и других исключительных ситуациях,
возникших при передаче данных.
Например, запрашиваемая услуга
недоступна, или хост, или маршрутизатор
не отвечают.
• Также на ICMP возлагаются некоторые сервисные
функции.
ICMP
• Протокол ICMP описан в RFC 792 и RFC 950, является
стандартом Интернета.
• Формально ICMP использует IP (ICMP-пакеты
инкапсулируются в IP пакеты), и является неотъемлемой
частью IP, следовательно обязателен при реализации стека
TCP/IP.
• Текущая версия ICMP для IPv4 называется ICMPv4.
В IPv6 существует аналогичный протокол ICMPv6.
• ICMP-сообщение строится из IP-пакетов, сгенерировавших
ICMP-ответ.
• Каждое ICMP-сообщение инкапсулируется непосредственно
в пределах одного IP-пакета, и, таким образом, как и UDP,
ICMP является ненадежным.
• ICMP не используется непосредственно в приложениях
пользователей сети.
Использование ICMP-сообщений
• ICMP-сообщения (тип 12) генерируются при нахождении ошибок в
заголовке IP-пакета (за исключением самих ICMP-пакетов, чтобы не
привести к бесконечно растущему потоку ICMP-сообщений об ICMPсообщениях).
• ICMP-сообщения (тип 3) генерируются маршрутизатором при отсутствии
маршрута к адресату.
• Утилита Ping, служащая для проверки возможности доставки IP-пакетов
использует ICMP-сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ).
• Утилита Traceroute, отображающая путь следования IP-пакетов, использует
ICMP-сообщения с типом 11.
• ICMP-сообщения (тип 5) используются маршрутизаторами для обновления
записей в таблице маршрутизации отправителя.
• ICMP-сообщения (тип 4) используются получателем (или маршрутизатором)
для управления скоростью отправки сообщений отправителем.
Формат пакета ICMP
Бит
0—7
8—15
16—31
0
Тип
Код
Контрольная сумма
32
Содержание сообщения (зависит от значений полей «Код» и
«Тип»)
Типы пакетов ICMP
•
•
•
•
•
0 — Эхо-ответ
1 — Зарезервировано
2 — Зарезервировано
3 — Адресат недоступен
– код 0 — Сеть недостижима
код 1 — Узел недостижим
код 2 — Протокол недостижим
код 3 — Порт недостижим
код 4 — Необходима фрагментация, но
установлен флаг ее запрета (DF)
код 5 — Неверный маршрут от источника
код 6 — Сеть назначения неизвестна
код 7 — Узел назначения неизвестен
код 8 — Узел источник изолирован
код 9 — Сеть административно запрещена
код 10 — Узел административно запрещен
код 11 — Сеть недоступна для ToS
код 12 — Узел недоступен для ToS
код 13 — Коммуникации административно
запрещены
код 14 — Нарушение порядка предпочтения
узлов
код 15 — Активно отсечение порядка
предпочтения
4 — Сдерживание источника (отключение источника
при переполнении очереди)
•
5 — Перенаправление
– код 0 — Перенаправление пакетов в сеть
Код 1 — Перенаправление пакетов к узлу
Код 2 — Перенаправление для каждого типа
обслуживания (TOS)
Код 3 — Перенаправление пакета к узлу для
каждого типа обслуживания
•
•
•
•
6 — Альтернативный адрес узла
7 — Зарезервировано
8 — Эхо-запрос
9 — Объявление маршрутизатора (RFC-1256)
– код 0 — Нормальное объявление
маршрутизатора
код 16 — Не маршрутизировать обычный
трафик
•
•
10 — Запрос маршрутизатора (RFC-1256)
11 — Превышение временного интервала (для
дейтаграммы время жизни истекло)
– код 0 — Время жизни пакета (TTL) истекло при
транспортировке
код 1 — Время жизни пакета (время сборки
фрагментов) истекло при дефрагментации
Типы пакетов ICMP
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
12 — Неверный параметр (проблема с параметрами •
дейтаграммы: ошибка в IP-заголовке или отсутствует
необходимая опция)
•
– код 0 — Указатель говорит об ошибке
код 1 — Отсутствует требуемая опция
•
код 2 — Некорректная длина
•
13 — Запрос метки времени
•
14 — Ответ с меткой времени
15 — Информационный запрос
16 — Информационный ответ
17 — Запрос адресной маски (RFC-950)
18 — Отклик на запрос адресной маски (RFC-950)
19 — Зарезервировано (для обеспечения
безопасности)
20-29 — Зарезервировано (для экспериментов на
устойчивость к ошибкам)
30 — Трассировка маршрута (RFC-1393)
31 — Ошибка преобразования дейтаграммы (RFC1475)
32 — Перенаправление для мобильного узла
33 — IPv6 Where-Are-You (где вы находитесь)
•
34 — IPv6 I-Am-Here (я здесь)
35 — Запрос перенаправления для мобильного узла
36 — Отклик на запрос перенаправления для
мобильного узла
37 — Запрос доменного имени (Domain Name
Request)
38 — Ответ на запрос доменного имени (Domain
Name Reply)
39 — SKIP
40 — Photuris
– код 0 — Зарезервировано
код 1 — Неизвестный индекс параметров
безопасности (Unkown Security Parameters
Index)
код 2 — Параметры безопасности верны, но
произошла ошибка аутентификации (Valid
Security Parameters, but Authentication Failed)
код 3 — Параметры безопасности верны, но
произошел сбой при расшифровке (Valid
Security Parameters, but Decryption Failed)
код 4 — Требуется проверка подлинности (Need
Authentication)
код 5 — Требуется авторизация (Need
Authorization)
41-255 — Зарезервировано
Пример
• Эхо сообщение о недостижимости адресата
содержит следующие поля:
– Заголовок (4 байта):
тип – 3;
возможные коды – [0,15];
контрольная сумма ;
– Пустое поле 32 бита;
– Данные исходной диаграммы (первые 64 бита).
Сообщение о перенаправлении
дейтаграммы
• Сообщение посылается шлюзом, при условии
существования более короткого маршрута.
• Формат сообщения:
– Заголовок (4 байта):
тип – 5;
возможные коды – [0,5];
контрольная сумма;
– Адрес более выгодного шлюза (4 байта);
– Данные исходной дейтограммы (первые 64 бита).
При муршрутизации от источника данное сообщение
никогда не высылается.
Сообщение эхо-запрос и эхо-ответ
• Используется для тестирования соединения между
узлами сети.
• Сообщение запроса и ответа имеют одинаковый формат
дейтограммы:
– Заголовок (4 байта):
• Тип (Эхо-запрос – 8, Эхо-ответ – 0);
• Код не используется;
• Контрольная сумма;
– Идентификатор;
– Последовательный номер;
– Данные – имеет переменную длину.
• Идентификатор и последовательный номер используются
для определения соответствия эхо-запросов в эхо-ответы.
Обмен информацией о маршрутах
• Такие пакеты используются маршрутизаторами (один раз в 10
мин), передаются широковещательно.
• Формат сообщения объявление маршрутизатора:
– Заголовок (4 байта):
Тип – 9;
Код;
Контрольная сумма;
– Число адресов – количество адресов машрутизатора, указанных в
сообщении (байт);
– Длина адреса – число 32-битных слов, необходимых для указания
записи каждого маршрутизатора (байт);
– Время жизни – максимальное время выраженное в секундах, в
течении которого адреса маршрутизатора могут считываться (2
байта);
– Адрес маршрутизатора – ip-адрес интерфейса маршрутизатора (4
байта для ipv4);
– Уровень приоритета – предпочтительность для каждого маршрута (4
байта для ipv4).
ICMP-сообщение
«запрос-маршрутизатора»
• Передается при включении маршрутизатора и
необходимости немедленного получения
информации о соседних маршрутизаторах.
• Формат сообщения:
– Заголовок:
Тип – 10;
Код;
Контрольная сумма;
– 32 бита нулей.
DoS-атака (Denial of Service –
подавление услуги)
• Цель: загрузить сервер так, чтобы он не мог отвечать.
• Нужно послать как можно больше ответов Echo Reply на
жертву.
• Для этого можно задействовать чужие сети.
• Алгоритм:
1. Указываем адрес источника - адрес жертвы (194.85.241.1)
2. Указываем адрес получателя - адрес типа Directed Broadcast
(195.208.44.255), на этот адрес должны ответить все узлы сети
195.208.44.0/24
3. Посылаем сообщение Echo Request.
4. 253 машины посылают ответ на жертву (194.85.241.1)
5. Все повторяем много раз, а лучше задействовать побольше таких сетей.
6. Жертва будет перегружена.
Меры предотвращения DoS-атак
• Запретить прием и распространение
сообщений типа Directed Broadcast.
• Уничтожать сфальсифицированные пакеты,
сопоставляя IP источника с маршрутной
таблицей и номером интерфейса, с
которого получен пакет.
• Запретить трафик ICMP (ping, traceroute и
т.д., работать не будут).
Протокол BOOTP
• Создан для загрузки бездисковых машин.
• Стандарт BOOTP - RFC0951 (Bootstrap Protocol W.J. Croft, J. Gilmore
Sep-01-1985).
• Последняя версия дополнений для BOOTP - RFC1542 (Clarifications
and Extensions for the Bootstrap Protocol W. Wimer October 1993).
Введено понятие Relay Agent.
• Первая версия расширения разработчиков (поле vend) для BOOTP
- RFC1048 (BOOTP vendor information extensions P.A. Prindeville Feb01-1988).
• Последняя версия расширения разработчиков (поле vend) для
BOOTP - RFC2132(DHCP Options and BOOTP Vendor Extensions S.
Alexander, R. Droms March 1997).
• BOOTP является прототипом DHCP, в DHCP есть все что было в
BOOTP.
Принцип работы traceroute
• traceroute отправляет на существующий порт удаленного
узла последовательность UDP-дейтаграмм, .
• Номер используемого порта по умолчанию 33434.
• Алгоритм работы:
1. Посылаются дейтограммы с TTL=1 (время жизни пакета)
2. Первый же маршрутизатор уменьшает TTL на 1, т.е. TTL=0 и пакет
уничтожается, а отправителю посылается ICMP сообщение Time Exceeded.
3. Посылаются дейтограммы с TTL=2 (время жизни пакета)
4. Первый же маршрутизатор уменьшает TTL на 1, т.е. TTL=1 и пакет проходит
дальше.
5. Второй маршрутизатор уменьшает TTL на 1, т.е. TTL=1 и пакет
уничтожается, а отправителю посылается ICMP сообщение Time Exceeded.
6. И т.д.
7. Попадая на получателя, пакет уничтожается, т.к. получатель не знает, что с
ним делать (порт не существует), и отправителю посылается ICMP
сообщение Destination Unreachable.
Принцип работы traceroute
Служба SNMP
• Простой протокол управления сетями (Simple Network Management
Protocol, SNMP) предназначен для управления сетями и является частью
семейства стандартов Интернета.
• Например, в сети установлены разные маршрутизаторы (cisco, motorola,
linux и т.д.), все настраиваются по-разному. Необходимо изменять
настройки на всех маршрутизаторах. Обычным методом придется
каждый настраивать индивидуально (интерфейсы у всех разные). С
помощью SNMP можно настроить используя один интерфейс.
• SNMP обеспечивает управления узлами сети с центрального
компьютера, на котором выполняется программное обеспечение
управления сетью. SNMP выполняет службы управления с
использованием распределенной архитектуры систем управления и
агентов.
• Объекты сети:
– Сервера управления - порт по умолчанию 162.
– Клиенты - сетевая станция, на который находится агент (программный модуль),
позволяющий серверу управлять и наблюдать за ней. Порт по умолчанию 161.
«Менеджер-агент»
• Система SNMP содержит множество управляемых узлов, на каждом из
которых размещается агент SNMP, а также, по крайней мере, один узел,
содержащий менеджера SNMP.
• Менеджер взаимодействует с агентами при помощи протокола SNMP с
целью обмена управляющей информацией. Это взаимодействие
реализуется в виде периодического опроса менеджером множества
агентов.
• Система, построенная по таким принципам, теряет в
масштабируемости, поскольку есть выделенный клиент,
занимающийся опросом всех серверов. Зато такая схема обеспечивает
простоту реализации систем под управлением SNMP.
SAEAUT SNMP OPC Server for managing
industrial and network devices
SNMP задачи
• Настройка удаленных устройств. Из системы управления можно
отправить сведения о настройке на каждый узел сети.
• Наблюдение за производительностью сети. Существует возможность
отслеживать скорость обработки и передачи данных, а также собирать
сведения об успешной передаче данных.
• Определение сбоев сети или неправильного доступа. На сетевых
устройствах можно настроить триггеры, срабатывающие при
возникновении конкретных событий. При срабатывании триггера
устройство пересылает в систему управления сообщение о событии.
• Аудит использования сети. Существует возможность наблюдения как за
общим использованием сети для определения доступа пользователей
или групп, так и за типами использования для сетевых устройств и служб.
Компоненты SNMP
• Протокол SNMP
• SMI - (Structure of Management
Information) - структура информации
управления.
• MIB (Management Information Base) информационная база управления.
SNMP (Simple Network Management Protocol) простой протокол управления сетью.
• Первый стандарт SNMP определен в RFC1067 (Simple
Network Management Protocol J.D. Case, M. Fedor, M.L.
Schoffstall, J. Davin Aug-01-1988).
• Последняя версия RFC1157 (STD0015 Simple Network
Management Protocol (SNMP) J.D. Case, M. Fedor, M.L.
Schoffstall, J. Davin May-01-1990).
• RFC1592 (Simple Network Management Protocol Distributed
Protocol Interface Version 2.0 B. Wijnen, G. Carpenter, K.
Curran, A. Sehgal, G. Waters March 1994).
• Протокол прикладного уровня работает по умолчанию
поверх UDP, но может работать по TCP.
• Клиент и сервер обмениваются сообщениями.
Взаимодействие клиент-сервера SNMP.
Пять типов сообщений.
Сообщение SNMP
• Сообщение SNMP содержит номер версии SNMP,
информацию о безопасности и протокольный блок
данных PDU, который характеризует выполняемую
операцию и её параметры.
Например: SNMPv1 описывает следующие PDU и
соответствующие операции:
• Get-Request — запрос на получение значений 1..N переменных;
• Get-Next-Request — запрос на получение значений 1..N переменных,
чьи OID идут следом за OID указанных 1..N переменных;
• Get-Response — ответ на запросы Get-Request, Get-Next-Request и SetRequest;
• Set-Request — установка значений 1..N переменных;
• Trap — ловушка.
Trap
• На срочные события вводится специальный тип операции
протокола SNMP, называемый «ловушка» (Trap).
• Позволяет агентам асинхронно информировать менеджера
(по собственной инициативе) о наступлении ограниченного
числа значимых событий.
• В этом случае агент выступает в необычной для себя роли
клиента, а менеджер — в роли сервера. В случае
использования транспорта UDP для входящих соединений
менеджер использует порт UDP 162.
Формат SNMP-сообщений
Trap-сообщений
Типы PDU сообщений SNMP
Тип PDU
Имя
Значение
0
get-request
Получить значение переменных
1
get-nextrequest
Получить следующие переменные после
этой
2
set-request
Установить значение переменных
3
getresponse
Выдать значение переменных
(Посылает агент в ответ на get-request,
get-next-request, set-request)
4
trap
Уведомить менеджера, когда что-либо
произошло с агентом
PDU (Protocol Data Unit) - блок (пакет) данных протокола.
SMI - (Structure of Management Information) структура информации управления
• Первый стандарт SMI определен в RFC1155 (Structure and
identification of management information for TCP/IP-based
internets M.T. Rose, K. McCloghrie May-01-1990)
• Последний стандарт для версии SMIv1 RFC1155 (Structure and
identification of management information for TCP/IP-based
internets M.T. Rose, K. McCloghrie May-01-1990)
• Последний стандарт для версии SMIv2 RFC2578 (Structure of
Management Information Version 2 (SMIv2) K. McCloghrie, D.
Perkins, J. Schoenwaelder April 1999)
Переменные в SNMP
• В SNMP каждое управляемое устройство, на котором
расположен агент, представляет свою управляющую
информацию в виде переменных.
• Переменными могут быть, например, имя системы, время
с момента её перезапуска, записи в таблице
маршрутизации и т. д. В общем случае переменные можно
разделить на:
– скалярные переменные;
– таблицы переменных.
• Схема данных описывается SMI, которая определяет, как
выглядит управляющая информация, описывает её
синтаксис.
Базы MIB
• Конкретные наборы управляющей информации для
разных типов устройств, протоколов и т. д. описываются
базами управляющей информации (Management
Information Bases, MIBs).
• Базы MIB определяют, какая управляющая информация
существует.
Например, для устройства, поддерживающего IP, MIB описывает
таблицу маршрутизации, флаг активации функции маршрутизации,
число переданных и принятых пакетов, число ошибок различного
характера и т. д.
Дерево идентификаторов объектов
• Каждой переменной присваивается уникальный
идентификатор объекта (Object Identifier, OID).
Пространство имён OID является иерархическим и
контролируется организацией по распределению номеров
в Интернете (Internet Assigned Numbers Authority, IANA).
• Каждый компонент имени является числом, которые
записываются как десятичные числа, разделённые
точками, слева направо. Числам могут быть поставлены в
соответствие текстовые строки для удобства восприятия.
• Все управляемые объекты глобальной сети расположены в
дереве.
Пример
• Каждая MIB определяет набор переменных, т. е.
определённую ветку дерева OID, описывающую
управляющую информацию в определённой области.
• Например, ветка 1.3.6.1.2.1.1 (мнемонический
эквивалент: iso.org.dod.internet.mgmt.mib-2.system)
описывает общую информацию о системе.
• Некоторые переменные:
– sysDescr (1.3.6.1.2.1.1.1) — краткое описание системы
– sysUpTime (1.3.6.1.2.1.1.3) — время с момента последнего
перезапуска
– sysName (1.3.6.1.2.1.1.5) — имя системы
Операции над данными
• Чтение переменной
• Запись переменной
• Чтение переменной, следующей за
заданной переменной (требуется для
просмотра таблиц переменных)
Информационная база управления (MIB)
• Первый стандарт MIB определен в RFC1066 (Management
Information Base for network management of TCP/IP-based
internets K. McCloghrie, M.T. Rose Aug-01-1988 )
• Последний стандарт для версии MIB-I RFC1156
(Management Information Base for network management of
TCP/IP-based internets K. McCloghrie, M.T. Rose May-01-1990)
• Последний стандарт для версии MIB-II RFC1213 (STD0017
Management Information Base for Network Management of
TCP/IP-based internets:MIB-II K. McCloghrie, M.T. Rose Mar01-1991)
• Ветвь 1.3.6.1.2.1.4 (iso.org.dod.internet.mgmt.mib-2).
Ветвь UDP
Группа UDP содержит четыре переменные, и одну таблицу
(udpTable) из двух переменных.
Имя
Тип данных
Чтение/Запись
Описание
udpInDatagr
ams
Counter
Только чтение
Количество UDP датаграмм, доставленных
пользовательским процессам.
udpNoPorts
Counter
Только чтение
Количество доставленных UDP датаграмм, для
которых не оказалось порта назначения.
udpInErrors
Counter
Количество недоставленных UDP датаграмм по
Только чтение
другим причине (например, ошибка
контрольной суммы UDP).
udpOutData
grams
Counter
Только чтение
Количество отправленных UDP датаграмм.