удвоить пакеты и направить в разные адреса

А в чем практический смысл такого дублирования? Сниффер?

-j TEE

смысл простой - на сервере внутренней сети сидит программка которая слушает порт 51968 и пишет в БД FireBird показания счетчиков эл энергии. Счетчики эл энергии шлют данные на определенный IP адрес.На другой промплощадке, но в этой же внутренней сети такая же БД FireBird, к ней коннектятся юзеры, чтобы по данным отчитаться. Сейчас репликация происходит 1 раз в сутки. Я и подумала, распараллелить пакеты, запустить на втором компе прогу, которая слушает порт и пишет в БД и тогда данные в обеих БД будут актуальны в любой момент времени.

-j TEE

Простите недоучку, это стандартный iptables, или надо что-то доустанавливать? Можно пример цепочки?

-j TEE в общем случае пригоден только для снифинга.

То, что вы хотите - не заработает. tcp требует установки соединения, соответственно оба сервера будут отвечать на SYN пакет в то время, как клиент ждет только один. Да и на более высоком уровне у вас наверняка там какой-то протокол реализован, а не тупое кидание пакетов с данными в порт, не требующее получения подтверждений. Вам нужен какой-то ip-proxy, который будет принимать ваши показания и сам раздавать их по нужным базам. Скорее всего его придется написать.

tcp требует установки соединения, соответственно оба сервера будут > > отвечать на SYN пакет

Там вроде UDP пакеты? Хотя вы правы конечно, счетчик офигеет если запросы и квитирования начнут двоиться, прога-то не будет сидеть сложа руки...

Дело в том, что прога закрытая, ее разработчик поставляет вместе со счетчиками. обмен идет по Ethernet. К счетчику прицеплен GSM модем и адаптер от разрабочика, куда можно вбить статический IP для остсылки данных. Я так думаю, что счетчик присылает свой ip адрес, после чего прога берет конфигурацию архивов и начинает опрашивать счетчик и писать в базу.

Ну соответственно вам либо сделать reverse-engineering протокола обмена и написать прокси, который будет правильно отвечать счетчику и раскидывать пакеты по нужным серверам, прикидываясь счетчиком для них. Либо решить вопрос на уровне БД. Второй вариант проще и стабильнее.

Да, спасибо, поняла, одна проблема, репликация средствами СУБД идет слишком долго....

а зачем вообще что-то куда-то каким-то способом нужно перекидывать? иными словами, зачем 2 базы? исключаем одну и вуаля, проблема решается не поднимая зада.)

Зависит от логики приложения в общем случае. Если разработчик когда-то построил систему с двумя базами, не факт, что всё будет работать корректно с обновлением данных на лету.

у ТС есть файрберд в который пишет софтина и еще один такой же файрберд с которым уже работают юзвери.
причина по которой юзеры не могут удовлетворять свои потребности с помощью одной базы вроде бы не раскрыты.

Совершенно верно, не раскрыты, но это не означает, что их нет. Так что это и ТС намёк подумать в эту сторону.

Технических причин нет, есть административные (процесс слияния двух организаций). Пока обязали поддерживать две базы в актуальном состоянии на разных серверах. Впоследствии естественно будет одна база и один сервер.

udp
Задача: дублировать пакеты, приходящие на порт 51968

Непонятно, это односторонний поток? Какие-то ответы должны улетать обратно? Если нет, то можно сделать что-то вроде такого:

$ socat - udp4-listen:51968,fork | tee >(socat - udp-sendto:172.16.1.223:51968) >(socat - udp-sendto:172.16.1.224:51968)

Если так не получится, можно посмотреть на https://github.com/sleinen/samplicator