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