I hope this question is on-topic for this website.
So I’ve just started playing around with Windows Subsystem for Linux 2 and, after racking my brain a bit, I’ve come up with a rough idea of how the networking between the Linux VM and the Windows host is handled. Since there are few good resources online on this topic, I thought I’d outline how I suspect it works here and someone could tell me what I’ve got wrong and fill in the parts that I haven’t quit figured out:
(BTW: I know very little about networking, so don’t be surprised if this is completely wrong.)
So the VM is in it’s own network, whereby the host machine is the gateway for that network. The interesting part is this mini-network seems to have a different subnet mask than the normal home network the host is part of. The gateway (the host) also doesn’t seem to forward any packets from outside the mini-network to the VM, even though I would expect it to at least forward ICMP and other house-keeping things. Based on this, I reckon that it’s more accurate to look at the mini-network as a completely separate network, rather than a sub-network of the normal home network the host is part of. That begs the question: why did they (the people who made WSL) decide to do this?
Another thing that confuses me a little bit is outgoing traffic from the VM. When the VM opens up a TCP connection to some listener on the web, it first sends the packets to the gateway (the host). Then, the host has to somehow get those onto the normal home network, which I assume is done through some kind of port proxy thing. First of all, am I correct in assuming that such a port proxy wouldn’t be visible in a command such as netstat? Second, can it also be invisible in netsh interface portproxy show all? I tried the latter command, but it didn’t display anything. Maybe this kind of proxy is so low-level that it doesn’t show up in the normal channels?
Follow-up line of questioning for the proxy: It wouldn’t be enough to just forward the packets right? You would have to somehow forward the TCP session as a whole, so that returning packets from the remote could be tunneled back to the VM. The return direction is normally disabled on WSL (that is, you can’t access the VM from anywhere but the host machine, you can only access it from within the mini-network), but if the TCP session were proxied, it would create a path for a response to come back from the internet, which is of course necessary. Does that sort of thing exist?
A cool feature of WSL2 is that, due to the modified kernel in the Linux VM, any listener that is listening on the loopback interface (in the VM) is accessible from the host. The way this is achieved is by synchronously listening on the same port on the host loopback interface, and then tunneling the accepted connection through the VM kernel into the loopback listener. This effectively combines the two definitions of localhost (one for the VM, one for the host) into one thing. My question is: why isn’t this implemented for the reverse direction? When I listen on loopback on the host and then connect to the same port on loopback in the VM, a connection isn’t achieved. Why only tunnel one way? Is it some technical limitation?
That’s it. Help in sorting out this mess would be greatly appreciated, thank you.
