Я пытаюсь перенаправить порт и проверяю, что перенаправление работает, используя
iptables -t nat -D PREROUTING -i enp0s3 -p udp --dport 162 -j REDIRECT --to-port 10162
а потом
tcpdump -i enp0s3 udp port 10162
К сожалению, это ничего не захватывает, в то же время я все еще получаю пакеты на порт 162, просматривая через tcpdump.
Также, когда я начинаю использовать iptables redirect 162 -> 10162, я перестаю видеть snmptrapd сообщения в системном журнале, информирующие меня, что ловушка была получена. После удаления правила системный журнал снова получает информацию.
Я ищу свидетельство того, что порт 10162 получает перенаправленную ловушку, которая вводится для моего журнала, и поэтому я могу продолжить исследование своей более серьезной проблемы со стеком ELK. По сути, я пытаюсь идти по этому пути шаг за шагом и посмотреть, в чем заключается моя проблема.
По крайней мере, почему snmptrapd перестает сообщать, что trap-сообщение получено в системном журнале (при перенаправлении), и определяет правильный способ настройки tcpdump для перехвата «внутреннего» взаимодействия.
Итак, перенаправление работает нормально, я проверил другими способами (отладка самого logstash - отправка snmptrap и перехват его в консоли logstash). Я предполагаю: когда происходит перенаправление, snmptrapd больше ничего не получает на порт 162, поскольку он, вероятно, перенаправляется до того, как достигнет его с помощью iptables, но tcpdump запускается даже до этого перенаправления, поэтому он фактически принимает 162 в качестве исходного порта (на основе самого сообщения), НО не может захватить порт 10162, так как он не работает или не читает «за ним». Это мое основное понимание. Было бы неплохо узнать, как проверить также порт 10162 после перенаправления, для еще более глубокого понимания и знаний ... или лучшего объяснения, чем мое, которое является серьезным предположением