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

Enable external DNS for ipvlan-l3, and disable it for macvlan/ipvlan with no parent interface #47677

Merged
merged 4 commits into from
Apr 10, 2024

Conversation

robmry
Copy link
Contributor

@robmry robmry commented Apr 4, 2024

- What I did

The internal DNS resolver should only forward requests to external resolvers if the libnetwork.Sandbox served by the resolver has external network access (so, no forwarding for '--internal' networks).

The test for external network access was whether the Sandbox had an Endpoint with a gateway configured.

However, an ipvlan-l3 networks with external network access does not have a gateway, it has a default route bound to an interface.

Also, we document that an ipvlan/macvlan network with no parent interface is equivalent to a '--internal' network. But, in these cases, endpoints were still configured with a gateway (or a default route). So, DNS proxying would be enabled in the internal resolver (and, if the host's resolver was on a localhost address, requests to external resolvers from the host's network namespace would succeed).

Also also, CI hasn't been running most of the ipvlan tests becuase a check that the kernel supports ipvlan has been failing. However, without that check, tests pass (locally, and on the CI test runners). I want the new ipvlan/dns tests to run in CI, and it'd be weird to run only those and not the existing tests. So, removed the kernel-check.

- How I did it

Adjusted the test for enabling DNS proxying to include a check for '--internal' (as a shortcut) and, for non-internal networks, check for a default route as well as a gateway.

Disable configuration of a gateway or a default route for an ipvlan/macvlan Endpoint when no parent interface is specified. (Note that if a parent interface with no external network is supplied as '-o parent=', the gateway/default route will still be set up and external DNS proxying will be enabled. The network must be configured as '--internal' to prevent that from happening.)

Revert the changes from #39358 ... run ipvlan tests without a kernel-check (but not in rootless mode).

- How to verify it

New macvlan/ipvlan integration tests.

- Description for the changelog

- Fix a regression that prevented the internal resolver from forwarding requests from ipvlan-l3 networks to external resolvers.
- Prevent the use of external resolvers in ipvlan/macvlan networks created with no parent interface specified.

Signed-off-by: Rob Murray <rob.murray@docker.com>
@robmry robmry force-pushed the 47662_ipvlan_l3_dns branch from 70ed81b to ef26220 Compare April 4, 2024 12:27
@robmry robmry self-assigned this Apr 4, 2024
@robmry robmry added this to the 26.0.1 milestone Apr 4, 2024
@robmry robmry marked this pull request as ready for review April 4, 2024 13:27
@robmry robmry requested review from akerouanton and corhere April 4, 2024 13:27
Copy link
Member

@akerouanton akerouanton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah thaJeztah modified the milestones: 26.0.1, 27.0.0 Apr 8, 2024
@vvoland
Copy link
Contributor

vvoland commented Apr 9, 2024

@corhere PTAL

integration/network/ipvlan/ipvlan_test.go Outdated Show resolved Hide resolved
robmry added 3 commits April 10, 2024 08:50
The internal DNS resolver should only forward requests to external
resolvers if the libnetwork.Sandbox served by the resolver has external
network access (so, no forwarding for '--internal' networks).

The test for external network access was whether the Sandbox had an
Endpoint with a gateway configured.

However, an ipvlan-l3 networks with external network access does not
have a gateway, it has a default route bound to an interface.

Also, we document that an ipvlan network with no parent interface is
equivalent to a '--internal' network. But, in this case, an ipvlan-l2
network was configured with a gateway. So, DNS proxying would be enabled
in the internal resolver (and, if the host's resolver was on a localhost
address, requests to external resolvers from the host's network
namespace would succeed).

So, this change adjusts the test for enabling DNS proxying to include
a check for '--internal' (as a shortcut) and, for non-internal networks,
checks for a default route as well as a gateway. It also disables
configuration of a gateway or a default route for an ipvlan Endpoint if
no parent interface is specified.

(Note if a parent interface with no external network is supplied as
'-o parent=<dummy>', the gateway/default route will still be set up
and external DNS proxying will be enabled. The network must be
configured as '--internal' to prevent that from happening.)

Signed-off-by: Rob Murray <rob.murray@docker.com>
We document that an macvlan network with no parent interface is
equivalent to a '--internal' network. But, in this case, an macvlan
network was still configured with a gateway. So, DNS proxying would
be enabled in the internal resolver (and, if the host's resolver
was on a localhost address, requests to external resolvers from the
host's network namespace would succeed).

This change disables configuration of a gateway for a macvlan Endpoint
if no parent interface is specified.

(Note if a parent interface with no external network is supplied as
'-o parent=<dummy>', the gateway will still be set up. Documentation
will need to be updated to note that '--internal' should be used to
prevent DNS request forwarding in this case.)

Signed-off-by: Rob Murray <rob.murray@docker.com>
This reverts commit a77e147.

The ipvlan integration tests have been skipped in CI because of a check
intended to ensure the kernel has ipvlan support - which failed, but
seems to be unnecessary (probably because kernels have moved on).

Signed-off-by: Rob Murray <rob.murray@docker.com>
@robmry robmry force-pushed the 47662_ipvlan_l3_dns branch from ef26220 to 9954d7c Compare April 10, 2024 07:52
@vvoland
Copy link
Contributor

vvoland commented Apr 10, 2024

Thanks, I'll get this one in!

@vvoland vvoland merged commit 051d587 into moby:master Apr 10, 2024
126 checks passed
@robmry robmry deleted the 47662_ipvlan_l3_dns branch May 1, 2024 09:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IPVLAN L3 is not forwarding non Docker DNS requests outside of the container anymore
5 participants