如何将Sensu数据包追溯到其始发IP地址？

我正在尝试在导致Sensu通知的环境中找到一台机器。通知中列出的主机名和IP地址都是混乱的，因为在创建机器时，它有不同的数据。因此，错误的数据卡住了，机器仍然活着，踢着......我的意思是，从某处发送错误的数据到Sensu服务器。如何将Sensu数据包追溯到其始发IP地址？

我试图追查机器的地址。在tcpdump的帮助下，我找到了两种类型的数据包：

1）在运行Sensu客户端的每台计算机上，都会看到带有正确有效负载的数据包，以便为Sensu服务器机。 Sensu配置文件告诉我，Sensu在与Sensu服务器相同的机器上使用RabbitMQ，并且数据包正朝着这个方向前进。

2）在扇子服务器，我看到所有那些从本地10. 传入分组的。。*来自各种不同端口的IP地址。当我使用wget探测IP地址时，它会将我作为Sensu仪表板的index.html，因此本地地址似乎是同一台机器 - 可能是RabbitMQ或其他东西，因为Sensu使用它。

有可能高达一百机在我们的环境中运行的扇子客户端，但也有无处的传入流量几乎同样多的连接或源IP地址。所以，我无法弄清楚如何找到合适的源机器，而不是蛮力地逐一关闭每台机器，并看到何时弹出另一个通知。

额外的信息：我们的机器都在AWS，并创建后由木偶供应。 Sensu被烘烤到基地AMI中，以便我们可以在木偶失败后立即得到提醒。除了Puppet甚至不知道他在失败的时候是谁。

编辑：另外，现在我想到了，Sensu服务器坐在弹性负载平衡器后面，这是路由53条目的后面，这是所有Sensu客户端发送内容的位置。

来源

2014-01-15 snetch

不知道我跟着......我不熟悉的扇子，但你不能设置tcpdump和直到所需的通知进来看扇子仪表板，然后检查tcpdump的捕获周边同戳包？如果你能在tcpdump中识别出正确的数据包，你将看到真正的源IP地址（与通知有效负载中报告的IP地址相反）。 – James

那么，至少在Sensu的这个特定通知 - “最后的木偶运行状态：失败” - 每十秒钟发送一次，并且它停留在仪表板上。是的，这就是我所做的，我设置了tcpdump，找到了正确的包，但它来自本地的10 *。* * *地址。通知的有效载荷中的错误地址是第三个不同的全球IP地址 - 可能是亚马逊用来启动它的机器。 – snetch

我明白了...所以你说右边数据包的源地址是10.x.x.x地址。你说那个地址“似乎是同一台机器”。这对我来说没有什么意义...你的网络上的tcpdump流量是从/到同一个设备？它有助于从tcpdump数据包中提取MAC地址并检查供应商？这可能会给你一个线索...... – James

ELB竟然是麻烦。只要我将Route 53直接重新路由到Sensu服务器，并且（由于缓存问题）将Sensu服务器从ELB中取出，所有传入连接都假定为正确的IP地址。毕竟，这不是一个Sensu问题。

来源

2014-01-16 16:38:53 snetch

如何将Sensu数据包追溯到其始发IP地址？

回答

相关问题