Никакие ответы запроса SNMP из Ubuntu 14.04 клиентская машина сервера LTS

Хорошо, у меня есть два VMs оба выполнения под ESXI. Одна VM размещает Observium, который использует SNMP захватить его информацию. Я указал на Observium на свой хост ESXI непосредственно, и он хорошо работал, таким образом, нет никакой проблемы с Observium. Попытка добавить устройство с помощью надлежащих настроек (попробовал SNMP v1, v2c, и v3), с сервера всегда нет никакого ответа.

Имя хоста для сервера в этом случае cal, и имя хоста для клиента default, просто для уточнения.

Клиент, к которому я отправляю запросы SNMP, является новой установкой Сервера Ubuntu 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'

Так фигурируя я настроил все очень хорошо, я проблема a snmpwalk протестировать:

taylor@cal:~$ snmpwalk -v 2c -c taylor default
Timeout: No Response from default

Я могу проверить с помощью ping-запросов очень хорошо:

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

Желание удостовериться у нас есть трафик, я проблема a 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. Журналы только сказали это эпизодически, потому что я включал и отключал ту строку. Так, назад в квадратном.