-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Add chain DOCKER-FORWARD #49518
Add chain DOCKER-FORWARD #49518
Conversation
9a041f2
to
c07435c
Compare
c07435c
to
6da51b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a look and it seems okay but I'd like to take another look and play with it a bit on Monday before approving.
Will this fix fix the problem described in docker/for-linux#1521? This does not appear to be directly linked to Tailscale, though I note in the comments to the Tailscale issue that one user notes OCI as a contributing factor and 1521 was discovered and repro'd on OCI. |
Yes, it looks the same. |
Added a regression test. |
In 28.0.0, Docker appended to the FORWARD chain - breaking other applications that had appended their own rules that needed to execute after Docker's rules. Move most of Docker's rules out of the filter-FORWARD chain into a new DOCKER-FORWARD chain, so that Docker can append to DOCKER-FORWARD without affecting the order of rules in the FORWARD chain. After daemon startup inserts jumps to DOCKER-USER and DOCKER-FORWARD, the bridge driver will not touch the FORWARD chain again. DOCKER-INGRESS is still added to the FORWARD chain, if used, as it was in 27.x and earlier. Signed-off-by: Rob Murray <rob.murray@docker.com>
Signed-off-by: Rob Murray <rob.murray@docker.com>
d04ff16
to
341cafa
Compare
Rebased to resolve conflict. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
## Description - Describe new iptables chain `DOCKER-FORWARD`, which splits Docker's rules out of the main `FORWARD` chain where they were being antisocial - related to moby/moby#49518 - Update notes about IP Forwarding and the default DROP policy - Only engine < 28.0.0 allows remote access to ports published to the localhost address ## Related issues or tickets ## Reviews <!-- Notes for reviewers here --> <!-- List applicable reviews (optionally @tag reviewers) --> - [ ] Technical review - [ ] Editorial review - [ ] Product review --------- Signed-off-by: Rob Murray <rob.murray@docker.com>
- What I did
In 28.0.0, Docker appended to the FORWARD chain - breaking other applications that had appended their own rules that needed to execute after Docker's rules.
- How I did it
Move most of Docker's rules out of the filter-FORWARD chain into a new DOCKER-FORWARD chain, so that Docker can append to DOCKER-FORWARD without affecting the order of rules in the FORWARD chain.
After daemon startup inserts jumps to DOCKER-USER and DOCKER-FORWARD, the bridge driver will not touch the FORWARD chain again. DOCKER-INGRESS is still added to the FORWARD chain, if used, as it was in 27.x and earlier.
(Links to code in the generated iptables docs are all out of date ... I'll update them once this is merged and there's something to link to - haven't thought of a better way to deal with that, but I think the links are probably worth keeping.)
- How to verify it
Existing and updated tests.
New test
TestDropInForwardChain
- reliably fails without this change.To check removal of rules from the FORWARD chain on upgrade from 27.5.1 ...
Upgrade test detail ...
Networks and containers ...
27.5.1 iptables
27.5.1 - ip6tables
Dev build after upgrade from 27.5.1 - iptables
Dev build after upgrade from 27.5.1- ip6tables
Dev build started after iptables flush - iptables
Dev build started after ip6tables flush - ip6tables
- Human readable description for the release notes