LINUX.ORG.RU
Форум — Admin  

UDP proxy for SNMP

 , ,


0

1

Условная схема.

ServerA - это Nagios сервер, которому нужно мониторить по SNMP устройства device1-3, слушающие на дефолтном 161 UDP порту.

Устройства device1-3 не доступны напрямую с ServerA, так как в общей сети существует аналогичная подсеть 10.10.10.0

Зато устройства device1-3 доступны напрямую с ServerB, при этом ServerB ничего не знает о существующей аналогичной подсети 10.10.10.0 так что здесь это не будет проблемой.

Сервера А и В доступны между собой.

Что можно сделать, чтоб ServerA мог по UDP подключаться к устройствам, используя ServerB? Разумеется на ServerA я могу указывать другой адрес и порты для устройств, например если прокси или тунель будет поднят на ServerB.

Смотрел в сторону SSF, но не понял как применить в моем случае.

mky, vodz

★★

Последнее исправление: nerve (всего исправлений: 1)
← btrfs-transacti makes me wonder
Squid ограничить доступ для пользователей →
Ответ на: комментарий от drsm

то есть на ServerB что-то вроде этого:

stream {
    server {
        listen     10001 udp;
        proxy_pass device1:161;
    }
    server {
        listen     10002 udp;
        proxy_pass device2:161;
    }
    server {
        listen     10003 udp;
        proxy_pass device3:161;
    }

а на ServerА подключаться к ServerB:10001, ServerB:10002, ServerB:10003?

nerve ★★
() автор топика
Ответ на: комментарий от nerve

а это «Менеджер получает уведомления (Traps и InformRequests) по порту 162.» ?

link

drsm ★★
()
Ответ на: комментарий от Oleg_Iu

Есть разница.

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

Ну в общем то, да. Что-то я притормозил.

Но я бы сделал через xinetd redirect. Точнее, я так делал, когда у меня еще xinetd юзался. :)

В «новые времена» советуют делать через systemd-socket-proxy, но я им проксировал только tcp, поэтому не могу настаивать, что с udp тоже будет малина. :)

Oleg_Iu ★
()
Ответ на: комментарий от vel

у snmpd (net-snmp) есть встроенный snmp-proxy. Лет 10 назад приходилось использовать.

пробовал настроить это на serverB, но не работает. в конец snmpd.conf добавляю строки и рестартую snmpd:

com2sec -Cn ctx_device1 notConfigUser default device1
view allview included .1
access notConfigUser ctx_device1 any noauth exact allview none none
proxy -Cn ctx_device1 -v 2c -c device1 10.10.10.1 .1.3

где device1 это новое комьюнити на устройстве.

проверяю на том же serverB:

snmpstatus -c device1 -v 2c serverB
Timeout: No Response from serverB

при этом public комьюнити самого serverB работает:

snmpstatus -c public -v 2c serverB
[UDP: [serverB]:161->[0.0.0.0]:48917]=>[Linux 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64] Up: 0:06:48.81
Interfaces: 7, Recv/Trans packets: -33586958/58755334 | IP: -33655398/58751486

так же работает смнп и на самом устройстве если обратиться к нему напрямую с serverB:

snmpstatus -c device1 -v 2c 10.10.10.1  
[UDP: [10.10.10.1]:161->[0.0.0.0]:46122]=>[] Up: 0:24:02.83
Interfaces: 2, Recv/Trans packets: 1385255/1411843 | IP: 1360549/1410842

то есть проксирование через serverB не работает и требует дополнительной магии..

может есть у кого-то рабочий конфиг?

nerve ★★
() автор топика
Ответ на: комментарий от nerve 
access notConfigGroup ctx_device1 any noauth exact allview none none

Рабочий конфиг.

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← btrfs-transacti makes me wonder
Admin
Squid ограничить доступ для пользователей →