Não sei bem por que isso funcionou, mas parece que resolvi o problema. No meu /etc/snmp/snmpd.conf , substituí a linha:
com2sec readonly default taylor
com
rocommunity taylor
e tudo funciona muito bem.
Tudo bem, tenho duas VMs em execução no ESXi. Uma VM hospeda o Observium, que usa SNMP para capturar suas informações. Eu indiquei o Observium no meu host ESXi diretamente, e funcionou bem, então não há problema com o Observium. Tentando adicionar o dispositivo usando as configurações adequadas (tentei% SNMPv1, v2c e v3 ), não há sempre nenhuma resposta do servidor.
O nome do host para o servidor, neste caso, é cal , e o nome do host para o cliente é default , apenas para esclarecer.
O cliente para o qual estou enviando solicitações SNMP é uma nova instalação do Ubuntu Server 14.04 LTS. Tudo o que fiz foi instalar o pacote snmpd e configurá-lo.
Aqui está o meu /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 protected]
No meu entender, colocar default antes do nome da comunidade (que é taylor ) significa que ele aceitará solicitações SNMP de qualquer IP.
E meu /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'
Então, pensando que eu tinha configurado tudo muito bem, eu emito um snmpwalk para testar:
taylor@cal:~$ snmpwalk -v 2c -c taylor default
Timeout: No Response from default
Eu posso pingar bem:
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
Querendo ter certeza de que temos tráfego, eu emito um tcpdump nas extremidades de envio e recebimento:
Envio (servidor 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)
Recebendo (cliente 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)
Então, essencialmente a mesma coisa, apenas timestamps ligeiramente diferentes. A coisa concernente é que não há pacotes de resposta sendo enviados. Tudo bem, então talvez haja um problema de firewall ou de porta.
Desativei o Uncomplicated Firewall do Ubuntu com ufw disable e confirmei que ele não estava sendo executado com ufw status .
Em seguida, verifiquei meu iptables , que estava vazio da nova instalação. Eu adicionei regras de entrada e saída para a porta 161 no cliente 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
Ainda com o mesmo problema. Outra postagem em SuperUser ou ServerFault foi resolvida para o mesmo problema porque seus /etc/hosts.allow e iptables estavam bloqueando o tráfego. Aqui está o meu:
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
Estou sem ideias neste momento. Alguma sugestão sobre o que eu posso tentar fazer com que isso realmente responda às minhas consultas SNMP?
EDITAR:
Aqui está o meu /var/log/syslog no cliente:
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
Parece que alguns deles são devidos à observação de pacotes e, em seguida, há algumas menções de Error opening specified endpoint "udp:161" , mas elas são esporádicas. Poderia ser alguma coisa.
EDIT: Isto foi realmente devido a eu tentar agentAddress udp:161,udp6:[::1]:161 . Os logs só diziam esporadicamente porque eu estava habilitando e desabilitando essa linha. Então, de volta à estaca zero.
A partir de seus registros, o daemon SNMP não está ligado à porta 161 e, em seguida, saindo:
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
Por isso, o motivo pelo qual você não está recebendo respostas é que snmpd não está sendo executado no momento.
Você pode tentar comentar a linha agentAddress caso haja algum problema de sintaxe, mas também pode ser o caso de alguma outra coisa estar vinculada à porta UDP 161. Verifique a saída de netstat -lnp | grep :161 que mostrará o que é ligado a essa porta.