Хорошо, у меня две виртуальные машины, обе работают под управлением ESXi. На одной виртуальной машине размещен Observium, который использует SNMP чтобы получить его информацию. Я указал Observium на свой хост ESXi напрямую, и он работал нормально, так что с Observium проблем нет. Попытка добавить устройство с правильными настройками (пробовал SNMP v1, v2c, и v3), от сервера всегда нет ответа.
Имя хоста для сервера в этом случае cal, а имя хоста для клиента - default, просто для уточнения.
Клиент, которому я отправляю запросы SNMP, - это свежая установка Ubuntu Server 14.04 LTS. Все, что я сделал, это установил snmpd пакет и настройте его.
Вот мой /etc/snmp/snmpd.conf:
com2sec readonly default taylor
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly
view all included .1 80
access MyROGroup “” any noauth exact all none none
syslocation “San Francisco, CA”
syscontact email@somesite.com
Насколько я понимаю, размещение default перед названием сообщества (которое taylor) означает, что он будет принимать запросы SNMP с любого IP-адреса.
И мой /etc/default/snmpd:
export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'
TRAPDRUN=no
TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'
Итак, полагая, что я все правильно настроил, я выдаю snmpwalk тестировать:
taylor@cal:~$ snmpwalk -v 2c -c taylor default
Timeout: No Response from default
Я отлично могу пинговать:
taylor@cal:~$ ping default
PING default.mywebsite.com (192.168.1.130) 56(84) bytes of data.
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=1 ttl=64 time=0.350 ms
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=2 ttl=64 time=0.235 ms
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=3 ttl=64 time=0.192 ms
taylor@default:~$ ping cal
PING cal.taylorjthurlow.com (192.168.1.112) 56(84) bytes of data.
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=1 ttl=64 time=0.306 ms
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=2 ttl=64 time=0.188 ms
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=3 ttl=64 time=0.264 ms
Желая убедиться, что у нас есть трафик, я выдаю tcpdump как на отправляющей, так и на принимающей стороне:
Отправка (сервер SNMP):
02:22:51.569041 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:52.569547 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:53.570659 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:54.571775 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:55.572715 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:56.573874 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
Прием (клиент SNMPD):
02:22:51.858750 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:52.859290 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:53.860371 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:54.861495 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:55.862424 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
02:22:56.863590 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp: C=taylor GetNextRequest(25)
Итак, по сути, одно и то же, только немного разные временные метки. Беспокоит то, что не отправляются ответные пакеты. Хорошо, может быть, проблема с брандмауэром или портом.
Я отключил Ubuntu Uncomplicated Firewall с участием ufw disable и подтвердил, что он не работает с ufw status.
Затем я проверил свой iptables, которые были пустыми из новой установки. Я добавил входящие и исходящие правила для порта 161 на клиенте SNMPD.
taylor@default:~$ sudo iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:161
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:161
По-прежнему возникает та же проблема. Другой пост на SuperUser или ServerFault был решен для той же проблемы, потому что их /etc/hosts.allow и iptables блокировали движение. Вот мои:
taylor@default:~$ cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
taylor@default:~$ cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
У меня нет идей на данный момент. Есть какие-нибудь предложения о том, что я могу попробовать, чтобы эта штука действительно отвечала на мои запросы SNMP?
РЕДАКТИРОВАТЬ: вот мой /var/log/syslog на клиенте:
Dec 9 01:48:24 default snmpd[2888]: NET-SNMP version 5.7.2
Dec 9 01:48:27 default snmpd[2888]: Connection from UDP: [192.168.1.112]:41109->[192.168.1.130]:161
Dec 9 01:50:54 default kernel: [ 8359.253571] nf_conntrack version 0.5.0 (7951 buckets, 31804 max)
Dec 9 01:48:32 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:41109->[192.168.1.130]:161]
Dec 9 01:52:53 default snmpd[2888]: Connection from UDP: [192.168.1.112]:40482->[192.168.1.130]:161
Dec 9 01:54:05 default kernel: [ 8550.718971] ip6_tables: (C) 2000-2006 Netfilter Core Team
Dec 9 01:52:58 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:40482->[192.168.1.130]:161]
Dec 9 01:54:11 default snmpd[2888]: Connection from UDP: [192.168.1.112]:59617->[192.168.1.130]:161
Dec 9 01:54:16 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:59617->[192.168.1.130]:161]
Dec 9 01:56:43 default snmpd[2888]: Received TERM or STOP signal... shutting down...
Dec 9 01:56:45 default snmpd[3165]: NET-SNMP version 5.7.2
Dec 9 02:00:06 default snmpd[3165]: Received TERM or STOP signal... shutting down...
Dec 9 02:00:08 default snmpd[3216]: NET-SNMP version 5.7.2
Dec 9 02:00:18 default snmpd[3216]: Connection from UDP: [192.168.1.112]:45692->[192.168.1.130]:161
Dec 9 02:00:23 default snmpd[3216]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:45692->[192.168.1.130]:161]
Dec 9 02:02:36 default snmpd[3216]: Received TERM or STOP signal... shutting down...
Dec 9 02:02:38 default snmpd[3242]: Error opening specified endpoint "udp:161"
Dec 9 02:02:38 default snmpd[3242]: Server Exiting with code 1
Dec 9 02:07:16 default snmpd[3281]: duplicate registration: MIB modules pass and pass (oid .1.3.6.1.4.1.4413.4.1).
Dec 9 02:07:16 default snmpd[3281]: Error opening specified endpoint "udp:161"
Dec 9 02:07:16 default snmpd[3281]: Server Exiting with code 1
Dec 9 02:17:01 default CRON[3283]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Dec 9 02:23:55 default kernel: [10340.925233] device eth0 left promiscuous mode
Похоже, что частично это связано с тем, что я смотрю пакеты, а затем есть несколько упоминаний о Error opening specified endpoint "udp:161" но они спорадические. Может быть что-то.
РЕДАКТИРОВАТЬ: Это было на самом деле из-за того, что я пытался agentAddress udp:161,udp6:[::1]:161. В журналах это говорилось время от времени, потому что я включал и отключал эту строку. Итак, вернемся к исходной точке.
Я не совсем уверен, почему это сработало, но, похоже, я решил свою проблему. В моем /etc/snmp/snmpd.conf, Я заменил строку:
com2sec readonly default taylor
с участием
rocommunity taylor
и все отлично работает.
Судя по вашим журналам, демон SNMP не может подключиться к порту 161, а затем завершает работу:
Dec 9 02:07:16 default snmpd[3281]: Error opening specified endpoint "udp:161"
Dec 9 02:07:16 default snmpd[3281]: Server Exiting with code 1
поэтому вы не получаете ответов по той причине, что snmpd на самом деле не работает в то время.
Вы можете попробовать прокомментировать agentAddress на случай, если есть синтаксическая проблема, но также может быть, что что-то еще привязано к UDP-порту 161. Проверьте вывод netstat -lnp | grep :161 который покажет вам, что привязано к этому порту.