Files
moby/libnetwork
Rob Murray 4d8cff7bd4 Don't skip DNAT for a routed network without userland-proxy
If the userland-proxy is running, packets from one bridge network
addressed to the host port are not DNAT'd - so that docker-proxy
can pick them up, and therefore the packet bypasses the network
isolation rules.

Without the userland-proxy, there's no way for a packet from one
bridge network to bypass the network isolation rules. So, in this
case, DNAT is not skipped - and that at-least allows packets
originating from the network that published the port to access
the host port.

Commit 0546d90 improved support for routed mode networks (allowing
nat-mode networks access to containers in routed-mode networks, as
well as just remote access).

That commit changed the "SKIP DNAT" logic, making sure DNAT was
skipped for a routed-mode network if the userland-proxy was enabled
(so, containers in routed mode networks could access ports published
by other networks).

But, it still skipped DNAT for a routed mode network if the userland
proxy was disabled - packets from the routed mode network aimed at
any other network would be dropped by the network isolation rules
anyway, and containers in a routed mode network don't need access to
ports published from that network (because, by definition, there
can't be any).

However, network isolation rules can be worked-around with a rule
in the DOCKER-USER chain, but the SKIP DNAT rule is harder to deal
with.

So, for routed-mode, only skip DNAT if the userland-proxy is
enabled (just like nat-mode networks).

Signed-off-by: Rob Murray <rob.murray@docker.com>
2025-03-10 17:15:10 +00:00
..
2024-11-12 14:02:09 +01:00
2025-03-04 13:55:46 +01:00
2024-06-27 23:18:48 +02:00
2025-02-24 17:09:09 +00:00
2025-03-04 13:55:46 +01:00
2025-02-25 15:24:25 +00:00
2025-03-04 13:55:46 +01:00
2024-09-06 21:53:09 +10:00
2024-09-06 21:53:09 +10:00
2025-01-27 14:19:19 +01:00
2024-06-27 23:18:48 +02:00
2024-09-06 21:53:09 +10:00
2024-11-12 14:02:09 +01:00

libnetwork - networking for containers

Libnetwork provides a native Go implementation for connecting containers

The goal of libnetwork is to deliver a robust Container Network Model that provides a consistent programming interface and the required network abstractions for applications.

Design

Please refer to the design for more information.

Using libnetwork

There are many networking solutions available to suit a broad range of use-cases. libnetwork uses a driver / plugin model to support all of these solutions while abstracting the complexity of the driver implementations by exposing a simple and consistent Network Model to users.

Contributing

Want to hack on libnetwork? Docker's contributions guidelines apply.

Code and documentation copyright 2015 Docker, inc. Code released under the Apache 2.0 license. Docs released under Creative commons.