Скачать в формате PDF 
|
|---|
Расширение возможностей протоколирования и мониторинга шлюза безопасности «С-Терра Шлюз»
Настоящий документ содержит описание способа совместного использования Продуктов компании ООО
«С-Терра СиЭсПи» и Продуктов третьих производителей.
ООО «С-Терра СиЭсПи» осуществляет сопровождение настоящего сценария в части настроек Продуктов Компании. Упоминание наименований, продуктов, торговых марок третьих организаций исключительно неформально и не является поддержкой, рекомендацией либо рекламой. ООО «С-Терра СиЭсПи» не несет какой-либо ответственности в отношении работоспособности и использования этих Продуктов.
Документ имеет статус вспомогательного материала, который может быть использован технологическими партнерами, компаниями-интеграторами, при разработке собственных решений.
Решения, разработанные на базе данного сценария, могут применяться в действующих сетях/системах
только после тестовой и/или опытной эксплуатации.
Дополнительные файлы:
mibs.zip
snmp_extend_scripts.zip
zbx_sterra_gates_snmpv2_template.zip
power_test.tar.gz
В данном документе рассматриваются:
· настройка SNMP агентов для сбора статистики со шлюза безопасности «С-Терра Шлюз»;
· примеры расширенных скриптов, благодаря которым можно запрашивать по SNMP статистику, которая изначально отсутствует (например - срок действия локального сертификата шлюза);
· использование шаблона для системы мониторинга Zabbix (4.4.X, 5.0 LTS, 6.0 LTS);
· настройки Syslog;
· настройка отправки почты;
· прочее.
С устройства Server будет запрашиваться статистика шлюза GW1 по протоколу SNMP. Построение защищенного IPsec туннеля в данном документа рассматриваться не будет.
Канал между системой мониторинга Server и шлюзом GW1 должен быть доверенным. В данном документе мониторинг будет осуществляться через подсеть 192.168.1.0/24, которая является доверенной. Если требуется осуществлять мониторинг через Интернет, то трафик нужно защитить при помощи IPsec.
Схема стенда (Рисунок 1):
Рисунок 1
В состав Продукта «С-Терра Шлюз» входит два SNMP агента. Первый (VPNGATE) отвечает за предоставление информации о подсистемах IKE/IPsec, второй (SNMPD) - за выдачу общей информации о системе (счетчики сетевых интерфейсов, загрузка ЦПУ/ОЗУ и так далее) и о информации о третьих сервисах (Keepalived и так далее).
Два SNMP агента работают следующим образом. Агент SNMPD принимает все SNMP запросы на порту 161 и проксирует определенные объектные идентификаторы (OIDs, список можно посмотреть в /etc/snmp/snmpd.conf) агенту VPNGATE.
SNMP агент VPNGATE не поддерживает SNMPv3, но благодаря проксированию запросов от SNMPD к VPNGATE становится возможным получение статистики о подсистемах IKE/IPsec по SNMPv3.
Дополнительную информацию о настройке SNMP можно прочитать в документации на «С-Терра Шлюз 4.3» (https://doc.s-terra.ru/ -> С-Терра Шлюз -> С-Терра Шлюз 4.3 -> Мониторинг).
В данном документе для настройки SNMP агента VPNGATE будет использоваться cisco-like консоль.
Базовая настройка SNMP v2 состоит из двух этапов. Первый - правка конфигурационного файла /etc/snmp/snmpd.conf агента SNMPD. Второй - настройка SNMP агента VPNGATE через cisco-like консоль.
Для базовой настройки SNMPv2 следует выполнить следующие действия:
1. В конфигурационном файле /etc/snmp/snmpd.conf нужно добавить следующую строку:
agentaddress <адрес>:<порт>
agentaddress <IP адрес шлюза>:<порт> - локальный адрес шлюза и порт (161 по умолчанию), на которых SNMPD будет слушать запросы по SNMP.
При необходимости стоит также поменять community в строке:
rocommunity public default -V customview
Здесь приведена строка по умолчанию.
rocommunity - задает значение community-строки (в данном случае - “public”) с правами только на чтение, а следующее за ним ключевое слово default -V <имя> указывает какие OID будут выдаваться.
Для более подробной информации по составу файла /etc/snmp/snmpd.conf можно обратиться к пункту «Конфигурационный файл /etc/snmp/snmpd.conf» Приложения.
2. После внесения изменений в конфигурационный файл /etc/snmp/snmpd.conf перезапустите демон SNMPD и добавьте его в автозапуск:
root@GW1:~# systemctl restart snmpd.service
root@GW1:~# systemctl enable snmpd.service
3. В cisco-like консоли перейдите в режим конфигурирования и введите следующее:
GW1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
GW1(config)#snmp-server community public
GW1(config)#snmp-server polling address 127.0.0.1
GW1(config)#snmp-server polling udp-port 1161
GW1(config)#end
GW1#exit
Community строка в команде snmp-server community (в данном случае public) и UDP порт в snmp-server polling udp-port должны соответствовать строкам из настроек proxy в файле /etc/snmp/snmpd.conf (строки proxy -v 2c -c "public" …). Данную настройку менять не рекомендуется.
Для проверки можно воспользоваться предустановленными утилитами snmpget или snmpwalk.
На настроенном устройстве GW1 выполните команду:
root@GW1:~# snmpwalk -v 2c -c public <IP адрес шлюза>:161
где <IP адрес шлюза> - это адрес, на который должны поступать SNMP запросы
На экран будут выведены все SNMP значения, предоставляемые SNMPD.
Выполните команду:
root@GW1:~# snmpwalk -v 2c -c public <IP адрес шлюза>:161 .1.3.6.1.4.1.9
где <IP адрес шлюза> — это адрес, на который должны поступать SNMP запросы.
На экран будут выведены SNMP значения, предоставляемые встроенным агентом VPNGATE.
Также следует проверить работу утилиты snmptranslate. Если передать ей в качестве параметра объектный идентификатор в численном виде, то в стандартный вывод она должна вернуть его в текстовом. Выводы должны соответствовать представленным ниже.
root@GW1:~# snmptranslate .1.3.6.1.4.1.9
CISCO-SMI::cisco
root@GW1:~# snmptranslate .1.3.6.1.2.1.31.1.1.1.1
IF-MIB::ifName
root@GW1:~# snmptranslate .1.3.6.1.4.1.8072.1.3.2.3.1.2.29.103.101.116.95.100.97.121.115.95.117.110.116.105.108.95.108.111.99.97.108.95.99.101.114.116.95.101.120.112
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_days_until_local_cert_exp"
После локальной проверки следует таким же образом проверить работу snmpwalk с устройства Server, выполнив те же команды. В случае, если команда работает нормально на устройстве GW1, но не работает с устройства Server, можно прийти к выводу, что проблема кроется не в настройках SNMP, а в сетевых настройках.
В приложении так же можно найти примеры использования SNMP запросов для различных случаев.
1. В конфигурационном файле /etc/snmp/snmpd.conf нужно добавить следующую строку (если это уже не было сделано ранее):
agentaddress <адрес>:<порт>
agentaddress <IP адрес шлюза>:<порт> - локальный адрес шлюза и порт (161 по умолчанию), на которых SNMPD будет слушать запросы по SNMP.
2. Создайте учетную запись пользователя SNMPv3. Для этого добавьте в файл конфигурации /etc/snmp/snmpd.conf следующие строки:
rouser <username> <security level> -V customview
где:
<username> - имя учетной записи,
<security level> - способ аутентификации пользователя, должен быть одним из следующих:
· noauth - только по имени пользователя (без шифрования соединения)
· auth - по имени пользователя и паролю <authpass> (без шифрования соединения)
· priv - по имени пользователя и паролям <authpass> и <privpass> (с шифрованием соединения)
-V customview - указывает, что по умолчанию будут выдаваться OID, входящие в customview.
Данная строка используется, чтобы явно указать права создаваемого пользователя. Пользователь будет создан с правами только на чтение (для прав на чтение и запись используйте rwuser).
createUser <username> [(MD5|SHA) <authpass> [DES|AES [<privpass>]]]
где <username> - имя учетной записи; MD5|SHA - варианты аутентификации; <authpass> - пароль аутентификации (должен быть не короче 8 символов); DES|AES - протоколы шифрования (используется OpenSSL); <privpass> - пароль шифрования (если не указан, используется тот же пароль, что указан в <authpass>).
Пример 1:
rouser user auth -V customview
createUser user MD5 password
Пример 2:
rouser test_user priv -V customview
createUser test_user SHA supersecret123 AES superpassword456
После завершения всех настроек и проверки работоспособности, строку createUser можно удалить из конфигурационного файла, чтобы пароли доступа не оставались лежать в открытом виде.
3. (Опционально) Чтобы отключить SNMP v2 закомментируйте следующую строку:
rocommunity public default -V customview
4. После внесения изменений в конфигурационный файл /etc/snmp/snmpd.conf перезапустите демон SNMPD и добавьте его в автозапуск:
root@GW1:~# systemctl restart snmpd.service
root@GW1:~# systemctl enable snmpd.service
5. Настройте встроенного SNMP агента VPNGATE (если это уже не было сделано ранее). Для этого в cisco-like консоли перейдите в режим конфигурирования и введите следующее:
GW1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
GW1(config)#snmp-server community public
GW1(config)#snmp-server polling address 127.0.0.1
GW1(config)#snmp-server polling udp-port 1161
GW1(config)#end
GW1#exit
Community строка в команде snmp-server community (в данном случае public) и UDP порт в snmp-server polling udp-port должны соответствовать строкам из настроек proxy в файле /etc/snmp/snmpd.conf (строки proxy -v 2c -c "public" …). Данную настройку менять не рекомендуется.
Для проверки можно воспользоваться предустановленными утилитами snmpget или snmpwalk.
Если используется метод аутентификации auth, выполните на настроенном устройстве GW1 команду (на основе Примера 1 выше):
root@GW1:~# snmpwalk -v 3 -u user -l authNoPriv -a MD5 -A password <IP адрес шлюза>:161
где <IP адрес шлюза> - это адрес, на который должны поступать SNMP запросы
Если используется метод аутентификации priv, выполните команду (на основе Примера 2 выше):
root@GW1:~# snmpwalk -v 3 -u test_user -l authPriv -a SHA -A supersecret123 -x AES -X superpassword456 <IP адрес шлюза>:161
где <IP адрес шлюза> - это адрес, на который должны поступать SNMP запросы.
Описанный в этом разделе способ управления настройками SNMP v3 является опциональным. Утилиты snmpusm и snmpvacm позволяют удаленно и без внесения изменений в конфигурационный файл snmpd.conf управлять пользователями, группами и view, в том числе создавать, удалять, активировать/деактивировать пользователей, определять доступные для выдачи OID и прочее. Все настройки, заданные таким образом, применяются сразу и не требуют перезапуска службы snmpd. Все действия выполняются из-под предварительно созданного пользователя SNMP v3.
Создайте пользователя, из-под которого будут выполняться все дальнейшие настройки. Для этого добавьте в конфигурационный файл /etc/snmp/snmpd.conf следующие строки (в данном примере будет создан пользователь с именем snmp_admin с правами на чтение и запись, методом аутентификации priv и двумя паролями):
rwuser snmp_admin priv
createUser snmp_admin SHA adminpass123 AES adminsecret123
Затем перезапустите сервис snmpd:
root@GW1:~# systemctl restart snmpd.service
С использованием утилиты snmpusm, подключившись по SNMP v3 под пользователем snmp_admin, создайте нового пользователя (в данном примере будет создан пользовать с именем user1):
root@GW1:~# snmpusm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> create user1 snmp_admin
User successfully created.
Обратите внимание, что создание нового пользователя осуществляется посредством клонирования уже существующего пользователя. Новый пользователь унаследует метод аутентификации и пароли того пользователя, от которого он был клонирован.
В общем виде команда создания нового пользователя выглядит следующим образом:
snmpusm <опции подключения> <адрес шлюза> create <имя нового пользователя> <имя существующего пользователя>
Для созданного пользователя user1 задайте новые пароли:
root@GW1:~# snmpusm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> passwd -Ca adminpass123 userpass123 user1
SNMPv3 Key(s) successfully changed.
root@GW1:~# snmpusm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> passwd -Cx adminsecret123 usersecret123 user1
SNMPv3 Key(s) successfully changed.
В общем виде команда обновления паролей пользователя выглядит следующим образом:
snmpusm <опции подключения> <адрес шлюза> passwd (-Cx|-Ca) <старый пароль> <новый пароль> <имя пользователя>
Под пользователем user1 на данный момент нельзя подключиться по SNMP v3, до тех пор, пока для него не будет задана группа, и не будут определены права доступа к тем или иным OID.
Для удаления пользователя user1 используйте следующую команду:
root@GW1:~# snmpusm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> delete user1
User successfully deleted.
Посмотреть существующих пользователей можно следующей командой:
root@GW1:~# snmpwalk -v 3 -u snmp_admin -l authpriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> usmUserSecurityName
SNMP-USER-BASED-SM-MIB::usmUserSecurityName.".....]..21W.d...."."user1" = STRING: user1
SNMP-USER-BASED-SM-MIB::usmUserSecurityName.".....]..21W.d...."."snmp_admin" = STRING: snmp_admin
Подробное описание параметров утилиты snmpusm содержится в выводе команд man snmpusm иsnmpusm --help.
View используется для указания перечня выдаваемых OID. Для примера, создадим view с именем disk_monitoring, в который будут входить всего две ветви OID (dskPath и dskUsed, содержащие информацию о файловой системе диска и занятом объеме):
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> createView disk_monitoring dskPath
View successfully created.
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> createView disk_monitoring dskUsed
View successfully created.
Этот view будет использован далее в настройках. В общем виде команда добавления OID в view выглядит следующим образом:
snmpvacm <опции подключения> <адрес шлюза> createView <имя view> <OID>
Удаление view disk_monitoring выполняется аналогично:
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> deleteView disk_monitoring dskPath
View successfully deleted.
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> deleteView disk_monitoring dskUsed
View successfully deleted.
Подробное описание параметров утилиты snmpvacm содержится в выводе команд man snmpvacm и snmpvacm --help.
Группы используются для того, чтобы задавать права доступа пользователей SNMP к конкретным view. Для примера, создадим группу с именем DiskWatchers и поместим туда созданного ранее пользователя user1:
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> createSec2Group 3 user1 DiskWatchers
Sec2group successfully created.
В общем виде команда добавления пользователя в группу выглядит следующим образом:
snmpvacm <опции подключения> <адрес шлюза> createSec2Group <модель безопасности> <имя пользователя> <имя группы>
<модель безопасности> в примере выше принимает значение 3, что соответствует User-based Security Model (USM).
Для группы DiskWatchers выдадим права на просмотр view disk_monitoring, созданного ранее:
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> createAuth DiskWatchers 3 3 read 1 disk_monitoring
AuthAccess successfully created.
В общем виде команда назначения прав для группы выглядит следующим образом:
snmpvacm <опции подключения> <адрес шлюза> createAuth <имя группы> <модель безопасности> <минимальный уровень аутентификации> <права доступа> <тип совпадения контекста> <имя view>
<модель безопасности> в примере выше принимает значение 3, что соответствует User-based Security Model (USM).
<минимальный уровень аутентификации> в примере выше принимает значение 3, что соответствует уровню authPriv.
<права доступа> в примере выше выставлены в read, то есть разрешено только чтение.
<тип совпадения контекста> в примере выше принимает значение 1, что соответствует точному совпадению контекста.
Обратите внимание, что пользователь может входить только в одну группу. Группа, в свою очередь, может включать в себя несколько пользователей. Группе можно назначить права только на один конкретный view.
Для удаления группы DiskWatchers используйте следующую команду:
root@GW1:~# snmpvacm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> deleteSec2Group 3 DiskWatchers
Sec2group successfully deleted.
Посмотреть существующие группы можно следующей командой:
root@GW1:~# snmpwalk -v 3 -u snmp_admin -l authpriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> vacmGroupName
SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.1."comm1" = STRING: grpcomm1
SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.2."comm1" = STRING: grpcomm1
SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.3."user1" = STRING: DiskWatchers
SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.3."snmp_admin" = STRING: grpsnmp_admin
Подробное описание параметров утилиты snmpvacm содержится в выводе команд man snmpvacm иsnmpvacm --help.
Для проверки заданных параметров, с помощью утилиты snmpwalk, запросите все доступные OID, подключившись под пользователем user1:
root@GW1:~# snmpwalk -v 3 -u user1 -l authPriv -a SHA -A userpass123 -x AES -X usersecret123 <адрес шлюза> .1
UCD-SNMP-MIB::dskPath.1 = STRING: /run
UCD-SNMP-MIB::dskPath.2 = STRING: /
UCD-SNMP-MIB::dskPath.3 = STRING: /dev/shm
UCD-SNMP-MIB::dskPath.4 = STRING: /run/lock
UCD-SNMP-MIB::dskPath.5 = STRING: /sys/fs/cgroup
UCD-SNMP-MIB::dskPath.6 = STRING: /var/log
UCD-SNMP-MIB::dskPath.7 = STRING: /tmp
UCD-SNMP-MIB::dskPath.8 = STRING: /boot/efi
UCD-SNMP-MIB::dskUsed.1 = INTEGER: 10000
UCD-SNMP-MIB::dskUsed.2 = INTEGER: 894952
UCD-SNMP-MIB::dskUsed.3 = INTEGER: 0
UCD-SNMP-MIB::dskUsed.4 = INTEGER: 0
UCD-SNMP-MIB::dskUsed.5 = INTEGER: 0
UCD-SNMP-MIB::dskUsed.6 = INTEGER: 532
UCD-SNMP-MIB::dskUsed.7 = INTEGER: 0
UCD-SNMP-MIB::dskUsed.8 = INTEGER: 3975
UCD-SNMP-MIB::dskUsed.8 = No more variables left in this MIB View (It is past the end of the MIB tree)
Видно, что вывод включает в себя только те OID, которые входят в view disk_monitoring.
Существующих пользователей можно деактивировать, чтобы отключить им доступ, при этом не удаляя самих пользователей. Для примера, деактивируем пользователя user1:
root@GW1:~# snmpusm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> deactivate user1
User successfully deactivated.
Теперь при попытке подключения под этим пользователем будет отображаться соответствующее сообщение:
root@GW1:~# snmpwalk -v 3 -u user1 -l authPriv -a SHA -A userpass123 -x AES -X usersecret123 <адрес шлюза> .1
snmpwalk: Unknown user name
Для активации пользователя user1 выполните команду:
root@GW1:~# snmpusm -v 3 -u snmp_admin -l authPriv -a SHA -A adminpass123 -x AES -X adminsecret123 <адрес шлюза> activate user1
User successfully activated.
Для настройки Syslog необходимо создать пользовательский файл в директории /etc/rsyslog.d/. Файл должен иметь такое название, чтобы он выполнялся раньше файла 05-sterragate.conf. Для этого его можно назвать любым именем, начинающимся на число менее «05» и заканчивающимся на «.conf» (0[0-4]-[[:word:]]*.conf).
В файле (назовем его для примера 04-custom.conf) можно настроить отправку логов на несколько серверов по заданным IP адресам и номерам портов, добавив для этого в файл конфигурационные строки.
Настройки для отправки логов имеют следующий вид:
*.* <@|@@|:omrelp:><IP адрес>:<порт>
· *.* - в первом поле указывается канал протоколирования событий (factility), на который отправляются записи, во втором - уровень детализации;
· <@|@@|:omrelp:> - здесь указывается по какому протоколу будет осуществляться передача логов. @ - передача осуществляется по UDP (на данный момент рекомендуется), @@ - передача осуществляется по TCP, :omrelp: - передача осуществляется по протоколу RELP;
· <IP адрес>:<порт> - логи должны передаваться на указанные здесь порт и IP адрес.
В качестве примера ниже разобраны несколько строк:
Пример:
*.* @192.168.0.10:516
Строка указывает на то, что все логи всех уровней важности нужно отправлять на адрес, заданный после символа ‘@’ (для передачи используется протокол UDP).
При таких настройках rsyslog на принимающей стороне следует позаботиться о ротации логов (к примеру, воспользоваться logrotate).
Для того, чтобы добавить имя хоста в syslog сообщения, задайте соответствующее имя в файле /etc/hosts в следующей строке:
127.0.0.1 <имя хоста> localhost
Так же следует обратить внимание на то, что некоторые syslog сообщения берут имя хоста из файла /etc/hostname.
После проведения настройки перезапустите сервис:
root@GW1:~# systemctl restart rsyslog.service
Также опционально в файл /etc/snmp/snmpd.conf могут быть добавлены следующие настройки:
sysdescr <строка с описанием платформы>
Рекомендуемые значения:
RVPN
CSP VPN Gate 100
CSP VPN Gate 1000
CSP VPN Gate 3000
CSP VPN Gate 7000
CSP VPN Gate 10000
При необходимости можно использовать значения, специфичные для пользователя.
Для корректной работы данной настройки следует закомментировать в /etc/snmp/snmpd.conf строку proxy-v2c-c"public" 127.0.0.1:1161 .1.3.6.1.2.1.1.1.0
sysContact <строка с контактными данными администратора платформы>
sysLocation <строка с описанием местоположения платформы>
Например:
sysContact A.I.Ivanov, admin@example.com
sysLocation Moscow, DC-2, unit 123
sysobjectid <объектный идентификатор платформы>
Рекомендуемые значения:
Тип платформы |
Объектный идентификатор |
RVPN |
.1.3.6.1.4.1.31342.1.1.1 |
CSP VPN Gate 100 |
.1.3.6.1.4.1.31342.1.1.2 |
CSP VPN Gate 1000 |
.1.3.6.1.4.1.31342.1.1.3 |
CSP VPN Gate 3000 |
.1.3.6.1.4.1.31342.1.1.4 |
CSP VPN Gate 7000 |
.1.3.6.1.4.1.31342.1.1.5 |
CSP VPN Gate 10000 |
.1.3.6.1.4.1.31342.1.1.6 |
Также могут использоваться значения, специфичные для пользователя. Для них рекомендуется использовать префикс 1.3.6.1.4.1.31342.1.1.1000. Например:
sysobjectid .1.3.6.1.4.1.31342.1.1.1000.17
1. Добавьте в файл конфигурации /etc/snmp/snmpd.conf строки, отвечающие за настройку сокетов AgentX:
agentXSocket /var/agentx/master,tcp:localhost:705
2. Добавьте в файл конфигурации /etc/snmp/snmpd.conf строку с добавлением нужных OID и комментарий:
# BGP4 MIB
view customview included .1.3.6.1.2.1.15
3. Добавьте в файл конфигурации /etc/snmp/snmpd.conf строки, исключающие потенциально опасные с точки зрения производительности OID (https://docs.frrouting.org/en/latest/snmp.html#net-snmp-configuration) и комментарии к ним:
# Remove ipRouteTable from view
view all excluded .1.3.6.1.2.1.4.21
# Remove ipNetToMediaTable from view
view all excluded .1.3.6.1.2.1.4.22
# Remove ipNetToPhysicalPhysAddress from view
view all excluded .1.3.6.1.2.1.4.35
# Remove ipCidrRouteTable from view
view all excluded .1.3.6.1.2.1.4.24
# Optionally protect SNMP private/secret values
view all excluded .1.3.6.1.6.3.15
view all excluded .1.3.6.1.6.3.16
view all excluded .1.3.6.1.6.3.18
4. Создайте файл /etc/snmp/zebra.conf и добавьте туда следующую строку:
master agentx
5. В файле /etc/frr/daemons замените значения zebra_options, bgpd_options, ospfd_options и ripd_options на следующие (нужно добавить опцию ‘-M snmp’):
zebra_options=" -A 127.0.0.1 -M snmp -s 90000000"
bgpd_options=" -A 127.0.0.1 -M snmp"
ospfd_options=" -A 127.0.0.1 -M snmp"
ripd_options=" -A 127.0.0.1 -M snmp"
6. Перезапустите сервис frr:
root@GW1:~# systemctl restart frr.service
7. Добавьте AgentX в конфигурацию vtysh:
root@GW1:~# vtysh
Hello, this is FRRouting (version 7.3).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
GW1# configure terminal
GW1(config)# agentx
GW1(config)# exit
GW1# write
GW1# exit
8. Перезапустите сервис snmpd:
root@GW1:~# systemctl restart snmpd.service
Посмотреть статусы всех пиров можно следующей командой:
root@GW1:~# snmpwalk -v 2c -c public 127.0.0.1:161 BGP4-MIB::bgpPeerState
BGP4-MIB::bgpPeerState.10.10.20.2 = INTEGER: established(6)
BGP4-MIB::bgpPeerState.10.10.20.3 = INTEGER: established(6)
BGP4-MIB::bgpPeerState.192.168.255.1 = INTEGER: established(6)
Для того чтобы выяснить статус конкретного пира можно воспользоваться утилитой snmpget, в качестве OID подав BGP4-MIB::bgpPeerState.<IP_адрес_пира>:
root@GW1:~# snmpget -v 2c -c public 127.0.0.1:161 BGP4-MIB::bgpPeerState.10.10.20.2
BGP4-MIB::bgpPeerState.10.10.20.2 = INTEGER: established(6)
Для приема и разбора SNMP трапов на сервере мониторинга должны быть произведены соответствующие настройки, которые в данной инструкции рассматриваться не будут. Шаблон Zabbix, о котором идет речь в приложении, содержит настройку, позволяющую отслеживать все трапы, получаемые системой, но для того, чтобы ей воспользоваться требуется настройка соответствующих сервисов (пример: snmptrapd и snmptt). Со списком SNMP трапов, отправляющихся с устройства С-Терра Шлюз по умолчанию, можно ознакомиться на портале документации https://doc.s-terra.ru.
Для включения автоматической отправки SNMP трапов, доступных встроенному VPNGATE агенту, выполните следующие настройки в cisco-like консоли:
Встроенный VPNGATE агент может отправлять только трапы версий SNMPv1 и SNMPv2
1. Войдите в режим конфигурации:
GW1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
2. Задайте адрес хоста, на который будут отправляться трапы (в данном примере - 192.168.1.5), версию SNMP трапов (в данном примере - SNMPv2), community строку (в данном примере - public) и порт (в данном примере - 162):
GW1(config)#snmp-server host 192.168.1.5 traps version 2c public udp-port 162
3. Опционально: укажите интерфейс, с которого будут отправляться SNMP трапы:
GW1(config)#snmp-server trap-source gigabitEthernet0/1
4. Включите отправку SNMP трапов:
GW1(config)#snmp-server enable traps
В «С-Терра Шлюз» версии 4.3 отправка SNMP трапов с помощью snmpd не поддерживается.
Утилиты snmptrap и snmpinform на шлюзе отвечают за отправку SNMP трапов. Шаблон команды для отправки трап сообщения из linux консоли может быть следующим:
snmptrap -v <версия SNMP> -c <community-строка> <IP адрес сервера>:<порт> <uptime> <OID> <object/OID> <тип переменной> <значение>
Значение параметра uptime задавать необязательно и можно заменить пустыми кавычками - “” или ‘’. Примеры отправки тестового SNMPv2-трапа с использованием кастомного OID:
root@GW1:~# snmptrap -v 2c -c public 192.168.1.5:162 '' .1.3.6.1.4.1.31342.1.2 .1.3.6.1.4.1.31342.1.2 s "Test message"
root@GW1:~# snmpinform -v 2c -c public 192.168.1.5:162 '' .1.3.6.1.4.1.31342.1.2 .1.3.6.1.4.1.31342.1.2 i 1234
Отправка SNMPv3 трапов требует указания дополнительных параметров аутентификации. Пример отправки SNMPv3 трапа:
root@GW1:~# snmpinform -v 3 -l authpriv -u User -a MD5 -x DES -A "UserPassword" -X "UserSecret" 192.168.1.5:162 '' .1.3.6.1.4.1.31342.1.2 .1.3.6.1.4.1.31342.1.2 s "Test message v3"
Сервис SNMPD позволяет расширить использование SNMP для тех случаев, когда какие-то значения нельзя напрямую получить по SNMP от какой-то подсистемы. Расширенное использование SNMP заключается в применении NET-SNMP-EXTEND-MIB для запуска произвольных программ или скриптов (директива extend в /etc/snmp/snmpd.conf).
Программы и скрипты запускаются демоном SNMPD от пользователя Debian-snmp.
На данный момент, посредством NET-SNMP-EXTEND-MIB, осуществляется сбор информации о количестве дней до истечения локального сертификата и сбор параметров rtt, jitter, loss при мониторинге состояния канала. Примеры описаны ниже. При необходимости добавления произвольного функционала просьба руководствоваться данными примерами.
Метод, описанный в данном разделе, позволяет отслеживать сроки истечения всех локальных сертификатов, если их несколько. Этот метод является рекомендуемым и лучше всего подходит для использования с Zabbix шаблоном.
Подготовка
1. Создайте директорию /opt/snmp_monitoring/snmp_extend/certs_expiry/ и перенесите в нее все файлы из папки certs_expiry архива snmp_extend_scripts.zip, который можно загрузить на портале документации https://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл snmp_extend_scripts.zip.
2. Установите нужные права на директорию certs_expiry:
root@GW1:~# chmod a+rx /opt/snmp_monitoring/snmp_extend/certs_expiry/
3. Установите права на запуск скрипта certs_expiry.py:
root@GW1:~# chmod +x /opt/snmp_monitoring/snmp_extend/certs_expiry/certs_expiry.py
Настройка расширенного объектного идентификатора в SNMPD
1. В файл конфигурации /etc/snmp/snmpd.conf добавьте следующие строки для получения объектных идентификаторов:
extend local_certs_index /opt/snmp_monitoring/snmp_extend/certs_expiry/certs_expiry.py print --option indexes
extend local_certs_days_til_exp /opt/snmp_monitoring/snmp_extend/certs_expiry/certs_expiry.py print --option days
В соответствии с этими строками конфигурационного файла в системе станут доступны объектные идентификаторы:
NET-SNMP-EXTEND-MIB::nsExtendOutLine."local_certs_index"
NET-SNMP-EXTEND-MIB::nsExtendOutLine."local_certs_days_til_exp"
2. Опционально: закомментируйте строку, описанную во втором методе получения срока действия локального сертификата, если не планируете пользоваться тем методом:
#extend get_days_until_local_cert_exp /bin/bash /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.extend.bash
Настройка cron
Создайте файл /etc/cron.d/certs_expiry и поместите в него следующую строку:
0 3 * * * root /opt/snmp_monitoring/snmp_extend/certs_expiry/certs_expiry.py write
Данная запись говорит cron о том, что скрипт
/opt/snmp_monitoring/snmp_extend/certs_expiry/certs_expiry.py
write
должен запускаться один раз в сутки (в 03:00 часов) с правами root. После
помещения записи в файл сервис cron перезапускать не обязательно, запись
должна подхватиться автоматически в течение
минуты.
Крайне не рекомендуется задавать вызов данного скрипта чаще чем один раз в сутки, так как, при наличии большого количества сертификатов в базе шлюза, вызов утилиты cert_mgr может быть очень ресурсоемкой и длительной операцией.
После настройки cron следует выполнить один раз скрипт вручную, чтобы сразу получить результаты:
root@GW1:~# /opt/snmp_monitoring/snmp_extend/certs_expiry/certs_expiry.py write
Описание работы скрипта
Описание логики работы скрипта представлено в файле:
/opt/snmp_monitoring/snmp_extend/certs_expiry/README.txt
Подробности по использованию Zabbix шаблона описаны в разделе «Использование SNMP шаблона на Zabbix сервере».
Описанный в этом разделе метод мониторинга локального сертификата считается устаревшим и не рекомендуется к использованию. Данный метод позволяет отслеживать срок истечения только одного локального сертификата (с наибольшим id). Все необходимые скрипты для получения количества дней до истечения локального сертификата уже присутствуют на криптошлюзе.
Общая логика работы следующая:
· Для скриптов существует структура директорий (/opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/);
· В директории присутствует скрипт get_days_until_local_cert_exp.cron.bash, выполняющийся раз в день при помощи cron. Он получает количество дней до истечения срока действия локального сертификата и записывает число во временный файл get_days_until_local_cert_exp.cron.result;
Этот скрипт выполняется отдельно по той причине, что для получения даты истечения сертификата требуется утилита cert_mgr, запуск которой возможен только с правами пользователя root. При работе же с расширенными идентификаторами демон SNMPD запускает скрипты от пользователя Debian-snmp.
· Также в директории присутствует второй скрипт get_days_until_local_cert_exp.extend.bash, который считывает из временного файла get_days_until_local_cert_exp.cron.result созданного первым скриптом get_days_until_local_cert_exp.cron.bash информацию и на ее основе посылает на стандартный вывод число дней до истечения сертификата и/или возвращает код ошибки;
· Для get_days_until_local_cert_exp.extend.bash скрипта создан расширенный объектный идентификатор. Он описан в файле конфигураций /etc/snmp/snmpd.conf;
· Полученный объектный идентификатор используется системой мониторинга.
Настройка cron
Скрипт get_days_until_local_cert_exp.cron.bash следует запускать раз в день при помощи cron. Для этого нужно создать файл /etc/cron.d/local_cert_exp и поместить в него следующую строку:
0 7 * * * root /bin/bash /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.cron.bash
Данная
запись
говорит
cron о
том,
что
скрипт
/opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.cron.bash
должен
раз
в
день
в
7
часов
утра
запускаться
с
правами
root.
После
помещения записи в файл сервис cron перезапускать
не обязательно, запись должна подхватиться автоматически в течение
минуты.
После настройки cron следует выполнить один раз скрипт вручную, чтобы сразу получить искомое количество дней:
root@GW1:~# /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.cron.bash
Настройка расширенного объектного идентификатора в SNMPD
В данном разделе приводится пример того, как расширенный объектный идентификатор задается в /etc/snmp/snmpd.conf, а также то, как осуществляется проверка правильности настройки.
Все требуемые ниже настройки уже выполнены на криптошлюзе.
Для получения объектного идентификатора в файл конфигураций /etc/snmp/snmpd.conf добавлена следующая строка:
extend get_days_until_local_cert_exp /bin/bash /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.extend.bash
На данный момент эта строка присутствует в файле по умолчанию (см. Приложение «Конфигурационный файл /etc/snmp/snmpd.conf»).
В соответствии с этой строкой конфигурационного файла в системе доступен объектный идентификатор под названием NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_days_until_local_cert_exp".
Проверить его наличие можно при помощи следующей команды:
root@GW1:~# snmpwalk -v 2c -c public <адрес> NET-SNMP-EXTEND-MIB::nsExtendObjects
Вместо <адрес> здесь следует указать тот адрес, что указывался в файле /etc/snmp/snmpd.conf при помощи agentaddress (вместо public при необходимости следует подставить свою community строку).
В выводе команды snmpwalk, представленной выше можно увидеть примерно следующее:
NET-SNMP-EXTEND-MIB::nsExtendNumEntries.0 = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendCommand."get_days_until_local_cert_exp" = STRING: /bin/bash
NET-SNMP-EXTEND-MIB::nsExtendArgs."get_days_until_local_cert_exp" = STRING: /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.extend.bash
NET-SNMP-EXTEND-MIB::nsExtendInput."get_days_until_local_cert_exp" = STRING:
NET-SNMP-EXTEND-MIB::nsExtendCacheTime."get_days_until_local_cert_exp" = INTEGER: 5
NET-SNMP-EXTEND-MIB::nsExtendExecType."get_days_until_local_cert_exp" = INTEGER: exec(1)
NET-SNMP-EXTEND-MIB::nsExtendRunType."get_days_until_local_cert_exp" = INTEGER: run-on-read(1)
NET-SNMP-EXTEND-MIB::nsExtendStorage."get_days_until_local_cert_exp" = INTEGER: permanent(4)
NET-SNMP-EXTEND-MIB::nsExtendStatus."get_days_until_local_cert_exp" = INTEGER: active(1)
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."get_days_until_local_cert_exp" = STRING: 364
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_days_until_local_cert_exp" = STRING: 364
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."get_days_until_local_cert_exp" = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendResult."get_days_until_local_cert_exp" = INTEGER: 0
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_days_until_local_cert_exp".1 = STRING: 364
В данном случае нас интересуют объектные идентификаторы NET-SNMP-EXTEND-MIB::nsExtendResult."get_days_until_local_cert_exp" и NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_days_until_local_cert_exp". Первый дает код возврата, а второй - количество дней, которое было передано в стандартный вывод.
Описание работы скриптов
Подробное описание логики работы скриптов для получения количества дней до истечения локального сертификата представлено в файле на криптошлюзе:
/opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/README.txt
Осуществлять мониторинг состояния канала можно только до одного хоста.
Для того, чтобы воспользоваться мониторингом состояния канала, необходимо выполнить следующие шаги.
Подготовка
1. Создайте в директории /opt/snmp_monitoring/snmp_extend директорию с именем get_rtt_jitter_loss и перенесите в неё все файлы из папки get_rtt_jitter_loss архива snmp_extend_scripts.zip, который можно загрузить на портале документации https://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл snmp_extend_scripts.zip.
2. Установите нужные права на директорию get_rtt_jitter_loss:
root@GW1:~# chmod a+rx /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/
3. Установите права на запуск перенесённых скриптов:
root@GW1:~# chmod u+x /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.cron.bash
root@GW1:~# chmod u+x /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash
Настройка расширенного объектного идентификатора в SNMPD
1. В файл конфигурации /etc/snmp/snmpd.conf добавьте следующие строки для получения объектных идентификаторов:
...
extend get_rtt /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash rtt
extend get_jitter /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash jitter
extend get_loss /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash loss
...
В соответствии с этими строками конфигурационного файла в системе станут доступны объектные идентификаторы:
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_rtt"
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_jitter"
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_loss"
2. Перезапустите сервис snmpd:
root@GW1:~# systemctl restart snmpd.service
Задание адреса устройства для мониторинга
Измените содержимое скрипта /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.cron.bash, указав адрес устройства, для мониторинга. Изменения необходимо внести в переменную “HOST_TO_MONITORING”:
#!/bin/bash
...
HOST_TO_MONITORING="8.8.8.8"
...
Настройка cron
Создайте файл /etc/cron.d/sla_monitoring и поместите в него следующую строку:
* * * * * root /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.cron.bash
Данная
запись
говорит
cron о
том,
что
скрипт
/opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.cron.bash
должен
запускаться
один
раз
в
минуту
с
правами
root.
После
помещения записи в файл сервис cron перезапускать
не обязательно, запись должна подхватиться автоматически в течение
минуты.
Проверка
1. Проверить правильность работы получения данных о состоянии канала (например, rtt) можно при помощи команды:
root@GW1:~# snmpget -v 2c -c public <адрес> NET-SNMP-EXTEND-MIB::nsExtendOutputFull.\"get_rtt\"
В поле <адрес> следует указать тот адрес, что указывался в файле /etc/snmp/snmpd.conf при помощи agentaddress (вместо public при необходимости следует подставить свою community строку). Вывод должен выглядеть подобным образом:
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_rtt" = STRING: 18.120
2. Проверить наличие всех доступных расширенных объектных идентификаторов можно при помощи следующей команды:
root@GW1:~# snmpwalk -v 2c -c public <адрес> NET-SNMP-EXTEND-MIB::nsExtendObjects
Описание работы скриптов
Подробное описание логики работы скриптов для мониторинга состояния канала представлено в файле на криптошлюзе:
/opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/README.txt
Для мониторинга статистики системы шифрования по количеству входящих, исходящих, потерянных IPsec пакетов, потерям низкоприоритетных и высокоприоритетных пакетов и процентам потерь были созданы специальные скрипты.
Для начала работы со скриптами выполните следующие действия.
Подготовка
1. Создайте на криптошлюзе следующую директорию: /opt/snmp_monitoring/snmp_extend/check_kstat_show/. Перенесите в неё все файлы из папки check_kstat_show архива snmp_extend_scripts.zip, который можно загрузить на портале документации https://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл snmp_extend_scripts.zip.
2. Установите нужные права на директорию check_kstat_show:
root@GW1:~# chmod a+rx /opt/snmp_monitoring/snmp_extend/check_kstat_show/
3. Установите права на запуск перенесённых скриптов:
root@GW1:~# chmod u+x /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.cron.py
root@GW1:~# chmod u+x /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh
Настройка расширенного объектного идентификатора в SNMPD
1. В файл конфигурации /etc/snmp/snmpd.conf добавьте следующие строки для получения объектных идентификаторов:
...
extend ipsec_dropped_percentage /bin/bash /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh ipsec_dropped_percentage
extend high_prio_dropped_pkts /bin/bash /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh high_prio_dropped_pkts
extend low_prio_dropped_pkts /bin/bash /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh low_prio_dropped_pkts
...
В соответствии с этими строками конфигурационного файла в системе станут доступны объектные идентификаторы:
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."ipsec_dropped_percentage"
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."high_prio_dropped_pkts"
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."low_prio_dropped_pkts"
2. Перезапустите сервис snmpd:
root@GW1:~# systemctl restart snmpd.service
Настройка cron
Создайте файл /etc/cron.d/check_kstat_show и поместите в него следующую строку:
* * * * * root /usr/bin/python /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.cron.py
Данная
запись
говорит
cron о
том,
что
скрипт
/opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.cron.py
должен
запускаться
один
раз
в
минуту
с
правами
root.
После
помещения записи в файл сервис cron перезапускать
не обязательно, запись должна подхватиться автоматически в течение
минуты.
Проверка
1. Проверить правильность работы получения данных от системы шифрования (например, ipsec_dropped_percentage) можно при помощи команды:
root@GW1:~# snmpget -v 2c -c public <адрес> NET-SNMP-EXTEND-MIB::nsExtendOutputFull.\"ipsec_dropped_percentage\"
В поле <адрес> следует указать тот адрес, что указывался в файле /etc/snmp/snmpd.conf при помощи agentaddress (вместо public при необходимости следует подставить свою community строку). Вывод должен выглядеть подобным образом:
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."ipsec_dropped_percentage" = STRING: 0.0
2. Проверить наличие всех доступных расширенных объектных идентификаторов можно при помощи следующей команды:
root@GW1:~# snmpwalk -v 2c -c public <адрес> NET-SNMP-EXTEND-MIB::nsExtendObjects
Описание работы скриптов
Подробное описание логики работы скриптов для получения статистики от системы шифрования представлено в файле на криптошлюзе:
/opt/snmp_monitoring/snmp_extend/check_kstat_show/README.txt
Для Продукта «С-Терра Шлюз» был создан шаблон для системы мониторинга Zabbix. Загрузить его можно на портале документации https://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл zbx_sterra_gates_snmpv2_template.zip. Шаблон протестирован на версиях Zabbix Appliance 4.4.X, 5.0 LTS, 5.2, 6.0 LTS.
Данный шаблон позволяет получать следующую информацию:
· Информация об IKE/IPsec SA;
· Информация о количестве свободного места на различных разделах;
· Информация о количестве дней до истечения срока действия локальных сертификатов;
· Информация о состоянии канала (jitter, rtt, loss);
· Информация о сетевых интерфейсах;
· Информация о загрузке ЦПУ, ОЗУ;
· Информация о температуре ЦПУ;
· Информация о состоянии ноды VRRP кластера;
· Информация о состоянии пиров BGP.
1. Для импорта шаблона требуется в веб интерфейсе выбрать вкладку Configuration -> Templates -> Import и импортировать файл шаблона с параметрами по умолчанию.
2. Для корректной работы шаблона на Zabbix сервере должны присутствовать MIB файлы. Взять их можно со Шлюза 4.3 из директории /usr/share/snmp/mibs/ (включая все поддиректории), либо на портале документации https://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл mibs.zip. Файлы следует поместить на сервер Zabbix также в директорию /usr/share/snmp/mibs/ (актуально для Zabbix Appliance 4.4.X, 5.0 LTS и 5.2, для других версий директория может отличаться). После на сервере Zabbix следует включить использование MIB файлов, для этого в файл /etc/snmp/snmp.conf. (если файл и директория отсутствуют, то их требуется создать) параметру mibs нужно выставить значение +ALL. По умолчанию во многих системах MIB файлы из вложенных в /usr/share/snmp/mibs/ директорий включены не будут. Добавить их можно, модифицируя переменную mibdirs. Таким образом, нужно добавить в файл конфигураций /etc/snmp/snmp.conf следующие строки:
mibs +ALL
mibdirs +/usr/share/snmp/mibs/iana
mibdirs +/usr/share/snmp/mibs/ietf
3. Перезагрузите Zabbix сервер.
1. Первый способ мониторинга срока действия локальных сертификатов использует правило обнаружения (Discovery rule) Local Certificate Discovery, которое по SNMP запросу получает индексы локальных сертификатов со шлюза, а затем на основе полученных значений создает объекты (Items) вида Local Certificate Index <i> Days Until Expiry, где i - индекс (id) локального сертификата в базе шлюза. Эти объекты показывают оставшееся число дней до истечения локальных сертификатов с соответствующим id. По умолчанию, данное правило обнаружения выполняется каждый день в 00:00 часов. Для использования данного способа требуется выполнение действий, описанных в разделе «Получение информации о количестве дней до истечения локального сертификата». Информация на сервере Zabbix появится не сразу, а только после того, как успешно отработает скриптcerts_expiry.py на шлюзе по расписанию в cron и успешно выполнится правило обнаружения в Zabbix.
2. Если для мониторинга срока действия используется второй способ, то необходимо обратить внимание на то, что на Zabbix сервере количество дней до истечения срока действия локального сертификата может отобразиться не сразу. Следует перейти во вкладку Configurations -> Templates, выбрать шаблон Template S-Terra Gates SNMPv2, в подменю Items найти элемент данных Days until local certificate expires и выбрать нужный интервал получения срока действия сертификата (по умолчанию, информация снимается в 0.00 и в 12.00). Если для мониторинга срока действия используется первый способ, то можно отключить элементы данных Days until local certificate expires и Days until local certificate expires (script exit code).
3. Значения «SLA. Jitter», «SLA. Loss» и «SLA. RTT» будут доступны только после выполнения инструкций из раздела «Получение параметров при мониторинге состояния канала с помощью ICMP».
4. Значения «IPsec dropped packets percentage», «High priority packets dropped» и «Low priority packets dropped» будут доступны только после выполнения инструкций из раздела «Получение статистики от системы шифрования».
1. Необходимо выбрать вкладку Configuration -> Hosts -> Create host для того, чтобы создать узел сети.
2. После настройки параметров во вкладке Host, необходимо перейти во вкладку Templates и добавить в узел шаблон, который был загружен в разделе «Импорт шаблона» данной главы.
3. Затем, нужно перейти во вкладку Monitoring -> Latest data для того, чтобы проверить, начал ли осуществляться мониторинг. Если всё сделано верно, то в подменю Last value будут изменяться отслеживаемые параметры.
Для того, чтобы пользоваться шаблоном для SNMPv3, нужно изменить тип элементов данных шаблона с SNMPv2 agent на SNMPv3 agent. После чего нужно ввести параметры пользователя (нового или ранее созданного), которые были внесены в главе «Настройка SNMP v3» данной инструкции.
В шаблоне присутствуют правила автоматического обнаружения объектных идентификаторов. Каждое обнаружение выполняется с некоторым заданным периодом и по результатам выполнения создаются объекты (Items), по которым можно отслеживать состояние оборудования.
Делается это для того, чтобы отслеживать состояние объектов, названия которых заранее неизвестны. В качестве примера можно привести VRRP. Изначально неизвестно какой именно идентификатор виртуального маршрутизатора (VRID) будет задан пользователем, поэтому неизвестно за чем именно предстоит следить. После выполнения обнаружения (в данном шаблоне VRRP Instance Discovery) будут автоматически созданы объекты для отслеживания состояния каждого VRID.
В случае если объекты не создаются сразу после импорта шаблона, можно запустить обнаружение вручную (в веб интерфейсе Zabbix): Configuration -> Templates-> Template S-Terra Gates SNMPv2 -> Discovery rules, выбрать требуемое правило и нажать кнопку «Check now».
Для мониторинга параметров, помимо snmp, можно использовать zabbix агент.
Для того, чтобы использовать zabbix агент, необходимо выполнить следующие настройки на криптошлюзе:
1. В файле /etc/zabbix/zabbix_agentd.conf найти строку “Server=127.0.0.1” и задать адрес zabbix сервера, с которого будет осуществляться мониторинг криптошлюза:
### Option: Server
...
Server=192.168.1.5
...
2. В файле /etc/zabbix/zabbix_agentd.conf раскомментировать строку “#ListenPort=10050” для того, чтобы порт 10050 использовался для мониторинга криптошлюза:
### Option: ListenPort
...
ListenPort=10050
...
3. Запустить zabbix агент и добавить его в автозагрузку:
root@GW1:~# systemctl start zabbix-agent.service
root@GW1:~# systemctl enable zabbix-agent.service
После чего на zabbix сервере для криптошлюза нужно указать интерфейс мониторинга - “Agent”.
Шаблон, указанный в главе “Использование SNMP шаблона на Zabbix сервере”, может быть использован только для snmp агента. Ключи шаблонов для zabbix агента и для snmp агента отличаются. Для работы с zabbix агентом можно воспользоваться предустановленными на zabbix сервере шаблонами или же создать свой.
Для просмотра счетчиков IPsec драйвера можно воспользоваться утилитой kstat_show.
Если значение хоть одного из перечисленных счетчиков 'skb allocation errors', 'send queue overflows', 'high priority packets dropped', 'low priority packets dropped' в выводе утилиты kstat_show увеличивается, то это свидетельствует о перегруженности подсистемы шифрования С-Терра Шлюз.
Для определения количества пропускаемого трафика на интерфейсе С-Терра Шлюз воспользуйтесь утилитой vnstat (например vnstat-l-i eth0).
Для отправки электронных писем и уведомлений можно воспользоваться утилитой msmtp. Для отправки почтовых сообщений следует указать SMTP сервер, который их будет перенаправлять. Настройки для подключения к такому серверу следует указать в файле конфигураций $HOME/.msmtprc (где $HOME - домашняя директория пользователя которым будет отправляться почта). Если такой файл отсутствует, создайте его и введите требуемые настройки. Подробнее о настройках msmtp можно узнать здесь: https://marlam.de/msmtp/documentation/.
Создадим файл /root/.msmtprc и добавим в него нужные настройки.
Ниже указаны настройки для SMTP сервера yandex.ru:
Оптимальная работа при данных настройках не гарантируется. Отсылаемые письма могут быть заблокированы yandex.ru как спам. Для отправления писем рекомендуется использовать собственный SMTP сервер.
# Default values
defaults
auth on
port 587
tls on
tls_certcheck off
# Yandex account
account yandex
host smtp.yandex.ru
from <имя пользователя>@yandex.ru
user <имя_пользователя>@yandex.ru
password <пароль_пользователя>
# What account will be used if 'msmtp' is used without '-a' option
account default : yandex
где:
defaults - указывает на то, что дальше будут заданы значения по умолчанию;
· auth on - указывает на то, что метод аутентификации будет выбран автоматически;
· port 587 - говорит о том, что для соединения с SMTP сервером будет использован указанный порт (587);
· tls on - соединения будут защищаться при помощи TLS;
· tls_certcheck off - отключает проверку сертификата сервера;
account yandex - указывает на то, что дальше будут заданы значения для аккаунта с названием ‘yandex’ (можно указать любое название);
· host smtp.yandex.ru - указывает на то, что письма связанные с аккаунтом будут отсылаться на SMTP сервер с указанным названием (smtp.yandex.ru);
· from <имя_пользователя>@yandex.ru - устанавливает обратный адрес (на этот адрес будут отправляться уведомления в случае если письмо не удалось доставить);
· user <имя_пользователя>@yandex.ru - задает имя аутентифицируемого пользователя;
· password <пароль_пользователя> - здесь требуется указать пароль пользователя;
account default : yandex - указывает на то, что по умолчанию утилитой msmtp будут использоваться настройки, указанные в account Yandex.
После указания настроек можно отправлять письма. Для этого можно использовать файлы следующего содержания:
To: <адрес_получателя>
From: <имя пользователя>@yandex.ru
Subject: <тема_письма>
[текст_письма]
Дополнительный перенос строки после ‘Subject’ не является опечаткой. При отсутствии переноса текст письма будет утерян.
Отправить письмо можно следующей командой:
root@GW1:~# cat <имя_файла> | msmtp <адрес_получателя>
Получить информацию о температуре процессора можно с использованием пакета lm-sensors, либо из подкаталога /sys:
· lm-sensors
root@GW1:~#
sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +29.0 C (high = +98.0 C, crit = +98.0 C)
Core 1: +29.0 C (high = +98.0 C, crit = +98.0 C)
nct6776-isa-0a10
Adapter: ISA adapter
Vcore: +0.83 V (min = +0.00 V, max = +1.74 V)
in1: +1.50 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: +3.33 V (min = +2.98 V, max = +3.63 V)
+3.3V: +3.31 V (min = +2.98 V, max = +3.63 V)
in4: +1.00 V (min = +0.00 V, max = +0.00 V) ALARM
in5: +1.02 V (min = +0.00 V, max = +0.00 V) ALARM
3VSB: +3.31 V (min = +2.98 V, max = +3.63 V)
Vbat: +3.23 V (min = +2.70 V, max = +3.63 V)
fan1: 0 RPM (min = 0 RPM) ALARM
fan2: 7627 RPM (min = 0 RPM) ALARM
fan3: 0 RPM (min = 0 RPM) ALARM
SYSTIN: +28.0 C (high = +0.0 C, hyst = +0.0 C) ALARM sensor = CPU diode
CPUTIN: +51.0 C (high = +80.0 C, hyst = +75.0 C) sensor = CPU diode
AUXTIN: +26.0 C (high = +80.0 C, hyst = +75.0 C) sensor = thermistor
cpu0_vid: +1.708 V
intrusion0: ALARM
intrusion1: ALARM
Примечание:
В случае, если команда sensors не показывает требуемой информации,
следует единожды выполнить команду sensors-detect. Она запустит поиск
сенсоров. На все вопросы следует ответить положительно.
· Из подкаталога /sys можно получить информацию в следующем виде:
root@GW1:~# cat /sys/bus/platform/devices/coretemp.0/temp*_input
29000
29000
Здесь указана температура процессоров в миллиградусах. Для форматирования вывода можно воспользоваться следующей командой:
root@GW1:~# paste <(cat /sys/devices/platform/coretemp.0/temp*_label) <(cat /sys/devices/platform/coretemp.0/temp*_input) | column -s $'\t' -t | sed 's/\(.\)..$/.\1 C/'
Core 0 29.0 C
Core 1 31.0 C
Кроме информации, доступной по SNMP, можно получить информацию о состоянии жестких дисков при помощи утилиты smartctl. Данная утилита использует технологию SMART (Self Monitoring Analysing and Reporting Technology) для получения информации о различного рода проблемах и повреждениях (проблемы блока магнитных головок, проблемы механики, температура и др.).
Для определения дисков в системе можно использовать утилиту с опцией «--scan»:
root@sterragate:~# smartctl --scan
/dev/sda -d scsi # /dev/sda, SCSI device
Для вывода информации по диску можно использовать утилиту с опцией «-a»:
root@sterragate:~# smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-11-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Innodisk 3IE3/3ME3 SSDs
Device Model: mSATA mini 3ME3
Serial Number: B2A11807170060805
LU WWN Device Id: 5 24693f 22a221959
Firmware Version: S16425
User Capacity: 16,013,942,784 bytes [16.0 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Nov 3 23:02:14 2016 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Total time to complete Offline
data collection: ( 32) seconds.
Offline data collection
capabilities: (0x00) Offline data collection not supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x00) Error logging NOT supported.
No General Purpose Logging support.
SCT capabilities: (0x0039) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x0000 000 000 000 Old_age Offline - 0
2 Throughput_Performance 0x0000 000 000 000 Old_age Offline - 0
3 Spin_Up_Time 0x0000 000 000 000 Old_age Offline - 0
5 Later_Bad_Block 0x0013 100 100 001 Pre-fail Always - 0
7 Seek_Error_Rate 0x0000 000 000 000 Old_age Offline - 0
8 Seek_Time_Performance 0x0000 000 000 000 Old_age Offline - 0
9 Power_On_Hours 0x0002 119 000 000 Old_age Always - 1143
10 Spin_Retry_Count 0x0000 000 000 000 Old_age Offline - 0
12 Power_Cycle_Count 0x0002 115 000 000 Old_age Always - 371
163 Total_Bad_Block_Count 0x0000 000 000 000 Old_age Offline - 11
168 SATA_PHY_Error_Count 0x0000 000 000 000 Old_age Offline - 0
169 Remaining_Lifetime_Perc 0x0000 099 000 000 Old_age Offline - 99
175 Bad_Cluster_Table_Count 0x0000 000 000 000 Old_age Offline - 0
192 Power-Off_Retract_Count 0x0000 000 000 000 Old_age Offline - 0
194 Temperature_Celsius 0x0000 030 100 000 Old_age Offline - 30 (2 100 0 0 0)
197 Current_Pending_Sector 0x0012 000 100 000 Old_age Always - 0
225 Data_Log_Write_Count 0x0000 000 032 000 Old_age Offline - 569317
240 Write_Head 0x0000 000 000 000 Old_age Offline - 0
165 Max_Erase_Count 0x0002 025 001 000 Old_age Always - 25
167 Average_Erase_Count 0x0002 010 001 000 Old_age Always - 10
170 Spare_Block_Count 0x0003 100 001 000 Pre-fail Always - 143
171 Program_Fail_Count 0x0002 000 001 000 Old_age Always - 0
172 Erase_Fail_Count 0x0002 000 001 000 Old_age Always - 0
176 RANGE_RECORD_Count 0x0000 100 001 000 Old_age Offline - 0
187 Reported_Uncorrect 0x0002 000 001 000 Old_age Always - 0
229 Flash_ID 0x0002 100 001 000 Old_age Always - 0x517693943a98
232 Spares_Remaining_Perc 0x0003 100 001 000 Pre-fail Always - 0
235 Later_Bad_Blk_Inf_R/W/E 0x0002 000 000 000 Old_age Always - 0 0 0
241 Host_Writes_32MiB 0x0002 100 001 000 Old_age Always - 2223
242 Host_Reads_32MiB 0x0002 100 001 000 Old_age Always - 24116
SMART Error Log not supported
SMART Self-test Log not supported
Selective Self-tests/Logging not supported
Если по какой-то причине технология SMART на диске отключена, ее можно включить при помощи опции «-s»:
root@sterragate:~# smartctl -s on /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-11-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.
Проверьте наличие в образе утилит pwr_tst и pms. Для этого можно воспользоваться утилитой which:
root@sterragate:~# which pwr_tst
/usr/local/bin/pwr_tst
root@sterragate:~# which pms
/usr/local/bin/pms
В случае, если утилиты (pwr_tst для Lanner FW-8894 и pms для Lanner NCA-5210C) в образе отсутствуют, which выведет пустую строку. В таком случае следует скачать установочный архив, доступный на портале документации http://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл power_test.tar.gz.
Архив следует распаковать на Шлюзе и выполнить установочный скрипт:
root@sterragate:~# tar -xvf power_test.tar.gz
power_test/
power_test/pwr_tst_hash.sig
power_test/pwr_tst
power_test/pms_hash.conf
power_test/pms_hash.sig
power_test/install.bash
power_test/pwr_drv.ko
power_test/pwr_tst_hash.conf
power_test/pms
root@sterragate:~# cd power_test
root@sterragate:~# ./install.bash
OK
root@sterragate:~# cd ..
На платформе Lanner FW-8894 для получения информации о состоянии блоков питания следует использовать утилиту pwr_tst.
Примеры использования:
· Оба БП подключены к питанию:
root@sterragate:~# pwr_tst
=== Lanner platform miscellaneous utility ===
MB-8896 Redundant Power Supply V1.1 2019-02-19
Power supply 1/2 ....Normal state
· 1 БП подключен, 2 не подключен:
root@sterragate:~# pwr_tst
=== Lanner platform miscellaneous utility ===
MB-8896 Redundant Power Supply V1.1 2019-02-19
Power supply 1 ....Normal state
Power supply 2 ....Wrong state
На платформе Lanner NCA-5210C для получения информации о состоянии блоков питания следует использовать утилиту pms.
Примеры использования:
· Оба БП подключены к питанию:
root@sterragate:~# pms
****************************************************************
** Lanner Electronics Inc. 2019-07-05
** PMBUS utility Ver, 1.0 for NCB-5210
****************************************************************
<<<<< Power Information: >>>>>
Power Module 1 Power Mode:AC Power Mode
Power Module 1 SN:SA180J811724003455
Power Module 2 Power Mode:AC Power Mode
Power Module 2 SN:SA180J811724003444
================= Power Module 1 =================
Power Module Status:
12V: 12.047 5Vsb: 5.234
Fan Speed: 12400 Temp1: 38 Temp2: 38
================= Power Module 2 =================
Power Module Status:
12V: 12.078 5Vsb: 5.234
Fan Speed: 5800 Temp1: 37 Temp2: 40
· 1 БП подключен, 2 не подключен:
root@sterragate:~# pms
****************************************************************
** Lanner Electronics Inc. 2019-07-05
** PMBUS utility Ver, 1.0 for NCB-5210
****************************************************************
<<<<< Power Information: >>>>>
Power Module 1 Power Mode:AC Power Mode
Power Module 1 SN:SA180J811724003455
Power Module 2 Power Mode:AC Power Mode
Power Module 2 SN:SA180J811724003444
================= Power Module 1 =================
Power Module Status:
12V: 12.047 5Vsb: 5.234
Fan Speed: 5096 Temp1: 37 Temp2: 38
================= Power Module 2 =================
Power Module Status:
Unit not providing power to the output.
POWER_GOOD# present.
12V: 2.719 5Vsb: 2.797
Fan Speed: 0 Temp1: 40 Temp2: 43
====================================================
PMBUS Value fail
Для работы с Zabbix шаблоном следует настроить cron и snmpd в соответствии с главой «Расширенное использование SNMP при помощи NET-SNMP-EXTEND-MIB».
1. Создайте в директории /opt/snmp_monitoring/snmp_extend директорию с именем get_power_state и перенесите в неё все файлы из папки get_power_state архива snmp_extend_scripts.zip, который можно загрузить на портале документации http://doc.s-terra.ru в разделе Типовые сценарии применения -> Версия 4.3 -> файл snmp_extend_scripts.zip.
2. Установите права на запуск перенесённых скриптов:
root@GW1:~# chmod u+x /opt/snmp_monitoring/snmp_extend/get_power_state/get_power_state.cron.py
root@GW1:~# chmod u+x /opt/snmp_monitoring/snmp_extend/get_power_state/get_power_state.extend.sh
3. Рекомендуется установить выполнение скрипта /opt/snmp_monitoring/snmp_extend/get_power_state/get_power_state.cron.py раз в 15 минут в файле (/etc/cron.d/power_supplies):
*/15 * * * * root /usr/bin/python3 /opt/snmp_monitoring/snmp_extend/get_power_state/get_power_state.cron.py
4. Для получения объектного идентификатора в файл конфигураций /etc/snmp/snmpd.conf следует добавить следующую строку:
...
extend get_power_state /bin/bash /opt/snmp_monitoring/snmp_extend/get_power_state/get_power_state.extend.sh
...
В соответствии с этими строками конфигурационного файла в системе станет доступен объектный идентификатор:
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."get_power_state"
Обращаться к значению для первого и для второго блока
в отдельности можно при помощи следующих идентификаторов:
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_power_state".1
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_power_state".2
Проверка
1. Проверить правильность работы получения данных о состоянии блоков питания можно при помощи команды:
root@GW1:~# snmpwalk -v 2c -c public <адрес>NET-SNMP-EXTEND-MIB::nsExtendOutLine.\"get_power_state\"
В поле <адрес> следует указать тот адрес, что указывался в файле /etc/snmp/snmpd.conf при помощи agentaddress (вместо public при необходимости следует подставить свою community строку). Вывод должен выглядеть подобным образом:
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_power_state".1 = STRING: up
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_power_state".2 = STRING: up
2. Проверить наличие всех доступных расширенных объектных идентификаторов можно при помощи следующей команды:
root@GW1:~# snmpwalk -v 2c -c public <адрес> NET-SNMP-EXTEND-MIB::nsExtendObjects
Описание работы скриптов
Подробное описание логики работы скриптов для мониторинга состояния блоков питания представлено в файле на криптошлюзе:
/opt/snmp_monitoring/snmp_extend/get_power_state/README.txt
Также, можно получить информацию о соседних устройствах при помощи протокола LLDP. Информация об устройстве, которая может передаваться с помощью LLDP:
§ Имя устройства (System Name),
§ Описание устройства (System Description),
§ Идентификатор порта (Port ID),
§ Описание порта (Port Description),
§ Возможности устройства (System Capabilities),
§ Управляющий адрес (Management Address),
Запустите сервис lldpd (по умолчанию, он выключен):
root@sterragate:~# systemctl start lldpd.service
После запуска проверьте список доступных устройств:
root@sterragate:~# lldpctl
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface: eth0, via: LLDP, RID: 1, Time: 0 day, 00:00:07
Chassis:
ChassisID: mac 08:00:27:17:ad:b4
SysName: sterragate
SysDescr: S-Terra_Gate_4.3
TTL: 120
MgmtIP: 0.0.0.0
Capability: Bridge, off
Capability: Router, on
Capability: Wlan, off
Capability: Station, on
Port:
PortID: mac 08:00:27:17:ad:b4
PortDescr: eth0
PMD autoneg: supported: yes, enabled: yes
Adv: 10Base-T, HD: yes, FD: yes
Adv: 100Base-TX, HD: yes, FD: yes
Adv: 1000Base-T, HD: no, FD: yes
MAU oper type: 1000BaseTFD - Four-pair Category 5 UTP, full duplex mode
-------------------------------------------------------------------------------
Настройка параметров запуска сервиса lldpd находится в файле /etc/defaults/lldp. По умолчанию, конфигурационный файл выглядит так:
root@sterragate:~# cat /etc/default/lldpd
# Uncomment to start SNMP subagent and enable CDP, SONMP and EDP protocol
# DAEMON_ARGS=" -x -c -s -e "
Опция «-m» позволяет задать управляющий адрес (Management Address),. Так как по умолчанию рассылка lldp-пакетов производится на все интерфейсы, можно выбрать тот, который необходим при помощи опции «-I». Также, можно добавить описание устройства (System Description) при помощи параметра «-S» :
root@sterragate:~# cat /etc/default/lldpd
# Uncomment to start SNMP subagent and enable CDP, SONMP and EDP protocol
DAEMON_ARGS="-m 0.0.0.0 -I eth0 -x -c -s -e -S S-Terra_Gate_4.3"
Для того, чтобы сервис lldpd осуществлял поиск соседних устройств на выборочных интерфейсах, необходимо внести правки в файл “/etc/default/lldpd” следующим образом:
root@sterragate:~# vi /etc/default/lldpd
# Uncomment to start SNMP subagent and enable CDP, SONMP and EDP protocol
DAEMON_ARGS="-I *,!eth1,!eth2 -x -c -s -e"
Далее, необходимо перезапустить сервис:
root@sterragate:~# systemctl restart lldpd.service
В данном примере протокол lldp активен на всех интерфейсах, кроме “eth1” и “eth2”.
По умолчанию файл /etc/snmp/snmpd.conf выглядит следующим образом:
###############################################################
# Listen for connections from the local system only.
agentaddress udp:127.0.0.1:161
# Listen for connections on all interfaces.
#agentaddress udp:161
####################################################################
# ATTENTION: change community and restrict access to SNMP requests #
# from the specified sources for security reasons. #
####################################################################
# Read-only access from anywhere with 'public' community.
rocommunity public default -V customview
# Read-only access from 10.0.0.0/16 with 'public' community.
#rocommunity public 10.0.0.0/16 -V customview
# .iso.org.dod.internet.mgmt.mib-2
view customview included .1.3.6.1.2.1
# .iso.org.dod.internet.private.enterprises.cisco
view customview included .1.3.6.1.4.1.9
# S-TERRA-CSP-MIB.
view customview included .1.3.6.1.4.1.31342
# .iso.org.dod.internet.private.enterprises.Debian.project.keepalived
view customview included .1.3.6.1.4.1.9586.100.5
# .iso.identified-organization.dod.internet.private.enterprise.ucdavis
view customview included .1.3.6.1.4.1.2021
# .iso.identified-organization.dod.internet.private.enterprise.netSnmpObjects.nsExtensions
# For using 'extend' directive (NET-SNMP-EXTEND-MIB).
view customview included 1.3.6.1.4.1.8072.1.3
# Getting the number of days until the the local certificate expires.
# Usage example: snmpget -v 2c -c public 127.0.0.1:161 NET-SNMP-EXTEND-MIB::nsExtendOutputFull.\"get_days_until_local_cert_exp\"
extend get_days_until_local_cert_exp /bin/bash /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.extend.bash
# Configures monitoring of all disks found on the system, using the specified (percentage) threshold.
includeAllDisks 10%
# Proxy directive to pass part of the OID tree to S-Terra CSP SNMP agent to retrieve IKE and IPsec stats.
# Example of S-Terra Gate SNMP configuration in Cisco-like console:
# snmp-server community public RO
# snmp-server polling address 127.0.0.1
# snmp-server polling udp-port 1161
proxy -v 2c -c "public" 127.0.0.1:1161 .1.3.6.1.4.1.9
proxy -v 2c -c "public" 127.0.0.1:1161 .1.3.6.1.2.1.1.1.0
proxy -v 2c -c "public" 127.0.0.1:1161 .1.3.6.1.4.1.31342
# Enable the AgentX functionality and cause the agent to start listening for incoming AgentX registrations
# (for example used by a Keepalived).
master agentx
###############################################################
Пояснения:
agentaddress <IP адрес шлюза>:<порт> - локальный адрес шлюза, на котором SNMPD слушает запросы от систем мониторинга; 161 - локальный порт (стандартный).
rocommunity - задает значение community-строки (в данном случае - “public”) с правами только на чтение, а следующее за ним ключевое слово default -V <имя> указывает какие объектные идентификаторы (OID) будут выдаваться. Если нужны права не только на чтение, но и на запись значений OID, замените rocommunity на rwcommunity.
view <имя> included <OID> -задает значения, объектных идентификаторов, доступные для использования. В качестве <OID> в конфигурации указаны поддеревья идентификаторов, т.е. доступными для использования становятся все присутствующие в системе значения, являющиеся дочерними к указанным.
includeAllDisks <число>% - включает мониторинг дискового пространства. Числом указывается процент оставшегося свободного места на разделе. В случае, если свободного места оказывается меньше указанного, переменная UCD-SNMP-MIB::dskErrorFlag.<номер> для соответствующего раздела примет значение «1».
proxy -v 2c -c "public" 127.0.0.1:1161 <OID> - указывает, что запросы к <OID> нужно перенаправлять встроенному агенту VPNGATE.
Для получения ARP записей с использованием SNMP запроса можно использовать OID RFC1213-MIB::atPhysAddress (1.3.6.1.2.1.3.1.1.2):
root@GW1:~# snmpwalk -v 2c -c public 127.0.0.1 RFC1213-MIB::atPhysAddress
RFC1213-MIB::atPhysAddress.2.1.172.16.100.1 = Hex-STRING: 00 0C 29 22 F4 35
RFC1213-MIB::atPhysAddress.3.1.192.168.100.11 = Hex-STRING: 00 0C 29 9D 26 88
RFC1213-MIB::atPhysAddress.3.1.192.168.100.100 = Hex-STRING: 00 0C 29 0A A3 5B
Пример содержимого ARP таблицы на шлюзе:
root@GW1:~# ip neigh
192.168.100.11 dev eth1 lladdr 00:0c:29:9d:26:88 REACHABLE
172.16.100.1 dev eth0 lladdr 00:0c:29:22:f4:35 REACHABLE
192.168.100.100 dev eth1 lladdr 00:0c:29:0a:a3:5b REACHABLE