SNMP. Знакомимся с протоколом сетевого управления.
Итак, поехали. Наверное, многие из вас, рано или поздно озадачивались вопросом мониторинга сетевого оборудования. В простейшем случае мониторинг сетевого оборудования (а именно проверку его доступности) можно организовать при помощи утилиты ping, использованной в несложных скриптах. Подобные решения будут периодически отправлять на требуемое оборудование ICMP запросы, и если оборудование будет присылать ICMP ответы, то скрипт будет отображать что оборудование доступно. Конечно, такой способ прост, хорош и имеет право на жизнь, но что если нам хочется чего то большего чем просто знать в работе сетевой интерфейс устройства или нет? Что если нам хочется следить за значениями конкретных параметров устройства (наличие ошибок, параметры входного/выходного напряжения, загрузку ОЗУ, CPU, состояние плат и т.д.) во время его работы? В этом нелегком деле на помощь нам придет протокол SNMP (Simple Network Management Protocol, простой протокол сетевого управления).
Протокол SNMP предназначен для мониторинга и управления активным сетевым оборудованием. Для осуществления мониторинга (управления) оборудования при помощи данного протокола, оборудование должно его поддерживать (Узнать поддерживает оборудование его или нет можно в его технических характеристиках). Каждое устройство поддерживающее протокол SNMP хранит в своей памяти упорядоченный набор переменных отвечающих за различные параметры устройства (например, за количество ошибок на интерфейсе и т.д.). Данный упорядоченный набор переменных называется MIB (Management Information Base, Административная База Данных). Для удобства работы c MIB они поставляются в виде отдельных текстовых файлов, содержащих как название переменных, так и их параметры, и краткое описание. К каждой переменной поддерживаемой устройством можно обратиться для её чтения или записи (если запись данной переменной разрешена) при помощи её уникального OID (Object Identifier, идентификатор объекта). Все переменные в MIB иерархически упорядочены и весь MIB можно представить в виде некоторого дерева, в ветвях которого сгруппированы переменные в соответствии с их назначением.
На рисунке представлен фрагмент MIBa некоторого оборудования. Синим цветом отмечены ветви дерева MIB. Каждая из ветвей дерева имеет OID. Хотя по данному OIDу нельзя получить какое либо значение переменной, они необходимы для определения места какого то отдельного параметра в общей структуре. Зеленым цветом отмечена некоторая переменная, значение которой мы можем считать и (или) изменить при помощи протокола SNMP. Для облегчения понимания структуры MIB попробуем провести аналогию между файлами и папками на компьютере. Ветви дерева похожи на папки (каталоги) на наших компьютерах, а переменные похожи на файлы, расположенные в этих папках, а значения OID в таком случае это аналог ссылок на файлы. Данные «ссылки» могут быть представлены как в полном текстовом виде, составленном на основе имен ветвей и параметров, так и в сокращенной числовой форме, на основе номеров ветвей и параметров.
Из всего вышесказанного можно сделать следующий вывод – для получения некоторого параметра от устройства по протоколу SNMP, к нему необходимо обратиться и запросить некоторый OID (Ну или же отдать команду на перезапись некоторого OIDа). Рассмотрим, как это можно сделать. Общение по протоколу SNMP происходит между агентом и менеджером (можно провести аналогию с клиент - сервер) SNMP. Агент SNMP это встроенная в оборудование (или программно устанавливаемая отдельная) программная прокладка осуществляющая связь между железом оборудования и протоколом SNMP. Менеджер SNMP это программное обеспечение, устанавливаемое на станцию (компьютер) управления.
Для общения между клиентом и менеджером SNMP используются следующие команды (набор данных команд может отличаться в зависимости от используемой версии протокола SNMP):
> GetRequest – позволяет запросить менеджеру от агента значение одной или нескольких переменных на основе номера OID;
> GetReponse – ответ агента менеджеру, возвращающий запрошенные значения переменных;
> GetNextRequest – данная команда отправляется от менеджера к агенту и используется для последовательного чтения значений переменных. Например, она может быть использована для чтения значений из таблиц, обнаружения доступных переменных и их значений;
> SetRequest – команда от менеджеру к агенту на установку значения некоторой переменной.
Как видно большинство данных команд отвечает за запросы менеджера к агенту и лишь одна, GetReponse за ответ агента менеджеру. Тут стоит отметить, что команда GetReponse генерируется только в случае ранее поступившего от менеджера запроса, самостоятельно она не используется.
Давайте рассмотрим примеры использования данных команд. Например, мы хотим запросить от устройства значение его переменной с некоторым OID. Для этого менеджер должен отправить на агент устройства команду GetRequest с указанием требуемого OID. Агент устройства примет данную команду, обработает, и если все нормально и данный параметр существует, то отправит на менеджер команду GetReponse содержащую значение данного параметра (конечно процесс общения менеджера и агента здесь сильно упрощен =) ).
Если мы хотим изменить значение какой либо переменной на устройстве, то нам необходимо менеджером инициализировать команду SetRequest с указанием требуемого OID и новым значением данной переменной. Если все нормально и значение переменной может быть заменено на указанное значение, то агент вернет сообщение GetReponse со значение установленным в переменную.
Кроме перечисленных выше команд, есть еще одна очень интересная команда Trap, которая генерирует сообщение от агента к менеджеру, необходимость выполнения данной команды регулируется самим агентом. Например, если на устройстве включены trap сообщения, и на устройстве произойдет некоторое определенное событие, то агент отправить менеджеру trap сообщение, извещающее менеджера о случившемся.
Наверное, вы уже могли обратить внимание на то, что чтение некоторых параметров устройства (а тем более их запись) может поставить под угрозу безопасность наших управляемых устройств. При помощи протокола SNMP злоумышленник может, как получить с устройства закрытую информацию, так и сделать устройство неработоспособным. Чтобы такого не произошло, в протокол SNMP встроены базовые средства обеспечения безопасности. Для того чтобы менеджер и агент могли обмениваться сообщениями на обоих должна быть задан один и тот же пароль, называемый Community (Все рассматривается очень упрощенно и без учета версий протокола SNMP). Обычно для повышения безопасности для чтения и чтения/записи устанавливаются разные значения Community. Обычно по умолчанию в устройстве для чтения задается Community – public, а для чтения/записи – private. При использование SNMP в производственных задачах настоятельно рекомендуется изменить данные Community.
Надо будет как-нибудь поднять вопрос применения протокола SNMP на практике, но это уже совсем другая история.
Протокол SNMP предназначен для мониторинга и управления активным сетевым оборудованием. Для осуществления мониторинга (управления) оборудования при помощи данного протокола, оборудование должно его поддерживать (Узнать поддерживает оборудование его или нет можно в его технических характеристиках). Каждое устройство поддерживающее протокол SNMP хранит в своей памяти упорядоченный набор переменных отвечающих за различные параметры устройства (например, за количество ошибок на интерфейсе и т.д.). Данный упорядоченный набор переменных называется MIB (Management Information Base, Административная База Данных). Для удобства работы c MIB они поставляются в виде отдельных текстовых файлов, содержащих как название переменных, так и их параметры, и краткое описание. К каждой переменной поддерживаемой устройством можно обратиться для её чтения или записи (если запись данной переменной разрешена) при помощи её уникального OID (Object Identifier, идентификатор объекта). Все переменные в MIB иерархически упорядочены и весь MIB можно представить в виде некоторого дерева, в ветвях которого сгруппированы переменные в соответствии с их назначением.
Пример структуры некоторого MIBa
На рисунке представлен фрагмент MIBa некоторого оборудования. Синим цветом отмечены ветви дерева MIB. Каждая из ветвей дерева имеет OID. Хотя по данному OIDу нельзя получить какое либо значение переменной, они необходимы для определения места какого то отдельного параметра в общей структуре. Зеленым цветом отмечена некоторая переменная, значение которой мы можем считать и (или) изменить при помощи протокола SNMP. Для облегчения понимания структуры MIB попробуем провести аналогию между файлами и папками на компьютере. Ветви дерева похожи на папки (каталоги) на наших компьютерах, а переменные похожи на файлы, расположенные в этих папках, а значения OID в таком случае это аналог ссылок на файлы. Данные «ссылки» могут быть представлены как в полном текстовом виде, составленном на основе имен ветвей и параметров, так и в сокращенной числовой форме, на основе номеров ветвей и параметров.
Из всего вышесказанного можно сделать следующий вывод – для получения некоторого параметра от устройства по протоколу SNMP, к нему необходимо обратиться и запросить некоторый OID (Ну или же отдать команду на перезапись некоторого OIDа). Рассмотрим, как это можно сделать. Общение по протоколу SNMP происходит между агентом и менеджером (можно провести аналогию с клиент - сервер) SNMP. Агент SNMP это встроенная в оборудование (или программно устанавливаемая отдельная) программная прокладка осуществляющая связь между железом оборудования и протоколом SNMP. Менеджер SNMP это программное обеспечение, устанавливаемое на станцию (компьютер) управления.
Общение по протоколу SNMP между агентом и менеджером
Для общения между клиентом и менеджером SNMP используются следующие команды (набор данных команд может отличаться в зависимости от используемой версии протокола SNMP):
> GetRequest – позволяет запросить менеджеру от агента значение одной или нескольких переменных на основе номера OID;
> GetReponse – ответ агента менеджеру, возвращающий запрошенные значения переменных;
> GetNextRequest – данная команда отправляется от менеджера к агенту и используется для последовательного чтения значений переменных. Например, она может быть использована для чтения значений из таблиц, обнаружения доступных переменных и их значений;
> SetRequest – команда от менеджеру к агенту на установку значения некоторой переменной.
Как видно большинство данных команд отвечает за запросы менеджера к агенту и лишь одна, GetReponse за ответ агента менеджеру. Тут стоит отметить, что команда GetReponse генерируется только в случае ранее поступившего от менеджера запроса, самостоятельно она не используется.
Давайте рассмотрим примеры использования данных команд. Например, мы хотим запросить от устройства значение его переменной с некоторым OID. Для этого менеджер должен отправить на агент устройства команду GetRequest с указанием требуемого OID. Агент устройства примет данную команду, обработает, и если все нормально и данный параметр существует, то отправит на менеджер команду GetReponse содержащую значение данного параметра (конечно процесс общения менеджера и агента здесь сильно упрощен =) ).
Запрос на чтение переменной по протоколу SNMP
Если мы хотим изменить значение какой либо переменной на устройстве, то нам необходимо менеджером инициализировать команду SetRequest с указанием требуемого OID и новым значением данной переменной. Если все нормально и значение переменной может быть заменено на указанное значение, то агент вернет сообщение GetReponse со значение установленным в переменную.
Запрос на запись переменной по протоколу SNMP
Кроме перечисленных выше команд, есть еще одна очень интересная команда Trap, которая генерирует сообщение от агента к менеджеру, необходимость выполнения данной команды регулируется самим агентом. Например, если на устройстве включены trap сообщения, и на устройстве произойдет некоторое определенное событие, то агент отправить менеджеру trap сообщение, извещающее менеджера о случившемся.
Наверное, вы уже могли обратить внимание на то, что чтение некоторых параметров устройства (а тем более их запись) может поставить под угрозу безопасность наших управляемых устройств. При помощи протокола SNMP злоумышленник может, как получить с устройства закрытую информацию, так и сделать устройство неработоспособным. Чтобы такого не произошло, в протокол SNMP встроены базовые средства обеспечения безопасности. Для того чтобы менеджер и агент могли обмениваться сообщениями на обоих должна быть задан один и тот же пароль, называемый Community (Все рассматривается очень упрощенно и без учета версий протокола SNMP). Обычно для повышения безопасности для чтения и чтения/записи устанавливаются разные значения Community. Обычно по умолчанию в устройстве для чтения задается Community – public, а для чтения/записи – private. При использование SNMP в производственных задачах настоятельно рекомендуется изменить данные Community.
Надо будет как-нибудь поднять вопрос применения протокола SNMP на практике, но это уже совсем другая история.
Комментариев 1