我正在尝试重定向端口并验证重定向是否正常工作
iptables -t nat -D PREROUTING -i enp0s3 -p udp --dport 162 -j REDIRECT --to-port 10162
进而
tcpdump -i enp0s3 udp port 10162
遗憾的是，这并没有捕获任何东西，同时，我仍然通过 tcpdump 接收到到端口 162 的数据包。
此外，当我开始使用 iptables 重定向 162 -> 10162 时，我不再看到snmptrapd系统日志中通知我已收到陷阱的消息。删除规则后，系统日志会再次获取信息。
我正在寻找的是端口 10162 正在接收重定向陷阱的证据，这是我的 logstash 的输入，因此我可以进一步调查 ELK 堆栈的更大问题。基本上，我正在尝试一步一步地遵循路径，看看我的问题在哪里。
至少为什么 snmptrapd 停止说在 syslog 中收到了陷阱（重定向时）以及如何设置 tcpdump 来捕获“内部”通信的正确方法。
答案1
因此重定向工作正常，我通过其他方式检查（调试 logstash 本身 - 发送 snmptrap 并在 logstash-console 中捕获它）。我猜：当重定向发生时，snmptrapd 不再在端口 162 上获取任何东西，因为它可能在通过 iptables 到达端口 162 之前就重定向了，但 tcpdump 甚至在重定向之前就运行了，因此它实际上将 162 作为原始端口（基于消息本身），但无法在端口 10162 上捕获，因为它没有在“后面”运行或读取。这是我的基本理解。如果知道重定向后检查端口 10162 的方法，那将是一件好事，这样可以更深入地理解和了解……或者比我的解释更好，这只是猜测