服务器换机房后cacti监控不出图故障排查

备注：这是本人转载过来的一篇文章，有效的解决了最近几天装了cacti监控，以实现监控远程服务器的内网服务器！由于远程服务器只有一个对外公网IP，故要远程内网的机器信息是无法直接获取的！而这一篇文章也帮我解决了这种问题！

服务器换机房后cacti监控不出图故障排查

环境介绍：

因为业务需要，公司在深圳机房的几台服务器搬迁到中山机房，由于监控服务器放在佛山，因此采用如下图的方式来对中山机房的机器进行监控：

佛山的监控系统采用cacti+nagios来监控，B服务器为windows机器，没有公网IP。因此cacti和nagios获取数据的时候需要通过A服务器(linux)的iptables来转发。如上图，cacti通过访问A服务器的11161端口来访问B服务器的snmp服务(snmp服务使用的端口为udp161端口)。在A服务器上添加了如下iptables规则来实现端口转发的目的：

# nagios的windows客户端NSClient的端口转发，nagios通过这个端口采集数据

/sbin/iptables -t nat -A PREROUTING -d 189.43.138.11 -p tcp -m tcp --dport 12489 -j DNAT --to-destination 172.16.100.82:12489

#windows中snmp的端口转发，cacti通过这个端口采集数据

/sbin/iptables -t nat -A PREROUTING -d 189.43.138.11 -p udp -m udp --dport 11161 -j DNAT --to-destination 172.16.100.82:161

#将B服务器的IP地址进行伪装，使B服务器能正常上网

/sbin/iptables -t nat -A POSTROUTING -s 172.16.100.0/24 -j SNAT --to-source 189.43.138.11

机器迁移以后因为IP变了因此只对一些涉及到IP的配置做了变更，变更后网站访问以及ssh登录等都正常，nagios监控的也正常，唯独cacti没有数据。奇怪的是以前在深圳机房的时候也是采取的iptables规则来做端口转发的，能正常地获取数据。现在不同的只是将IP变更了一下就出现不能获取数据的问题，检查了windows下的防火墙以及杀毒软件没有阻塞对161端口的访问，不知道什么原因？

故障排查：

         为了深入分析这个问题，首先在监控服务器上使用snmpwalk命令看看能否获取数据，命令如下：

snmpwalk -v2c -c public 189.43.138.11: 11161

#返回如下内容

Timeout: No Response from 189.43.138.11: 11161

发现没有内容返回，在监控服务器上ping 189.43.138.11没有问题。为了一探究竟在A服务器上使用tcpdump抓包

在A服务器使用如下命令抓包:

/usr/sbin/tcpdump -i eth1 port 11161 –vv

返回如下内容：

18:44:30.650302 IP (tos 0x0, ttl  58, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) 121.9.203.157.13065 > 189.43.138.11.suncacao-snmp: [udp sum ok] UDP, length 54

18:44:31.651067 IP (tos 0x0, ttl  58, id 0, offset 0, flags [DF], proto: UDP (17), length: 82) 121.9.203.157.13065 > 189.43.138.11.suncacao-snmp: [udp sum ok] UDP, length 54

备注：由于后面几个包和这两个包一样，限于篇幅，省略了。

从抓取的包中我们可以看出数据顺利的到了189.43.138.11服务器，但是从189.43.138.11却没有数据返回。

于是在B服务器使用ethereal进行抓包分析。通过161端口进行过滤后发现如下内容：

发现返回的IP确实172.16.100.83的IP，也就是B服务器上另外一个IP，对于这个IP我们的防火墙上没有任何规则。至此真相大白！

故障原因：

         从上面的分析中我们可以看出，我们的规则之是针对172.16.100.82这个IP，但是B服务器上snmp响应的IP确实172.16.100.83这个IP，因为A上的iptables只是针对172.16.100.82这个IP做了规则，因此导致数据返回监控服务器的时候出现问题。以前在深圳机房的时候只配置了一个IP，因此没有出现这个问题。

解决办法：

         知道了问题的原因，就好解决了，只需要将防火墙规则指向172.16.100.83这个IP即可或者将172.16.100.83这个IP去掉，因为那个IP是同事配置的因此采用第一种解决办法，于是将snmp端口转发的规则调整如下：

#windows中snmp的端口转发，cacti通过这个端口采集数据

/sbin/iptables -t nat -A PREROUTING -d 189.43.138.11 -p udp -m udp --dport 11161 -j DNAT --to-destination 172.16.100.83:161

再使用snmpwalk在监控服务器上获取一下数据看看:

snmpwalk -v2c -c public 189.43.138.11:11161

SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 6 Model 26 Stepping 5 AT/AT COMPATIBLE - Software: Windows Version 5.2 (Build 3790 Multiprocessor Free)

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.311.1.1.3.1.2

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (915656) 2:32:36.56

SNMPv2-MIB::sysContact.0 = STRING:

SNMPv2-MIB::sysName.0 = STRING: WEB2

哈哈，终于有数据了，再看看cacti中也开始有数据了。看来排查这种问题，还是需要通过抓包的方式来定位问题，比较快速！

故障总结：

         对于我们IT人员来说掌握各个平台下的抓包工具的使用也是一项很重要的技能，有了这些技能我们才能在复杂的和高压力的IT工作环境中脱颖而出，达到事半功倍的效果。在工作当中如果遇到网络不通或者是获取不了数据的情况，采用抓包的方法来分析能快速的定位问题。因此，在这里也希望通过这个问题的总结让更多的人重视一些IT工具的积累和使用。