hostonly and WSL2
audetto opened this issue · 12 comments
I am trying to find the simplest setup to use this on WSL2.
I have read #149 but I think it could be even easier.
Basically --hostonly
is not enough to cover WSL2.
I get
Client not allowed 172.18.88.214
even if the log has
proxy:hostonly = 1
On Windows I can see a WSL Ethernet adapter
So,
I wonder if px
could not scan all these Virtual adapters and add them to the "local" adapters directly.
The virtual adapter on the Px side is x.80.* whereas the connection is coming from x.88.* which is why Px rejects it.
the subnet mask is .240 not .255
172.18.88.* is in the networks defined by the IP+mask
Lines 412 to 417 in faaa57c
this function will return the hostname which is 172.18.80.1, but it knows nothing about the local network behind it.
is there a python way to extract the subnet mask?
The goal of --hostonly
is to allow all apps running on that same host OS to access Px even if via different interfaces. It does not equate to VMs running on the host which will have a different IP, they are a different host. WSL2 uses a VM so you will need to specify the IP or a range via --allow
like in #149 to make it work.
We want to be super careful who can authenticate via Px. --hostonly
is a shortcut to simplify that specific case. There's no way to correctly guess that the subnet is a virtual network and even if we did, the admin might not want those apps in VMs to inherit access. It has to be explicit. We could come up with another shortcut but --gateway
+ --allow
enable this already and can be very prescriptive.
The difference between "apps" and "VMs" is probably a bit blurred, especially when the doc says
This allows local apps as well as VM or container apps to use Px when in a NAT config.
but I totally understand that what I ask requires a deeper knowledge of the type of adapters each network uses and this might not be easy to extract.
The hostonly
feature is fantastic at protecting security. The problem with WSL2 is that at every reboot it will grab a new random subnet to run it's virtual network on.
If I was to open up allow to eg 172.17.0.0/16, then I'm opening myself up to potentially other people using my proxy if I happen to connect to a physical network that falls into the same range.
I'd like to see a configuration option added that allows me to specify the names of the WSL2 distros I want included as part of hostonly
and the command to execute in that distro to return it's IP address on stdout.
Then, when determining host IPs we could run wsl -l --running
on the windows side, read it's stdout and see if the distro I asked for is running.
- If it's not, no problem just skip adding it to host IPs
- If it is, execute the command given and read the IP address from that command's stdout
- If the command fails/doesn't return what looks like a valid IPv4, just skip adding it and log the error in the debug log
We would need to implement a refresh of host IPs every x seconds, similar to how proxyreload
works.
For example, a config that might look something like:
hostonly = 0
hostonlywsl2distros = [ { "distro": "Ubuntu", "command": "/home/david/get-ip.sh" } ]
This would mean at startup (and then every x seconds on a timer afterwards) we would:
- Create a buffer list of all host IPs as it currently works today
- Iterate the
hostonlywsl2distros
- Check if the given distro name is running
- If no, ignore it
- If yes, run the given command to get the IP address and add it to the buffer
- Replace the allowed hosts with the buffer
We can execute commands in a running distro with wsl
on the windows side:
wsl -d Ubuntu /home/david/get-ip.sh
Some examples of outputs:
No distros running
PS C:\Users\david> wsl -l --running
There are no running distributions.
Multiple distros running
PS C:\Users\david> wsl -l --running
Windows Subsystem for Linux Distributions:
Ubuntu (Default)
kali-linux
Getting the IP address by the command given
PS C:\Users\david> wsl -d Ubuntu /home/david/get-ip.sh
172.17.245.154
I'm open to PRs that can do this cleanly, agree randomizing the WSL2 IP will be a pain to deal with. That being said, I'm not a WSL2 user so hard to implement at this time.