Re: Routing / forwarding in user space?

Grant Taylor <[email protected]> Thu, 31 Dec 2020 19:49:25 +0000
Newsgroups org.kernel.vger.lartc
Message-ID <[email protected]>
On 12/31/20 7:01 AM, Marc Roos wrote:
> I have a vm that uses some linux routing / forwarding / nat. I thought 
> maybe this is a bit overkill and convert this to a container. However 
> I am not sure if and what linux capabilities I need to grant to 
> enable eg.  forwarding. I think from security perspective it would 
> be nicer to keep this isolated from the host.

The (full / fat) VM will have a different kernel completely separate 
from the host.

The container (as I understand them) will /not/ have a different kernel, 
thus /not/ completely separate from the host.

Aside:  My understanding of ""containers is that they are a collection 
of namespaces (in one combination or another).  As such -- IMHO -- they 
are /really/ part of / controlled by the host kernel.

I typically loosely describe it to people as it's the same kernel code 
working with different sets of data.  One set of data / configuration / 
IPs / routes / etc. is the host, another is a ""container, a 3rd set is 
another container, etc.

> sysctl -w net.ipv4.ip_forward=1
> Generates
> sysctl: error setting key 'net.ipv4.ip_forward': Read-only file system

That seems like a permissions issue.

I've done what you're wanting to do with network namespaces via ip netns 
as well as network namespaces + other namespaces via unshare & nsenter. 
(I've also gotten the two types to work together.)

> Nice would be to have something running maybe in user space that is 
> similar to:

Note:  In typical containers, this is *not* /user/ space.  This *is* 
/kernel/ space, just in a different namespace with a different set of data.

> /sbin/iptables -A FORWARD -o $EXT -s 192.168.122.74/32 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> /sbin/iptables -A FORWARD -i $EXT -d 192.168.122.74/32 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> 
> # meet frontend
> /sbin/iptables -t nat -A PREROUTING -d x.x.x.x/32 -p tcp -m tcp --dport
> 444 -j DNAT --to-destination 192.168.122.74
> /sbin/iptables -t nat -A PREROUTING -d x.x.x.x/32 -p tcp -m tcp --dport
> 4443 -j DNAT --to-destination 192.168.122.74
> /sbin/iptables -t nat -A PREROUTING -d x.x.x.x/32 -p udp -m udp --dport
> 10000:20000 -j DNAT --to-destination 192.168.122.74
> 
> /sbin/iptables -t nat -A POSTROUTING -o $EXT -s 192.168.122.74 -j SNAT
> --to-source x.x.x.x

I've done many different variations on what you're wanting to do using 
""containers.  (See above.)

Docker, Podman, et al. have their own implications ~> limitations that 
make this type of thing more difficult than it should be.

It is entirely possible to what you want to do in ""containers.

> Is there anything that can do routing/nat between interfaces but runs 
> in users space???

Absolutely.  I've got nine of these ""containers running on the system 
that I'm typing this reply on.

To me, the biggest question is what type of interfaces you are using. 
Are you moving a physical interface from the host into the network 
namespace / container?  Or are you using a logical interface from the 
network namespace / container and possibly extending it to a physical in 
the host via something like bridging.  (MACVLAN and IPVLAN play in this 
area.)


-- 
Grant. . . .
unix || die
smime.p7s (application/pkcs7-signature, 3.9 KB) - not displayed