Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup bridge0 and iptables automatically #24

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

wking
Copy link
Contributor

@wking wking commented Aug 16, 2015

If bridge0 doesn't exist, automatically create it, enable IPv4
forwarding, and setup a minimal MASQUERADE rule so the containers can
access the external network. Details in the individual commit
messages.

This grows the script by 7 lines (to 124 lines), but allowing most
users to not bother using brctl and iptables is probably worth it ;).

The brctl command (from bridge-utils) is an easier dependency than
requiring users to setup the bridge themselves.  Following [1].

[1]: https://docs.docker.com/articles/networking/#bridge-building
One 'ip link set' call can set all the values we need; there's no need
for a separate call for each value.

I've shifted the veth1 call to after the route and address, to avoid
putting it up before it's fully configured.  We have to add the route
after putting veth1 up though, to avoid:

  RTNETLINK answers: Network is unreachable
One less step for the user to handle on their own.  We might want to
log this change, since it has the potential to create unwanted
side-effects if the user has a permissive firewall.

If procps (from which we get sysctl) is too burdensome a dependency,
we could use:

  echo 1 > /proc/sys/net/ipv4/ip_forward
Based on [1].  With ACCEPT policies for INPUT, FORWARD, and OUTPUT in
the filter table, and PREROUTING, INPUT, OUTPUT, and POSTROUTING in
the nat table, this MASQUERADE jump is all we need.

With those permissive rules, external hosts can access the containers
by adding a route like:

  # ip route add 10.0.0.0/24 via 192.168.0.2

where 192.168.0.2 is the IP address of the Bocker host.

For more restrictive networking, you could be harsher with FORWARD on
the Bocker host and use:

  # iptables -t nat -A PREROUTING ! -i bridge0 -p tcp --dport 80 -j DNAT --to 10.0.0.3:80
  # iptables -I FORWARD -d 10.0.0.3 -p tcp --dport 80 -j ACCEPT

to forward the Bocker host's port 80 to the 10.0.0.3 container's port
80.

[1]: https://github.com/gdm85/docker-fw/blob/d9cee19989ead67e6107740869ba9c13d4ff6096/example-iptables.txt
@Fusion
Copy link

Fusion commented Aug 21, 2015

wking, do you think this should be merged with 'bocker route' in #23? The idea would be to allow the user to leave existing network configuration undisturbed if necessary.

@wking
Copy link
Contributor Author

wking commented Aug 29, 2015

On Thu, Aug 20, 2015 at 05:48:04PM -0700, Chris F Ravenscroft wrote:

wking, do you think this should be merged with 'bocker route' in
#23? The idea would be to allow
the user to leave existing network configuration undisturbed if
necessary.

This PR shouldn't be doing anything different if bridge0 already
exists 1. So I think it does leave any existing network
configuration undisturbed. Well, it will enable IPv4 forwarding,
but that was a README requirement anyway ;).

For rebasing onto #23, I'm happy to do that if #23 lands first, but
the changes in my PR are small enough that it shouldn't be too hard to
rebase #23 if this lands first. If you see some other gain to
integrating the branches ahead of time, let me know. But keeping them
small and orthogonal will probably make reviewing easier for @p8952
;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants