I have two separate networks, one which is trusted and one which is untrusted. The trusted network contains a server.
Blue is the existing, trusted network and the big box is the server, which is connected via eth0 to the trusted network.
I now want to start using free resources on the server to host services, which are contained in docker containers, to the untrusted network (red).
I want everything that gets bound to the 0.0.0.0 to work as usual, but not to bind to eth1 and docker1. This means that nginx should be able to communicate with all interfaces except eth1 and docker1. It should not be able to communicate with the 192.168.2.0/24 subnet, which also includes the docker1 bridge. This goes for the sshd and samba as well, for any service. No device coming from 192.168.2.0/24 should be able to establish a ssh session on the server or connect via samba. No routing for 192.168.2.0/24 to and from other subnets should happen on the server.
So the server and any device on the 192.168.1.0/24 network should be able to access containers 1 to 3, but not 4 and 5. And the containers 4 and 5 should not be able to access anything on the 192.168.1.0/24 network.
I believe that it should be doable by using iptables. Also, how would I configure the docker bridge?
I lack experience with iptables and more so with docker networking, so a detailed explanation would be greatly appreciated.
(All communications between those two networks should only occur over a router. The router is using NAT so that subnet 192.168.1.0/24 can access 192.168.2.0/24 through it, but the other way around only if port forwarding on the router allows it, but that is a different (and solved) issue.)
Update: Would adding these rules this do the job?
iptables -A INPUT -i eth1 -j DROP iptables -A OUTPUT -i eth1 -j DROP iptables -A FORWARD -i eth1 -j DROP iptables -A INPUT -i docker1 -j DROP iptables -A OUTPUT -i docker1 -j DROP iptables -A FORWARD -i docker1 -j DROP iptables -A FORWARD -i eth1 -o docker1 -j ACCEPT iptables -A FORWARD -i docker1 -o eth1 -j ACCEPT
If so, how could for example container1 connect to a HTTP server running on container4, if it doesn't know that to reach 18.104.22.168 it must first exit via eth0 because trying to contact 192.168.2.10 directly will result in the packets getting dropped.