I have some lab hardware consisting of a Windows machine running a GUI (Machine 1) and a DSP-based controller box (Machine 2). They are connected through a direct Ethernet cable. Some network snooping reveals that the GUI talks to the controller box using TCP. The TCP connection is initiated from the GUI. The host and port to which it connects are always the same, but (unfortunately) not easily configurable:
Because some interesting information is flowing over the network connection, I want to snoop it. My idea would be to insert a Linux machine between these two machines with two NICs, and have a "snooper" program running on that machine that accepts a TCP connection from Machine 1, upon connection opens a TCP connection to Machine 2, and henceforth forwards traffic between the two sides, bi-directionally, monitoring the traffic for interesting things:
My first question would be if anyone has alternative ideas to do what I want to do. I thought of several already, such as patching the executable running on Machine 1 to connect to a different IP address (did this, and it works, but it is messy to patch an executable in the blind, and it requires work if the executable is updated), and just tapping Ethernet traffic on Machine 1 (eg using pcap) but that forces me to do TCP protocol tracing. All in all, the physical man-in-the-middle approach seems to be the least intrusive / most robust.
My second question is, how should I configure the NICs and routing on the Linux machine to make this work? The challenge here is that both 192.168.0.1 and 192.168.0.2 will exist twice, once on the man-in-the-middle machine, and once on the remote machine. I think it should be possible to implement this via some routing and/or iptables configuration on the Linux machine, but I don't know enough about that to figure out the right approach.
If anyone can nudge me in the right direction, that would be great.