прием rsyslog не для текущего IP

tcpdump показывает что пакеты поступают ip получателя 192.168.100.1

на интерфейс они поступают, а в системе такой ip не настроен, поэтому пакеты отбрасываются не доходя до rsyslog

как настроить получение на два сервера rsyslog

вариант в лоб: проксировать на 2 сервера через какой-нибудь nginx или ha-proxy
вариант поделикатнее: настроить пересылку логов с первого syslog на второй средствами rsyslog

А что за задача в целом? хранить бекапы логов? может просто обучить rsyslog работать с кластером БД?

Два варианта (оба не те что выше предложили):

1) при зеркалировании подменяй айпи получателя, наверно iptables это умеет, но я не знаю как

2) подменяй адрес получателя на принимающем сервере - аналогично

1. rsyslog на 192.168.100.2 должен явно запросить у локального iptables пакеты для адреса 192.168.100.1. Интерфейс не нужен.

2. создайте широковещательный интерфейс 192.168.100.3 и шлите на него логи броадкастом. Интерфейс 192.168.100.3 должен быть поднят на обеих серверах

в iptables зеркалить

Что это значит? Какое правило?

tcpdump показывает

tcpdump на каком хосте?

настройка на хостах отпадает(там можно указать только 1 ip адрес)

Чак Норрис запрещает запустить второй экземляр rsyslog и указать ему другой адрес?

Но, tcp на два хоста принять не получится. Если трафик действительно зеркалится (-j TEE), то один хост будет мешать другому обрабатывать tcp-соединение.

Вобще не совсем понятно, от чего вы защищаетесь, от переполнения диска на первом хосте? Ведь если первый хост «отключится», то и зеркалирования трафика не будет, и трафика тоже не будет, так как не будет ответа на ARP-запросы...

То есть непонятно, почему просто не настроить на 192.168.100.1 rsyslogd на отправку логов на 192.168.100.2?

я пробовал на сервере прописать ip arp –set 192.168.100.1 00:00:22:22:44:44 не помогло

зеркалю в iptables

-A PREROUTING -t mangle -p tcp -d 192.168.100.1 –dport 514 -j TEE – gateway 192.168.100.2

-A PREROUTING -t mangle -p udp -d 192.168.100.1 –dport 514 -j TEE – gateway 192.168.100.2

tcpdump’ом смотрел на сервере 192.168.100.2

пробовал на 192.168.100.2 правило

-A PREROUTING -t mangle -p udp -d 192.168.100.1 –dport 514 -j TEE – gateway 127.0.0.1

или на другой ip -A PREROUTING -t mangle -p udp -d 192.168.100.1 –dport 514 -j TEE – gateway 192.168.200.5

через arp –set 192.168.200.5 00:00:22:22:44:44 не помогло

запустить еще экземпляр не получиться железяка которая шлет логи «закрытая»

Но, tcp на два хоста принять не получится. Если трафик действительно зеркалится (-j TEE)

Почему же , я использую это правило часто для wireshark

по поводу настройки rsyslog , это работает, но после обновления продукта настройка переписываются производителем и приходиться лезть править снова

как настроить получение на два сервера rsyslog, настройка на хостах отпадает(там можно указать только 1 ip адрес)

В syslog-ng можно настроить любое количество получателей

создайте широковещательный интерфейс 192.168.100.3 и шлите на него логи броадкастом

Можно даже мультикаст-группу создать, если rsyslog умеет слушать мультикаст

не получиться железяка которая шлет логи «закрытая» есть в настройках только возможность указать 1 ip

Тогда другой вариант: железяка шлёт на syslog-ng, а он уже рассылает всем остальным. Но тогда появляется единая точка отказа, к сожалению.

Если использовать мультикаст для сбора логов (syslog-ng, по крайней мере, умеет), то со стороны железки это обычный UDP, т.е. проблем быть не должно.

пробовал на 192.168.100.2 правило

Вам не -j TEE, а DNAT или REDIRECT нужно на 192.168.100.2 прописывать.
Или можно на 192.168.100.2 добавить ip адрес 192.168.100.1, только заблокировать отправку arp-ответов для этого адреса. arptables или ip на другой интерфейс (lo) и /proc/sys/net/ipv4/conf/e1/arp_ignore=1). Тогда syslogd на 192.168.100.2 сможет принимать пакеты для 192.168.100.1. Но с 192.168.100.2 к 192.168.100.1 не подключиться, то есть лучше для логов выделить отдельный ip, который будет дополнительным на обоих хостах.

Всё написаное выше относится к udp.

часто для wireshark

wireshark не устанавливает tcp-соединение. Одно дело перехват tcp-пакетов и вытаскивание из них полезного содержимого (данных, передаваемых по tcp), другое дело, работа по tcp-соединению. Если приложение получает данные через tcp-сокет, то ядро будет слать в ответ ACK-пакеты. Если вы tcp-пакет отправите на два хоста и его там пример ядро, в ответ полетит два ACK-пакета, но разных...

syslogd в принципе не умеет работать как wireshark.

Вы так и не ответили на вопрос, зачем вам именно такая схема дублирования логов? Почему вы не хотите, чтобы на 192.168.100.1 процесс syslogd просто отправлял логи на 192.168.100.2?

Дак у него и сейчас единственная точка отказа. Если 192.168.100.1 отвалится, то никто на arp-запросы не ответит и железяка не будет знать куда слать пакеты.

использовать мультикаст

Тут изначально, кроме, udp ещё и tcp, непонятно, правда, реально ли железяка шлёт логи по tcp.

Дак у него и сейчас единственная точка отказа. Если 192.168.100.1 отвалится, то никто на arp-запросы не ответит и железяка не будет знать куда слать пакеты.

Мне кажется, смысл задумки с двумя серверами был в увеличении надёжности, а тогда одновременная отправка на два сервера через мультикаст или броадкаст должна подходить лучше.

Тут изначально, кроме, udp ещё и tcp, непонятно, правда, реально ли железяка шлёт логи по tcp.

Если она правда шлёт и туда, и туда, то наверняка одно и то же.

Вы так и не ответили на вопрос, зачем вам именно такая схема дублирования логов?

тестировать новые обработчики логов или правила

Почему вы не хотите, чтобы на 192.168.100.1 процесс syslogd просто отправлял логи на 192.168.100.2?

по поводу настройки rsyslog , это работает, но после обновления продукта настройка переписываются производителем и приходиться лезть править снова

а тогда одновременная отправка на два сервера через мультикаст или броадкаст должна подходить лучше.

но тогда любой в подсети сможет получать их?

В случае мультикаста роутер может иметь политики, у кого есть право на join в группу, а у кого нет. Отправить пакет в группу может кто угодно, а получить — только тот, кто сделал успешный join.

Еще вопросик: как правильней перенаправить получаемые логи на русском в Транслитерацию на английский

допустим в этот скрипт

echo $1 |sed «y/абвгдезийклмнопрстуфхъьы/abvgdezijklmnoprstufx"’y/;s/ж/zh/g;s/ш/sh/g;s/ч/ch/g;s/щ/shh/g;s/ю/yu/g;s/я/ya/g;s/э/eh/g»