Сетевая диагностика. Протокол SNMP

Разбить на страницы

Показывать лекцию целиком

Читатели неизбежно делятся на две категории:

администраторы сети, которые формируют сетевую среду (подавляющее меньшинство);

пользователи сети, кто вынужден эту среду осваивать и в ней жить.

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

Число компьютерных сетей увеличивается лавинообразно, растет число крупных (>10 ЭВМ). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ЭВМ разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту. При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:

с чем связана проблема — с оборудованием или программным обеспечением;

чем вызван отказ — повреждением программы, неверным выбором конфигурации или ошибочными действиями оператора.

Начинать надо с исчерпывающего документирования аппаратной и программной части сети. Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ЭВМ, маршрутизаторов, значения MTU и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах).

В пределах локальной сети поиск неисправности возможен с помощью временного деления ее на части. По мере интеграции сети в Интернет такие простые меры становятся недостаточными или недопустимыми. Нужно помнить, что сопротивление тонкого коаксиального кабеля не должно превышать 10 Ом, а скрученная пара не должна иметь сопротивление больше 11,8 Ом (22AWG) и соответственно 18,8 Ом для 24AWG из расчета на 100 м.

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

Ниже будет предполагаться, что сеть на физическом уровне применяет стандарт Ethernet, а для межсетевой связи — протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС. Проблемы маршрутизации и конфигурирования системы также выходят за рамки данного рассмотрения.

В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump, netwatch, snmpman, netguard, ws_watch. Программа tcpdump переводит интерфейс ЭВМ в режим приема всех пакетов, пересылаемых по данному сетевому сегменту. Tcpdump написана на СИ, она отбирает и отображает на экране пакеты, посылаемые и получаемые данным интерфейсом. Критерии отбора могут варьироваться, что позволяет проанализировать выполнение различных сетевых процедур. В качестве параметров при обращении к программе могут использоваться наименования протоколов, номера портов и т.д., например, tcpdump TCP port 25 (программа полезна при отладке сетевых приложений). Существует довольно большое число модификаторов программы (опций). К сожалению, для рядовых пользователей программа не доступна — требуются системные привилегии. Описание применения программы можно найти в [10]. Другой полезной служебной программой является sock (socket или sockio). Эта программа способна посылать TCP- и UDP-пакеты, она может работать в четырех режимах.

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

Работа в режиме диалогового сервера (опция -s ). В этом режиме параметром операции является ее имя или номер порта (или комбинация IP-адреса и номера порта), например: sock -s 100. После установления связи с клиентом программа переадресовывает весь стандартный ввод клиенту, а все, что посылается клиентом, отправляет на стандартный вывод.

Режим клиента-отправителя (опция -i ). Программа выдает в сеть заданное число раз (по умолчанию 1024) содержимое буфера с объемом в 1024 байта. Опции -n и -w позволяют изменить число и размер посылок.

Режим приема и игнорирования данных из сети (опция -i и -s ).

Такие средства входят также и в комплекты поставки большинства стандартных сетевых пакетов для ОС UNIX, Windows и других: ping, traceroute, netstat, arp, snmpi, dig, hosts, nslookup, ifconfig, ripquery. Перечисленные выше диагностические программы являются необходимым инструментом для отладки программ, передающих и принимающих пакеты. Сводный перечень конфигурационных и диагностических команд стека протоколов TCP/IP представлен в таблице 8.1.

Название команды	Назначение
`arp`	Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса)
`chnamsv`	Применяется для изменения конфигурации службы имен на ЭВМ (для TCP/IP)
`chprtsv`	Изменяет конфигурацию службы печати на ЭВМ-клиенте или сервере
`gettable`	Получает таблицы ЭВМ в формате NIC
`hostent`	Непосредственно манипулирует записями адресного соответствия ЭВМ в конфигурационной базе данных системы
`hostid`	Устанавливает или отображает идентификатор данной ЭВМ
`hostname`	Устанавливает или отображает имя данной ЭВМ
`htable`	Преобразует файлы ЭВМ в формат, используемый программами сетевой библиотеки
`ifconfig`	Конфигурирует или отображает параметры сетевых интерфейсов ЭВМ (для протоколов TCP/IP)
`ipreport`	Генерирует сообщение о маршруте пакета на основе специфицированного маршрутного файла
`iptrace`	Обеспечивает отслеживание маршрута движения пакетов на интерфейсном уровне для протоколов Интернет
`lsnamsv`	Отображает информацию базы данных DNS
`lsprtsv`	Отображает информацию из базы данных сетевой службы печати
`mkhost`	Создает файл таблицы ЭВМ
`mknamsv`	Конфигурирует службу имен клиента (для TCP/IP)
`mkprtsv`	Конфигурирует службу печати ЭВМ (для TCP/IP)
`mktcpip`	Устанавливает требуемые величины для запуска TCP/IP на ЭВМ
`namerslv`	Непосредственно манипулирует записями сервера имен для локальной программы DNS в базе данных конфигурирования системы
`netstat`	Отображает состояние сети
`no`	Конфигурирует сетевые опции
`rmnamsv`	Удаляет TCP/IP службу имен из ЭВМ
`rmprtsv`	Удаляет службу печати на машине клиента или сервере
`route`	Служит для ручного манипулирования маршрутными таблицами
`ruptime`	Отображает состояние каждой ЭВМ в сети
`ruser`	Непосредственно манипулирует записями в трех отдельных системных базах данных, которые регулируют доступ внешних ЭВМ к программам
`securetcpip`	Активизирует сетевую безопасность
`setclock`	Устанавливает время и дату для ЭВМ в сети
`slattach`	Подключает последовательные каналы в качестве сетевых интерфейсов
`timedc`	Присылает информацию о демоне timed
`trpt`	Отслеживает реализации протокола для TCP-сокетов

Для того, чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet. Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35 ; цифры, напечатанные полужирным шрифтом, соответствуют кодам документов, содержащим описания стандартов), служащий для преобразования символьного имени сетевого объекта в его IP-адрес. DNS-сервер обслуживает соответствующую базу данных, которая хранит много другой полезной информации. Многие ЭВМ имеют SNMP -резиденты (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, -1157, -1098), обслуживающие управляющую базу данных MIB (RFC-1792, -1748-49, -1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13 ), содержимое которой поможет также узнать много интересного о состоянии вашей сети. Сама идеология Интернет предполагает богатую диагностику (протокол ICMP, RFC- 1256, 1885, -1788, -792 ).

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

ping <имя или адрес ЭВМ или другого объекта> [размер пакета] [число посылок]

Размер пакета задается в байтах (по умолчанию равен 56). Процедура выполнения ping может быть прервана нажатием клавиш ctrl-C. В различных реализациях программа ping имеет много разных опций, которые позволяют измерять статистические характеристики канала (например, потери), определять задержки в канале (RTT), отображать посылаемые пакеты и получаемые отклики, а также фиксировать маршрут до интересующего объекта. Ping применяется для выяснения доступности сервис-провайдера и т.д. Иногда ping является составной частью более мощной диагностической программы (например, netwatch). Ниже приведен пример использования команды traceroute:

traceroute kirk.Bond.edu.au (посмотрим, как идут пакеты до этого сервера в Австралии)
(IP-адрес=131.244.1.1 узнан, зондирование начинается, допустимо не более 30 шагов)
traceroute to kirk.Bond.edu.au (131.244.1.1) 30 hops max, 40 byte packets
1 ITEP-FDDI-BBone (193.124.224.50) 2 ms 2 ms 2 ms
2 MSU-Tower-2.Moscow.RU.Radio-MSU.net (194.67.80.65) 3 ms 3 ms 3 ms
3 NPI-MSU.Moscow.RU.Radio-MSU.net (194.67.80.5) 4 ms 3 ms 3 ms
4 NPI-P.Moscow.RU.Radio-MSU.net (194.67.80.18) 4 ms 5 ms 4 ms
5 DESY-P.Hamburg.DE.Radio-MSU.net (194.67.80.14) 317 ms 310 ms 329 ms
6 DESY.Hamburg.DE.Radio-MSU.net (194.67.82.17) 312ms 320ms 312ms (маршрут через Германию)
7 188.1.56.5 (188.1.56.5) 321 ms 357 ms 327 ms
8 188.1.56.10 (188.1.56.10) 347 ms 467 ms 356 ms
9 DE-f0-0.eurocore.bt.net (194.72.24.193) 331 ms 337 ms 331 ms
10 NL-s1-1.eurocore.bt.net (194.72.24.202) 355 ms 435 ms 343 ms
11 NL-f0.dante.bt.net (194.72.24.2) 367 ms 353 ms 573 ms
12 New-York2.dante.net (194.72.26.10) 497ms 493ms 489ms (пересекли Атлантический океан)
13 f1-0.t32-0.New-York.t3.ans.net (204.149.4.9) 546 ms 501 ms 490 ms
14 h5-0.t36-1.New-York2.t3.ans.net (140.223.33.10) 540 ms 506 ms 571 ms
15 * f2.t36-0.New-York2.t3.ans.net (140.223.36.221) 503 ms 505 ms
16 h13.t40-0.Cleveland.t3.ans.net (140.223.37.10) 802 ms 795 ms 523 ms
17 h14.t24-0.Chicago.t3.ans.net (140.223.25.9) 537 ms 509 ms 526 ms
18 h13.t96-0.Denver.t3.ans.net (140.223.25.18) 545 ms 531 ms 545 ms
19 h12.t8-0.San-Francisco.t3.ans.net (140.223.9.17) 853 ms 584 ms 592 ms
20 border2-fddi1-0.SanFrancisco.mci.net (206.157.77.1) 563 ms 591 ms 753 ms
21 telstra-ds3.SanFrancisco.mci.net (204.70.33.10) 691 ms * 691 ms
22 telstra.SanFrancisco.mci.net (204.70.204.6) 759 ms 815 ms 753 ms (достигли Тихого океана)
23 Fddi0-0.pad-core2.Sydney.telstra.net (139.130.249.227) 766 ms 1054 ms 837 ms (океан позади — Австралия!)
24 Serial4-4.cha-core1.Brisbane.telstra.net (139.130.249.202) 781 ms 776 ms 810 ms
25 qld-new.gw.au (139.130.247.227) 836 ms 917 ms 806 ms
26 139.130.5.2 (139.130.5.2) 816 ms 796 ms 811 ms
27 203.22.86.241 (203.22.86.241) 800 ms 787 ms 838 ms
28 203.22.86.194 (203.22.86.194) 850 ms 790 ms 768 ms
29 kirk.Bond.edu.au (131.244.1.1) 781 ms (ttl=226!) 918 ms (ttl=226!) 799 ms (ttl=226!)

Цель достигнута за 29 шагов! (Путь бывает и длиннее, но редко).

Программа traceroute посылает по три пакета с нарастающими значениями TTL, если отклик на пакет не получен печатается символ *. Большие задержки (RTT) в приведенном примере зависят от спутниковых каналов связи (время распространения сигнала до спутника).

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

Сетевое оборудование, описано в документации intro(4), которая доступна через справочную систему man, например:

man — 4 intro | grep Ether (Выделенная строка представляет собой команду, 
введенную с клавиатуры, следующий за ней текст — отклик ЭВМ на эту команду)
a network interface for the 10-Megabit Ethernet, along with SunOS supports
the 10-Megabit Ethernet as its primary net-ie ie(4S) Intel 10 Mb/s Ethernet
interface
le le(4S) LANCE 10Mb/s Ethernet interface

Для того, чтобы получить дополнительную информацию об этих интерфейсах, можно выдать команду dmesg (или просмотреть файл /usr/adm/messages):

dmesg | grep le0
le0 at SBus slot f 0xc00000 pri 6 (onboard)
le0: AUI Ethernet

Работа сетевого обеспечения базируется на нескольких резидентных программах (демонах): routed и gated (маршрутизация), named (сервер имен), inetd (Интернет услуги). Перечень демонов базовых услуг представлен в таблице 8.2.

Основные TCP/IP демоны
Название демона	Назначение
`fingerd`	Предоставляет информацию об удаленном пользователе
`ftpd`	Реализует функции сервера передачи файлов (протокол FTP)
`gated`	Реализует функции маршрутизации шлюза для протоколов RIP, HELLO, EGP, BGP и SNMP
`inetd`	Осуществляет управление сетевыми услугами Интернет
`named`	Реализует услуги сервера имен (DNS)
`rexecd`	Выполняет серверные функции для команд `rexec` (удаленное исполнение)
`rlogind`	Реализует серверные функции для команд `rlogin` (авторизация)
`routed`	Управляет сетевыми маршрутными таблицами
`rshd`	Реализует серверные функции для команд удаленного исполнения
`rwhod`	Реализует серверные функции для команд `rwho` и `ruptime`
`syslogd`	Читает и записывает в системный журнал сообщения
`talkd`	Реализует серверные функции для команд `talk`
`telnetd`	Реализует серверные функции для протокола TELNET
`tftpd`	Реализует серверные функции для протокола TFTP
`timed`	При загрузке системы устанавливает демон `timeserver`

Конфигурация inetd определяется содержимым файла /etc/inetd.conf. Для ознакомления с содержимым файла достаточно с клавиатуры ввести команду:

head -16 /etc/inetd.conf
# @(#)inetd.conf 1.24 92/04/14 SMI
# Configuration file for inetd(8). See inetd.conf(5).
# To re-configure the running inetd process, edit this file, then
# send the inetd process a SIGHUP.
# Internet services syntax:
# <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args>
# Ftp and telnet are standard Internet services.
#ftp stream tcp nowait root /usr/etc/in.ftpd in.ftpd
#ftp stream tcp nowait root /usr/etc/wrapper.3.9.4/tcpd in.ftpd -dl
ftp stream tcp nowait root /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd -lio

Строки, начинающиеся с символа #, являются комментариями. В данном примере представлена одна информативная строка (их может быть много больше), характеризующая файловый обмен. Каждая строка в этом файле начинается с имени ресурса (в приведенном примере ftp ). Далее следует поле типа соединителя (socket): stream (TCP поток байтов); dgram — передача данных в виде UDP-дейтограмм. Следующее поле характеризует протокол, используемый данным видом сервиса (TCP или UDP). За ним идет поле, которое описывает способ реализации процедуры ( wait/nowait; для поточных серверов nowait ). Следующее поле представляет собой идентификатор пользователя (UID), но обычно пользователем является системный администратор — root. Возможны два исключения. Процедура finger выполняется с UID=nobody или daemon. За полем uid следует поле сервера (в примере /usr/etc/wrapper.3.9.4/tcpd /usr/local/etc/ftpd ). В это поле заносится полное описание пути к программе-серверу, запускаемой inetd. Завершающим полем является поле аргументы, куда записывается строка, передаваемая программе-серверу. Содержимое файла inetd.conf должно быть предметом особой заботы администратора, так как от содержимого этого файла зависит эффективная работа сети и ее безопасность.

Как уже отмечалось выше, одним из важнейших частей любого узла Интернет является сервер имен (DNS). Конфигурация DNS-сервера определяется тремя файлами: named.boot, named.ca и named.local. Зонная информация содержится в файле named.rev, а данные о локальном домене — в файле named.hosts. Отладка, контроль и диагностика DNS-сервера осуществляется с использованием программ nslookup (или dig). Рассмотрим пример применения процедуры nslookup (здесь выполнены запросы по серверам имен, по почтовым серверам и по параметрам зоны ответственности):

Nslookup(запуск сервера)
Default Server: ns.itep.ru
Address: 193.124.224.35
set type=NS(запрос данных о серверах имен)
> > Server: ns.itep.ru
Address: 193.124.224.35
eunet.fi (определяем имя запрашиваемого узла)
Non-authoritative answer:
eunet.fi nameserver = ns1.EUNET.FI
eunet.fi nameserver = ns2.EUNET.FI
eunet.fi nameserver = ns3.eunet.fi
eunet.fi nameserver = ns.eu.net
eunet.fi nameserver = ns0.EUNET.FI
Authoritative answers can be found from (официальные данные могут быть получены от):
eunet.fi nameserver = ns1.EUNET.FI
set type=ANY (запрос всей информации)
..........................................
Non-authoritative answer:
eunet.fi Nameserver = ns1.EUNET.FI
eunet.fi Nameserver = ns2.EUNET.FI
eunet.fi Nameserver = ns3.eunet.fi
eunet.fi Nameserver = ns.eu.net
origin = ns1.eunet.fi
mail addr = hostmaster.eunet.fi
serial = 199607235
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
eunet.fi preference = 10, mail exchanger = pim.eunet.fi (Основной почтовый сервер)
eunet.fi preference = 50, mail exchanger = mail.eunet.fi
eunet.fi Nameserver = ns0.EUNET.FI
Authoritative answers can be found from:
eunet.fi nameserver = ns1.EUNET.FI
eunet.fi nameserver = ns2.EUNET.FI
eunet.fi nameserver = ns3.eunet.fi
eunet.fi nameserver = ns.eu.net
eunet.fi nameserver = ns0.EUNET.FI
ns1.EUNET.FI internet address = 192.26.119.7
ns2.EUNET.FI internet address = 192.26.119.4
ns3.eunet.fi internet address = 192.26.119.4
ns.eu.net internet address = 192.16.202.11
pim.eunet.fi internet address = 193.66.4.30
mail.eunet.fi internet address = 192.26.119.7
ns0.EUNET.FI internet address = 192.26.119.1
set type=MX (запрос информации о почтовых серверах)
...................................
Non-authoritative answer:
eunet.fi preference = 50, mail exchanger = mail.eunet.fi (имена почтовых серверов)
eunet.fi preference = 10, mail exchanger = pim.eunet.fi

Параметр preference характеризует степень предпочтения почтового сервера: чем он ниже — тем выше предпочтение.

Authoritative answers can be found from:
eunet.fi nameserver = ns1.EUNET.FI
eunet.fi nameserver = ns2.EUNET.FI
eunet.fi nameserver = ns3.eunet.fi
eunet.fi nameserver = ns.eu.net
eunet.fi nameserver = ns0.EUNET.FI
mail.eunet.fi internet address = 192.26.119.7
pim.eunet.fi internet address = 193.66.4.30
ns1.EUNET.FI internet address = 192.26.119.7
ns2.EUNET.FI internet address = 192.26.119.4
ns3.eunet.fi internet address = 192.26.119.4
ns.eu.net internet address = 192.16.202.11
ns0.EUNET.FI internet address = 192.26.119.1
set type=SOA (запрос параметров, зоны сервера имен, см. RFC-1034-35)
.......................................
Non-authoritative answer (см. документы RFC-1034-35):
origin = ns1.eunet.fi
mail addr = hostmaster.eunet.fi
serial = 199607235
refresh = 28800 (8 часов)
retry = 7200 (2 часа)
expire = 604800 (7 дней)
minimum ttl = 86400 (1 день)
Authoritative answers can be found from:
eunet.fi nameserver = ns1.EUNET.FI
eunet.fi nameserver = ns2.EUNET.FI
eunet.fi nameserver = ns3.eunet.fi
eunet.fi nameserver = ns.eu.net
eunet.fi nameserver = ns0.EUNET.FI
ns1.EUNET.FI internet address = 192.26.119.7
ns2.EUNET.FI internet address = 192.26.119.4
ns3.eunet.fi internet address = 192.26.119.4
ns.eu.net internet address = 192.16.202.11
ns0.EUNET.FI internet address = 192.26.119.1
>exit (команда выхода из nslookup)

Рассмотренный пример показывает, что DNS-сервер — весьма важный объект узла, от него зависит скорость обслуживания запросов и надежность системы в целом. Именно по этой причине любой узел помимо основного имеет один или более вторичных DNS-серверов.

Программа ).

Опции программы dig
Тип запроса	Запись DNS-сервера
`a`	Адресная запись
`any`	Любой тип записи
`axfr`	Все записи, относящиеся к зоне
`hinfo`	Записи, характеризующие ЭВМ
`mx`	Записи, определяющие почтовый обмен
`ns`	Записи сервера имен
`soa`	Начало записей для зоны ответственности DNS-сервера
`txt`	Текстовые записи

Ниже приведен пример использования команды dig для сервера имен узла DESY (Гамбург):

dig @vxdesy.desy.de ns
; <<>> DiG 2.0 <<>> @vxdesy.desy.de ns
; (3 servers found)
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 9, Auth: 9, Addit: 9
;; QUESTIONS:
;;., type = NS, class = IN
;; ANSWERS:
. 185470 NS A.ROOT-SERVERS.NET.
. 185470 NS H.ROOT-SERVERS.NET.
. 185470 NS B.ROOT-SERVERS.NET.
. 185470 NS C.ROOT-SERVERS.NET.
. 185470 NS D.ROOT-SERVERS.NET.
. 185470 NS E.ROOT-SERVERS.NET.
. 185470 NS I.ROOT-SERVERS.NET.
. 185470 NS F.ROOT-SERVERS.NET.
. 185470 NS G.ROOT-SERVERS.NET.
;; AUTHORITY RECORDS:
. 185470 NS A.ROOT-SERVERS.NET.
. 185470 NS H.ROOT-SERVERS.NET.
. 185470 NS B.ROOT-SERVERS.NET.
. 185470 NS C.ROOT-SERVERS.NET.
. 185470 NS D.ROOT-SERVERS.NET.
. 185470 NS E.ROOT-SERVERS.NET.
. 185470 NS I.ROOT-SERVERS.NET.
. 185470 NS F.ROOT-SERVERS.NET.
. 185470 NS G.ROOT-SERVERS.NET.
;; ADDITIONAL RECORDS:
A.ROOT-SERVERS.NET. 531366 A 198.41.0.4
H.ROOT-SERVERS.NET 531366 A 128.63.2.53
B.ROOT-SERVERS.NET. 531366 A 128.9.0.107
C.ROOT-SERVERS.NET. 578733 A 192.33.4.12
D.ROOT-SERVERS.NET. 578733 A 128.8.10.90
E.ROOT-SERVERS.NET. 547664 A 192.203.230.10
I.ROOT-SERVERS.NET. 578733 A 192.36.148.17
F.ROOT-SERVERS.NET. 531366 A 192.5.5.241
G.ROOT-SERVERS.NET. 531366 A 192.112.36.4
;; FROM: ns.itep.ru to SERVER: vxdesy.desy.de 131.169.30.46
;; WHEN: Thu Jul 25 12:07:54 1996
;; MSG SIZE sent: 17 rcvd: 429

Программа ifconfig служит для контроля состояния сетевых интерфейсов, их конфигурирования и проверки. С помощью этой команды интерфейсу присваивается IP-адрес, субсетевая маска и широковещательный адрес. Примером применения ifconfig для получения информации об интерфейсе может служить:

ifconfig le0
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>
inet 193.124.224.35 netmask ffffffe0 broadcast 193.124.224.32

Флаг UP означает, что интерфейс готов к использованию, DOWN указывает на необходимость перевода интерфейса в состояние UP с помощью команды ifconfig le0 up. Если эта команда не проходит, следует проверить соединительный кабель или сам интерфейс. Флаг RUNNING говорит о том, что интерфейс работает. При отсутствии этого флага нужно проверить правильность инсталляции. Флаг BROADCAST указывает на то, что интерфейс поддерживает широковещательный режим адресации ( MULTICAST — допускает многоадресное обращение). Флаг NOTRAILERS показывает, что интерфейс не поддерживает trailer-инкапсуляцию (Ethernet). Вторая строка отклика на команду начинается с ключевого слова inet (Интернет) и содержит IP-адрес, маску субсети и широковещательный адрес. На ошибку в задании маски субсети может указывать факт доступности удаленных ЭВМ и машин локальной субсети при недоступности ЭВМ соседних субсетей. При неверном задании IP-адреса возможны самые разные ошибки. При неверной сетевой части адреса команда Ping будет вызывать ошибку типа "no answer". Ошибка же в части адреса, характеризующей ЭВМ, может быть не замечена в течение длительного времени, если носителем ошибочного адреса является персональная ЭВМ, обращений к которой извне не происходит. Определенное время можно использовать и чужой IP-адрес. Такого рода ошибки не могут быть выявлены с помощью ifconfig, здесь хорошую службу может сослужить программа arp (см. описание протокола в RFC-826). Эта программа позволяет анализировать преобразование IP-адресов в физические (Ethernet). Она имеет несколько полезных опций (возможны вариации для разных реализаций и ОС):

`-a`	отображает содержимое всей ARP-таблицы
`-d <имя ЭВМ>`	удаляет запись из ARP-таблицы
`-s <имя ЭВМ> <Ethernet-адрес>`	Все записи, относящиеся к зоне

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

arp -a
itepgw.itep.ru          (193.124.224.33) at 0:0:c:2:3a:49
ITEP-FDDI-BBone.ITEP.RU (193.124.224.50) at 0:0:c:2:fb:c5
RosNET-Gw.ITEP.Ru       (193.124.224.37) at 0:c0:14:10:1:cd
nb.itep.ru              (193.124.224.60) at 0:80:ad:2:24:b7

Указанием на наличие ошибки в ARP-таблице может служить сообщение о недоступности или неизвестности ЭВМ при выполнении команд типа FTP или telnet. Такие сообщения возможны, например, при использовании одного и того же IP-адреса двумя ЭВМ. Все зависит от того, какая из машин успела "прописаться" в ARP-таблице раньше. Просматривая таблицу, администратор может заметить, что одному и тому же IP-адресу временами соответствуют разные физические адреса. Легальность адреса может быть проверена с помощью содержимого файла /etc/ethers. Первые три байта физического адреса характеризуют производителя интерфейса (см. Assigned Numbers, RFC-1700), что может помочь найти "IP-двойника". Если анализ ARP-таблицы не помог, попробуйте войти в ЭВМ, соответствующую подозрительному адресу, с помощью команды telnet (или FTP ). Если ЭВМ допускает удаленный доступ, характер входного сообщения поможет разобраться, что это за машина.

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

netstat -i
Name Mtu  Net/Dest       Address   Ipkts  Ierrs Opkts  Oerrs Collis Queue
le0  1500 193.124.224.32 ns        966204 0     584033 0     846    0
lo0  1536 127.0.0.0      127.0.0.1 4191   0     4191   0     0      0

Name — имя интерфейса, если в этом поле стоит *, это означает, что интерфейс в состоянии down ; Net/Dest показывает IP-адрес сети или ЭВМ, куда интерфейс осуществляет доступ; Address — IP-адрес интерфейса; Ipkt — число принятых пакетов; Ierr — число ошибок при приеме пакетов; Opkts — число отправленных пакетов через данный интерфейс, Oerrs — число ошибок при отправке; Collis — число столкновений в сегменте Ethernet, зафиксированных интерфейсом; Queue — длина очереди пакетов, ждущих отправки. Программа netstat позволяет ознакомиться и с маршрутной таблицей:

netstat -nr
Маршрутная таблица
Место назначения Маршрутизатор  Флаги Refcnt Use Интерфейс
192.148.166.185  193.124.224.33 UGHD  0      0   le0
192.148.166.161  193.124.224.33 UGHD  0      0   le0
192.148.166.97   193.124.224.33 UGHD  0      0   le0
192.148.166.177  193.124.224.33 UGHD  0      0   le0
192.148.166.129  193.124.224.33 UGHD  1      192 le0
192.148.166.145  193.124.224.33 UGHD  0      72  le0
192.148.166.170  193.124.224.33 UGHD  0      4   le0
192.148.166.26   193.124.224.60 UGHD  0      19  le0
192.148.166.131  193.124.224.33 UGHD  0      0   le0
192.148.166.140  193.124.224.33 UGHD  0      0   le0
192.148.166.173  193.124.224.33 UGHD  0      2   le0
192.148.166.182  193.124.224.33 UGHD  0      20  le0
192.148.166.142  193.124.224.33 UGHD  0      300 le0

Колонка место назначения указывает на конечную точку маршрута, колонка маршрутизатор — имя маршрутизатора, через который достижим адресат. Флаг "U" (Up) свидетельствует о том, что канал в рабочем состоянии. Флаг "G" указывает на то, что маршрут проходит через маршрутизатор (gateway). При этом вторая колонка таблицы содержит имя этого маршрутизатора или его адрес. Если флаг "G" отсутствует, ЭВМ непосредственно связана с указанной сетью. Флаг "D" указывает на то, что маршрут был добавлен динамически. Если маршрут связан только с конкретной ЭВМ, а не с сетью, он помечается флагом "H" (host), при этом первая колонка таблицы содержит его IP-адрес. Флаг "M" указывает на то, что маршрут был изменен с помощью сообщения о переадресации. Флаг <null> говорит о том, что адресат достижим непосредственно.

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

netstat -r 194.85.112.34
 input   (le0) errs   output  errs  colls   input   Total   Output  errs  colls
packets              packets               packets  errs   packets
7636610      0       4578719   0    5918   7674851    0    4616960   0    5918

Это может быть полезно при экспресс-диагностике внешних каналов связи, когда простого ping или traceroute оказалось недостаточно. Если возникло подозрение относительно маршрутизации пакетов, можно сначала проверить, работает ли программа gated. Для этого выдайте команду:

ps 'cat /etc/gated.pid'

после чего обратитесь к системному администратору :-).

Если нужно получить информацию о смонтированных файловых системах, вы можете воспользоваться командой:

showmount -e ns(ns - имя ЭВМ)
export list for ns.itep.ru:
/u1/SunITEP saturn.itep.ru,suncom.itep.ru

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

host -a vitep5
Trying domain "itep.ru"
rcode = 3 (Non-existent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=6
vitep5.itep.ru 86400 IN WKS 192.148.166.198 tcp ftp telnet
vitep5.itep.ru 86400 IN HINFO VAX-8530 VMS 5.3
vitep5.itep.ru 86400 IN MX 15 mx.itep.ru
vitep5.itep.ru 86400 IN MX 200 relay1.kiae.su
vitep5.itep.ru 86400 IN MX 210 relay2.kiae.su
vitep5.itep.ru 86400 IN A 192.148.166.198
Additional information:
relay1.kiae.su 18938 IN A 193.125.152.6
relay1.kiae.su 18938 IN A 193.125.152.1
relay2.kiae.su 18938 IN A 193.125.152.1

Во второй колонке данной выдачи указано время жизни пакетов (TTL) в секундах. Значение TTL в первых строках соответствует суткам ( 24x60x60=86400 ). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса. В пятой колонке идут названия серверов, IP-адреса ЭВМ и коды предпочтения (15, 200 и 210). Более подробно о возможностях этой команды можно ознакомиться в [11].

В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (NetWatch, WS_watch, SNMPMAN, Netguard и др.). Некоторые из этих пакетов позволяют построить графическую модель тестируемой сети, выделяя цветом или с помощью вариации картинок работающие ЭВМ. Программы, применяющие протокол SNMP, проверяют посредством специального запроса доступность SNMP -демона, с помощью ICMP -протокола определяют работоспособность ЭВМ, после чего отображают переменные и массивы данных из управляющей базы данных MIB (если эта база имеет уровень доступа public или если известен пароль community). Это может делаться автоматически или по запросу оператора. SNMP -протокол позволяет мониторировать вариации загрузки отдельных сегментов сети пакетами UDP, TCP, ICMP и т.д., регистрируя количество ошибок по каждому из активных интерфейсов. С точки зрения безопасности желательно использование SNMPv3. Для решения этой задачи можно применить программу, которая регулярно опрашивает MIB интересующих вас ЭВМ (например, MRTG ), а полученные числа заносятся в соответствующий банк данных. При возникновении нештатной ситуации администратор сети может просмотреть вариации потоков в сегментах сети и выявить время и причину сбоя в системе. Аналогичные данные можно получить с помощью программы, переводящей интерфейс Ethernet в режим приема всех пакетов ( mode=6 ). Такая программа допускает получение данных по всем типам пакетов, циркулирующих в данном кабельном сегменте. Введя в программу определенные фильтры (отбор по IP-адресам отправителей, получателей, по широковещательным запросам или определенным протоколам), можно узнать много полезного о своей сети. К сожалению, этот метод пригоден только в отношении логического сегмента, к которому подключена ваша ЭВМ. Такие программы могут использоваться для контроля сетевых ресурсов, если ЭВМ размещена на соответствующем сегменте, что может оказаться актуально в связи с коммерциализацией сетевых услуг. По этой причине метод диагностики через SNMP -резидентов более универсален. Упомянутые в начале программы Tcpdump и Etherfind крайне полезны для отладки программ, работающих с сетевыми пакетами. Они позволяют отображать все входящие и посылаемые пакеты. Следует иметь в виду, что эти программы потенциально опасны с точки зрения несанкционированного доступа и поэтому их применение часто возможно только для привилегированных пользователей. Работа интерфейса в режиме перехвата всех пакетов также представляет угрозу безопасности сети (возможность получения чужих паролей). С учетом этого обстоятельства должно приветствоваться применение программного обеспечения, где содержимое пакетов терминального обмена подвергается шифрованию-дешифрованию.

Определенный интерес может представлять диагностическая программа ttcp, которая позволяет измерять некоторые характеристики TCP- или UDP-обменов между двумя узлами.

Конфигурация сети и режимы ее работы определяются системными переменными, которые задаются администратором сети. Имена этих сетевых переменных для разных ЭВМ и программных пакетов варьируются. Ниже будут перечислены основные переменные, определяющие работу TCP/IP протоколов для Solaris (и SunOS).

SUBNETSARELOCAL — константа, определяющая начальное значение переменной ip_subnetsarelocal. Если она равна 1 (по умолчанию), то IP-адрес места назначения с идентификатором сети, идентичным с тем, что имеет ЭВМ-отправитель, считается локальным вне зависимости от идентификатора субсети. Если константа равна нулю, то локальным будет считаться только адрес, принадлежащий данной субсети (при совпадении идентификаторов сети и субсети).

IPSENDREDIRECTS — константа, используемая для определения стартового значения переменной ip_sendredirects. Если константа равна 1, (по умолчанию) ЭВМ при выполнении процедуры forward посылает ICMP -сообщения о переадресации. При равенстве нулю ICMP -сообщения не посылаются.

DIRECTED_BROADCAST — константа, определяющая начальное значение переменной ip_dirbroadcast. Если константа равна 1 (по умолчанию), получаемые дейтограммы, адрес места назначения которых является широковещательным адресом интерфейса, переадресуются на канальный широковещательный уровень. При равенстве нулю такие дейтограммы уничтожаются.

Ряд системных переменных содержится в файле in_proto каталога /usr/kvm/sys/netinet. При изменении этих переменных система должна быть перезагружена.

tcp_default_mss значение MSS протокола TCP для нелокальных адресатов, по умолчанию равна 512.

tcp_keepidle определяет число 500 мс тактов между посылками запросов о работоспособности. По умолчанию равна 14400 (2 час.).

tcp_keepintvl определяет число 500 мс тактов между посылками запросов о работоспособности, когда не получено никакого отклика. По умолчанию эта переменная равна 150 (75сек).

tcp_keeplen используется для обеспечения совместимости с ранними версиями (4.2BSD), должна равняться 1.

tcp_nodelack при неравенстве нулю требует отправки немедленного отклика (ACK), по умолчанию равна нулю.

tcp_recvspace определяет размер входного TCP-буфера и влияет на величину окна. По умолчанию эта переменная равна 4096.

tcp_sendspace определяет размер выходного TCP-буфера, по умолчанию равна 4096.

tcp_ttl задает значение поля TTL в TCP-сегменте, по умолчанию имеет значение 60.

udp_cksum при неравенстве нулю требует вычисления контрольной суммы для отправляемых UDP-дейтограмм и проверки контрольных сумм для получаемых UDP-дейтограмм, если поле контрольной суммы не равно нулю. По умолчанию переменная равна нулю.

udp_recvspace определяет размер входного UDP-буфера, по умолчанию равна 18000, что соответствует двум 9000-байтным дейтограммам.

udp_sendspace задает объем выходного UDP-буфера, ограничивая предельную длину посылаемой дейтограммы. По умолчанию переменная равна 9000.

udp_ttl определяет значение поля TTL для UDP-дейтограмм, значение по умолчанию - 60.

Для изменения значений этих переменных необходимо иметь системные привилегии.

Протокол SNMP

Интернет — гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без централизованного управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ: сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089 разработан в 1988 году; версия 3 – RFC-3411, -3412, -3413, STD0062) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP -UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.

Протокол SNMP работает на базе транспортных возможностей UDP (допустимы реализации и на основе ТСР) и предназначен для применения в сетевых управляющих станциях. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP -сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных ( MIB — management information base, RFC-1213, -1212, -2613, -2788, -3418).

Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и определены в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу система входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу интерфейсы входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB и т.д.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица 8.4 команд ( pdu — protocol data unit) SNMP:

Команды SNMP
Команда SNMP	Тип PDU	Назначение
`GET-request`	0	Получить значение указанной переменной или информацию о состоянии сетевого элемента;
`GET_next_request`	1	Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB );
`SET-request`	2	Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;
`GET response`	3	Отклик на `GET-request`, `GET_next_request` и `SET-request`. Содержит также информацию о состоянии (коды ошибок и другие данные);
`TRAP`	4	Отклик сетевого объекта на событие или на изменение состояния.
`GetBulkRequest`	5	Запрос пересылки больших объемов данных, например, таблиц.
`InformRequest`	6	Менеджер обращает внимание партнера на определенную информацию в MIB.
`SNMPv3-Trap`	7	Отклик на событие (расширение по отношению v1 и v2).
`Report`	8	Отчет (функция пока не задана).

Формат SNMP -сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис 8.2):

(рис 8.2) Схема запросов/откликов SNMP(рис 8.1) Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы

Поле версия содержит значение, равное номеру версии SNMP минус один. Поле пароль ( community — определяет группу доступа) включает в себя последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:

Номера и назначения используемых портов
Назначение	Порт	Пояснение
SNMP	161/TCP	Simple Network Management Protocol
SNMP	162/TCP	Trap
SMUX	199/TCP	SNMP Unix Multiplexer
SMUX	199/UDP	SNMP Unix Multiplexer
synoptics-relay	391/TCP	SynOptics SNMP Relay Port
synoptics-relay	391/UDP	SynOptics SNMP Relay Port
SNMP	161/TCP	Simple Network Management Protocol
agentx	705/TCP	AgentX
snmp -tcp-port	1993/TCP	cisco SNMP TCP port
snmp -tcp-port	1993/UDP	cisco SNMP TCP port

Если произошла ошибка, поле индекс ошибки (error index) определяет, к какой из переменных это относится. error index является указателем переменной и устанавливается объектом управления не равным нулю для ошибок badvalue, readonly и nosuchname. Для оператора TRAP (тип PDU=4) формат сообщения меняется. Таблица типов TRAP представлена ниже (табл. 8.7).

Коды ошибок
Статус ошибки	Имя ошибки	Описание
0	Noerror	Все в порядке;
1	Toobig	Объект не может уложить отклик в одно сообщение;
2	Nosuchname	В операции указана неизвестная переменная;
3	badvalue	В команде set использована недопустимая величина или неправильный синтаксис;
4	Readonly	Менеджер попытался изменить константу;
5	Generr	Прочие ошибки.

Коды TRAP
Тип TRAP	Имя TRAP	Описание
0	Coldstart	Установка начального состояния объекта.
1	Warmstart	Восстановление начального состояния объекта.
2	Linkdown	Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс.
3	Linkup	Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс.
4	Authenticationfailure	От менеджера получено snmp -сообщение с неверным паролем (community).
5	EGPneighborloss	EGP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера.
6	Entrprisespecific	Информация о TRAP содержится в поле специальный код.

Для тип TRAP 0-4 поле специальный код должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так, прерывание coldstart выдается объектом через 200 мс после инициализации.

В последнее время широкое распространение получила идеология распределенного протокольного интерфейса ):

(рис 8.3) Формат заголовка SNMP-запроса

Поле Флаг=0x30 является признаком ASN.1-заголовка. Коды Ln представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так, L1 — длина пакета-запроса, начиная с T1 и до конца пакета, а L3 — длина поля пароля. Субполя Tn — поля типа следующего за ними субполя запроса. Так, T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 8.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы — для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением L_из. СО — статус ошибки (СО=0 — ошибки нет); ТМ — тип MIB -переменной (в приведенном примере = 0x2B ); ИО — индекс ошибки. Цифровой код MIB -переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) задана последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3 (RFC-3411 [ ). Перечисленные подсистемы служат основой функционирования генератора и обработчика команд, отправителя и обработчика уведомлений и прокси-сервера (Proxy Forwarder), работающих на прикладном уровне. Процессор SNMP идентифицируется с помощью snmpEngineID. Обеспечение безопасности модели работы SNMP упрощается обычно тем, что обмен запросами-откликами осуществляется в локальной сети, а источники запросов-откликов легко идентифицируются.

(рис 8.4) Архитектура сущности SNMP (SNMP-entity)

Компоненты процессора SNMP перечислены в таблице 8.8 (смотри RFC 2571 и -2573)

Компоненты процессора SNMP
Название компонента	Функция компонента
Диспетчер	Позволяет одновременную поддержку нескольких версий SNMP -сообщений в процессоре SNMP. Этот компонент ответственен за прием протокольных блоков данных (PDU), за передачу PDU подсистеме обработки сообщений, за передачу и прием сетевых SNMP -сообщений
Подсистема обработки сообщений	Ответственна за подготовку сообщений для отправки и за извлечение данных из входных сообщений
Подсистема безопасности	Предоставляет услуги, обеспечивающие безопасность: аутентификацию и защищенность сообщений от перехвата и искажения. Допускается реализация нескольких моделей безопасности
Подсистема управления доступом	Предоставляет ряд услуг авторизации, которые могут использоваться приложениями для проверки прав доступа.
Генератор команд	Инициирует SNMP -запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы, которые могут использоваться приложениями для проверки прав доступа.
Обработчик команд	Воспринимает SNMP -запросы Get, GetNext, GetBulk или Set, предназначенные для локальной системы; это индицируется тем, что contextEngeneID в полученном запросе равно соответствующему значению в процессоре SNMP. Приложение обработчика команд выполняет соответствующие протокольные операции, генерирует сообщения отклика и посылает их отправителю запроса.
Отправитель уведомлений	Мониторирует систему на предмет выявления определенных событий или условий и генерирует сообщения Trap или Inform. Источник уведомлений должен иметь механизм определения адресата таких сообщений, а также параметров безопасности
Получатель уведомлений	Прослушивает сообщения уведомления и формирует сообщения-отклики, когда приходит сообщение с PDU Inform
Прокси-сервер	Переадресует SNMP -сообщения. Реализация этого модуля является опционной

На рис 8.5 показан формат сообщений SNMPv3, реализующий модель безопасности UBM (User-Based Security Model).

(рис 8.5) Формат сообщений SNMPv3 c UBM

Первые пять полей формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем. Следующие шесть полей несут в себе параметры безопасности. Далее следует PDU (блок поля данных) с contextEngeneID и contextName.

msgVersion (для SNMPv3)=3

msgID — уникальный идентификатор, используемый SNMP -сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 - (2³¹-1)

msgMaxSize - определяет максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 - (2³¹-1) и равно максимальному размеру сегмента, который может воспринять отправитель.

msgFlags - 1-октетная строка, содержащая три флага в младших битах: reportableFlag, privFlag, authFlag. Если reportableFlag=1, должно быть прислано сообщение с PDU Report; когда флаг =0, Report посылать не следует. Флаг reportableFlag=1 устанавливается отправителем во всех сообщениях запроса (Get, Set) или Inform. Флаг устанавливается равным нулю в откликах, уведомлениях Trap или сообщениях Report. Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 — аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFlag=0 (шифрование без аутентификации).

msgSecurityModel - идентификатор со значением в диапазоне 0 - (2³¹-1), который указывает на модель безопасности, использованную при формировании данного сообщения. Зарезервированы значения 1 для SNMPv1,2 и 3 - для SNMPv3.

Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного сервера (authoritative Engine). При любой передаче сообщения одна или две сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP -сервера. Это делается согласно следующим правилам.

Когда SNMP -сообщение содержит поле данных, которое предполагает отклик (например, Get, GetNext, GetBulk, Set или Inform), получатель такого сообщения считается авторизованным.

Когда SNMP -сообщение содержит поле данных, которое не предполагает посылку отклика (например, SNMPv2-Trap, Response или Report), тогда отправитель такого сообщения считается авторизованным.

Таким образом, для сообщений, посланных генератором команд, и сообщений Inform, посланных отправителем уведомлений, получатель является авторизованным. Для сообщений, посланных обработчиком команд или отправителем уведомлений Trap, отправитель является авторизованным. Такой подход имеет две цели:

своевременность сообщения определяется с учетом показания часов авторизованного сервера. Когда авторизованный сервер посылает сообщение (Trap, Response, Report), оно содержит текущее показание часов, так что неавторизованный получатель может синхронизовать свои часы. Когда неавторизованный сервер посылает сообщение (Get, GetNext, GetBulk, Set, Inform), он помещает туда текущую оценку показания часов места назначения, позволяя получателю оценить своевременность прихода сообщения;

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

Когда исходящее сообщение передается процессором сообщений в USM, последний заполняет поля параметров безопасности в заголовке сообщения. Когда входное сообщение передается обработчиком сообщений в USM, обрабатываются значения параметров безопасности, содержащихся в заголовке сообщения. В параметрах безопасности содержатся:

msgAuthoritativeEngeneID — snmpEngeneID авторизованного сервера, участвующего в обмене. Таким образом, это значение идентификатора отправителя для Trap, Response или Report или адресата для Get, GetNext, GetBulk, Set или Inform.

msgAuthoritativeEngeneBoots — snmpEngeneBoots авторизованного сервера, участвующего в обмене. Объект snmpEngeneBoots является целым в диапазоне 0 - (2³¹-1). Этот код указывает, сколько раз SNMP -сервер был перезагружен с момента конфигурирования.

msgAuthoritativeEngeneTime — nmpEngeneTime авторизованного сервера, участвующего в обмене. Значение этого кода лежит в диапазоне 0 - (231-1). Этот код характеризует число секунд, которое прошло с момента последней перезагрузки. Каждый авторизованный сервер должен инкрементировать этот код один раз в секунду.

msgUserName — идентификатор пользователя, от имени которого послано сообщение.

msgAuthenticationParameters — нуль, если при обмене не используется аутентификация. В противном случае — это аутентификационный параметр.

msgPrivacyParameters — нуль — если не требуется соблюдения конфиденциальности. В противном случае — это параметр безопасности. В действующей модели USM применяется алгоритм шифрования DES.

Механизм аутентификации в SNMPv3 предполагает, что полученное сообщение действительно послано принципалом, идентификатор которого содержится в заголовке сообщения, и он не был модифицирован по дороге. Для реализации аутентификации каждый из принципалов, участвующих в обмене, должен иметь секретный ключ аутентификации, общий для всех участников (определяется на фазе конфигурации системы). В посылаемое сообщение отправитель должен включить код, который является функцией содержимого сообщения и секретного ключа. Одним из принципов USM является проверка своевременности сообщения (смотри выше), что делает маловероятной атаку с использованием копий сообщения.

Система конфигурирования агентов позволяет обеспечить разные уровни доступа к MIB для различных SNMP -менеджеров. Это делается путем ограничения доступа некоторым агентам к определенным частям MIB, а также с помощью ограничения перечня допустимых операций для заданной части MIB. Такая схема управления доступом называется VACM (View-Based Access Control Model). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurityToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

SNMP -протокол служит примером системы управления, где для достижения нужного результата выдается не команда, а осуществляется обмен информацией, решение же принимается на месте в соответствии с полученными данными. Внедрены подсистемы аутентификации, информационной безопасности и управления доступом.

RFC-документы по протоколу SNMP
Название	Дата	Наименование документа
STD-15	май 1990	Simple Network Management Protocol (RFC-1157)
STD-16	май 1990	Structure and Identification of Management Information for TCP/IP-based Internets (RFC-1155)
SNMPv3
RFC3411	декабрь 2002	An Architecture for Describing Simple Network Management Protocol ( SNMP ) Management Frameworks. ( std0062 )
RFC3412	декабрь 2002	Message Processing and Dispatching for the Simple Network Management Protocol ( SNMP ).
RFC3413	декабрь 2002	Simple Network Management Protocol ( SNMP ) Applications
RFC3414	декабрь 2002	User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
RFC3415	декабрь 2002	View-based Access Control Model (VACM) for the Simple Network Management Protocol ( SNMP ).
RFC3417	декабрь 2002	Transport Mappings for the Simple Network Management Protocol ( SNMP )
RFC3418	декабрь 2002	Management Information Base ( MIB ) for the Simple Network Management Protocol ( SNMP )

Страницы: