Open dkoshkin opened 1 year ago
Hey @dkoshkin, thanks for reaching out. Without --internal
, Docker creates a bridge network between the container and the host (Linux VM) to give it external access. Since adding (not entirely true - see below)--internal
removes this bridge, you no longer get access to the Wireguard tunnel that lives on the Linux VM.
Curious what your use case is using --internal
with this tool?
We use it to simulate air-gapped (specifically no egress) networks in docker.
Got it. Yeah this is a bit of an interesting case, as typically air-gap would exclude all networks, including your host (but of course, that makes dev/debugging hard).
The solution here would be to somehow create a connection only between the --internal
container and the macOS host, without passing through the Linux host's network namespace. I'll have to think more about this one.
Okay I did a deep dive on this today. This is what I discovered (for those curious):
iptables
rules:
iptables
rules are added to the Linux host:iptables -I DOCKER-ISOLATION-STAGE-1 ! -d 172.20.0.0/16 -i br-f653b152ce48 -j DROP
iptables -I DOCKER-ISOLATION-STAGE-1 ! -s 172.20.0.0/16 -o br-f653b152ce48 -j DROP
br-f653b152ce48
as the example internal bridge interface and 172.20.0.0/16
as the example subnetWe need to respect the above isolation rules for internal networks while still giving access to the Wireguard VPN. I think the solution is to add 2 iptables
rules to the Linux host:
iptables -I DOCKER-USER -o chip0 -j ACCEPT
iptables -I DOCKER-USER -i chip0 -j ACCEPT
Basically anytime a packet is headed to or from the chip0
(Wireguard) interface, accept it.
Fyi, DOCKER-USER
is a custom iptables
chain created by Docker intended to be augmented by end users. See:
https://docs.docker.com/network/iptables/
I've tested the above and it works. I think it is safe to add these rules as defaults (rather than some sort of opt-in), because this is more-or-less the default behaviour if you were to run Docker on a vanilla Linux host.
Just found this project and super excited, works great for the default or other non --internal docker networks.
But it doesn't work if I use an
--internal
networkWas wondering if its even possible for this to work with an internal network?