Sstrhsrtj

Question:
How do I launch a program while ensuring that its network access is bound via a specific network interface?

Case:
I want to access two distinct machines with the same IP (192.168.1.1), but accessible via two different network interfaces (eth1 and eth2).

Example:

net-bind -D eth1 -exec {Program 192.168.1.1}

net-bind -D eth2 -exec {Program 192.168.1.1}

The above is an approximation of what I'd like, inspired by the hardware binding done via primusrun and optirun.

Challenge: As suggested in a related thread, the interfaces used are not chosen by the program, but rather by the kernel (Hence the pre-binding syntax in the above example).

I've found some related solutions, which are unsatisfactory. They are based on binding network interfaces via user-specific network blacklisting; i.e., running the process as a user which can only access a single specific network interface.

For Linux, this has already been answered on Superuser - How to use different network interfaces for different processes?.

The most popular answer uses an LD_PRELOAD trick to change the network binding for a program, but modern kernels support a much more flexible feature called 'network namespaces' which is exposed through the ip program. This answer shows how to use this. From my own experiments I have done the following (as root):

# Add a new namespace called test_ns

ip netns add test_ns



# Set test to use eth0, after this point eth0 is not usable by programs

# outside the namespace

ip link set eth0 netns test_ns



# Bring up eth0 inside test_ns

ip netns exec test_ns ip link set eth0 up



# Use dhcp to get an ipv4 address for eth0

ip netns exec test_ns dhclient eth0



# Ping google from inside the namespace

ip netns exec test_ns ping www.google.co.uk

It is also possible to manage network namespaces to some extent with the unshare and nsenter commands. This allows you to also create separate spaces for PIDs, users and mount points. For some more information see:

• Reliable way to jail child processes using `nsenter:`


• Namespaces in operation

I'm accepting Graeme's answer; this is simply a follow up to explain the changes I did to his suggestion to solve my issue.

Instead of binding the physical interface inside the namespace, I created a virtual network interface pair, with one end in the network namespace and one in the root. Packages are then routed via this virtual network from the namespace, to the root namespace and then to the physical interface.
- As such I'm able to run all my ordinary data transfers, and in addition start processes which can only access a specific interface.

# Create the eth0 network namespace

ip netns add eth0_ns



# Create the virtual network pair

ip link add v_eth0a type veth peer name v_eth0b



# Move v_eth0a to the eth0_ns namespace, the virtual pair is now split

# between two network namespaces.

ip link set v_eth0a netns eth0_ns



# Configure the ends of the virtual network pairs

ip netns exec eth0_ns ifconfig v_eth0a up {{NAMESPACE_IP}} netmask {{NAMESPACE_NETMASK}}

ifconfig v_eth0b up {{ROOT_NS_IP}} netmask {{ROOT_NS_NETMASK}}



# Setup routing from namespace to root

ip netns exec eth0_ns route add default gw {{ROOT_NS_IP}} dev v_eth0a



# Setup IP forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -s {{ROUTE_SOURCE}}/24 -o {{NETWORK_INTERFACE}} -j SNAT --to-source {{ROUTE_TARGET}}

Once the interfaces has been setup for eth0 and eth1, with their respective namespaces eth0_ns and eth1_ns, programs can be executed on the specified interface via;

ip netns exec eth0_ns fish

ip netns exec eth1_ns fish