How to natit responses to tcp connections?

Question

linux

Good afternoon!
There is a scheme Client-> Server
192.168.55.55 - client
192.168.100.246 and 192.168.49.56 - server
The client communicates with the server at 192.168.100.246:tcp:5689, you need to wrap it so that the server responds to the client by substituting source 192.168.49.56:tcp:5689 .
In nat POSTROUTING, only new connections are pulled, nat does not work to respond to incoming packets.
Don't ask why. Need so.

Answer 1

A very clumsy and risky solution to shoot yourself in the foot: stateless nat (tc filter action nat) . In your case to hang up on the interface towards the client. It doesn't care about state, tcp flags, or iptables, it just puts one address instead of the second on not all packets that match.
Something like this (not sure about correct arguments, tc syntax is scary as nuclear war)
# tc qdisc add dev eth0 root handle 1: htb
# tc filter add dev eth0 \
protocol ip parent 1: prio 10 u32 \
match ip src 192.168. 100.246/32 \
match ip protocol 6 0xff \
match ip sport 5689 0xffff \
action nat egress 192.168.100.246/32 192.168.49.56

Answer 2

well it is possible to wrap requests to other address through dnat.
Only you are sure that the client will work? He then sends a request to 192.168.100.246, and the answer from 192.168.49.56 simply does not interest him

Answer 3

let's say 192.168.49.56 hangs on eth1, 192.168.49.1 is the gateway to 192.168.55.55

iptables -t nat -A POSTROUTING -p tcp --sport 5689 -d 192.168.55.55 -o eth1 -j SNAT --to-source 192.168.49.56
ip ro add 192.168.55.55/32 via 192.168.49.1 dev eth1

here the route is completely specified (that is, other traffic is routed through eth1), but for verification,
it can be marked so that only responses from port 5689 will be driven

Answer 4

The client communicates with the server at 192.168.100.246:tcp:5689, you need to wrap it so that the server responds to the client by substituting source 192.168.49.56:tcp:5689.

The established TCP connection will not accept packets from another IP. Yes, and will not establish a 3-step connection either.
You read the difference between datagram (UDP) and streaming (TCP) networks - they are completely different networks.