76417bf763
Commit 0546d90 introduced the use of ipset to reduce the number
of rules that need to be processed per-packet, and make the code
a bit simpler.
But, docker's used on embedded kernels compiled without support
for ipset, so the change is too disruptive.
Replace the two ipset rules with a new chain that writes out the
rule's actions long-hand. So ..
This rule:
-A FORWARD -m set --match-set docker-ext-bridges-v4 dst \
-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Is transformed into a per-bridge rule in new chain DOCKER-CT:
-A DOCKER-FORWARD -j DOCKER-CT
-A DOCKER-CT -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A DOCKER-CT -o bridge1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
And:
-A FORWARD -m set --match-set docker-ext-bridges-v4 dst -j DOCKER
Is transformed into a per-bridge rule in new chain DOCKER-BRIDGE:
-A DOCKER-FORWARD -j DOCKER-BRIDGE
-A DOCKER-BRIDGE -o docker0 -j DOCKER
-A DOCKER-BRIDGE -o bridge1 -j DOCKER
Signed-off-by: Rob Murray <rob.murray@docker.com>
4.6 KiB
iptables for a new Daemon
When the daemon starts, it creates custom chains, and rules for the default bridge network.
Table filter:
{{index . "LFilter4"}}
iptables commands
{{index . "SFilter4"}}
The FORWARD chain's policy shown above is ACCEPT. However:
- For IPv4, setupIPForwarding sets the POLICY to DROP if the sysctl net.ipv4.ip_forward was not set to '1', and the daemon set it itself when an IPv4-enabled bridge network was created.
- For IPv6, similar, but for sysctls "/proc/sys/net/ipv6/conf/default/forwarding" and "/proc/sys/net/ipv6/conf/all/forwarding".
The FORWARD chain rules, explained in the order they appear in the output above, are:
- Unconditional jump to DOCKER-USER. This is set up by libnetwork, in setupUserChain. Docker won't add rules to the DOCKER-USER chain, it's only for user-defined rules. It's (mostly) kept at the top of the by deleting it and re-creating after each new network is created, while traffic may be running for other networks.
- Unconditional jump to DOCKER-FORWARD. This is set up by libnetwork, in setupUserChain.
Once the daemon has initialised, it doesn't touch these rules. Users are free to append rules to the FORWARD chain, and they'll run after DOCKER's rules (or to the DOCKER-USER chain, for rules that run before DOCKER's).
The DOCKER-FORWARD chain contains the first stage of Docker's filter rules. Initial rules are inserted at the top of the table, then not touched. Per-network rules are appended. The DOCKER-FORWARD chain rules, explained in the order they appear in the output above, are:
- Unconditional jump to DOCKER-CT.
Created during driver initialisation, in
setupIPChains. - Unconditional jump to DOCKER-ISOLATION-STAGE-1.
Also created during driver initialisation, in
setupIPChains. - Unconditional jump to DOCKER-BRIDGE.
Also created during driver initialisation, in
setupIPChains. - ACCEPT any packet leaving a network, set up when the network is created, in
setupIPTablesInternal. Note that this accepts any packet leaving the network that's made it through the DOCKER and isolation chains, whether the destination is external or another network.
The DOCKER-CT chain is an early ACCEPT for any RELATED,ESTABLISHED traffic to a docker bridge. It contains a conntrack ACCEPT rule for each bridge network.
DOCKER-BRIDGE has a rule for each bridge network, to jump to the DOCKER chain.
The DOCKER chain implements per-port/protocol filtering for each container.
The DOCKER chain has a single DROP rule for the bridge network, to drop any packets routed to the network that have not originated in the network. Added by setDefaultForwardRule. This means there is no dependency on the filter-FORWARD chain's default policy. Even if it is ACCEPT, packets will be dropped unless container ports/protocols are published.
The DOCKER-ISOLATION chains implement inter-network isolation, all (unrelated) packets are processed by these chains. The rule are inserted at the head of the chain when a network is created, in setINC.
- DOCKER-ISOLATION-STAGE-1 jumps to DOCKER-ISOLATION-STAGE-2 for any packet routed to a docker network that has not come from that docker network.
- DOCKER-ISOLATION-STAGE-2 processes all packets leaving a bridge network, packets that are destined for any other network are dropped.
Table nat:
{{index . "LNat4"}}
iptables commands
{{index . "SNat4"}}