Address Pools and Interfaces for Docker and WSL and Windows

Docker Desktop and WSL2 integration on Windows 10/11 "just works" in many situations but feels like magic. I needed a map of the networks and names to understand why I needed proxies, port forwarders, and projected ports. May this be useful to you also :-)

The Windows 10/11 machine in this diagram is known as Z820. This diagram is an outside-looking-in topology. There are multiple networks and different name resolutions for the same names depending on where you are in the network. In some places, the same hostname is resolved to different IPs if you use DNS vs the host table, /etc/hosts
Click to Enlarge

This diagram is a simplified version of the previous one with the WSL network and associated Linux installations removed.
Click to Enlarge

Video

The Six Networks in this diagram

The network IP ranges in the diagram above are those of the default Docker / WSL installations and can be adjusted via various mechanisms.  This is sometimes required in corporate environments where they have standard ranges for things like remote laptops and VPN adapters.
  1. Hyper-V Ethernet (WSL): The Linux WSL distributions communicate with the host over this network and through this Hyper-V switch. Note that in this picture the two WSL distributions have the same IP address as reported by the network tools in a shill on those machines
  2. Home Network (192.168.1.0): The windows Ethernet and Wi-Fi adapters are on this network.  This is the network IP that external devices use to connect to the Windows host. The network that all the devices in the office / house use and that is connected to the internet via a FIOS router.
  3. Docker Desktop Network: A network managed by Docker Desktop that acts as a bridge network between the Docker Nodes and the Windows host.  There is a virtual IP on this network that is essentially attached to the Windows host
  4. Docker Node Pool Network: This is a 2nd network managed by Docker that all of the deployed docker containers is attached too.  Every docker container has a unique IP on this network
  5. Localhost (127.0.0.1): The local loopback address on each device.  Port forwarded containers show up on this interface.  Each container must be forwarded to a different port as they all appear on the same network adapter
  6. 128.0.1.1: Debian ties this address to the host name in the /etc/hosts file.  DNS resolution will point at the ethernet address.

Other Networks

Some networks were not included in order to not clutter the diagram.  
  1. Hyper-V Ethernet (default): This switch and associated network routes were not included because they didn't show up in any of the traceroute output.
  2. Kubernetes Pods (10.1.x.x): Kubernetes manages networks for services and node pools.  It allocates those networks in the 10.1.0.0 range by default. This page does not talk bout Kubernetes networking so that is also not included.

Host Names, DNS, and Name Resolution

Windows and Linux instances use a combination of host files and DNS resolution. There are a few situations where those two actually resolve to different IP addresses.  You can see this for the name Z820 in the diagrams above.  That is the hostname for the Windows machine that all this runs upon.

WSL Linux Network Adapters

WSL Instances communicate with the Windows host over a private internal network that is attached to the Hyper-V Ethernet (WSL) vSwitch. External network devices cannot see the WSL instances unless additional networks or routes or port forwarding are in place.

Names, DNS, and Resolution

Docker ensures that host.docker.internal and gatweay.docker.internal resolve to the Windows hosts.  The WSL instances are not on the Docker Desktop network so those names resolve to the physical ethernet adapter, 192.168.1.0 in the picture above.

The two Linux WSL distributions eth0 adapters have the same IP address.  I'm not sure which one you get when you ping that address from the host.

Kali WSL distribution
┌──(joe㉿z820)-[~]
└─$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:b3:93:cc brd ff:ff:ff:ff:ff:ff
    inet 172.31.195.208/20 brd 172.31.207.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:feb3:93cc/64 scope link
       valid_lft forever preferred_lft forever

┌──(joe㉿z820)-[~]
└─$ lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux Rolling
Release:        2023.2
Codename:       kali-rolling

Ubuntu WSL distribution
joe@z820:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.31.195.208  netmask 255.255.240.0  broadcast 172.31.207.255
        inet6 fe80::215:5dff:feb3:93cc  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:b3:93:cc  txqueuelen 1000  (Ethernet)
        RX packets 18788  bytes 38889167 (38.8 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4419  bytes 347920 (347.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1239  bytes 472324 (472.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1239  bytes 472324 (472.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

joe@z820:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

Docker Desktop Network

This network is managed by Docker Desktop and acts as a bridge between the Docker Nodepools, Windows 11 Ethernet/Wi-Fi, and potentially any VPNs. The network in the diagrams above is the default network range for this and can be moved via the Docker Desktop management tool.

This network acts as a gateway for traffic coming into and out of the Node Pool networks. Communication between Docker containers and Windows or the internet transit through this network.  The diagram shows that DNS is manipulated on the docker pods so that traffic through the host goes through that IP on this network.  Traffic can be forced to the Ethernet adapter's public IP by explicitly requiring that address

I don't know what to call the 192.168.65.4 address in this diagram.  It may actually be one of the K8s control nodes as I have Kubernetes running in this Docker Desktop environment using the provided integration.

Names, DNS and Resolution

Docker ensures that host.docker.internal and gateway.docker.internal always resolve to the Windows host.  They point at the Virtual IP on the Docker network.  

Docker Address Pool for Deployed Containers

Docker allocates a separate CIDR for the deployed docker containers. This isolates the containers from the other networks.  Traffic out of the containers routes through node pool gateway to the Docker Desktop Network and then to the host or the internet.  External devices and Windows are not directly attached to this node pool network.  This is one of the reasons you have to add a localhost port exposure declaration when deploying Docker Containers.  A proxy has to be set up to transit the Docker network to the node pool network.

Names, DNS and Resolution

The node pool network uses the Docker Desktop DNS node for name resolution for anything outside the node pool. It maintains host.docker.internal and gateway.docker.internal to communicate with the Windows host. Traffic destined for the internet or other devices not on the Windows Host goes from the node pool network through the docker desktop network.

Video


References

Revision History

Created 2023 06

Comments

Post a Comment

Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Image
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time.  Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM.  You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop.  Docker Desktop has two of its own WSL modules that need to be accounted for.  You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory.  The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaults to a maximum RAM size of 5
Read more

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

Image
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Update Driver  does  not  install the RNDI
Read more

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs

Image
I wanted to access all my Azure resources without making any of them visible to the Internet.   The easiest give my local machine access to everything on my Azure Virtual Network (VNET) was to connect to it over VPN. It turns out creating Azure VPN gateways and connecting to Azure VPN endpoints is easy.  There are some subtleties in getting DNS name resolution to work that can confuse when first starting out. Setting the Stage There are a few ways to get to Azure endpoints and resources that are blocked from the internet.  We can  Create a Point-to-Site connection from our local machines to Azure Network Gateways Create a Site-to-Site network connection from our local networks to Azure Network Gateways. Use Bastion Hosts Use Cloud Shell Leave everything open to the internet. I chose a Point-to-Site (P2S) VPN connection that connects from my laptop to a VNet Gateway.  That joins my laptop
Read more