2

My network topology is as follows - enter image description here

My problem, is that the Purple Red Green and Orange PC's are actually hard coded industrial systems, and i have no possibility of changing any settings on them.

I require to intercept and manipulate the UDP packets with the addition of the interception PC.

Example - RED PC 192.168.0.20 sends a UDP packet to the purple PC. This actually arrives at my Interception PC (Ubuntu 16.04) where i receive and reply to the packet. I then construct a different message and deliver to the purple PC.

The problem is, that the network is all on the same subnet, and the kernel has no idea which NIC to send my outgoing packet as i already own the ip i am trying to forward to.

I have tried creating separate namespaces to own the NICS , and wrote several separate processes to communicate via Dbus between the namespaces, before realising they can not communicate. I can purchase more hardware if required, but im looking for suggestions about how i might achieve this outcome.

  • If the problem is just knowing which interfaces the ip addresses are on, then you can just set /32 single ip static routes. – RobotHumans Apr 13 '18 at 12:43
  • Do the red, green, and orange PCs really need to talk to the interception PC via separate NICs? Can't you put a switch there instead? – Johan Myréen Apr 13 '18 at 13:01
  • @RobotHumans - Yes i can attach a switch at this location, and forward all traffic to a different ip address at the interception PC. However i have a couple of queries - i need 192.168.0.10 still visible to the RGO pc's, and i am wondering if packets destined for the purple will still be forwarded in the wrong direction. My second query is that effectively a router is a group of nic's so i'm wondering why i cant locally achieve the same goal. I do appreciate the suggestion though and i will test this option and report back. – Wharbio Apr 13 '18 at 14:13
  • It's achievable, it's just not plug and play. It's the same reason cable installers come to your house instead of just saying "line's hot" over the phone. – RobotHumans Apr 13 '18 at 15:19
2

Yes, using a network namespace to isolate the two "same" networks would work.

For example, you have one network namespace for the right-hand side, with all the three interfaces in that namespace, and in addition, you have a bridge in the namespace and a tap for the traffic interception and forwarding. Add the tap and the three NICs to the bridge, and assign 192.168.0.10 only to the tap. Thus, no IP assignments to the NICs; only to the tap. The bridge will take care of channeling all traffic to 192.168.0.10 on the right-hand side to the tap, and all traffic to 192.168.0.{20,21,22} through the apprioriate NICs.

Write your interception program to read/write the tap (Level 2), and forward packets through stdin/stdout (unbuffered). Also write a similar simple transfer program to channel stdin/stdout packets to/from a tap (another tap), which you put in the left-hand side global namespace. The programs must forward all packets, with your interception applied to some of them.

The left-hand side namespace (the global namespace) is arranged in a corresponding way, with a bridge for the NICs and a tap, and then add all the IP addresses 192.168.0.{20,21,22} to the tap.

Next, use the dpipe program from the vde2 package (or write your own) to start the two tap connectors such that their stdin/stdout are mutually connected. With dpipe the command for this would be something like the following:

# dpipe program1 tap1 = ip netns exec RHS program2 tap2

for the effect that stdout of program1 goes to stdin of program2, and stdout of program2 goes to stdin of program1. (I've included notionally tap name arguments for the programs just for the sake of illustration)

All in all, that would be a way to intercept and transfer packets between the two namespaces without needing to mess with IP translations.

Note that the set up would work equally well with a single NIC at each side, plus a switch on the right. Thus, there is no need for two triplets of NICs, but you can get away with just two: one to the left and one to the right, plus of course a switch for the right-hand side network, which has 4 physical hosts.

  • - Thanks Ralph. i was hesitant to spend too much more time on the namespace solution without some confirmation that it can be done. I'll attempt this setup next. – Wharbio Apr 13 '18 at 14:08
  • I edited the answer to include the required "ip netns" part that makes program2 execute within the right-hand side network namespace. – Ralph Rönnquist Apr 14 '18 at 0:49
  • Just some feedback for those who helped me out, Ralph i used your advice, and after discovering network namespaces on Linux were handled per thread, i managed to merge the it into a single application, using setns() on separate threads. I created sockets per thread also, and i can now talk to each NIC separately, albeit with some small multithreading overheads. Thanks all. – Wharbio Apr 16 '18 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.