cross-posted from: https://lemmy.ml/post/15968883
Hello everyone ! Nobody seems to have an answer on [email protected] (or maybe they are not interested because it’s an enteprise network community?) and [email protected] seems dead?
Anyway, If anyone could guide me or direct me to the right direction, I would really appreciate it !
TL:DR
What is encapsulated into the frame that makes everyone understand: "OHHH that’s for 10.0.0.8, your docker container on bridge network br-b1de on the veth2b interface !!! "
Hi everyone !
I’m scratching my head in finding an actual answer on how virtual networking in docker actually works (mostly on the packets/frame level) or some good documentation to improve my understanding on how everything fits together.
Because I’m probably lacking the correct network terminology I made a simple network topology of my network. Don’t hesitate to correct any network mistake.
In my scenario, my docker container with the virtual interface veth2b22c98 and the following ip (10.0.0.8) connects to bridge network br-b1de95b5ea89. When I curl, from my conntainer, lemmy.ml the packets/frame is send to my enp4s0 and goes through my wireguard tunnel to my VPN provider which sends back the packet/frame/handshake…
I probed every interface with tcpdump (enp4s0, wg0, br-b1,veth2b):
-
enp4s0: Every packet/frame is encapsulated into the wireguard protocol with my physical interface’s IP (192.168.1.30) and no DNS is visible on that interface (like expected) and sends it out to my ISP’s public IP.
-
wg0: Shows every packet/frame with the actual protocol with my wireguard’s interface IP (192.168.2.1) with the destination IP of lemmy.ml (Dst: 54.36.178.108)
-
br-b1: Shows every packet/frame with the actual protocol with my containers IP (10.0.0.8) with the destination IP of lemmy.ml (Dst: 54.36.178.108)
I know there is a mix of 2 different concepts in my scenario (wireguard tunnel and virtual networking) but I really do not understand how the frame gets back to my docker container. When I look at the frames on wg0, there is no mention of either the MacAddress of my container or the actual IP of my container.
How/when/what ? is exactly happening to my frame so that it gets to the correct target between my physical interface, virtual interface, bridge ? I mean with VLAN’s there’s a VLAN tag on the frame, so you can easily identify with Wireshark where it should go. But here, I cannot find any clue who or what is doing the magic so the frame finds it’s way back to my docker container.
What is encapsulated into the frame that makes everyone understand: "OHHH that’s for 10.0.0.8, your docker container on bridge network br-b1de on the veth2b interface !!! "
Sorry for my broken English and lack of networking terminology and thank you for those who beared with me and are willing the give me some hints/proper networking lesson.
I was a bit surprised when I checked the docker docs that there’s no mention of NAT for the bridge network driver, because that’s what’s happening.
Within your server, between the docker-bridge and your physical (and virtual wireguard) interface is a router which performs NAT (Network-Address-Translation). As a matter of fact, it’s likely happening again on the other side of the wireguard tunnel, since you’ll probably end up sharing the public IP with other ProtonVPN customers.
It’s exactly the same mechanism your internet-router uses who likely only has a single public IPv4 Address. When you open a TCP connection from your computer, the router will store the combination of (src-ip, src-port, dst-ip, dst-port) into the NAT table and rewrites the src-ip to the public IPv4 address. Once a reply packet comes from the destination, it will look into its NAT table and if it finds a match, it’ll rewrite the dst-ip to your personal machine.
This whole process can also happen twice or more times without issue. (Initiating connections from outside to inside becomes a problem though, that’s why Port-Forwarding exists).
The wireguard tunnel might add to the confusion, but see it as a separate connection that needs to be established. Once the tunnel is made, all traffic flowing through the tunnel does not need to be aware of anything underneath the tunnel.
Hey thank your for your reply :).
When you open a TCP connection from your computer, the router will store the combination of (src-ip, src-port, dst-ip, dst-port) into the NAT table and rewrites the src-ip to the public IPv4 address.
Okay, but what’s actually appended into the frame or packet that correspond to the NAT table ? There must be something specific so It knows that this is for my container on it’s IP.
But when I checked on the bridge network, there was nothing that lead me to that conclusion.
Is there anyway I could check that intern NAT table?
Also I maybe found something of interest. Could It be that the temporary open port during the TCP connection is actually the way how the frame finds his way back?
Thanks for your time !!