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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
