From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Modules/SNMP and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська
Модуль Ім'я Версія Ліцензія Джерело Мови Платформи Тип Автор Опис
SNMP SNMP клієнт 0.8 GPL2 daq_SNMP.so en,uk,ru,de x86,x86_64,ARM DAQ Роман Савоченко Надає реалізацію клієнту SNMP-сервісу.

Протокол SNMP було розроблено з метою перевірки функціонування мережевих маршрутизаторів та мостів у 1988 році. Згодом сфера дії протоколу охопила і інші мережеві пристрої, такі як хаби, шлюзи, термінальні сервери та навіть пристрої, які мають віддалений стосунок до мереж: принтери, джерела безперебійного живлення, ПЛК та інші. Крім того, протокол допускає можливість внесення змін у функціонування вказаних пристроїв. На цей час протокол SNMP стандартизовано як RFC-1157, -1215, -1187, -1089.

Цей модуль надає можливість збирати інформацію та вносити зміни до різних пристроїв за SNMP протоколом та за допомогою бібліотеки NetSNMP. Також модулем реалізується функція горизонтального резервування, а саме спільна робота з віддаленою станцією цього-ж рівня.

1 SNMP

Основними дієвими "особами" протоколу є агенти та системи управління. Якщо розглядати ці два поняття на мові "клієнт-сервер", то роль серверу виконують агенти, тобто ті самі пристрої для опитування стану яких й було розроблено протокол. Відповідно роль клієнтів доводиться системам управління – мережевим додаткам, потрібним для збору інформації про функціювання агентів. Окрім цих двох суб'єктів у моделі протоколу можна виокремити також ще два: керуючу інформацію та сам протокол обміну даними.

Вся інформація про об'єкти системи-агенту міститься в так званому MIB (management information base) – базі керуючої інформації, іншими словами MIB представляє собою сукупність об'єктів (MIB-змінні), доступних для операцій запис-читання.

На цей час існує чотири типові бази MIB:

1. Internet MIB – база об'єктів для забезпечення діагностики помилок та конфігурацій. Включає у себе 171 об'єкти (у тому числі і об'єкти MIB I).
2. LAN manager MIB – база з 90 об'єктів – паролі, сесії, користувачі, загальні ресурси.
3. WINS MIB – база об'єктів, потрібних для функціювання WINS серверу.
4. DHCP MIB – база об'єктів, потрібних для функціювання DHCP сервера, що слугує для динамічного виділення IP адрес у мережі.

Окрім вищенаведених типових баз MIB можуть довантажуватися у вигляді модулів, згідно із бібліотекою NetSNMP.

1.1 MIB

Всі імена MIB мають ієрархічну структуру. Існують десять кореневих псевдонімів:

1. System — ця група MIB II містить у собі сім об'єктів, кожний з яких слугує для зберігання інформації про систему (версія ОС, час роботи та інше).
2. Interfaces — містить 23 об'єкти, потрібні для ведення статистики мережевих інтерфейсів агентів (кількість інтерфейсів, розмір MTU, швидкість передачі, фізичні адреси та інше).
3. AT (3 об'єкти) — відповідають за трансляцію адрес. Більш не використовуються. Була включена до MIB I. У SNMP v2 цю інформацію було перенесено до MIB для відповідних протоколів.
4. IP (42 об'єкти) — дані про IP пакети, що проходять (кількість запитів, відповідей, відкинутих пакетів).
5. ICMP (26 об'єктів) — інформація про контрольні повідомлення (вхідні/вихідні повідомлення, помилки та інше).
6. TCP (19) — все, що стосується однойменного транспортного протоколу (алгоритми, константи, підключення, відкриті порти та інше).
7. UDP (6) — аналогічно, тільки для UDP протоколу (вхідні/вихідні датаграми, порти, помилки).
8. EGP (20) — дані про трафік Exterior Gateway Protocol (використовується маршрутизаторами, об'єкти зберігають інформацію про прийняті/відіслані/відкинуті кадри).
9. Transmission — зарезервовано для специфічних MIB.
10. SNMP (29) — статистика по SNMP – вхідні/вихідні пакети, обмеження пакетів за розміром, помилки, дані про оброблені запити та багато іншого.

1.2 Адресація

Кожний з кореневих псевдонімів представляється у вигляді дерева, що росте донизу. Наприклад, до адреси адміністратору можна звернутися за посередництвом шляху: "system.sysContact.0", до часу роботи системи: "system.sysUpTime.0", до опису системи (версія, ядро та інша інформація про ОС): "system.sysDescr.0". З іншого боку, ті-ж дані можуть задаватися й у точковій нотації. Так "system.sysUpTime.0" відповідає значення "1.3.0", так як "system" має індекс "1" у групах MIB II, а "sysUpTime" – 3, у ієрархії групи "system". Нуль у кінці шляху каже про скалярний тип даних, що зберігаються. У процесі роботи символьні імена об'єктів не використовуються, тобто якщо менеджер запитує у агента вміст параметру "system.sysDescr.0", то у рядку запиту посилання на об'єкт буде перетворено у "1.1.0", а не передано "як є".

В цілому існує декілька способів запису адреси до MIB-змінної:

1. ".1.3.6.1.2.1.1" — пряма кодова адресація для об'єкту "System" (кореневий псевдонім System). При такій адресації кожна MIB змінна кодується ідентифікатором, а повна адреса записується у вигляді послідовності ідентифікаторів, поділених крапкою зліва на право. Такий запис адреси є основним та всі інші способи запису приводяться до нього.
2. ".iso.org.dod.internet.mgmt.mib-2.system" — повна символьна до прямої кодової адресації для об'єкту "System".
3. "system.sysDescr.0" — проста, не повним шляхом, адресація відносно кореневого псевдоніма (об'єкт "System").
4. "SNMPv2-MIB::sysDescr.0" — адресація із MIB бази та від ім'я модуля, для "system.sysDescr.0".

1.3 Взаємодія

SNMP клієнт взаємодії з сервером за принципом запит-відповідь. Сам по собі агент спроможний ініціювати тільки одну дію, яка називається пасткою переривань. Окрім цього, всі дії агентів зводяться до відповідей на запити, які надсилаються менеджерами.

Існують три основні версії протоколу SNMP (v1 & v2 & v3), які не є сумісними. SNMP v3 підтримує шифрування трафіку, для чого, у залежності від реалізації, використовуються алгоритми DES, MD5. Це веде до того, що при передачі більш важливі дані недоступні для прослуховування. У якості транспортного протоколу у SNMP зазвичай використовується протокол UDP, Хоча насправді SNMP підтримує багато інших транспортних протоколів нижнього рівня.

1.4 Авторизація

Одним з ключових понять у SNMP є група (group). Процедура авторизації менеджеру полягає у простій перевірці на приналежність його до визначеної групи, із переліку, що знаходиться у агента. Якщо агент не знаходить групи менеджеру у своєму переліку то їх подальша взаємодія неможлива. По замовченню використовуються групи: public (для читання) та private (для запису). У протоколі SNMP v3 для аутентифікації використовується поняття користувача з паролем аутентифікації та приватності, залежної від рівня секретності.

2 Модуль

Цей модуль підтримує роботу з усіма версіями протоколу SNMP (1, 2 та 3) у режимах читання та запису MIB-параметрів, завдяки використанню бібліотеки NetSNMP.

2.1 Об'єкт контролеру

Для додання джерел даних SNMP у OpenSCADA створюються та конфігуруються об'єкти контролеру. Приклад вкладки конфігурації об'єкту контролеру даного типу зображено на рисунку 1.

Рис.1. Вкладка конфігурації об'єктів контролеру.

За допомогою цієї вкладки можна встановити:

  • Стан об'єкту контролера, а саме: Статус, "Включено", "Виконується" та ім'я БД, яка містить конфігурацію.
  • Ідентифікатор, ім'я та опис об'єкту контролера.
  • Стан у який переводити об'єкт контролеру при завантажені: "Включати" та "Запускати".
  • Ім'я таблиці для зберігання конфігурації параметрів об'єкту контролеру.
  • Політика планування та пріоритет задачі збору даних.
  • Адреса віддаленого хосту агенту.
  • Кількість спроб відправки запитів.
  • Час очікування відповідей, у секундах.
  • Використану версію протоколу SNMP.
  • Спільноту або користувача підключення.
  • Обмеження на кількість атрибутів у одному параметрі.
  • Рівень безпеки для v3 (Немає автент./Немає приватн.; Автент./Немає приватн.; Автент./Приватн.).
  • Метод кодування (MD5, SHA) та пароль автентифікації для v3.
  • Метод кодування (DES, AES) та приватність автентифікації для v3.

2.2 Параметр об'єкту контролеру

Модуль SNMP надає тільки один тип параметрів — "Стандарт". Додатковим конфігураційним полем параметру цього модуля (рис.2) є перелік MIB-параметрів, гілки або окремі елементи (скаляри) яких підлягають зчитуванню.

Рис.2. Вкладка конфігурації параметрів.

Згідно до визначеного переліку MIB-параметрів здійснюється опитування їх гілок (або скалярів) та створення атрибутів параметрів. Надалі здійснюється оновлення значень параметрів. Атрибути іменуються згідно до кодової адресації MIB-параметрів, у якості ідентифікатору, та адресації від бази MIB об'єктів, у назві атрибуту (Рис.3).

Рис.3. Вкладка атрибутів параметрів.